В sitemap остались адреса до переезда каталога. Каждый ведёт на новую страницу, поэтому ошибок пользователь не видит. Карта всё равно перечисляет промежуточные URL. Очистка начинается с сопоставления старой записи и конечного назначения: удалять все адреса со статусом 301 без проверки замены недостаточно.
Выгрузите loc и фактические назначения
Карта должна отражать выбранные доступные страницы, которые вы хотите показывать в поиске. Для старого адреса найдите конечную подходящую страницу. Если такого назначения больше нет, запись не нужно заменять случайным URL ради сохранения количества строк.
Google рекомендует указывать в sitemap предпочтительные канонические URL. Официальная документация.
Начните с сохранения исходной карты и времени получения. XML может генерироваться динамически, поэтому повторная выгрузка после изменения каталога будет иметь другой состав. Выпишите каждый loc без ручного удаления параметров и нормализации слешей. Для большого списка ограничьте параллельность запросов и сохраните полный результат по каждому адресу. Нужны исходный URL, цепочка, конечный URL и причина предполагаемой замены. По этой таблице можно отличить технический переход на HTTPS от переноса конкретной услуги на другой путь.
Матрица замены промежуточных URL
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| /old-service/ | 301 на /service/ | Заменить запись | Проверить конечную услугу |
| /a/ → /b/ → /c/ | Два перехода | Записать /c/ | Проверить соответствие |
| /removed/ | 404 без аналога | Исключить | Не подменять главной |
| /service/ | 200 и self-canonical | Оставить | Нет noindex |
Один исходный адрес может вести на правильный аналог, другой — на главную, третий — на отсутствующую страницу. Эти три результата нельзя объединять как «все имеют редирект». Запишите семантическое соответствие: название, назначение и основной контент до и после. Для старого товара без аналога удаление записи может быть правильнее добавления категории. Для двух старых форм одной страницы новая карта может содержать только одно назначение. Уменьшение числа loc поэтому требуется объяснить, а не автоматически считать потерей страниц.
Как получить цепочку HTTP-переходов
Выгрузите loc, начальный статус и всю цепочку переходов. На конечной странице проверьте содержание, canonical и noindex. Повторяющиеся назначения объедините только после проверки, что старые записи действительно относились к одной странице.
Используйте GET и сохранение заголовков каждого перехода. В curl ключ -L следует переходам, а -D сохраняет полученные блоки заголовков; без -L видно исходный ответ. При диагностике сравните оба режима и укажите конечный URL. Команда с -I использует HEAD, который некоторые серверы обрабатывают иначе. Для подтверждения поведения обычного документа предпочтительно проверить GET. Не ставьте слишком большой лимит перенаправлений, чтобы скрыть цикл. Если адрес повторился, остановите проверку и зафиксируйте проблему цепочки отдельно от очистки sitemap.
Что проверить на конечной странице
Учебная карта содержит пять старых адресов, но только три конечные страницы: две записи сходятся на одной, ещё одна удалена. После очистки число записей уменьшается по объяснимым причинам; это не ошибка само по себе.
На конечном URL проверьте не только 200. Это может быть страница ошибки, входа или общая заглушка. Сравните title, H1 и основной текст с ожидаемой страницей, затем canonical и noindex. Если canonical ведёт дальше на другой адрес, выясните, какой URL действительно выбран. Страница после редиректа, исключённая из индексации намеренно, не должна попадать в новый список только потому, что успешно загружается. Отдельно проверьте доступность назначения для гостя и обычные ссылки на него из публичной навигации.
Исправьте источник адресов карты
Исправьте источник URL в генераторе карты: базовый домен, slug или выборку CMS. Сохраните редиректы для старых внешних переходов, но переведите sitemap и внутренние ссылки на конечные адреса.
Найдите, откуда генератор берёт старые loc: поле slug, таблица маршрутов, импортированный абсолютный адрес или базовый домен CMS. Ручное редактирование опубликованного XML часто исчезает при следующей регенерации. Исправьте источник и повторите штатное построение карты. Если плагин имеет отдельные настройки типов записей, убедитесь, что смена URL не выключила нужный раздел. После публикации проверьте публичный файл, а не только сохранённый результат генератора. При наличии sitemap index проверьте также обновлённую дочернюю карту и её ссылку в индексе.
Старые внешние ссылки и новая навигация
Редирект в sitemap не доказывает потерю трафика. Проблема качества списка отличается от подтверждённого изменения индекса; не обещайте рост после удаления промежуточных записей.
Удаление старого URL из sitemap не означает, что нужно удалить его редирект. Внешние ссылки, закладки и история посетителей могут продолжать использовать прежний адрес. Сохраните необходимые серверные правила, а новые внутренние ссылки переведите на конечный URL. Это две разные работы с разными критериями: история должна приводить к подходящей странице, новая навигация — не создавать лишних переходов. Проверьте меню, крошки и карточки соответствующего раздела. Если редирект был нужен только для технической формы, подтвердите, что прямое назначение не меняет состояние пользователя.
Приёмка состава и изменения числа записей
Сравните исходный и новый набор loc по категориям: заменён, объединён, удалён, оставлен. Каждое изменение должно иметь запись в рабочей таблице. Затем запросите все новые адреса в согласованном охвате и выборочно перепроверьте их содержание. Отчёт должен отделять чистоту sitemap от последующего состояния поиска. Принятый файл не гарантирует, что поисковик сразу обработает каждую страницу. Если старые URL ещё отображаются в инструменте, посмотрите дату получения карты и обхода, сохраняя доказательство свежего публичного списка.
Критерии завершения проверки
Новые loc отвечают 200 без ненужной цепочки и согласованы с canonical. Удалённые страницы исключены, подходящие замены добавлены, количество строк объясняется списком изменений.
- /old-service/: Проверить конечную услугу. Зафиксируйте фактический результат и адрес проверенного сценария.
- /a/ → /b/ → /c/: Проверить соответствие. Зафиксируйте фактический результат и адрес проверенного сценария.
- /removed/: Не подменять главной. Зафиксируйте фактический результат и адрес проверенного сценария.
- /service/: Нет noindex. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Ошибки в sitemap.xml: как найти и исправить и Как использовать reChecker для анализа редиректов. Отдельные проверки сайта собраны на странице технического аудита reChecker.