Ссылку поменяли, страницу перенесли, а посетители всё ещё приходят по старому адресу. В этот момент нужен понятный переход к тому, что они искали. Мы в «Гуси-Лебеди» разбираем, как настроить 301-редирект, проверить его работу и не отправить человека с карточки товара на случайный раздел.
301 сообщает о постоянном перемещении ресурса: сервер возвращает новый адрес в заголовке Location. Но одного кода недостаточно. Нужны подходящая конечная страница, корректные параметры и проверка пользовательского сценария. Ниже показываем порядок действий и узкие учебные примеры, а не готовую конфигурацию для любого сайта.
Что такое 301-редирект и чем он отличается от 302 и 308
| Инструмент | Назначение | Что учитывать |
|---|---|---|
| 301 | Постоянное перемещение | POST может превратиться в GET |
| 302 | Временное перемещение | Также допускает изменение POST на GET |
| 307 | Временное перемещение с сохранением метода | Проверить поддержку клиентом |
| 308 | Постоянное перемещение с сохранением метода | Учесть кеширование и интеграции |
| canonical | Указание предпочтительного адреса документа | Не перенаправляет посетителя |
Различия методов определены в RFC 9110. Это особенно важно для API и отправки форм: правило, приемлемое для просмотра статьи через GET, может изменить смысл POST-запроса. Не выбирайте код только по знакомому названию из SEO-инструкции.
Canonical применяют, когда несколько адресов остаются доступны, а нужно обозначить предпочтительный. Если старый адрес действительно заменён новым и не должен обслуживать отдельный документ, серверный редирект решает другую задачу. Не пытайтесь исправить цикл перенаправлений добавлением canonical в недостижимую страницу.
В справке Яндекс Вебмастера отдельно описана обработка переходов в пределах хоста и между хостами. Для SEO важен весь маршрут: куда он ведёт, доступна ли цель роботу и соответствует ли она исходной странице. Мы не обещаем фиксированный процент передачи ссылочного веса или неизменность позиций после переезда.
Как составить карту перенаправлений страниц
Выгрузите старые адреса из CMS, Sitemap, внутреннего обхода, аналитики и известных внешних ссылок. Для каждого определите новое назначение. Приоритет отдайте адресам с реальными переходами и важным содержимым, но не исключайте остальные только потому, что в последнем месяце у них не было визитов.
| Старый URL | Новый результат | Причина |
|---|---|---|
| /old-service/ | /services/new-service/ | Та же услуга в новой структуре |
| /catalog/item-a/ | /products/item-a/ | Перенос той же карточки |
| /guide-part-1/ и /guide-part-2/ | /guides/full-guide/ | Материалы объединены в полный разбор |
| /removed-item/ без замены | Корректная страница отсутствия | Нет содержательно подходящего назначения |
Массовый перенос всех удалённых страниц на главную создаёт обманутые ожидания: человек искал конкретный товар, а получил общий сайт. Если подходящей замены нет, корректный ответ об отсутствии может быть лучше нерелевантного редиректа. Решение зависит от содержания, а не от желания любой ценой убрать все 404 из отчёта.
Для объединённых материалов проверьте, что новая страница действительно покрывает содержание старых. Совпадение раздела недостаточно. Сохраните в карте объяснение решения - оно поможет при проверке спорных адресов после запуска.
Как настроить редирект в Apache, NGINX или CMS
Редирект может находиться в CDN, балансировщике, Nginx, Apache, приложении или CMS-плагине. Сначала прочитайте текущую конфигурацию и фактическую цепочку ответа. Добавление ещё одного правила в .htaccess ничего не даст, если запрос до Apache не доходит.
Когда правила переходов находятся на reverse proxy, настройка NGINX должна учитывать то, какие заголовки и протокол получает приложение. Перед изменением сохраните действующую конфигурацию и примеры полных цепочек ответа.
Особенно внимательно проверяйте определение HTTPS за обратным прокси. Внешний запрос может быть защищённым, а внутренняя связь прокси с приложением - другой. Если приложение неправильно определяет схему, оно начинает перенаправлять уже защищённый адрес на него самого. Исправляют доверенную конфигурацию прокси, а не бесконечно добавляют исключения в CMS.
Соберите правила в понятную систему: конкретные переносы, затем согласованная нормализация адресов. Изменение порядка может изменить результат. Не объединяйте независимые примеры из интернета в один файл без анализа условий и того, какие модули их обрабатывают.
Для Apache с доступным mod_alias можно использовать точное выражение по пути. В примере символы начала и конца ограничивают совпадение только адресом /old-service/.
RedirectMatch 301 ^/old-service/$ https://example.com/services/new-service/Синтаксис описан в документации RedirectMatch. Пример не охватывает вариант без завершающего слеша и не задаёт отдельную бизнес-политику параметров. Это специально узкое правило, а не универсальный конфиг миграции.
Проверьте адреса /old-service/, /old-service-extra/ и /old-service/child/. Последние два не должны случайно попасть под точечный перенос. Если нужно переносить целый раздел, это уже другое правило с явным сохранением или преобразованием остатка пути.
Применимость .htaccess зависит от настройки сервера. При доступе к основной конфигурации проверьте синтаксис штатным инструментом сервера до применения. После изменения проверьте публичный ответ: успешная проверка синтаксиса не подтверждает правильность выбранного назначения.
В NGINX для одного точного пути внутри нужного server можно задать:
location = /old-service/ {
return 301 https://example.com/services/new-service/$is_args$args;
}Здесь сохраняются исходные параметры запроса. Делать это нужно только после согласования их назначения; пример относится к одному пути и не переносит вложенные страницы. Директива описана в документации NGINX. Проверьте, что server выбран для нужного хоста и правило не конфликтует с другими уровнями.
В WordPress, 1С-Битрикс и конструкторах переход может задаваться через настройки платформы, модуль или плагин. Название CMS не определяет единственное место настройки: сначала выясните, откуда приходит текущий ответ. В интерфейсе нужны как минимум исходный путь, назначение и выбранный код. После сохранения откройте старый URL без авторизации и проверьте сеть. Не включайте одновременно одинаковое правило в плагине, сервере и CDN.
Как избежать цепочек, циклов и потери параметров
Типичная цепочка: http со старым доменом → https со старым доменом → новый домен → новый путь. Каждый переход - дополнительный запрос и ещё одно место ошибки. Для обычного переноса страницы стремитесь вести известные варианты сразу на согласованный конечный URL, если это совместимо с выбранной процедурой переезда.
Цикл возникает, когда два уровня спорят: один добавляет www, второй убирает; один добавляет слеш, второй удаляет. Зафиксируйте единую политику адресов и уберите противоречие в источнике. Повышение допустимого числа переходов не исправляет цикл.
При смене домена поисковики могут описывать специальную последовательность уведомления и переноса. Сверяйте её отдельно с текущей документацией и планом миграции: общее пожелание сократить цепочку не заменяет требования конкретного процесса.
Рекламные метки нужны для атрибуции; фильтр может менять набор товаров; параметр языка - содержание; служебный токен - доступ к операции. У этих параметров разные назначения. Составьте таблицу «сохранить, преобразовать, удалить» и согласуйте её с аналитикой и разработкой.
Учебный переход /old-service/?utm_source=yandex должен сохранять измеримый источник, если по нему идёт реклама. Но перенос устаревшего параметра page=999 на новую страницу услуги может не иметь смысла. Не копируйте все параметры на внешний домен без понимания их содержимого.
Фрагмент после # не отправляется серверу как часть HTTP-запроса, поэтому серверное правило не может выбирать назначение по нему так же, как по пути. Старые ссылки с якорями нужно отдельно проверить в браузере на конечной странице.
Учебная инфраструктура: посетитель приходит по HTTPS на прокси, тот обращается к приложению по внутреннему HTTP. Приложение видит незашифрованный внутренний запрос и выполняет 301 на тот же внешний HTTPS-адрес. Следующий запрос проходит тем же путём, поэтому цикл повторяется. Сертификат при этом может быть полностью исправен.
Начните с цепочки Location: если адрес повторяется, сравните, какой компонент формирует ответ. Проверьте настройку доверенных прокси и передачу исходной схемы в соответствии с документацией используемого приложения. Нельзя просто доверять заголовку от любого клиента: доверие должно относиться к известному прокси, который корректно задаёт или очищает этот заголовок.
Затем определите единственное место принудительного перехода на HTTPS и согласуйте его с приложением. Отключение проверки схемы на одном уровне без понимания архитектуры может скрыть цикл, но оставить неправильные абсолютные ссылки и cookies. Поэтому проверяйте не только редирект, но и формирование URL внутри страницы.
Матрица после правки: внешний HTTP переходит на HTTPS; внешний HTTPS сразу открывает нужную страницу; форма отправляется на ожидаемый защищённый адрес; callback интеграции не меняет метод неожиданно. В журнале фиксируйте внешний запрос и соответствующий ответ, не раскрывая пользовательские данные.
Если цикл исчез только в одном браузере, проверьте кеш и разные узлы доставки. Если исчез только при прямом обращении к источнику, проблема может оставаться на прокси. Оба наблюдения нужны для локализации, но не дают основания объявить виновным конкретный компонент без проверки его ответа.
Как проверить 301-редирект и конечную страницу
Сначала получите первый ответ GET без автоматического следования. Для PowerShell используйте curl.exe; домен в примере учебный.
curl.exe -sS -D - -o NUL "https://example.com/old-service/"Проверьте код и Location. Затем посмотрите все переходы:
curl.exe -sS -L --max-redirs 10 -D - -o NUL "https://example.com/old-service/"NUL - имя устройства вывода Windows; в другой системе способ отбросить тело будет отличаться. Команды не используют HEAD, поэтому проверяют получение ресурса методом GET. Конечный код 200 ещё не доказывает правильную страницу: отдельно откройте назначение и проверьте заголовок и содержание.
Для массовой карты сохраняйте старый URL, первый статус, всю цепочку, конечный URL, конечный статус и смысловую проверку. Ограничивайте нагрузку на свой сервер. Не отправляйте реальные POST-запросы с рабочими данными ради проверки редиректа: интеграции тестируют в согласованной среде.
- Точный старый адрес и ожидаемая конечная страница.
- Варианты HTTP/HTTPS и хоста, если они существовали.
- Адрес со слешем и без него согласно принятой политике.
- Рекламные и функциональные параметры.
- Похожий путь, который не должен совпадать с правилом.
- Несуществующий URL, который должен остаться отсутствующим.
- Формы, API, файлы и изображения, которые не относятся к переносу страниц.
- Работа конечной страницы без авторизации и без старого браузерного кеша.
Проверка в свежем контексте важна, потому что постоянные редиректы могут кешироваться. Если после исправления один браузер продолжает старое поведение, сравните сетевой ответ и кеш, прежде чем повторно менять сервер. Также проверьте CDN: ответ у него и у источника может временно различаться.
Что обновить на сайте после настройки редиректов
Перепишите внутренние ссылки на конечные адреса, обновите Sitemap и canonical, проверьте меню, хлебные крошки, рекламные ссылки и интеграции. Редирект нужен для старых входов; собственная навигация не должна постоянно использовать устаревшие маршруты.
Если переходы появились из-за новой структуры, включите обновление ссылок и карт адресов в редизайн сайта с сохранением структуры переходов. Перенаправление не должно оставаться постоянной заменой исправления собственных ссылок.
Сохраните карту и резервную копию конфигурации. План отката должен учитывать кеширование: возврат старого файла не мгновенно отменяет уже сохранённые клиентами постоянные ответы. Поэтому широкие правила сначала проверяют на стенде и ограниченной выборке.
После релиза наблюдайте ошибки, обращения к старым URL и состояние новых страниц в поиске. Не удаляйте правила сразу после первого успешного обхода: старые внешние ссылки и закладки продолжают существовать. Срок поддержки определяйте по плану миграции и данным, а не произвольной короткой дате.
Полный перенос разобран в плане миграции сайта, отсутствие подходящей замены - в статье про ошибку 404. После изменений проверьте Sitemap и индексацию конечных URL.
Для смены домена и путей есть особенность: Яндекс описывает последовательный переход через новый домен со старым путём. Поэтому совет сокращать цепочки применяют вместе с конкретным планом переезда, а не вместо него. Мы заранее фиксируем выбранную схему и проверяем её целиком.
В передаче результата нам нужен список правил, карта адресов, фактические ответы и ответственный за наблюдение после запуска. Если сайт продолжает меняться, включите эти проверки в сопровождение сайта после изменений. Так перенаправления остаются частью понятной навигации, а не коллекцией забытых исключений.