Критичные недочеты в архитектуре сайта – от неочевидных дублей и каноникал-хаоса до сломанной пагинации – «съедают» crawl budget и блокируют рост органического трафика. Как отмечено в материале, корень проблемы часто в неверной структуре URL, чрезмерной глубине вложенности, бесконечных фильтрах и слабой внутренней связности, что мешает роботам быстро находить и индексировать ключевые страницы.
Разберём, какие ошибки особенно опасны: дубли URL и контента, неправильные canonical и hreflang, конфликтующие правила robots.txt и sitemap, тяжелый JavaScript-рендеринг, цепочки редиректов и битые ссылки, изоляция разделов, неверная пагинация и фильтрация, несогласованность доменов и протоколов. Цель – чек-лист симптомов и решений для ускорения индексации, увеличения покрытия и устойчивого роста.
Canonical указан противоречиво: протоколы смешаны, www расходится, параметры плодят копии
Признаки проблемы видны даже без лупы: страницы «прыгают» между http/https и www/без www, в индексе соседствуют одно и то же с «?utm=», «?sort=», «?page=», а в Search Console растет группа «Дубли, Google выбрал канонический URL, отличный от заданного пользователем». Всё это – классика технических ошибок архитектуры, которая крадет потенциал роста: сканирование сайта расползается, индексация размазывается, редиректы плодят цепочки, а каноникал не синхронизирован с реальностью.
как работает canonical и где он ломается
rel=’canonical’ – это подсказка, а не приказ. Поисковик сопоставляет её с сигналами сайта: внутренними ссылками, редиректами, картой сайта, hreflang, протоколом и даже поведением пользователей. Если видит расхождение, выбирает канонический URL сам. Ошибки начинаются там, где каноникал говорит одно, 301-редирект ведёт на другое, внутренние ссылки расслаиваются по третьему, а параметры плодят копии с «пустячными» отличиями. Получается как в плохом сериале: герои те же, но сюжет распадается на параллельные ветки.
Ключевой принцип прост и строг: один адрес – один канон. Всё остальное подчиняется ему. Любое исключение надо оправдывать и документировать: иначе поисковый робот будет играть в угадайку, а вы – в бесконечную чистку дублей.
Протоколы смешаны: http против https
Самое болезненное – когда каноникал на http, а сайт фактически обслуживается по https, или наоборот. Поисковик видит две версии одного контента и вынужден выбирать. Пара гвоздей в крышку:
- каноникал указывает на http, но сервер делает 301 на https;
- часть внутренних ссылок идёт на http, часть на https;
- в sitemap.xml перемешаны протоколы;
- HSTS не включён, поэтому робот иногда получает http-ответы или смешанный контент.
Что делать: выбрать https как единственный протокол, настроить строгий 301 с http на https без цепочек, включить HSTS, перепроверить каноникал на всех шаблонах страниц, пересобрать внутренние ссылки и карту сайта. Важно, чтобы rel=’canonical’ вёл на финальный 200-ответ по https, без редиректа. Проверяйте головой и руками: curl -I http://example.com должен отдать 301 c Location на https-версию, а curl -I https://example.com – 200 и тот же адрес в canonical.
www расходится: два «домена» в одном проекте
История так же стара, как и интернет: где-то живёт https://www.example.com, где-то – https://example.com, рел canonical прыгает между ними, а 301 иногда ведёт туда‑сюда. Поисковики это терпеть не любят, потому что вся связность сигналов рушится. Для пользователя разницы почти нет, а для робота – это две разные сущности.
Что делать: принять волевое решение, какой хост основной (с www или без), и принудительно свести всё к нему. Настроить 301 на уровень сервера: с «неосновного» хоста на «основной» с сохранением пути и параметров. Внутренние ссылки, каноникал и карта сайта должны строго указывать на основной хост. Не забывайте про поддомены и CDN: там часто всплывают альтернативные хосты в ссылках на изображения и стили, и робот тоже их видит.
Параметры плодят копии: utm, сортировки, фильтры
Фасетная навигация, «умные» сортировки, трекинговые хвосты – всё это рождает тьму вариантов URL. Примеры: ?utm_source=…, ?sort=price_asc, ?view=grid, ?color=blue&size=m. Для человека различия мелкие, для робота – это новые страницы. Индексация расползается на нецелевые варианты, а «чистые» адреса проседают.
Базовая стратегия выглядит так:
- канонизируйте параметры к «чистой» версии без трекинга и без сортировок, которые не меняют смысл контента;
- для фильтров, создающих уникальные подборки с спросом, разрешайте индексацию осознанно и задавайте каноникал на саму себя; для «служебных» фильтров – каноникал на базовую категорию;
- utm-параметры лучше отрезать 301-редиректом или игнорировать на уровне приложения, чтобы не плодить URL; каноникал на «чистую» версию обязателен;
- не закрывайте параметрические URL robots.txt вслепую: если робот не может видеть страницу, он не сможет учесть canonical с неё;
- внутренние ссылки должны вести на канонические адреса: никогда не ссылаться из меню и блоков на сортированные/utm-версии.
У Google больше нет инструмента управления параметрами, поэтому архитектурная дисциплина важнее прежнего. У Яндекса подход тоже сместился: ставка на сигналы сайта и явную консистентность, а не на «магические» директивы. Чем меньше противоречий, тем быстрее сканирование сайта входит в ритм.
Редиректы и canonical: союзники, но без бардака
Частая беда – canonical указывает на адрес, который сам редиректит. Еще хуже – указывает на 404/410 или в редирект-цепочку. Поисковик видит слабый сигнал и предпочитает выбрать каноник сам. Есть три «золотых» правила:
- канонический URL должен отдавать 200 без редиректов;
- если страница окончательно переехала, используйте 301 и обновите canonical на всех страницах, которые на неё ссылаются;
- редирект-цепочки длиннее одного прыжка – сигнал к пересборке ссылок и карт карт.
Не пытайтесь «лечить» несоответствия canonical вместо 301 там, где реальные адреса изменились: поисковик будет сомневаться и тратить краулинг на уточнения.
Карта сайта и hreflang: синхронизируемся
В sitemap.xml должны жить только канонические URL. Любая примесь неканонических адресов – и робот получает смешанные сигналы. Для hreflang правило не менее жёсткое: каждая языковая версия должна ссылаться каноникалом на саму себя, а hreflang-связи строятся между каноническими страницами. Любые перекрёстные каноникалы между языками – стоп‑сигнал к переобходу и потере доверия.
Технические тонкости, которые часто забывают
- используйте абсолютные URL в canonical: относительные адреса иногда интерпретируются неожиданно при нестандартных заголовках или базовых путях;
- только один canonical на страницу: дубли в head или разные указания из HTML и HTTP-заголовков – конфликт;
- регистр в путях и слеш на конце – это разные URL для робота: решите раз и навсегда, «/catalog» или «/catalog/», и держите линию;
- canonical на страницу с noindex или закрытую robots.txt – это почти как шептать в выключенный микрофон;
- для PDF и других не-HTML ресурсов используйте Link: <...; rel='canonical'> в HTTP-заголовках;
- на SPA и рендере через JS canonical должен попадать в итоговый HTML на стороне сервера или в prerender: иначе робот его просто не увидит.
Как диагностировать проблему быстро
- прогоните сайт краулером (Screaming Frog, Sitebulb): выгрузите столбцы Address, Status Code, Canonical Link Element 1, Canonical Status Code, Protocol, www;
- сегментируйте: http vs https, www vs без www, параметры; проверьте, чтобы canonical в каждой группе указывал на единый финальный 200;
- поймайте редирект-цепочки и каноникалы, ведущие на 3xx/4xx/5xx;
- сверьте sitemap.xml: только канонические, без