301 редирект: когда он нужен, как его настроить и что происходит с позициями

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

«Мы в anyseo относимся к редиректу как к операции над индексом, а не как к строчке в конфиге, — говорит Алексей Крайнов, автор блога anyseo. — Строчку можно написать за пять минут. Дальше поисковая система несколько недель решает, какой адрес показывать людям, и на это решение влияет всё: статус ответа, длина цепочки, совпадение содержимого и даже canonical, который забыли снять».

Разберём по порядку: что этот код означает по спецификации, чем он отличается от соседних, как его прописывать на разных серверах и что происходит с позициями после переклейки.

Что такое 301 редирект простыми словами

301 — это код ответа сервера, который говорит: страница переехала навсегда, новый адрес указан в заголовке Location.

Обмен выглядит так: браузер запрашивает старый URL. Сервер вместо содержимого отдаёт короткий ответ со статусом 301 и полем Location с новым адресом. Браузер молча идёт по нему, и человек видит уже новую страницу — часто даже не заметив пересадки.

Поисковый робот в той же ситуации делает больше. Он не просто переходит, а запоминает: этот адрес заменён. Справка Google по HTTP-статусам для краулеров формулирует это так — при 301 «системы Google используют редирект как сильный сигнал», что обрабатывать надо целевой адрес.

Ключевое слово здесь — «навсегда». Временный редирект устроен иначе и приводит к другому результату.

301, 302, 307 и 308: чем отличаются и когда какой

Четыре кода редиректа различаются по двум признакам: постоянство и обращение с методом запроса. Спецификация HTTP — RFC 9110 — описывает их в соседних разделах.

У 301 и 302 в RFC 9110 стоит одинаковая оговорка: по историческим причинам клиент вправе заменить метод POST на GET, и если такое поведение нежелательно, спецификация советует взять 308. Ровно для этого 307 и 308 и придумали — у 307 сказано жёстко: клиент не должен менять метод запроса.

Для поисковых систем разница проще. В справке Google 308 назван эквивалентом 301, а 307 — эквивалентом 302. Там же стоит оговорка: коды обрабатываются одинаково, но семантически различаются, поэтому выбирать надо подходящий по смыслу — им пользуются и другие клиенты, от читалок до чужих поисковых роботов.

Практический вывод: для постоянного переезда обычной страницы берите 301, для форм и API, где важно сохранить POST, — 308, для временной заглушки — 302 или 307.

Про возраст: примечание RFC называет 308 заметно более молодым кодом, чем его собратья, — он появился в июне 2014 года, и спецификация предупреждает, что распознают его не везде. За прошедшие годы поддержка стала повсеместной, но в древнем самописном клиенте сюрприз возможен.

Редирект, canonical и склейка зеркал — три разных инструмента

Эти три вещи решают похожую задачу — сказать поиску, какой адрес считать основным, — но работают несовместимо.

Редирект физически уводит с адреса. Страница по старому URL перестаёт существовать для всех: и для человека, и для робота.

`rel="canonical"` оставляет обе страницы доступными и лишь рекомендует поиску, какую считать основной. Это подсказка, а не команда. Для дублей, которые должны остаться доступными людям, годится только она.

Склейка зеркал — механизм Яндекса, который объединяет несколько адресов одного сайта в группу и выбирает среди них главный. Редирект для склейки — сигнал, но не сам механизм.

Смешивать их опасно. В справке Яндекса по переезду разбирается ситуация, когда заявка на переезд не выполняется: если на страницах сайта, который должен стать главным адресом, остался атрибут rel="canonical", его нужно удалить и отправить заявку заново. Canonical, забытый после переноса, тихо отменяет переезд.

Когда 301 редирект действительно нужен

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

Переезд на HTTPS и склейка www

Самый частый случай — не смена домена, а четыре адреса одного сайта: с www и без, по HTTP и по HTTPS. Домен один, а адресов четыре.

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

Сам по себе префикс роли не играет — там же сказано, что поисковой системе нет разницы, содержит адрес www или нет. Важно не какой вариант выбран, а то, что выбран один и остальные три ведут на него.

Смена домена и перенос старых адресов

При переезде на новый домен работает правило соответствия: каждая страница старого сайта ведёт на аналогичную страницу нового, а не куда придётся. Новое доменное имя не наследует историю старого само по себе — её переносят редирект и заявка в Вебмастере.

Если одновременно поменялись и домен, и структура каталогов, справка Яндекса допускает двойной редирект и приводит собственный пример: http://сайт.рф/стр/ → http://example.ru/стр/ → http://example.ru/page/. Это редкий случай, когда лишний хоп в цепочке разрешён первоисточником.

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

Удалённые, объединённые и переименованные страницы

Здесь чаще ошибаются в другую сторону — ставят 301 там, где честнее 404.

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

Если преемника нет — материал удалён и заменять его нечем, — правильный ответ 404 или 410. Перенаправление «лишь бы не 404» создаёт проблему, к которой вернёмся ниже.

Как настроить 301 редирект

