У агрегатора с десятками тысяч карточек товаров Google месяцами игнорирует значительную часть страниц, хотя у соседнего сайта на пару сотен страниц такой проблемы никогда не возникает. Это и есть главная сложность продвижения портала такого масштаба. Причина не в контенте и не в возрасте домена. Причина в том, что крупный портал физически не может рассчитывать на то же внимание робота, что небольшой сайт, и каждая лишняя дублирующаяся страница, кривой фильтр или забытый раздел в sitemap отбирает ресурс у страниц, которые должны попасть в поиск.
Продвижение портала строится на других принципах, чем SEO сайта-визитки или блога. Вместо «написать текст и расставить ключи» на первый план выходят индексация, архитектура разделов и борьба с дублями: три задачи, которые в нишевых гайдах по продвижению клиник или интернет-магазинов среднего размера почти не затрагиваются, потому что там счет страниц идет на сотни, а не на сотни тысяч.
Главная ошибка в работе с крупным порталом одна: лечить симптом, просадку позиций отдельной категории, без диагностики причины. А причина почти всегда лежит в обходе и индексации, а не в текстах на странице.
Почему продвижение портала отличается от SEO обычного сайта
На сайте из трехсот страниц робот Google обходит их все за считаные дни и переобходит при каждом заходе. На портале с сотнями тысяч URL такой роскоши нет: Googlebot распределяет внимание неравномерно, и часть каталога может не обновляться в индексе неделями. Любая техническая ошибка на уровне шаблона здесь не единична: один баг в генерации URL для фильтра дает не одну битую страницу, а тысячи клонов с одинаковым контентом.
Это меняет приоритеты работы. Для небольшого сайта SEO начинается с текста и семантики. Для портала или агрегатора SEO начинается с обхода: что робот видит, что он игнорирует и куда уходит его ресурс.
Краулинговый бюджет: как Google решает, что обходить
Краулинговый бюджет складывается из двух частей: скорости, с которой сервер готов отдавать страницы без перегрузки, и спроса, насколько Google считает нужным обходить сайт заново. На крупном портале обе части легко испортить, если не следить за техническим состоянием каталога.
Бюджет уходит впустую на страницы, которые не приносят пользы в индексе:
- дубли, возникшие из параметров URL, UTM-меток и сортировок;
- цепочки редиректов вместо прямых ссылок на актуальный адрес;
- страницы с кодом 200, которые фактически являются мягкими 404 (пустые категории, карточки без товара);
- медленные ответы сервера при большом количестве одновременных запросов робота;
- бесконечные комбинации фасетных фильтров с уникальными URL без реального спроса.
Прежде чем чинить структуру, стоит провести технический аудит и посмотреть логи сервера: какие разделы робот обходит регулярно, а какие игнорирует месяцами. Как устроен обход сайта в деталях, разбирает технический аудит сайта, и для крупного портала этот шаг обязателен, а не опционален.
Структура разделов: как разложить тысячи страниц без хаоса
Плоская структура, где все карточки висят прямо под главной, работает для магазина с парой сотен товаров. На портале с десятками категорий и подкатегорий без иерархии робот и пользователь одинаково теряются. Рабочий принцип: любая значимая страница каталога должна быть доступна не дальше четырех кликов от главной, а категории верхнего уровня должны вести на подкатегории через ссылки в тексте и в навигации, а не только через меню, которое робот иногда интерпретирует иначе, чем обычная ссылка.
Категории и хабы выполняют двойную роль: они удобны пользователю для навигации и одновременно передают вес ссылок вглубь каталога. Если хаб-страница появляется только в меню третьего уровня и никуда больше не ведет, часть карточек под ней фактически превращается в сироты: формально доступны, но без входящих внутренних ссылок с других разделов сайта.
Борьба с дублями: где они возникают на крупных порталах
Дубли на крупном сайте редко появляются по одной причине. Обычно это сочетание нескольких технических решений, принятых независимо друг от друга разработчиками фронтенда, бэкенда и маркетинга.
Дубли от параметров URL и UTM-меток
Каждая ссылка с рекламной меткой или параметром сортировки формально создает новый адрес с тем же содержимым. Без канонического тега на оригинальную страницу Google может начать считать такие варианты самостоятельными страницами и путаться, какую версию показывать в выдаче.
Дубли от фильтров и фасетной навигации
Агрегаторы и маркетплейсы страдают от этого больше всех: комбинации «цвет плюс размер плюс бренд» дают математически огромное число URL, из которых реальный поисковый спрос есть разве что у нескольких десятков популярных сочетаний.
Дубли от пагинации и сортировки
Страница второй, третьей и дальше в листинге категории содержит ту же логическую сущность, что и первая, просто другой кусок списка. В 2019 году Google официально подтвердил, что больше не использует rel=prev/next как сигнал для индексации: робот определяет связанные страницы пагинации самостоятельно, анализируя ссылки и структуру URL, поэтому держать эти атрибуты можно, но строить на них защиту от дублей больше нельзя.
Для каждого типа дублей нужен свой инструмент, и смешивать их не стоит:
| Метод | Когда применять | Что происходит с краулинговым бюджетом |
|---|---|---|
| Canonical на оригинал | Страница должна остаться доступной, но не участвовать в выдаче отдельно от основной версии | Робот все равно обходит дубль, бюджет расходуется, но сигналы ранжирования консолидируются |
| Noindex, follow | Страница нужна пользователю и ссылкам, но не нужна в индексе (например, страница сравнения товаров) | Обход продолжается, индексация прекращается |
| Disallow в robots.txt | Раздел не несет пользы ни пользователю, ни роботу (служебные параметры, личный кабинет, поиск по сайту) | Робот перестает заходить в раздел, бюджет освобождается для других страниц |
| Параметр в URL без canonical и noindex | Практически никогда не оправдано на крупном портале | Максимальный расход бюджета на бесполезные страницы |
Sitemap для крупных порталов: как разбить и что включать
У одного файла sitemap есть жесткое ограничение: не больше 50 000 URL и не больше 50 МБ в несжатом виде, это требование протокола sitemaps.org, которое поддерживает Google. Для сайта с миллионом карточек один файл просто не вместит каталог, поэтому нужен sitemap index, который объединяет несколько отдельных файлов, например по типам страниц: отдельно товары, отдельно категории, отдельно статьи блога.
В каждый sitemap должны попадать только страницы, которые реально нужны в индексе: с кодом ответа 200, без redirect, без noindex, в канонической версии URL. Включать туда отфильтрованные листинги или страницы с параметрами бессмысленно: это создает противоречие между sitemap и остальными сигналами на странице, и Google в такой ситуации ориентируется не на sitemap. Подробный разбор настройки файлов для обхода и индексации есть в статье про sitemap и robots.txt.
robots.txt на масштабе: что закрывать осторожно
На крупном портале соблазн закрыть в robots.txt все подряд: внутренний поиск, личный кабинет, страницы сравнения, параметры сортировки. Общий принцип разумен, но два технических нюанса легко упускают из виду. Во-первых, Google ограничивает размер файла robots.txt 500 кибибайтами, и все, что идет после этого объема, просто игнорируется: на портале с тысячами уникальных путей перечислять каждый вручную не получится, нужны маски и регулярные конструкции в правилах. Во-вторых, Google не поддерживает директиву crawl-delay: управлять скоростью обхода через robots.txt не выйдет, для этого есть только настройки в Search Console и стабильность самого сервера.
Закрывать через Disallow стоит то, что не несет пользы ни пользователю, ни роботу: служебные параметры, страницы внутреннего поиска, личные разделы. Фильтры с реальным спросом лучше оставлять открытыми и канонизировать, а не прятать целиком: потерять видимый трафик по частым запросам проще, чем его вернуть.
Внутренняя перелинковка на больших объемах
На небольшом сайте перелинковка почти случайна: ссылок мало, и даже хаотичная структура меню покрывает весь каталог. На портале с десятками тысяч страниц без системы ссылок часть контента гарантированно остается без внутренних переходов, и такие страницы индексируются хуже или не индексируются вовсе.
Работают три механики одновременно: хлебные крошки, которые показывают путь от главной до текущей страницы и дают роботу четкий сигнал об иерархии; блоки похожих товаров или статей, которые соединяют страницы одного уровня горизонтально; и ссылки из текста категорийных страниц на популярные подкатегории, а не только пункты меню. Частые ошибки в построении такой системы и как их избежать разбирает статья про внутреннюю перелинковку.
Пагинация и фасетная навигация: типичная головная боль агрегаторов
Листинг категории на второй и последующих страницах должен иметь собственный самоссылающийся canonical, а не canonical на первую страницу: это сохраняет доступ к товарам, которые показаны только в глубине списка, и не прячет их от индекса искусственно.
Фасетная навигация устроена сложнее. Комбинация из пяти фильтров с десятком значений каждый дает десятки тысяч теоретических URL, и обходить их все бессмысленно: спрос есть у малой части сочетаний. Практичный подход такой:
- выделить комбинации фильтров с реальным поисковым спросом и сделать для них отдельные индексируемые страницы с уникальным описанием;
- для остальных комбинаций использовать noindex, follow или полностью убрать их из индексируемых URL через AJAX-фильтрацию без генерации нового адреса;
- не допускать, чтобы один и тот же набор товаров был доступен по пяти разным URL одновременно.
Частые вопросы
Сколько страниц портала может проиндексировать Google?
Жесткого лимита на количество проиндексированных страниц у Google нет. Но технический предел есть у sitemap: один файл вмещает не больше 50 000 URL и 50 МБ в несжатом виде, поэтому крупному порталу нужен sitemap index из нескольких файлов, а не один гигантский документ.
Как понять, что Google реально обходит нужные разделы сайта?
Самый точный источник, лог-файлы сервера с запросами Googlebot: по ним видно, какие разделы робот посещает регулярно, а какие игнорирует неделями. Отчет об индексировании в Search Console дополняет картину статусами страниц, но без логов нельзя увидеть частоту и глубину обхода.
Что лучше для дублей: canonical или noindex?
Canonical подходит, когда страницу нужно оставить доступной, но консолидировать сигналы ранжирования с оригиналом, например при дублях с UTM-метками. Noindex с follow нужен, когда страница полезна пользователю и для ссылок, но не должна появляться в выдаче отдельно, например страница сравнения товаров.
Нужно ли закрывать все фильтры в robots.txt?
Нет. Комбинации фильтров с реальным поисковым спросом стоит оставлять открытыми и канонизировать под уникальный URL с описанием. Через Disallow закрывают только то, что не несет пользы ни пользователю, ни роботу: служебные параметры, внутренний поиск, личные разделы.
Нужны ли теги rel=prev/next для пагинации в 2026 году?
Для Google они не нужны: с 2019 года компания официально не использует rel=prev/next как сигнал индексации и определяет связанные страницы листинга по ссылкам и структуре URL самостоятельно. Для других поисковых систем и доступности эти атрибуты можно оставить, вреда от них нет.
С чего начать
Для портала или агрегатора работу стоит начинать не с текстов, а с диагностики обхода и структуры. Четыре шага, с которых это удобно начать:
- выгрузить логи сервера за пару недель и посмотреть, какие разделы Googlebot посещает часто, а какие практически не заходит;
- провести аудит дублей по шаблонам URL (фильтры, пагинация, параметры) и для каждого типа выбрать canonical, noindex или disallow;
- пересобрать sitemap по типам страниц и подключить sitemap index вместо одного большого файла;
- проверить глубину вложенности ключевых категорий и добавить хаб-страницы там, где каталог уходит глубже четырех кликов от главной.
Если самостоятельно разбирать логи сервера, настраивать sitemap index и выстраивать структуру каталога не хочется, этим занимается команда технического SEO в Neurounit.
