Поиск страниц 404 на сайте: как найти и что с ними делать

Почему недостаточно открыть несколько адресов вручную

Поиск страниц 404 на сайте начинается не с проверки случайных URL, а со сбора адресов из разных источников. Обычный обход по ссылкам обнаружит только те мёртвые страницы, на которые можно перейти с других страниц сайта. Изолированные адреса, старые посадочные страницы и URL с ошибками в параметрах при таком обходе останутся незамеченными.

Важно различать сам несуществующий URL и источник проблемы. Например, адрес /catalog/stul-12/ может закономерно отдавать 404 после удаления товара. Исправлять нужно не только ответ сервера, но и ведущую на этот адрес ссылку в меню, карточке категории, статье или XML-карте.

Эта задача относится именно к ошибке 404 и мёртвым страницам. Она не заменяет полный аудит всех кодов ответа и не предназначена для диагностики серверной ошибки 500: у неё другие причины и порядок расследования.

Откуда собрать URL для проверки

Полного списка адресов обычно нет в одном месте. Чем больше независимых источников использовано, тем выше шанс найти устаревшие и потерянные страницы.

• Внутренний обход сайта. Соберите ссылки из навигации, основного текста, карточек, пагинации, хлебных крошек, тегов link и других доступных элементов.
• XML-карты сайта. Каждый включённый в sitemap URL должен открываться и соответствовать назначению карты. Адреса с 404 из неё удаляют либо восстанавливают.
• Системы веб-аналитики. Отчёты по страницам входа помогают найти несуществующие URL, на которые ещё приходят посетители.
• Панели для вебмастеров. Отчёты поисковых систем могут содержать ранее известные им адреса, которых уже нет в текущей структуре.
• Журналы запросов сервера. Если они доступны, отфильтруйте запросы с ответом 404 и сгруппируйте их по URL, источнику перехода и частоте.
• Списки после миграции. Сопоставьте адреса старой и новой версии сайта, особенно если менялись домен, структура каталогов или правила формирования URL.

Полученный перечень следует нормализовать: привести хост и протокол к единому виду, убрать фрагменты после #, отдельно учесть параметры запроса и удалить точные дубликаты. При этом нельзя без анализа считать одинаковыми URL, различающиеся регистром, завершающим слешем или параметрами: сервер может обрабатывать их по-разному.

Диагностический алгоритм

1. Выполните запрос к каждому адресу

Для первичной проверки удобно запросить заголовки командой:

curl -I https://example.ru/nesushchestvuyushchaya-stranitsa/

Однако запрос HEAD не всегда обрабатывается так же, как обычный GET. Если результат выглядит необычно, повторите проверку полноценным запросом:

curl -sS -o /dev/null -D - https://example.ru/nesushchestvuyushchaya-stranitsa/

Фиксируйте исходный URL, конечный URL после переходов, цепочку редиректов и итоговый HTTP-код. Проверяйте адрес без авторизации и специальных cookies, то есть в условиях, близких к визиту нового пользователя или робота.

2. Убедитесь, что это настоящий ответ 404

Надпись «страница не найдена» в браузере ещё ничего не доказывает. Иногда сервер показывает шаблон ошибки, но возвращает код 200 OK. Это «мягкая 404»: URL фактически не содержит полезной страницы, однако технически выглядит успешным. Обратная ситуация тоже возможна — полезный контент отображается вместе с кодом 404 из-за ошибки маршрутизации.

Проверяемый критерий простой: для действительно отсутствующего ресурса сервер должен вернуть 404 Not Found или, если удаление окончательное и это осознанное решение, 410 Gone. Страница ошибки должна ясно сообщать о ситуации и помогать продолжить путь, но её оформление не меняет HTTP-код.

3. Найдите источник каждого мёртвого адреса

Для URL с 404 определите, откуда он получен. Внутренняя ссылка требует исправления на странице-доноре. Запись в sitemap требует обновления карты. Переходы из внешних источников могут стать основанием для редиректа, если существует точная смысловая замена.

