Чтобы исправить цепочки редиректов после смены URL, найдите все адреса, которые проходят через два и более перенаправления, определите конечный канонический URL и измените правила так, чтобы каждый старый адрес сразу возвращал один постоянный редирект на конечную страницу. Одновременно обновите внутренние ссылки, sitemap, canonical и hreflang, иначе сайт продолжит создавать лишние переходы даже после исправления серверных правил.
Что считать цепочкой редиректов
Цепочка возникает, когда запрошенный URL перенаправляет не сразу на целевую страницу, а на другой промежуточный адрес:
https://example.com/old
301 → https://example.com/category/old
301 → https://www.example.com/category/new/
200 → конечная страницаПравильная схема для окончательно перенесённой страницы:
https://example.com/old
301 → https://www.example.com/category/new/
200 → конечная страницаОтдельно проверьте циклы, при которых адреса перенаправляют друг на друга или правило возвращает пользователя на уже пройденный URL. Цикл обычно заканчивается ошибкой браузера или превышением допустимого числа редиректов.
Инструкция применима к обычным HTTP-перенаправлениям 301, 302, 307 и 308 независимо от CMS. Примеры конфигурации ниже предназначены для типовых установок Apache HTTP Server и nginx. Расположение конфигурационных файлов и порядок подключения правил зависят от конкретного хостинга, панели управления и архитектуры приложения.
Шаг 1. Зафиксировать конечные URL
До изменения конфигурации составьте таблицу соответствий. Для каждого старого адреса должен быть указан один конечный URL, который:
- возвращает HTTP-статус 200;
- доступен без дополнительного редиректа;
- использует выбранный протокол и вариант домена;
- имеет согласованный формат завершающего слеша;
- содержит актуальный контент, соответствующий старой странице.
| Старый URL | Промежуточный URL | Конечный URL | Действие |
|---|---|---|---|
| /catalog/item-10 | /products/item-10 | /shop/item-10/ | Направить старый URL сразу на конечный |
| /blog/post-a | /articles/post-a | /articles/post-b/ | Проверить соответствие материала и убрать промежуточный переход |
Не назначайте редирект автоматически только по похожему адресу. Если старой странице нет содержательно подходящей замены, корректнее вернуть 404 или 410, чем отправлять все удалённые URL на главную страницу или нерелевантный раздел.
Перед правкой правил сохраните текущую конфигурацию и список обнаруженных цепочек. Массовая замена без таблицы соответствий может создать циклы, перенаправить служебные URL или потерять переходы со старых внешних ссылок.
Шаг 2. Проверить цепочку для отдельного URL
Для ручной проверки используйте браузерные инструменты разработчика или curl. Следующая команда выводит заголовки всех ответов при переходе по цепочке и ограничивает число перенаправлений:
curl -sS -o /dev/null -D - -L --max-redirs 10 "https://example.com/old-url"В выводе последовательно найдите строки статуса и заголовки Location:
HTTP/2 301
location: https://example.com/intermediate-url
HTTP/2 301
location: https://example.com/final-url/
HTTP/2 200После исправления ожидается один ответ 301 и затем ответ 200:
HTTP/2 301
location: https://example.com/final-url/
HTTP/2 200Команда не доказывает, что страница корректно индексируется: она проверяет только HTTP-маршрут. Содержимое конечной страницы, canonical, robots directives и доступность для поискового робота нужно проверять отдельно.
Шаг 3. Найти цепочки по всему сайту
Для массовой проверки запустите краулер, который умеет следовать редиректам и экспортировать отчёт по цепочкам. В область обхода включите:
- текущие страницы сайта;
- старые URL из предыдущих sitemap и файлов миграции;
- адреса из журналов веб-сервера;
- страницы с внешними ссылками и переходами из поисковых систем;
- URL из отчётов об ошибках сканирования;
- варианты HTTP и HTTPS, с
wwwи без него.
В отчёте должны присутствовать исходный URL, каждый промежуточный адрес, статус ответа и конечная точка. Отсортируйте результаты по числу переходов. Сначала исправляйте циклы и цепочки, затрагивающие страницы с внутренними ссылками, органическим трафиком, внешними ссылками или большим числом обращений в логах.
Название отчёта и способ экспорта зависят от используемого краулера. Без доступа к конкретному инструменту нельзя достоверно указать названия пунктов меню или ограничения его текущей версии.
Шаг 4. Определить причину лишних переходов
Чаще всего цепочка появляется из нескольких независимых правил нормализации:
- HTTP перенаправляется на HTTPS.
- Домен без
wwwперенаправляется на домен сwwwили наоборот. - CMS добавляет либо удаляет завершающий слеш.
- Старый путь переводится на промежуточную структуру.
- Промежуточная структура затем переводится на новый URL.
Например, отдельные правила могут последовательно менять протокол, домен и путь:
http://example.com/old
→ https://example.com/old
→ https://www.example.com/old
→ https://www.example.com/new/Исправление должно объединить эти преобразования для старого URL:
http://example.com/old
→ https://www.example.com/new/При этом общие правила канонизации домена и протокола могут остаться для остальных адресов. Важно разместить точные правила миграции раньше общих правил CMS и проверить, что они не обрабатывают один запрос повторно.
Шаг 5. Изменить серверные правила
Пример для Apache с .htaccess
Для точного перенаправления одной старой страницы можно использовать mod_rewrite. Правило должно находиться до универсального правила, передающего запросы CMS:
RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]В контексте .htaccess шаблон RewriteRule обычно указывается без начального слеша. Не копируйте пример в конфигурацию виртуального хоста без проверки контекста: правила переписывания могут обрабатываться там иначе.
Пример для nginx
Для одного точного пути можно создать отдельный блок location:
location = /old-page {
return 301 https://example.com/new-page/;
}После изменения nginx сначала проверьте синтаксис конфигурации, а затем примените её штатным способом, установленным в вашей системе. Конкретная команда управления зависит от способа установки, имени службы, контейнеризации и полномочий пользователя, поэтому универсальная команда здесь не приводится.
Редиректы на уровне CMS
Если перенаправления настроены плагином или модулем CMS, найдите несколько последовательных записей для одного материала. Замените их одной записью «старый URL → конечный URL». Затем проверьте, не добавляет ли сама CMS дополнительную нормализацию адреса после выполнения пользовательского правила.
Не держите одинаковое перенаправление одновременно в CDN, конфигурации веб-сервера и CMS без необходимости. Разнесённые по нескольким уровням правила сложнее диагностировать, а порядок их выполнения не всегда очевиден.
Шаг 6. Обновить источники старых URL
Серверный редирект нужно сохранить для внешних переходов и старых закладок, но внутри сайта следует ссылаться сразу на конечный адрес. Проверьте и замените URL в следующих местах:
- навигация, хлебные крошки и ссылки в тексте;
- XML Sitemap;
rel="canonical";hreflangи ссылки между языковыми версиями;- структурированные данные;
- RSS-ленты;
- параметры форм, API-клиенты и JavaScript-запросы;
- шаблоны писем и выгрузки для внешних систем.
Canonical не заменяет редирект. На перенесённой странице старый URL должен отдавать перенаправление, а конечная страница — указывать canonical на собственный канонический адрес, если нет обоснованной альтернативы.
Шаг 7. Проверить результат
После применения правил выполните повторный обход и ручную проверку ключевых URL. Для каждого старого адреса подтвердите:
- первый ответ имеет ожидаемый постоянный статус, обычно 301;
- заголовок
Locationсразу содержит конечный URL; - конечный URL возвращает 200 без нового перенаправления;
- нет перехода между HTTP и HTTPS после первого ответа;
- нет смены варианта домена или завершающего слеша на втором шаге;
- конечная страница доступна для сканирования и содержит ожидаемый контент;
- внутренние ссылки больше не ведут на старый адрес.
Дополнительно просмотрите журналы сервера после публикации изменений. Повторяющиеся запросы к промежуточным URL покажут, что где-то остались старые внутренние ссылки, интеграции или внешние источники. Удалять действующие редиректы только потому, что внутренние ссылки исправлены, не следует: старые адреса могут продолжать получать внешние переходы.
Типичные ошибки
- Удаление первого редиректа. Старый URL начинает возвращать 404, хотя на него ещё ведут ссылки.
- Редирект всех удалённых страниц на главную. Пользователь и поисковая система получают нерелевантную целевую страницу.
- Использование временного редиректа для постоянного переноса. Для окончательной смены адреса обычно применяют постоянный статус.
- Исправление только sitemap. Цепочка остаётся доступной через внутренние и внешние ссылки.
- Правило после маршрутизации CMS. Запрос сначала обрабатывается приложением и только затем попадает под перенаправление либо не попадает под него вообще.
- Массовые регулярные выражения без теста. Одно слишком широкое правило может затронуть административные разделы, файлы и уже корректные URL.
Итоговый чек-лист
- Собран список старых, промежуточных и конечных URL.
- Для каждого старого адреса выбрана содержательно подходящая конечная страница.
- Циклы устранены.
- Каждый старый URL перенаправляет сразу на конечный.
- Конечный URL возвращает 200.
- Протокол, домен и формат слеша нормализуются без дополнительных шагов.
- Внутренние ссылки, sitemap, canonical и hreflang обновлены.
- Правила проверены на тестовом окружении или ограниченном наборе URL.
- После публикации выполнен повторный обход.
- Старые постоянные редиректы сохранены для внешних ссылок.