Десктоп отдает 404, мобилка возвращает 200 — mobile-first краулер держит мертвый урл в индексе
Урл, который начал отдавать 404 семь месяцев назад, все еще может ранжироваться.
Причина не в прошедшем времени, а в том, что гуглобот фактически получает при скачивании страницы.
Первым делом проверяй код ответа на обоих рендерах: страница может отдавать 404 на десктопе, но при этом возвращать 200 на мобилке.
Поскольку Google сканирует в режиме mobile-first, этот 200 — единственный ответ, который имеет значение.
Получается, с точки зрения индекса страница никуда не пропадала.
Одна внутренняя ссылка усугубляет ситуацию.
Единственного упоминания с родительской страницы FAQ достаточно, чтобы поддерживать урл в живых — гуглобот переходит по ссылке, решает, что конечный адрес стоит пересканировать, и продолжает его подтверждать.
Даже один входящий путь удерживает незначительный урл в ротации.
Дальше удаление делится по целям.
Для долгосрочного сноса работает noindex или честный 404/410, причем разницы в скорости между ними обычно нет.
Джон Мюллер отмечает: инструмент удаления — это рычаг, чтобы снести что-то быстро, тогда как код ответа или noindex фиксируют результат намертво.
Железобетонное решение бьет по ссылке, а не только по коду ответа.
Если удалить ту единственную ссылку из FAQ, путь обнаружения уничтожается полностью, и гуглобот теряет причину для повторного визита.
Альтернатива — изменить ссылку и закинуть запрос на удаление в GSC; в обоих случаях урл быстро вылетает.
Один нюанс, который скрывает сам статус-код: пока мобильный эндпоинт продолжает отдавать 200, отдача 410 или 404 чисто для десктопа не меняет ровным счетом ничего, потому что mobile-first краулер этого просто не видит.
#Crawling #Mobile #404Errors
@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO