Каноникал на Vercel: кластеризатор отбрасывает тег и клеит блог...

Каноникал на Vercel: кластеризатор отбрасывает тег и клеит блог со спамным беттингом

Клиентский блог на 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

@MikeBlazerX

📈 "Пушки" — в @MikeBlazerPRO

Источник новости https://t.me/mikeblazerx/6728...