Клиентский блог на
Vercel с headless CMS нормально проиндексировал большую часть статей, но на двух URL алгоритм отбросил собственный rel=canonical сайта и выбрал левый спамный беттинг-домен в качестве канонического.Этот паттерн не единичный.
На форумах
Search Central висят аналогичные кейсы, включая тайский телеканал, чей каноникал перехватили по той же схеме — и это тоже была сборка на Next.js.Лучшее из доступных объяснений (пока не проверенное): такие страницы выдают ошибку, но при этом отдают код
200, после чего кластеризатор дублей Google схлопывает несколько не связанных сайтов в один выбранный каноникал.Второй возможный триггер — клиентский рендеринг:
Next.js может подтягивать каноникал уже после начальной загрузки, так что тег существует в отрендеренном DOM, но Гуглобот не видит его в сыром HTML.Эта разница определяет диагноз — чекай пострадавшие урлы через просмотр кода, а не через инспектор элементов.
Инспектор элементов покажет
DOM после гидратации и радостно подтвердит наличие каноникала, который Google так и не получил.Если тега нет в сыром
HTML, фикс должен быть на стороне сервера, а не через очередную правку тега.Тайминги краулинга только усугубляют путаницу.
Пострадавшая страница последний раз сканировалась 14 августа, в релизное окно, когда внутренняя перелинковка еще была сломана, поэтому сохраненный Гуглом каноникал отражает состояние страницы, которого в лайве уже нет.
Повторное объявление каноникала ничего не изменит, пока не пройдет свежий краул.
Рычаг восстановления — это форсирование переобхода, а не переписывание тега.
Именно заливка внутренних ссылок на пострадавшие урлы сдвинула дело с мертвой точки: один из двух
URL восстановился, как только поправили перелинковку и страница ушла на рекраул.Инсайты комьюнити
— Прежде чем винить тег каноникала, убедись, что рекраул вообще может отработать. Обнови контент на странице, чтобы изменения были фактическими, затем проверь кеширование на баг с
if-modified-since, из-за которого Гуглоботу уходит неизмененный ответ — иначе принудительный обход ничего не обновит. Запараллель это с проверкой пострадавших URL в GSC, чтобы подтвердить индексацию и выбор каноникала, изолируя проблему — происходит ли вообще что-то специфичное для Google.—
Chrome-расширение Detailed SEO выводит фактический URL и URL rel=canonical рядом на первой вкладке обзора — это быстрый способ чекать по каждому урлу, отображается ли чужой каноникал как заявленный.— Если сайт, который выбрал Google, копирует контент, эскалировать проблему нужно
CDN-провайдеру или хостеру этого сайта, а не его владельцу. Хостеры и CDN обычно реагируют быстрее.— Неожиданные спам-каноникалы также считываются как сигнал взлома, поэтому первая ветка диагностики — это проверка
WordPress на хак. Стек Vercel плюс headless CMS без явных признаков компрометации отбрасывает эту ветку — хотя, поскольку секьюрити-чек от разработчиков еще не проведен, это скорее отложенное исключение, чем окончательно закрытое.— Усиление заголовков — смежный защитный шаг: добавь секьюрити-хидеры вроде
HSTS и проаудируй текущий набор через тест MDN HTTP Observatory на https://developer.mozilla.org/en-US/observatory#Canonical #TechnicalSEO #Indexing
@MikeBlazerX
📈 "Пушки" — в @MikeBlazerPRO