Десктоп отдает 404, мобилка возвращает 200 — mobile-first...

Десктоп отдает 404, мобилка возвращает 200 — mobile-first краулер держит мертвый урл в индексе

Урл, который начал отдавать 404 семь месяцев назад, все еще может ранжироваться.

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

Первым делом проверяй код ответа на обоих рендерах: страница может отдавать 404 на десктопе, но при этом возвращать 200 на мобилке.

Поскольку Google сканирует в режиме mobile-first, этот 200 — единственный ответ, который имеет значение.

Получается, с точки зрения индекса страница никуда не пропадала.

Одна внутренняя ссылка усугубляет ситуацию.

Единственного упоминания с родительской страницы FAQ достаточно, чтобы поддерживать урл в живых — гуглобот переходит по ссылке, решает, что конечный адрес стоит пересканировать, и продолжает его подтверждать.

Даже один входящий путь удерживает незначительный урл в ротации.

Дальше удаление делится по целям.

Для долгосрочного сноса работает noindex или честный 404/410, причем разницы в скорости между ними обычно нет.

Джон Мюллер отмечает: инструмент удаления — это рычаг, чтобы снести что-то быстро, тогда как код ответа или noindex фиксируют результат намертво.

Железобетонное решение бьет по ссылке, а не только по коду ответа.

Если удалить ту единственную ссылку из FAQ, путь обнаружения уничтожается полностью, и гуглобот теряет причину для повторного визита.

Альтернатива — изменить ссылку и закинуть запрос на удаление в GSC; в обоих случаях урл быстро вылетает.

Один нюанс, который скрывает сам статус-код: пока мобильный эндпоинт продолжает отдавать 200, отдача 410 или 404 чисто для десктопа не меняет ровным счетом ничего, потому что mobile-first краулер этого просто не видит.

@MikeBlazerX

⚠️ Закрытый канал: @MikeBlazerPRO

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