Дальше — рабочие конфиги. Настройка 301 редиректа зависит от того, что стоит перед вашим приложением: у Apache, Nginx и панели хостинга синтаксис разный.

Apache и файл .htaccess

На Apache редирект прописывают в файле .htaccess в корневой директории сайта или в конфигурации виртуального хоста.

Чтобы сделать 301 редирект для одного адреса, хватает модуля mod_alias и одной строки:

Redirect 301 /old-page https://example.com/new-page

Групповые правила и условия — это mod_rewrite:

RewriteEngine On

# без www → на адрес без префикса, любой протокол
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# http → https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# один раздел целиком
RewriteRule ^catalog/old/(.*)$ /catalog/new/$1 [R=301,L]

Что означают флаги: R=301 задаёт статус ответа, L останавливает обработку правил на текущем, NC отключает чувствительность к регистру. Без L сервер продолжит перебирать правила и легко соберёт цепочку из двух-трёх редиректов там, где вы задумывали одно.

Переменная %{REQUEST_URI} содержит запрошенный путь целиком — она пригодится, когда нужно перенести адрес вместе с параметрами. Правило для директории пишется тем же способом: шаблон ловит префикс, а $1 подставляет остаток пути.

Nginx

Nginx ничего не читает из .htaccess — конфигурация правится в файле сервера и применяется перезагрузкой.

# отдельный адрес
location = /old-page {
    return 301 https://example.com/new-page;
}