4. Определите назначение удалённой страницы

Сравните адрес с текущей структурой, резервной копией, данными аналитики или старой выгрузкой. Нужно понять, была ли страница удалена намеренно, перенесена, переименована либо никогда не существовала. Без этого нельзя безопасно выбирать между восстановлением, перенаправлением и сохранением 404.

Что делать с найденными страницами

Редирект на главную страницу не является универсальным решением. Если пользователь запросил конкретный товар, документ или статью, переход на главную скрывает причину ошибки и не даёт ожидаемого ответа. Перенаправление оправдано только при наличии содержательно подходящей замены.

Чек-лист повторной проверки

• Целевой URL возвращает ожидаемый код при запросе без авторизации.
• Редирект, если он нужен, ведёт сразу на конечную релевантную страницу.
• Внутренние ссылки больше не указывают на удалённый адрес.
• URL с 404 исключён из XML-карты и других автоматически формируемых списков.
• Канонический адрес, альтернативные языковые ссылки и метаданные не ссылаются на несуществующую страницу.
• Шаблон 404 содержит понятное сообщение, ссылку на главную и доступную навигацию.
• После изменений выполнен новый обход, а не только ручная проверка исправленного URL.

Типовые ошибки при обработке 404

Массовый редирект всех ошибок в один раздел. Он создаёт ложное соответствие и затрудняет обнаружение битых ссылок. Сначала классифицируйте URL, затем назначайте замену индивидуально или по обоснованному правилу.

Исправление только страницы ошибки. Красивый шаблон улучшает навигацию, но не устраняет неверные ссылки и записи в sitemap.

Проверка только HTML-ссылок. Мёртвые адреса могут находиться в канонических ссылках, структурированных элементах шаблона, XML-карте или формироваться скриптами.

Игнорирование цепочек переходов. Схема «старый URL → промежуточный URL → новый URL» сложнее сопровождать. Если известен конечный адрес, лучше настроить прямой переход.

Удаление корректной 404. Не каждый отсутствующий URL нужно восстанавливать. Если адрес ошибочен, не имеет внутренних ссылок и подходящей замены, честный ответ 404 остаётся нормальным результатом.

Границы метода

Обход публичной части сайта не гарантирует обнаружение каждого когда-либо существовавшего адреса. Он не видит страницы без входящих ссылок, закрытые авторизацией области и URL, известные только внешним системам. Поэтому результаты обхода полезно объединять с картами сайта, аналитикой, панелями вебмастеров и серверными журналами.

Проверка также показывает состояние на конкретный момент. Динамически создаваемые ссылки, временные сбои и различия между пользовательскими агентами требуют повторного запроса. Если сервер отвечает 403, 429 или 500, такой адрес нельзя автоматически записывать в 404: это отдельное состояние, которое нужно исследовать своим методом.

SiteVisor работает с публичным URL без доступа к CMS и проверяет технические, SEO/GEO и конверсионные сигналы. Такая внешняя проверка помогает увидеть страницу с позиции доступного извне ресурса, но не заменяет анализ закрытых данных CMS или журналов сервера. Для первичной оценки можно запустить бесплатную проверку, а дополнительные практические материалы собраны в блоге SiteVisor.

Итог

Надёжный поиск страниц 404 на сайте состоит из четырёх этапов: собрать URL из нескольких источников, проверить фактический HTTP-ответ, установить происхождение каждого адреса и выбрать действие по смыслу удалённой страницы. Нужный материал восстанавливают, перенесённый направляют на точную замену, а окончательно удалённый оставляют с корректным кодом и исключают из внутренней структуры.

Работа считается завершённой не после настройки редиректа, а после повторного обхода. Именно он подтверждает, что внутренние ссылки и карта сайта обновлены, цепочки не появились, а отсутствующие ресурсы возвращают ожидаемый код.