В sitemap попали редиректы и 404: как сверить канонические URL

Порядок сверки URL внутри sitemap с HTTP-ответами и canonical. Что заменить, восстановить или исключить и как не вернуть ошибки при следующей выгрузке.

Если в sitemap попали страницы с редиректом и 404, исправляйте список URL в генераторе карты: замените переехавшие адреса актуальными, а окончательно удалённые исключите. Сначала убедитесь, что ошибка реальна: браузер может незаметно пройти редирект, а отчёт поисковика — показывать прежний результат.

Рабочий порядок для вебмастера: выгрузить адреса из карты, проверить первый и конечный HTTP-ответ, сверить содержимое и canonical, затем повторить проверку после новой генерации. Доступность самого sitemap ещё не означает исправность перечисленных страниц.

1. Соберите таблицу адресов из действующей карты

Скачайте публичную версию sitemap без авторизации. Если это индекс карт, разберите дочерние файлы: адрес дочерней карты и адрес страницы — разные объекты проверки.

Извлеките значения loc XML-парсером или краулером с поддержкой Sitemap. Не делите XML по строкам: генератор может записать весь документ одной строкой. Если файл не разбирается или вместо него приходит заглушка, сначала устраните эту проблему; здесь рассматриваем уже читаемую карту.

Для каждой страницы заведите строку:

| URL из loc | Первый код | Конечный URL и код | Canonical | Решение | | --- | --- | --- | --- | --- | | Старый адрес | 301 | Новый адрес, 200 | Новый адрес | Заменить loc | | Удалённый адрес | 404 | Тот же адрес, 404 | — | Проверить удаление | | Действующий адрес | 200 | Тот же адрес, 200 | Другой URL | Проверить дубль |

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

2. Отделите редирект от успешного ответа

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

curl -sS -o /dev/null -D - --max-time 30 https://example.com/old/
curl -sS -L -o /dev/null --max-redirs 5 --max-time 30 \
  -w 'HTTP: %{http_code}\nURL: %{url_effective}\n' \
  https://example.com/old/

В первом результате ищите код и Location, во втором — конечный адрес и статус. При ошибке curl результат неполон; тайм-аут не равнозначен 404. HEAD-запрос здесь не заменяет GET: приложение может обрабатывать их по-разному.

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

Временный 302 или 307 требует выяснить причину: это может быть обслуживание, геопереход или отправка на вход. Не подставляйте в sitemap страницу авторизации. Если переходов несколько, разберите маршрут по руководству о цепочках редиректов.

3. Для 404 выберите восстановление или удаление

Сначала откройте адрес без сессии администратора и сверьте его с записью CMS. Возможны три решения:

  • Страница должна существовать: исправьте маршрут, slug, публикацию или ошибку выгрузки; проверьте, что вернулся нужный материал.
  • Страница переехала: настройте постоянный редирект на содержательно подходящую замену и внесите замену в карту.
  • Материал удалён без замены: исключите URL из sitemap, сохранив корректный 404 или 410.

Не перенаправляйте все удалённые товары на главную и не возвращайте пустую заглушку с кодом 200. Такой ответ не делает страницу полезной: Google может определить его как soft 404. Обработка кодов описана в документации Google.

При внезапных массовых 404 после релиза сначала проверьте маршрутизацию и состояние CMS. Удаление всех таких URL из карты может скрыть симптом сломанного каталога.

4. Сверьте успешные страницы с canonical

Даже ответ 200 требует проверки содержимого. Убедитесь, что открывается нужная страница, нет noindex и доступа только после входа, а robots.txt не мешает её обходу.

Для HTML найдите rel="canonical" в head; если используется HTTP-заголовок Link, проверьте и его. Сопоставьте протокол, домен, путь, параметры и завершающий слеш. Не приводите регистр пути и параметры к одному виду автоматически: их смысл зависит от сайта.

Когда страница A указывает canonical на B, выясните, действительно ли это дубли. Если B — выбранная основная версия, проверьте её доступность и используйте B в карте. Если canonical ошибочен, исправьте шаблон. Отсутствие canonical само по себе ещё не доказывает дефект.

Google рекомендует согласовывать sitemap, canonical и внутренние ссылки; включение URL в карту — лишь сигнал, а не приказ поисковику. Подробнее — в правилах канонизации.

5. Устраните источник и проверьте повторную генерацию

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

После исправления:

  1. Пересоздайте карту и обновите только относящийся к ней кэш.
  2. Повторно скачайте публичную версию и сравните её с таблицей решений.
  3. Убедитесь, что нужные страницы сохранены, а исправленные URL не возвращаются при следующей генерации.
  4. Передайте актуальную карту через панель вебмастера и сопоставьте отчёт со временем нового обхода.

В sitemap должны быть предпочтительные адреса для поиска; сама отправка не гарантирует индексацию. Это ограничение отмечено в рекомендациях по Sitemap.

Web-Puls помогает регулярно следить за доступностью выбранных URL, но проверка нескольких страниц не заменяет сверку всей карты и решений поисковой системы. Если генератор продолжает возвращать старые адреса, можно отправить заявку на диагностику: укажите публичную карту, примеры URL и время проверки без паролей и cookies.

Мониторинг сайтов

Ошибка 404 означает, что сервер доступен, но не нашел запрошенный ресурс. Разбираем, когда это нормально, как найти битую ссылку и выбрать между восстановлением, 301 и честным 404.

Проверьте свой сайт прямо сейчас

Введите адрес сайта: Web-Puls покажет HTTP-код, время ответа и базовую диагностику. Для постоянного контроля можно подключить мониторинг.

Нужна помощь с диагностикой ошибки?

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