Каноникал на 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
#Canonical #TechnicalSEO #Indexing
@MikeBlazerX
📈 "Пушки" — в @MikeBlazerPRO
Клиентский блог на 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