Редиректы 301 и 302: настройка и проверка

Редирект отправляет запрос на другой адрес

Посетитель открывает старую ссылку. Сервер отвечает кодом перенаправления и передаёт новый адрес в заголовке Location. Браузер запрашивает этот адрес, а человек видит итоговую страницу. Например, вместо /uslugi-old/ открывается /services/. Перенаправление нужно проверить как маршрут: исходный URL, каждый промежуточный шаг и конечный документ.

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

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

301 и 302 различаются назначением переноса

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

У 307 и 308 есть важное отличие для разработки: при переходе сохраняются метод и тело запроса. Для 301 и 302 поведение запросов, отличных от GET, может различаться между клиентами. Поэтому правила для форм, оплаты и API нельзя выбирать только по SEO-таблице. Сравнение поведения приведено в справочнике MDN.

Для Google постоянное перенаправление служит сигналом выбора нового канонического адреса; временное такого намерения не сообщает. Это не гарантия немедленной замены URL в выдаче и не правило «302 никогда не индексируется». Подробности — в документации Google о редиректах.

Сначала определите цель для каждого старого URL

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

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

Не направляйте все исчезнувшие адреса на главную. Человек, который искал конкретную инструкцию, не получает её замену на странице компании. Google отдельно предупреждает о риске интерпретации нерелевантных массовых перенаправлений как soft 404 в руководстве по переносу сайта.

Подберите инструмент под объём проверки

Для одной ссылки достаточно сервиса просмотра HTTP-ответов и браузера. Для десятков или тысяч адресов удобнее краулер с экспортом. Поисковые кабинеты нужны на следующем этапе: они показывают обработку изменений поисковиком, а не заменяют проверку ответа сервера.

• httpstatus.io — увидеть ответ и переходы для заданного списка URL.
• Network в Chrome DevTools — разобрать запросы браузера и заголовок Location.
• Screaming Frog SEO Spider — проверить маршруты массово, найти источники внутренних ссылок и выгрузить ошибки.
• Google Search Console и Яндекс Вебмастер — наблюдать за обходом и индексированием после публикации.

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

Посмотрите код, Location и конечную страницу

1. Откройте httpstatus.io и вставьте полный старый URL с протоколом.
2. Запустите проверку кнопкой Check status.
3. Раскройте результат и просмотрите все переходы до последнего ответа.
4. Сравните конечный адрес с картой переноса.
5. Откройте конечную страницу и убедитесь, что там нужный материал.
6. Повторите проверку для важных вариантов: со слешем, без него и с рабочими параметрами.

Ожидаемый результат нашего примера — старый URL отвечает 301, указывает сразу на /services/audit/, а тот возвращает 200 с содержанием услуги. Последний код 200 сам по себе недостаточен: это может быть главная, пустой шаблон или сообщение «страница не найдена».

Запись «редирект работает» замените проверяемой формулировкой: «24 сентября, старый URL → 301 → согласованный новый URL → 200; содержимое и параметры проверены». Если сервис не смог подключиться, это отдельный результат, требующий уточнения. Он не подтверждает ни исправность, ни отсутствие перенаправления.

Network помогает увидеть то, что скрыла адресная строка

Откройте инструменты разработчика Chrome и вкладку Network. Включите Preserve log, чтобы журнал не очищался при переходе, и Disable cache на время проверки с открытыми инструментами. Затем введите исходный адрес заново. Выберите запрос документа и посмотрите Status Code и Response Headers → Location. Названия и возможности панели описаны в официальной инструкции Chrome.

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

Если старый документ отдаёт 200, а адрес меняется позже, проверьте клиентское перенаправление: JavaScript, meta refresh или настройку конструктора. Такая картина отличается от ответа HTTP 301. В браузере также могут работать ранее сохранённые правила, поэтому после изменения конфигурации полезно сравнить результат со свежей независимой HTTP-проверкой.

Точное правило для одной страницы в .htaccess

Этот пример предназначен для Apache с доступным mod_alias и разрешёнными директивами в .htaccess. Сохраните действующую конфигурацию и проверьте, не управляет ли этим файлом CMS или панель хостинга. На Nginx такой файл сам по себе не работает.

RedirectMatch 301 ^/old-service/$ https://example.com/services/audit/

Знаки ^ и $ ограничивают совпадение полным путём. Правило не должно случайно захватить /old-service/price/. URL без завершающего слеша в этот конкретный шаблон тоже не входит: для него сначала определите ожидаемый маршрут. Поведение Redirect и RedirectMatch описано в документации Apache.