# весь домен с www на адрес без префикса
server {
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

# группа адресов по маске
rewrite ^/catalog/old/(.*)$ /catalog/new/$1 permanent;

Ключевое слово permanent в директиве rewrite даёт 301, redirect — 302. Конструкция return предпочтительнее: она короче и не запускает разбор регулярного выражения.

На стороне приложения: PHP, Node.js, web.config

Когда правило зависит от данных — например, от таблицы соответствий старых и новых адресов, — редирект отдаёт само приложение.

В PHP заголовки нужно отправить до любого вывода на экран, иначе они не уйдут. Google в справке по редиректам приводит такой пример:

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();

В Node.js на Express то же самое занимает строку:

app.get('/old-page', (req, res) => res.redirect(301, '/new-page'));

На IIS правила живут в web.config, в секции <rewrite>: синтаксис XML, логика та же, что у mod_rewrite, а обработку запроса берёт на себя сам сервер.

Через CMS и панель хостинга

Если доступа к конфигурации нет, остаются два пути.

Панель управления хостингом почти всегда содержит настройки редиректов: вы задаёте пару «откуда — куда» и тип, панель сама дописывает правило в настройки сервера.

В CMS задачу решает плагин или встроенная настройка. Это удобно для точечных случаев и заметно медленнее серверного правила: запрос проходит через приложение и базу данных, прежде чем получить ответ. Массовое объединение адресов домена лучше держать на сервере, а на плагин отдавать разовые переносы страниц.

Что происходит с позициями и ссылочным весом

Здесь придётся сказать то, о чём в блогах пишут неохотно: ни одна из двух поисковых систем не обещает, что позиции сохранятся.

Формулировка повторяется в нескольких статьях справки Вебмастера почти дословно: объединение адресов позволяет передать некоторые накопленные показатели старого сайта новому — например, внешние ссылки старого сайта будут учитываться как внешние ссылки нового, — однако это не гарантирует сохранение количества страниц в результатах поиска, позиций или посещаемости.

Google в справке по HTTP-статусам называет 301 сильным сигналом, а 302 — слабым. Слова «передаёт вес полностью» в документации нет.

Популярное утверждение «301 переносит сто процентов ссылочного веса» восходит к устному выступлению сотрудника Google на отраслевой конференции 2016 года, а не к документу. Проверяемая формулировка звучит скромнее: редирект — сильный сигнал для объединения адресов, часть накопленных показателей переносится, точной доли не называет никто.

Сколько ждать переклейки

Сроки в справках названы, и они длиннее, чем ожидает большинство.

Яндекс пишет, что смена главного адреса сайта происходит в течение нескольких недель, а заявка на переезд выполняется от нескольких недель до месяцев — в зависимости от типа переезда, скорости обхода сайтов роботом и обновления данных о адресах в выдаче.

У Google механика другая. Чтобы переезд считался завершённым, робот должен посетить каждый адрес старого и нового сайта хотя бы один раз, и происходит это поадресно. Фиксированной частоты обхода нет — она зависит от размера сайта и допустимой скорости краулинга.

Отсюда практическое следствие: старый адрес в выдаче через неделю после переезда — не поломка. Google прямо пишет, что после смены домена старые URL ещё какое-то время появляются в результатах, даже когда новые уже проиндексированы, и называет это нормальным.

Что сделать в Яндекс Вебмастере и Search Console

Перенаправление — половина работы. Вторая половина делается в панелях.

В Яндекс Вебмастере есть инструмент «Переезд сайта» в разделе «Индексирование». Он не заменяет редирект, а ускоряет учёт изменений: робот узнал бы о новом главном адресе при очередном обходе, а через инструмент вы сообщаете об этом сразу. Условия из справки: оба сайта добавлены в Вебмастер и подтверждены, содержимое совпадает, индексирование разрешено в файлах robots.txt обоих доменов, ответ сервера укладывается в десять секунд, новый адрес отдаёт 200, старый — 200 либо код перенаправления. Годится и 301, и 302 — Яндекс принимает оба.

В Search Console переезд с изменением адресов оформляется по инструкции Google: подтвердить оба ресурса, загрузить новую карту сайта, следить за отчётами по индексированию и трафику на обоих сайтах.

Одна деталь экономит часы отладки: в справке Google по HTTP-статусам сказано, что инструменты проверки URL перенаправления не проходят. Проверить цепочку через инспектор страницы не получится — для этого нужен запрос к серверу.

Ошибки, из-за которых редирект вредит

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

Цепочки и петли редиректов

Цепочка — это когда старый адрес ведёт на промежуточный, тот на следующий, и лишь третий отдаёт содержимое.

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

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

Мы проверили собственный сайт и нашли у себя ровно такую цепочку. Запрос http://www.anyseo.io/ доходит до конечного адреса за два перехода: сначала меняется протокол, потом с домена снимается префикс. Одно правило вместо двух решило бы это в один хоп. В пределах лимита — да, но именно такую конструкцию Google просит не делать. Проверка сделана 10 сентября 2026 года, повторить её можно одной командой из раздела ниже.

Редирект всех страниц на главную

Соблазн понятный: страниц удалили много, сопоставлять лень, отправим всё в корень сайта.

Обе поисковые системы против, и по разным причинам. Google в инструкции по переезду пишет, что не надо направлять множество старых адресов на один нерелевантный, например на главную нового домена: это запутывает людей и может быть расценено как ошибка soft 404. Яндекс в справке по переезду формулирует иначе: такая организация редиректов неудобна пользователям и, следовательно, снижает скорость индексации нового сайта роботом.

То есть Google видит в этом подделку под содержимое, Яндекс — потерю скорости обхода. Результат в обоих случаях хуже, чем честный 404 на страницах без преемника.

301 закешировался в браузере

Эта ловушка стоит своего абзаца, потому что выглядит как мистика.

RFC 9110 говорит, что ответ 301 кешируется эвристически — то есть клиент вправе сохранить и повторно использовать его, даже если явных заголовков управления кешем не пришло. Та же оговорка стоит у 308.

Последствие: вы поправили правило на сервере, а браузер продолжает уводить вас на старый адрес, потому что помнит прошлый ответ. Отладка идёт по кругу, при этом у робота всё уже правильно.

Лечится двумя способами. На время отладки отдавайте редирект с явным Cache-Control: no-store. А проверяйте не в своём браузере, а запросом к серверу — он кеш не читает.

Как проверить, что редирект работает

Проверка занимает одну команду. Смотреть надо на код ответа и на заголовок Location, а не на то, куда в итоге привёл браузер.

# код и заголовки одного адреса
curl -sSI https://example.com/old-page

# вся цепочка целиком, с числом переходов
curl -sSL -o /dev/null -w "хопов: %{num_redirects}, финал: %{url_effective}\n" \
     https://example.com/old-page

Что проверять по списку:

1. Код: 301, а не 302, если переезд постоянный.
2. Location: абсолютный адрес с нужным протоколом.
3. Число переходов: в идеале один.
4. Конечная страница: отвечает 200, а не 404.
5. Выборка адресов: не только корневой адрес домена. Возьмите страницу из глубины каталога, адрес с параметрами и адрес со слешем на конце.

Последний пункт мы проверили на себе и получили неожиданный результат. Один и тот же адрес anyseo.io отдаёт разный код разным методам запроса: на GET приходит 301, на HEAD — 308. Замер сделан 10 сентября 2026 года, воспроизводится обеими командами выше. Причину мы пока не выясняли, но вывод для проверки прямой: инструмент, который ходит методом HEAD, покажет не то же самое, что видит браузер. Если два сервиса дают разные ответы по одному адресу — сначала посмотрите, каким методом каждый из них спрашивает.

Частые вопросы

Можно ли отменить 301? Технически да: достаточно убрать правило из конфигурации. Практически поиску потребуется столько же времени на обратную переклейку, сколько ушло на прямую, а у части людей адрес останется в кеше браузера. Отменять постоянный редирект стоит только при реальной ошибке.

Что делать с GET-параметрами? В Apache строка запроса не входит в шаблон RewriteRule — для условий по параметрам берут %{QUERY_STRING}, в Nginx подставляют $request_uri, который содержит путь вместе с параметрами.

Нужен ли редирект между мобильной и основной версией? Если у вас отдельный мобильный поддомен — да, и парный: с мобильной страницы на соответствующую основную и обратно, по определению устройства. Для адаптивной вёрстки редирект не нужен вовсе.

Что выбрать для формы или API — 301 или 308? 308. По RFC 9110 при 301 клиент вправе превратить POST в GET, и тело запроса потеряется по дороге.

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