Ржанский Д.

Какую структуру выбрать для международного B2B-сайта?

Как организовать направления и языковые версии крупного международного B2B-сайта: сравнение подпапок, поддоменов и отдельных доменов с учётом ссылочного профиля и миграции.

Дмитрий Ржанский Дмитрий Ржанский 1 просмотров

Для описанного сайта базовый выбор — вариант №2: развивать направления внутри основного site.com, а если технических ограничений нет, я бы пошёл ещё дальше и языковые версии тоже разместил в каталогах вида site.com/de/direction/, site.com/fr/direction/, site.com/en/direction/.

То есть из предложенных вариантов порядок такой:

  1. Основной домен + подпапки — предпочтительный вариант.
  2. Поддомены направлений — допустимы при реальной необходимости разделить проекты.
  3. Отдельные новые домены — худший вариант для этой исходной ситуации, если направления остаются частями одной компании и одного бренда.

Почему имеет смысл собирать направления на site.com

Главное преимущество существующего site.com — не абстрактный «возраст домена» и не сторонние DR/DA, а уже существующий сайт с большим количеством известных Google URL, входящих ссылок и внутренней ссылочной структурой.

Google анализирует связи между страницами, включая ссылочные сигналы, а внутренние ссылки помогают находить страницы и понимать отношения между ними. При этом ранжирование в основном происходит на уровне отдельных страниц, хотя используются и некоторые сигналы уровня сайта.

Поэтому представление, будто новая страница автоматически получает всю «силу домена», слишком упрощено. Но новый раздел на site.com можно непосредственно включить в существующий внутренний граф ссылок и связать с уже сильными страницами сайта.

У anothersite.com такой связи по определению нет. Если поставить на него ссылку из навигации site.com, Google увидит обычную ссылку на другой сайт. Такая ссылка может передавать сигналы, но она не превращает anothersite.com в раздел site.com и не переносит на него весь существующий ссылочный профиль основного сайта.

Поэтому создавать anothersite1.com, anothersite2.com и далее только ради разделения направлений обычно означает искусственно распределять контент, внешние ссылки и дальнейшее продвижение между несколькими самостоятельными сайтами.

Подпапки против поддоменов

Здесь нельзя утверждать, что Google имеет официальный алгоритмический бонус именно для подпапок. Google умеет работать и с поддоменами, и с подкаталогами.

Поэтому разницу между:

site.com/direction/

и:

direction.site.com/

не следует описывать как гарантированный SEO-бонус первого варианта.

Но в данном проекте у подпапок меньше неоправданной сложности. Все направления принадлежат одной компании, работают на одном основном домене и могут использовать единую архитектуру, навигацию и внутреннюю перелинковку. Создавать отдельный hostname для каждого направления просто потому, что это технически возможно, смысла нет.

Поддомены оправданы, когда разделение существует не только в URL. Например, направление работает на другом техническом стеке, управляется отдельной командой, представляет существенно другой сервис или по инфраструктурным причинам должно существовать независимо.

Конструкция вроде:

it.direction.site.com

технически рабочая, но для обычного корпоративного сайта она добавляет ещё один уровень сегментации без очевидной SEO-выгоды.

Языки и регионы тоже необязательно выносить на поддомены

Для международной структуры допустимы разные варианты:

example.de

de.example.com

example.com/de/

Поддомены и подпапки технически нормальны. Но для .com подпапки обычно проще в настройке, поддержке и дальнейшей консолидации структуры.

Поэтому вместо:

de.site.com/direction/

fr.site.com/direction/

при отсутствии технической причины я бы использовал:

site.com/de/direction/

site.com/fr/direction/

Если английская версия является основной, допустима и структура:

site.com/direction/

site.com/de/direction/

site.com/fr/direction/

Сам URL при этом не заменяет hreflang. Для языковых и региональных вариантов нужны отдельные URL и корректная связь соответствующих версий страниц между собой.

Также не стоит считать de в hostname или каталоге достаточным указанием языка. Язык страницы определяется прежде всего по содержимому, а структура URL и hreflang помогают поисковой системе правильно сопоставлять локализованные версии.

Что делать с уже существующим хаосом

Я бы проектировал конечную архитектуру примерно так:

site.com/en/direction-a/

site.com/en/direction-b/

site.com/de/direction-a/

site.com/de/direction-b/

site.com/fr/direction-a/

а существующие направления постепенно переносил бы в неё с текущих поддоменов и слабых отдельных доменов.

Для существующих URL это уже полноценная миграция. Нужны однозначные постоянные редиректы старый URL → соответствующий новый URL, обновление внутренних ссылок, canonical, hreflang и sitemap.

При крупных переносах лучше не менять одновременно всё подряд. Если одновременно изменить домен, структуру URL, CMS, шаблоны, контент и внутреннюю перелинковку, потом будет сложно понять причину возможной просадки. Временные колебания при миграции нормальны, пока Google повторно обходит и переобрабатывает URL.

Исключение — отдельный домен, который уже сам стал сильным самостоятельным сайтом: имеет собственные хорошие внешние ссылки, поисковый спрос по бренду, значимый органический трафик или фактически представляет отдельный бизнес. Такой сайт не стоит автоматически уничтожать только ради архитектурной чистоты. Сначала нужно сравнить ценность его текущего присутствия с преимуществами консолидации.

Для новых направлений такого исключения нет. Если это подразделения одной компании и отдельная инфраструктура им не требуется, создавать под каждое новый домен или новый поддомен — лишнее дробление.

Для исходных условий наиболее рациональная конечная модель — один сильный site.com, направления в подпапках и, по возможности, языки и регионы тоже в подпапках. Поддомены оставить для случаев, когда разделение продиктовано бизнесом или инфраструктурой, а отдельные домены — для действительно самостоятельных брендов, компаний или страновых проектов, а не как стандартный способ расширения структуры.

Разобрать проблему на вашем сайте

Опишите проблему — найду вероятную причину и предложу понятный план исправлений без лишних работ.

Связаться