5453 страницы-дубля: как мультиязычность тихо убивает индексацию

Если на сайте включена мультиязычность, но переведена только часть страниц, движок может сгенерировать пустые копии всех остальных разделов на каждом языке. Эти копии отдают код 200 («страница существует»), но контента в них нет, а заголовок они берут от главной, и для поисковой системы это превращается в тысячи одинаковых страниц.

На собственном сайте BotClinic (botclinicco.com) таких страниц нашлось 5453. Панель Яндекс.Вебмастера при этом показывала «2 дублирующихся title», потому что она видит только то, что уже попало в индекс. Реальный масштаб оказался в 2700 раз больше.

Диагностика в Вебмастере и в Search Console строится по проиндексированным страницам, и если мусорные копии в индекс ещё не попали, то в отчёте их не будет. Вы видите «2 дубля» и считаете проблему мелкой. А робот в это время потихоньку обходит остальные тысячи.

Это ограничение принципиальное: панели показывают следствие (и с задержкой), а причину не показывают. Чтобы увидеть причину, нужно смотреть на то, что физически лежит в сборке сайта, то есть на файлы, а не на отчёты.

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

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

Получилось так, что адрес вида /en/blog/статья/ отдавал код 200, пустое тело и заголовок главной. И хуже того, на этих страницах стояли сразу два конфликтующих указания для роботов: одно запрещало индексацию (от механизма «страница не найдена»), другое разрешало (от общего шаблона). Какое из них учтёт поисковик... вопрос удачи.

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

Первая проверка самая быстрая. Сравните число страниц в сборке с числом уникальных заголовков, и если страниц 5000, а уникальных title 3000, то у вас 2000 дублей (на это уходит пара минут, и доступ к панелям не нужен).

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

Третья проверка. Загляните в историю обхода в Яндекс.Вебмастере, где видно, какие адреса робот посещал и какой код получал. Именно этот отчёт в нашем случае и показал реальную картину (и в нём нашлись другие проблемы, которых в сводке не видно).

Такие проверки входят в наш технический аудит: панельные отчёты там дополняются анализом самой сборки, потому что панели по определению отстают от реальности.

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

Для каждого раздела было явно указано, что он существует только на русском. Число страниц упало с 5482 до 5106, а групп дублирующихся заголовков стало три вместо семи, и все три безобидны: это перенаправление с корня, служебные страницы ошибок и раздел контактов, закрытый каноническим адресом.

Адреса вида /en/blog/статья/ теперь честно отдают 404 вместо ложного «страница есть». Для поисковой системы это чистый сигнал о том, что страницы не существует.

Был и отдельный нюанс. Одна страница оказалась клиентским компонентом, и задать для неё язык сборки на уровне фреймворка было нельзя (сборка падала с ошибкой), поэтому там хватило канонического адреса, который решает ту же задачу другим способом.

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

Второе это риск для оценки качества. Тысячи пустых страниц с одинаковыми заголовками выглядят как признак низкокачественного сайта. Прецедент у нас был: Яндекс исключил 3808 страниц со статусом «нет спроса», когда на сайте сгенерировали лишние комбинации. Урок тот же самый (объём без содержания вредит).

Третье это ложные сигналы для нейросетей. Языковой указатель сообщал ИИ-краулерам, что у страницы есть английская версия, они приходили и получали пустоту вместо контента, который могли бы процитировать. О том, как ИИ выбирает источники, рассказано в исследовании AI-выдачи.

Мультиязычность включается не флагом, а решением о том, какие именно страницы вы реально переводите. Всё остальное не должно существовать физически: не «закрыто от индексации», а просто не сгенерировано.

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

И главное. Сборке доверяйте больше, чем панели, ведь панель показывает то, что успел увидеть робот, а сборка показывает то, что есть на самом деле.