Нужен ли поддомен для статей и не помешает ли блог коммерческим страницам?

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

Поддомен не даёт отдельного SEO-преимущества

Google прямо указывает: с точки зрения индексирования и ранжирования поисковик не отдаёт предпочтения ни подпапкам, ни поддоменам. Выбирать предлагается тот вариант, который проще организовывать и поддерживать.

Поэтому схема blog.example.ru не получает подтверждённого преимущества только потому, что статьи вынесены на отдельный хост. Аналогично нет специального бонуса за сам факт использования example.ru/articles/.

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

Поддомен оправдан, когда для него существует отдельная задача: независимая платформа, инфраструктура, продукт, региональная или языковая версия. У Яндекса различие ещё заметнее: Яндекс считает поддомен отдельным сайтом в Вебмастере, а в документации среди типичных сценариев использования поддоменов приводит региональные и языковые версии.

Информационный раздел не «размывает коммерческость» домена автоматически

Подтверждённого правила вида «много информационных страниц ухудшает коммерческое ранжирование домена» нет.

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

Поэтому считать нужно не соотношение коммерческих и информационных URL, а качество самого массива:

• статьи относятся к тематике агрегатора;
• закрывают реальные информационные задачи его аудитории;
• не являются массовыми пересказами SERP;
• не создаются только потому, что по теме удалось собрать ключи;
• не дублируют коммерческие посадочные по назначению.

Google отдельно относит массовое создание страниц без существенной пользы пользователю к scaled content abuse, независимо от того, создаётся такой контент людьми или автоматизированно.

Что действительно может создать проблемы

Первый риск — каннибализация. Она возникает, когда информационная и коммерческая страницы начинают конкурировать за один и тот же интент.

Например:

купить промышленный насос → категория или каталог;

как выбрать промышленный насос → информационная статья.

Если обе страницы фактически отвечают на один вопрос, проблема не решается переносом статьи на поддомен. Нужно развести назначение URL, содержание и семантические кластеры.

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

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

Третий риск — масштаб. Для обычного сайта crawl budget здесь вообще не должен быть главным аргументом. Актуальная документация Google адресует отдельную оптимизацию crawl budget в первую очередь сайтам примерно от миллиона URL либо ресурсам от 10 000 URL с очень быстрым ежедневным обновлением; сами значения Google называет ориентировочными.

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

Но создавать поддомен специально ради crawl budget без реальной проблемы с обходом — лечение проблемы, которой может не существовать.

Какую архитектуру выбрать

Если статьи относятся к тем же товарам, услугам и задачам аудитории, я бы использовал:

example.ru/catalog/ — коммерческая часть;

example.ru/articles/ — информационная часть.

Поддомен выбирал бы только при объективной необходимости отделить проект технически, организационно, регионально или по продукту.

После запуска проверять стоит не «стал ли блог слишком большим», а конкретные симптомы:

1. Какой URL получает показы и позиции по каждому кластеру запросов.
2. Не переключается ли выдача между статьёй и коммерческой страницей по одному интенту.
3. Индексируются ли новые полезные статьи.
4. Нет ли большого массива страниц в состояниях Discovered — currently not indexed и других признаков проблем с индексированием.
5. Для крупного агрегатора — не тратится ли обход на дубли, фильтры и малоценные URL вместо важных коммерческих и информационных страниц.

Если этих проблем нет, сам по себе рост тематического информационного раздела не является причиной переносить статьи на поддомен.