После изменения проверьте исходную страницу, цель, главную и соседний адрес, который правило не должно затронуть. Затем повторите запрос с параметром. Более общие правила и директивы другого модуля могут изменить результат; проверка одной строки отдельно от конфигурации не доказывает корректность сайта.

Перенаправление через точный location

В подходящем блоке server можно задать точное соответствие пути. Пример сохраняет строку параметров исходного запроса:

location = /old-service/ {
    return 301 https://example.com/services/audit/$is_args$args;
}

Здесь адрес назначения фиксирован, а $is_args$args добавляет параметры, если они есть. Это удобно, когда их смысл сохраняется. Если старые параметры управляли фильтрами, языком или содержимым, решение нужно принять отдельно: нельзя переносить или удалять их только ради короткого URL. Синтаксис return приведён в документации Nginx.

Администратор проверяет конфигурацию до её применения, затем обновляет работающий сервер и повторяет HTTP-проверку снаружи. Если впереди находится CDN или другой прокси, убедитесь, что наблюдаемый ответ формируется новым правилом. Для HTTP/HTTPS и www настройку согласуют на уровне хостов; копирование отдельного location не решает автоматически все варианты домена.

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

На WordPress единичные перенаправления можно вести через поддерживаемый инструмент CMS. Например, в плагине Redirection откройте раздел Redirects и форму добавления правила. В Source URL укажите /old-service/, в Target URL — полный согласованный адрес назначения. Проверьте код 301 и параметры сопоставления, сохраните правило, затем протестируйте старый URL без авторизации. Порядок описан в документации Redirection.

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

В Tilda настройка находится в «Настройки сайта → SEO → Редиректы страниц (Code 301)»: задаются старый и новый пути без домена. По инструкции Tilda, этот механизм работает внутри одного домена и для несуществующих старых страниц. Блок переадресации T223 не равен серверному 301: документация блока указывает ответ 200 исходной страницы.

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

Сократите маршрут до согласованной цели

Цепочка возникает, когда A ведёт на B, а B — на C. Цикл возвращает запрос к уже пройденному адресу: A → B → A. Первый случай добавляет переходы, второй может закончиться ошибкой слишком большого числа перенаправлений. При исправлении проверьте причину, прежде чем менять отдельное звено.

Учебная ситуация: три года назад страницу перенесли из /audit-old/ в /audit/, а сейчас — в /services/audit/. Оба старых адреса должны вести прямо к действующему материалу. Ссылки меню, статей и Sitemap обновляются на конечный URL, чтобы собственный сайт не отправлял посетителей по устаревшему маршруту.

Для массовой проверки в Screaming Frog переключитесь в Mode → List и загрузите исходные адреса. По инструкции аудита переноса включите следование редиректам до конечной цели, запустите обход и выгрузите Reports → Redirects → All Redirects. Сравните начальные и итоговые адреса, коды, число переходов и признак цикла с вашей картой.

Чтобы найти внутренние ссылки на старые URL, выполните обычный обход сайта и разберите фильтр Redirection (3XX) во вкладке Response Codes вместе с Inlinks. Порядок показан в руководстве по массовой проверке. У бесплатного режима есть ограничение на объём; размер списка и возможности вашей версии нужно учесть до запуска.

Разбирайте ошибку по наблюдаемому результату

В задаче разработчику укажите точный исходный URL, ожидаемую цель, фактическую последовательность ответов и дату. Например: «Для /old-service/ согласован прямой 301 на /services/audit/. Сейчас первый переход ведёт на /services/, второй — на главную. Исправить правило и проверить соседний /old-service/price/, который переносить не требуется».

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

Разделите технический результат и обработку поисковиком

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

Проверьте новый адрес на доступность, запреты индексирования и корректный canonical. Обновите внутренние ссылки и Sitemap. Старые URL должны оставаться доступными для получения ответа перенаправления: закрытие их в robots.txt мешает проверять переезд поисковым обходом.

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

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

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

• Карту исходных и конечных адресов с объяснением исключений.
• Описание места, где находятся правила, и способа их восстановления.
• Выгрузку проверки всех согласованных исходных URL.
• Подтверждение кода и содержания конечных страниц.
• Проверку параметров, слешей и важных вариантов домена.
• Контроль отсутствия циклов и лишних промежуточных переходов.
• Обновлённые внутренние ссылки, canonical и Sitemap.
• Проверку форм и других действий, если маршрут затрагивает их.
• Отдельный список поисковых статусов, которые ещё ожидают обновления.

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

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

Частые вопросы о редиректах