Редиректы при переезде сайта: карта и проверка

Когда при переезде сайта нужны редиректы#

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

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

Зафиксируйте границы работы: какие разделы сохраняют адреса, какие получают новые, какие вы удаляете. Так вы отделите настройку перенаправлений от переноса контента и не отдадите разработчику расплывчатую задачу «сохранить всё SEO».

Основание для карты редиректов — изменение адресов. Смена системы управления сама по себе не показывает, какие перенаправления нужны.

Согласуйте сценарий до настройки. Если часть адресов остаётся прежней, отметьте это в рабочем перечне. Тогда проверяющий поймёт, где ждать перенаправление, а где — доступную страницу по сохранённому URL.

Как собрать старые адреса для карты редиректов#

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

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

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

В рабочем перечне нужны поля:

• Старый полный URL — вместе с доменом, протоколом и параметрами.
• Источник обнаружения — откуда вы взяли адрес.
• Тип страницы — услуга, статья, категория, документ или другой объект.
• Значимость для бизнеса — какие переходы и обращения связаны со страницей.
• Текущий ответ сервера — результат проверки до переезда.

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

Как сопоставить старые страницы с новыми#

Сопоставляйте страницы по содержанию и задаче посетителя. Для старой услуги выбирайте новую страницу этой услуги, для инструкции — материал, который отвечает на прежний вопрос. Если подходящего продолжения нет, фиксируйте удаление без замены. Совпадение слов в URL удобно для поиска кандидатов, но окончательную цель выбирайте после просмотра материала.

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

Массовый перенос на нерелевантную главную может привести к оценке soft 404. Это поисковая оценка страницы как отсутствующей при другом ответе сервера. Для удаления без замены задайте HTTP-ответ об отсутствии ресурса: стандарт HTTP описывает статусы 404 и 410.

Используйте такой набор решений в карте:

Ситуация	Решение в карте	Что проверить вручную
Страница получила новый адрес	Указать соответствующий новый URL	Сохранена задача посетителя
Материалы объединили	Указать общий URL объединённой страницы	Прежние темы раскрыты в новом материале
Материал удалили без замены	Зафиксировать удаление и ожидаемый ответ	Подходящего продолжения действительно нет

Перенаправление согласуют вместе с содержанием страницы. Правильный адрес должен приводить к ответу, ради которого посетитель открыл старую ссылку.

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

Что передать разработчику для настройки редиректов#

Передайте разработчику согласованную карту, общие правила для групп адресов, исключения и критерии приёмки. Укажите ответственных за выбор целей, настройку и проверку. В карте должны быть старый полный URL, новый URL либо решение об удалении, ожидаемый HTTP-статус и основание выбора. Цель перенаправления — конечный согласованный адрес.

Для постоянного переноса задайте HTTP 301 или 308. HTTP 302 и 307 обозначают временное перенаправление — это разграничение приводит Яндекс в документации по редиректам. Согласуйте конкретный статус в задании, чтобы проверяющий сравнивал результат с требованием.

Общие правила и исключения#

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

Опишите варианты, которые входят в проверку: HTTP и HTTPS, www и адрес без www, завершающий слеш, параметры запроса, кодирование символов. Для параметров примите решение по назначению. Значимые параметры учитывайте отдельно. Механическое удаление всех параметров не стоит делать правилом по умолчанию.

Задание готово к работе, когда по каждой строке понятно, какой ответ сервера и какой конечный URL вы примете.

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

Как проверить редиректы до запуска#

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

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

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

Что искать в отчёте#

Проверьте неверные цели, отсутствующие страницы, неожиданные промежуточные переходы и циклы. Цепочка редиректов содержит последовательные переходы. Цикл редиректов возвращает запрос к адресу, который уже встретился в этой последовательности.

Сохраняйте фактический результат рядом с ожидаемым. Если проверяющий отклонил строку, напишите причину: «цель отличается от карты», «материал отсутствует» или «переход возвращается на исходный адрес». Такая запись даёт разработчику воспроизводимую задачу.

Приёмка редиректа заканчивается на конечной странице: проверьте путь запроса, ответ сервера и материал, который увидит посетитель.

Как проверить результат после переезда#

После запуска повторите проверку всей карты на публичном сайте. Сверьте фактические перенаправления с согласованными целями и отдельно проверьте удалённые адреса. Затем проверьте внутренние ссылки, Sitemap, rel="canonical" и hreflang при наличии. Проверьте robots.txt и отсутствие случайного noindex на страницах, которые должны участвовать в поиске.

Разделяйте документы по назначению. Карта редиректов связывает старые адреса с новыми. Sitemap перечисляет адреса для поисковых систем. Серверный редирект перенаправляет запрос, а rel="canonical" указывает предпочтительный адрес для индексирования. Согласуйте эти настройки между собой, чтобы они не указывали на разные версии страницы.

Для Яндекс Вебмастера выберите процедуру по своему сценарию: смене домена, протокола или варианта с www. Яндекс публикует отдельные инструкции по видам переезда. Не переносите действия из другого сценария автоматически.

Что наблюдать после технической проверки#

Следите за ошибками обхода, индексированием, поисковыми переходами, обращениями и серверными журналами. Обход означает получение страницы роботом, индексирование — включение и обработку в поисковом индексе. Для наблюдения используйте Google Search Console, Яндекс Вебмастер и данные аналитики.

Сохраните исходные показатели и сопоставляйте их с данными новых страниц. Отдельный порядок наблюдения описан в материале как отслеживать позиции сайта.

Если техническая проверка пройдена, а обращения снизились, проверьте работу форм и аналитики. Без этой проверки нельзя отделить изменение поведения посетителей от проблемы учёта заявок.

Какие ошибки исправлять в первую очередь#

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

Используйте список для приёмки исправлений:

• Недоступные важные страницы. Проверьте согласованный конечный адрес и доступность нужного материала.
• Циклы редиректов. Запишите повторяющиеся адреса и проверьте маршрут после изменения правила.
• Ошибочные цели. Верните старой ссылке согласованное продолжение по содержанию.
• Закрытие от индексирования. Проверьте ограничения, которые могли остаться от тестового контура.
• Цепочки редиректов. Сверьте промежуточные переходы с заданием и уберите лишние.
• Устаревшие внутренние ссылки. Замените старые адреса на согласованные конечные URL.

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

В журнале исправлений сохраняйте проблему, затронутые URL, ответственного, изменение и результат повторной проверки. Для разбора сопутствующих проблем используйте поисковый аудит и исправление проблем.

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

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

Источники#

Для задания используйте документацию поисковых систем о переезде, а значение HTTP-статусов сверяйте со стандартом. Google описывает подготовку и контроль переноса, Яндекс разграничивает перенаправления и сценарии переезда, стандарт HTTP определяет смысл ответа сервера. Выбор конкретной новой страницы согласуйте по содержанию вашего сайта.

• Переезд сайта с изменением URL — Google Search Central.
• Обработка редиректов — Яндекс Вебмастер.
• Виды переезда сайта — Яндекс Вебмастер.
• HTTP Semantics — IETF.

Если вы готовите переезд сайта, оставьте заявку на разбор карты редиректов и критериев приёмки.