Цепочки редиректов: почему 301 настроен, а проблема осталась

Редирект после смены URL может быть настроен формально правильно, но всё равно работать плохо. Например, старый адрес ведёт на http, потом на https, потом на www, потом убирает слеш, потом только попадает на нужную страницу. Пользователь этого почти не замечает, но лишние переходы замедляют загрузку и создают технический шум.

Хороший редирект ведёт с устаревшего URL на актуальный коротким путём. В большинстве случаев это один 301.

Проверить цепочку curl

Для просмотра цепочки удобно использовать curl с ключом -L и выводом URL после каждого перехода.

curl -I https://example.ru/old-page/
curl -IL https://example.ru/old-page/

Если видно несколько Location подряд, нужно понять, какие из них лишние. Нормальная цель — привести старый адрес сразу к конечному каноническому URL.

301 или 302

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

HTTP/2 301
location: https://example.ru/new-page/

Если старые URL долго отдают 302, поисковые системы могут воспринимать перенос менее определённо. Для временных акций 302 подходит, для постоянной смены адресов — обычно нет.

HTTP, HTTPS, www и слеш

Частая причина длинной цепочки — правила настроены отдельными слоями. Сначала http переводится на https, потом www на non-www, потом добавляется или убирается слеш.

http://www.example.ru/page
301 -> https://www.example.ru/page
301 -> https://example.ru/page
301 -> https://example.ru/page/

Лучше сразу вести на конечный вариант:

http://www.example.ru/page
301 -> https://example.ru/page/

nginx: общий редирект домена

Для www на non-www правило может быть отдельным server-блоком:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.ru;

    return 301 https://example.ru$request_uri;
}

Для HTTP на HTTPS основного домена:

server {
    listen 80;
    server_name example.ru;

    return 301 https://example.ru$request_uri;
}

Конкретная конфигурация зависит от SSL и структуры server-блоков, но смысл один: не собирать цепочки из нескольких лишних шагов.

Редиректы старых страниц

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

rewrite ^/old-service/$ /services/new-service/ permanent;
rewrite ^/old-blog/post-1/$ /blog/post-1/ permanent;

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

Yii2 и редиректы в приложении

Часть редиректов можно делать в приложении, но базовые технические переходы вроде HTTP на HTTPS и www лучше обрабатывать на уровне веб-сервера. Так запрос не будет зря запускать PHP.

return $this->redirect(['/new-route'], 301);

В Yii2 такой редирект полезен для бизнес-логики: например, старый slug статьи изменился, но запись найдена по alias.

Canonical не заменяет редирект

Если старая страница открывается с кодом 200 и просто указывает canonical на новую, это не то же самое, что 301. Для явного переезда URL лучше использовать редирект.

Canonical полезен для дублей, параметров и похожих страниц, но старые адреса после смены структуры обычно лучше переводить 301.

sitemap должен содержать конечные URL

В sitemap.xml не нужно оставлять адреса, которые редиректят. Карта сайта должна содержать URL с кодом 200.

curl https://example.ru/sitemap.xml | grep "old"

Если URL из sitemap отдаёт 301, лучше обновить генератор карты сайта.

Чек-лист проверки редиректов

1. Проверить старые важные URL через curl -IL.
2. Убрать лишние цепочки HTTP/HTTPS и www.
3. Заменить временные 302 на 301 для постоянных переездов.
4. Не редиректить все старые страницы на главную.
5. Проверить слеши в конце URL.
6. Проверить, что sitemap содержит конечные URL с 200.
7. Проверить canonical на новых страницах.
8. Посмотреть 404 и 301 в логах после запуска.

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