301 редирект: как настроить перенаправление и проверить результат
301 редирект нужен, когда страница окончательно переехала на новый адрес, а посетители ещё приходят по старым ссылкам. Он помогает сохранить понятный маршрут: человек открывает прежний URL и попадает на соответствующий материал, а поисковая система получает информацию о переносе. Для бизнеса это особенно важно при изменении адресов услуг, объединении статей и обновлении структуры каталога.
Однако одного кода 301 недостаточно. Нужно выбрать правильную страницу назначения, учесть параметры адреса, проверить правила сервера и убедиться, что конечная страница работает. Ниже — инструкция по плановой настройке перенаправлений: от таблицы соответствий до проверки HTTP-ответов и приёмки. Примеры используют условный домен example.com; они показывают принцип и требуют адаптации к вашему проекту.
301 редирект: что это и как он работает
301 Moved Permanently — HTTP-ответ о постоянном перемещении ресурса. В заголовке Location сервер указывает адрес назначения. Получив такой ответ, браузер выполняет следующий запрос уже к новой странице. Определение и пример приведены в справке MDN по статусу 301.
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/Это условный фрагмент ответа для старого URL. Он ещё не показывает, что произойдёт дальше: новый адрес может вернуть полезную страницу, ещё одно перенаправление или ошибку. Поэтому проверка состоит из двух частей: правильно ли сработал первый переход и что фактически получил посетитель в конце.
Редирект, внутренняя перезапись и ссылка — разные механизмы
При внешнем перенаправлении клиент получает новый адрес и обращается к нему. Внутренняя перезапись маршрута позволяет серверу обработать запрос другим компонентом без такого перехода в браузере. Обычная ссылка предлагает посетителю перейти самостоятельно. Эти решения могут быть полезны, но не являются взаимозаменяемыми доказательствами HTTP-редиректа.
Атрибут canonical тоже не переводит посетителя на новую страницу. Он сообщает поисковой системе предпочтительный адрес для похожего содержимого. Если старую страницу нужно продолжать показывать пользователям, выбор между сохранением URL и перенаправлением следует делать по назначению страницы. Подробная настройка canonical — отдельная задача.
JavaScript может изменить адрес уже после загрузки документа, но исходный HTTP-ответ при этом бывает 200. Google рекомендует предпочитать серверные способы, когда они доступны, и описывает ограничения клиентского перехода в руководстве по переадресации. Для приёмки требования «должен быть 301» проверяйте код ответа, а не только движение адресной строки.
Когда нужен 301, а когда следует выбрать другой вариант
Постоянное перенаправление подходит, если новый адрес действительно заменяет старый. Например, услуга получила понятный URL, несколько материалов объединены в один полноценный ответ или прежняя карточка заменена соответствующей актуальной страницей. При этом посетитель должен узнавать предмет своего перехода, а не заново искать его на сайте.
| Ситуация | Подход | Что проверить |
|---|---|---|
| Материал окончательно переехал | Постоянный редирект на новый URL | Соответствие содержимого и работоспособность цели |
| Перенос временный, старый адрес сохраняет назначение | Временное перенаправление по логике проекта | Условия и срок возврата исходного маршрута |
| Материал удалён, равноценной замены нет | Рассмотреть корректный 404 или 410 | Понятную страницу ошибки и полезную навигацию |
| Обе версии должны оставаться доступны | Сначала определить назначение адресов и канонизацию | Не ломает ли перенаправление нужный сценарий |
| Переносится форма, платёжный обработчик или API | Отдельное техническое решение | Метод, тело запроса, авторизацию и поведение клиента |
Отличие 301 от 302, 307 и 308
Коды 301 и 308 обозначают постоянное перемещение, 302 и 307 — временное. Но различие касается не только срока. По HTTP Semantics, при обработке 301 клиент может изменить POST на GET. Статус 308 предназначен для постоянного перехода с сохранением метода; 307 сохраняет метод при временном переходе. Поэтому рецепт для обычной страницы, открываемой через GET, нельзя автоматически применять к отправке заказа.
Ни постоянный, ни временный статус не избавляет от проверки кэширования. Не выбирайте 302 только из предположения, что такой ответ никогда не сохраняется. Сначала определите назначение переноса и требования клиента, затем согласуйте заголовки и правила промежуточных систем. Для важных операций решение должен проверить разработчик соответствующей интеграции.
Не перенаправляйте все удалённые страницы на главную ради уменьшения числа 404. Если посетитель искал конкретную инструкцию, общая витрина может не отвечать его задаче. Google предупреждает, что массовые переходы на нерелевантную цель могут трактоваться как soft 404. Перенос нескольких старых материалов на объединённую страницу уместен, когда она действительно заменяет их содержание.
Шаг 1. Составьте таблицу соответствий старых и новых URL
Настройка начинается с перечня адресов. Соберите старые URL из CMS, внутренних ссылок, карты сайта, данных посещений и известных внешних переходов. Для каждого выберите новую страницу и объясните причину выбора. Не оставляйте решение «всё, что не нашли, отправить в раздел» без проверки смысла.
В таблице полезны столбцы: старый адрес, новый адрес, причина переноса, параметры запроса, ожидаемый код, ответственный и результат теста. Отдельно отметьте страницы без замены и адреса, которым перенос не нужен. Это позволяет отделить согласованное изменение от случайного расширения правила.
Проверяйте весь адрес, а не только название страницы
Протокол, домен, поддомен, регистр пути и завершающий слэш могут влиять на обработку запроса. Для примера /old-page/ заранее решите, что должно происходить с /old-page, /Old-Page/ и /old-page/extra/. Не объявляйте все варианты эквивалентными, пока это не подтверждено устройством сайта.
Для языковых и региональных страниц сопоставляйте соответствующие версии. Перевод всех адресов на один язык способен лишить посетителя нужного содержания. Яндекс отдельно описывает особенности таких переходов в документации обработки редиректов. Условные перенаправления по региону требуют проверки того, какую страницу получает поисковый робот.
Согласуйте судьбу параметров запроса
Часть после знака вопроса может содержать рекламные метки, выбранный вариант товара, фильтр или другие данные. Для каждого значимого параметра решите: сохранить, преобразовать или удалить. Если новый адрес получает прежние параметры, приложение должно понимать их правильно; механическое сохранение старого идентификатора не гарантирует нужного результата.
Например, переход с /old-page/?utm_source=mail можно настроить с сохранением метки, если это нужно аналитике. Параметр variant=blue уже способен менять выбор посетителя. В таблице должны быть не общие слова «параметры работают», а ожидаемый конечный адрес и состояние страницы. Не переносите приватные токены на другой домен без отдельной обоснованной схемы.
Проверьте также логическую замкнутость карты: цель не должна вести обратно к источнику или через несколько устаревших промежуточных адресов. Если страница переезжала раньше, обновите прежние переходы так, чтобы они приводили к актуальному назначению. Делайте это по согласованной карте, сохраняя историю изменений.
Шаг 2. Выберите, где будет работать правило
Перенаправление может создавать CMS, приложение, веб-сервер, панель хостинга или CDN. Определите, какой компонент уже управляет адресами и в каком порядке обрабатывается запрос. Если один слой добавляет слэш, другой убирает его, а третий отправляет на другой хост, даже простое изменение получает лишние переходы.
Для конкретного набора URL назначьте один понятный источник правил. Это не означает, что вся инфраструктура обязана иметь только одно перенаправление: важно согласовать ответственность и исключить дублирующие или противоречащие настройки. Перед выпуском сохраните предыдущую конфигурацию и перечень существующих правил.
На управляемом хостинге сначала выясните доступный механизм у провайдера. Файл .htaccess работает в соответствующей среде Apache и может быть запрещён настройками сервера. Nginx не использует его как конфигурацию. В конструкторе сайтов редиректы обычно задаются через предусмотренный интерфейс. Вставка кода сервера в HTML-блок страницы не создаст серверное перенаправление.
Если конечный адрес содержит HTTPS, проверьте сертификат и доступность этого хоста до переключения. Старый HTTPS-адрес тоже должен оставаться доступным с корректным сертификатом, пока принимает посетителей: защищённое соединение устанавливается до получения HTTP-ответа. Ошибка на этом этапе помешает человеку дойти даже до правильного правила 301.
Шаг 3. Настройте точечный 301 редирект в Apache
Следующий пример предназначен для Apache 2.4 с доступным модулем mod_alias. Для использования в .htaccess сервер должен разрешать соответствующие директивы; у RedirectMatch указан класс разрешений FileInfo. Это проверяют по настройкам хостинга, а не включают произвольно на рабочем сервере.
RedirectMatch 301 "^/old-page/$" "https://example.com/new-page/"Правило сопоставляет путь /old-page/ и отправляет на заранее заданный адрес. Якоря ^ и $ ограничивают совпадение. Путь /old-page/extra/ не подходит под этот шаблон; вариант без завершающего слэша тоже требует отдельного решения. Пример рассчитан на обычную публичную страницу, которую получают через GET.
Почему здесь используется RedirectMatch
Обычный Redirect сопоставляет префикс по полным сегментам пути и может добавлять оставшуюся часть к адресу назначения. RedirectMatch позволяет использовать регулярное выражение. Эти различия, доступные контексты и порядок обработки описаны в документации mod_alias. Поэтому короткую строку с Redirect нельзя без проверки выдавать за точное перенаправление единственного URL.
В приведённом варианте параметры запроса сохраняются: адрес с ?utm_source=mail должен прийти к новой странице с той же строкой параметров. Шаблон пути не выбирает отдельно определённое значение query. Если требуется преобразовать или отбросить параметры, нужен специально подготовленный вариант; Apache рекомендует для сложной работы с ними mod_rewrite.
Не размещайте новое правило вслепую рядом с правилами CMS. Порядок и контекст обработки имеют значение, особенно при сочетании модулей. Попросите разработчика проверить конфигурацию в используемой среде, затем испытайте согласованные адреса. Здесь не требуется создавать второй файл .htaccess или заменять им действующую конфигурацию целиком.
Шаг 4. Настройте точечное перенаправление в Nginx
Для Nginx пример помещается внутрь уже существующего подходящего блока server. Он не является полным файлом конфигурации и не заменяет настройки домена, TLS, приложения и журналов. Перед изменением убедитесь, что выбран именно тот виртуальный сервер, который принимает старый URL.
location = /old-page/ {
return 301 https://example.com/new-page/$is_args$args;
}Модификатор = задаёт точное совпадение пути. Директива return выдаёт клиенту ответ 301 и указанный адрес. Её синтаксис и допустимость переменных в URL описаны в справке Nginx по return. Символы точного сопоставления здесь отличаются от синтаксиса Apache.
Что делают $is_args и $args
Переменная $args содержит строку параметров, а $is_args — знак вопроса при её наличии. Их значения и правила location описаны в документации основного HTTP-модуля. В этом примере параметры добавляются в адрес явно; если их нет, лишний вопросительный знак не появляется.
Так, для /old-page/?utm_source=mail ожидается https://example.com/new-page/?utm_source=mail. Если согласованный сценарий требует отбросить все параметры, вариант return с фиксированным адресом без этих переменных решает другую задачу. Не меняйте поведение случайно и не переносите автоматически правила работы query из rewrite на return.
Точное location не отменяет влияние более ранней обработки на уровне server и внешнего CDN. После проверки конфигурации специалист применяет её штатным способом, затем выполняет HTTP-тесты. Если запрос доходит до другого слоя или обслуживается старой конфигурацией, наличие правильного фрагмента в файле само по себе не подтверждает работу редиректа.
Как настроить 301 редирект в Тильде
В Тильде для переноса между страницами одного домена предусмотрен раздел Настройки сайта → SEO → Редиректы страниц (Code 301). Укажите старый и новый пути без домена, начиная со слэша, добавьте правило и сохраните изменения. Эта последовательность и ограничения приведены в официальном SEO-руководстве Тильды.
Существенная особенность: такой 301 работает только с несуществующих страниц. Если старый путь по-прежнему занят опубликованной страницей, настройку нельзя принимать без проверки. Сначала согласуйте перенос содержимого и освобождение старого адреса. Не удаляйте материал только ради эксперимента с настройкой.
Блок T223 выполняет JavaScript-переход: справка Тильды прямо указывает, что исходная страница отвечает HTTP 200. Поэтому визуальный переход через этот блок не подтверждает серверный 301. Перенос на другой домен также требует отдельной схемы; возможности настройки внутри одного сайта нельзя автоматически распространять на него.
Шаг 5. Проверьте первый ответ, цепочку и конечную страницу
Начните с точного старого URL из таблицы. Открытие новой страницы напрямую проверяет только цель и ничего не говорит о перенаправлении. Сохраните первый HTTP-код, Location, все промежуточные переходы, конечный адрес и конечный код. Затем убедитесь, что на экране находится нужный материал и работает основное действие посетителя.
Проверка через curl
Для технической проверки можно использовать обычный GET-запрос. Ниже пример для Linux или macOS: замените условный адрес согласованным публичным тестовым URL. Параметр -D - выводит заголовки, а -o /dev/null не сохраняет тело ответа. Эти команды приведены как образец проверки; они не описывают выполненный аудит сайта.
curl -sS -D - -o /dev/null 'https://example.com/old-page/?utm_source=mail'Первая команда не следует за перенаправлением. Для просмотра последовательности добавляют -L; ограничение числа переходов помогает остановить ошибочную цепочку:
curl -sS -L --max-redirs 5 -D - -o /dev/null 'https://example.com/old-page/?utm_source=mail'Назначение опций описано в официальной справке curl. Здесь проверяется GET без данных формы и авторизации. Отдельный HEAD-запрос может быть дополнительным наблюдением, но не заменяет проверку обычного получения страницы. Для действий с POST и API нужен собственный тестовый сценарий.
Проверка в браузере и онлайн
В инструментах разработчика откройте вкладку Network, сохраните журнал переходов и загрузите старый адрес. Найдите запрос документа, посмотрите статус и Location, затем следующий запрос. При необходимости повторите проверку без использования локального кэша, чтобы понять ответ сервера. После этого проверьте и обычный пользовательский режим: именно в нём работают реальные посетители.
Онлайн-проверка редиректа полезна как независимое наблюдение публичного URL, если сервис показывает всю цепочку. Но её результат относится к конкретному запросу и точке проверки. Она не подтверждает работу авторизованного сценария, формы или регионального условия. Не передавайте такому инструменту приватные ссылки и секретные параметры.
Проверьте адреса, которые не должны перенаправляться
Для точного правила особенно важны отрицательные примеры. Они показывают, не захватило ли изменение соседние страницы. Ожидаемые результаты ниже относятся к приведённой паре путей; если на сайте действуют другие согласованные правила, включите их в общую схему проверки.
| Запрос | Что ожидаем от нового правила | Что дополнительно проверить |
|---|---|---|
| /old-page/ | 301 на /new-page/ | Правильный хост и содержимое цели |
| /old-page/?utm_source=mail | Переход с сохранением параметра | Отсутствие потери или повторного добавления query |
| /old-page | Новое точное правило не совпадает | Как обрабатывается вариант без слэша по общей политике |
| /old-page/extra/ | Новое точное правило не совпадает | Нет случайного переноса вложенного материала |
| /new-page/ | Не возвращает на старый адрес | Конечный ответ и основное действие посетителя |
В рабочий набор добавьте варианты регистра и кодирования, используемые на вашем сайте. Ошибка возникает не только при цикле: редирект может успешно завершиться на чужом товаре, потерять выбранный вариант или отправить посетителя в неподходящий язык. Итоговый 200 нужно проверять вместе с содержимым.
Шаг 6. Согласуйте редирект с поисковыми сигналами
Google рассматривает перенаправление как сильный сигнал выбора основного адреса; это описано в документации канонизации. Однако технически правильный переход не обещает немедленного переноса позиций и трафика. Поисковой системе нужно обнаружить изменение и обработать новые данные.
Обновите внутренние ссылки на актуальные конечные URL: меню, карточки, хлебные крошки, связанные материалы и важные кнопки. В рабочей карте сайта используйте выбранные новые адреса. На целевой странице проверьте отсутствие случайного noindex, доступность содержимого и правильный canonical. Иначе разные части сайта сообщают поиску противоречащие сведения.
Не закрывайте исходный URL от обхода только потому, что он уже перенаправляет. Роботу нужно получить ответ и узнать назначение перехода. При этом настройки конфиденциальных разделов и формы с персональными данными не следует менять по инструкции для публичных страниц.
В отчётах поисковиков отдельно наблюдайте источник и цель. Исключение старого URL из самостоятельной выдачи может быть нормальным результатом переноса. Например, Яндекс в описании статусов страниц для перенаправления рекомендует проверять индексирование цели. Сравнивайте даты обхода с датой выпуска, а не требуйте изменения всех отчётов сразу после настройки.
Как выпустить изменение, подготовить откат и сохранить результат
До публикации согласуйте список правил, ожидаемые ответы и условия остановки. Сохраните рабочую конфигурацию и убедитесь, что конечные страницы готовы. На тестовой среде проверьте положительные и отрицательные примеры, затем начните с ограниченного набора адресов. После выпуска повторите проверки на фактическом публичном маршруте через используемый CDN или прокси.
Постоянный редирект может кэшироваться. RFC 9110 допускает эвристическое кэширование 301 с учётом метода и явных правил. Поэтому удаление строки из конфигурации не обязано немедленно изменить поведение всех клиентов. В плане отката учитывайте серверные и внешние кэши, а также сравнивайте свежий запрос с обычным браузерным сеансом.
При ошибке не создавайте автоматически обратный постоянный редирект: у клиентов с прежней копией это способно породить неожиданные маршруты. Восстановите согласованную конфигурацию, устраните причину и проверьте фактические ответы. Откат должен возвращать работоспособный сценарий, а не только прежний текст файла.
| Критерий приёмки | Подтверждение |
|---|---|
| Правильный источник и цель | Сохранены исходный запрос, код и Location |
| Предсказуемая цепочка | Нет цикла и лишних промежуточных переходов |
| Корректная конечная страница | Нужный материал доступен, основное действие работает |
| Параметры и соседние адреса | Согласованное поведение подтверждено тестовыми примерами |
| Сопровождение | Есть версия правил, дата выпуска, ответственный и план отката |
Как долго сохранять старое перенаправление
Не удаляйте редирект сразу после появления нового URL в поиске. Старые адреса могут оставаться в закладках, письмах, публикациях и внешних ссылках. В руководстве по переносу URL Google рекомендует сохранять редиректы как можно дольше, обычно не меньше года; для удобства посетителей — рассматривать бессрочное сохранение. Это ориентир сопровождения переноса, а не обещание срока индексации.
Если адрес меняется повторно, пересмотрите старые правила и направьте их к актуальной подходящей странице. Для отдельного старого домена продолжайте поддерживать необходимые DNS, сертификат и обслуживание, пока используете его для перенаправлений. Нельзя сохранить переход, просто оставив текст правила на выключенном сервере.
Запишите результат в журнал: что перенесли, почему выбрана цель, где расположена настройка и как прошла проверка. Таблица соответствий и сохранённые HTTP-ответы помогут предметно сформулировать задачу и принять работу исполнителя.
После настройки редиректов регулярно контролируйте доступность страниц назначения. Оцените SiteGuard для мониторинга сайта: важно замечать, когда конечная страница перестаёт открываться.
Частые вопросы о настройке 301 редиректа
Можно ли настроить 301 редирект с одной страницы на другую без программиста?
Да, если платформа предоставляет понятный инструмент и задача укладывается в его ограничения. Но после сохранения правила всё равно нужно проверить первый ответ и конечную страницу. Для преобразования параметров, переносов обработчиков и конфликтов нескольких слоёв потребуется специалист, который понимает конфигурацию проекта.
Почему браузер переходит, а проверка показывает 200?
Возможны JavaScript-переход, проверка уже конечного URL или другие особенности инструмента. Смотрите исходный запрос документа и промежуточные ответы. Если условие приёмки требует серверный 301, один визуальный переход этого не подтверждает.
Нужно ли оставлять старую страницу с текстом?
При серверном переносе старый URL должен выдавать предусмотренный ответ перенаправления, а новый — нужный материал. Хранение старого содержимого зависит от архитектуры и правил платформы. Не удаляйте данные до проверки целевой страницы и сохранения необходимой резервной копии.
Можно ли направить несколько старых URL на одну страницу?
Можно, если новая страница действительно объединяет их содержание и отвечает ожиданиям посетителей. Проверяйте каждую группу по смыслу. Общая главная или категория не становится подходящей заменой автоматически только потому, что она отвечает 200.
Достаточно ли исправить только редиректы?
Нет: обновите собственные ссылки, проверьте целевые страницы и связанные настройки. Хороший результат — посетитель получает нужный материал без лишних переходов, а команда может объяснить назначение каждого правила и воспроизвести его проверку.