Справочник по редиректам

Мануал по редиректам: какие бывают, когда какой использовать и как не сломать SEO

Это не статья из блога, а рабочая справочная страница для команды, разработчиков и SEO-специалистов. Здесь собраны типы редиректов, паттерны для продакшена и практические правила выбора.

Справочник

Какие бывают редиректы

Не все редиректы решают одну и ту же задачу. Самая частая ошибка в продакшене не в том, что редирект вообще есть, а в том, что выбран не тот тип.

301 Moved Permanently

Постоянный серверный редирект.

Использовать для
переезд страницы на новый URL
миграция HTTP -> HTTPS
канонизация www/non-www
удаление дублей и консолидация
Не использовать для
Не используйте для временных промо, A/B тестов и коротких кампаний.
Вывод: Основной безопасный редирект для постоянных изменений.
302 Found

Временный серверный редирект.

Использовать для
краткосрочная замена страницы
временная кампания
временный режим обслуживания
Не использовать для
Не оставляйте 302 на месяцы для постоянных миграций.
Вывод: Нормален только когда изменение реально временное.
307 Temporary Redirect

Временный редирект с сохранением HTTP-метода.

Использовать для
API и формы, где важно не менять POST/PUT на GET
временные сценарии маршрутизации на бэкенде
Не использовать для
Для обычных SEO URL чаще понятнее и проще использовать 302.
Вывод: Полезен больше для технического поведения, чем для контентных страниц.
308 Permanent Redirect

Постоянный редирект с сохранением HTTP-метода.

Использовать для
постоянный перенос API
сценарии, где нельзя потерять исходный метод запроса
Не использовать для
Не нужен по умолчанию для большинства URL в контентных миграциях.
Вывод: Технически корректен, но для SEO-страниц 301 обычно проще и привычнее.
Meta Refresh

Редирект в HTML, а не на уровне HTTP.

Использовать для
почти никогда
Не использовать для
Не используйте как основной редирект при миграции.
Вывод: Слабый и хрупкий вариант. Для SEO и надёжности хуже серверных редиректов.
JavaScript Redirect

Редирект после загрузки страницы в браузере.

Использовать для
только как крайний запасной вариант, если серверный редирект невозможен
Не использовать для
Не стройте на этом слой миграции или управление canonical.
Вывод: Плохой базовый выбор для SEO. Краулеры и внешние клиенты видят его нестабильно.

Выбор

Какой редирект использовать в реальных сценариях

Самый полезный вопрос не “какой статус-код существует”, а “какой нужен в этом кейсе”.

Сценарий

Страница навсегда переехала на новый slug

Ответ
301
Почему

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

Сценарий

Переезд на новый домен

Ответ
301
Почему

Это классическая постоянная миграция. Все старые URL должны вести напрямую в финальные канонические адреса.

Сценарий

Временная промостраница или краткосрочная кампания

Ответ
302
Почему

После окончания кампании исходный URL должен вернуться как основной.

Сценарий

API endpoint временно перенесён, но метод POST должен сохраниться

Ответ
307
Почему

307 сохраняет метод запроса и лучше подходит для технических сценариев.

Сценарий

API endpoint переехал навсегда, и метод должен сохраниться

Ответ
308
Почему

Это постоянный перенос с сохранением исходного метода запроса.

Сценарий

Хочется “быстро закрыть вопрос” через JavaScript-редирект

Ответ
Не надо
Почему

Это почти всегда временный костыль, который потом бьёт по SEO, отладке и стабильности краулинга.

Чеклист

Правила безопасных редиректов для продакшена

Даже правильный статус-код бесполезен, если редирект-слой собран неаккуратно.

Делайте один прямой переход до финального canonical URL, а не цепочку из двух-трёх промежуточных переходов.

Не смешивайте несколько задач в одной цепочке. HTTP -> HTTPS, non-www -> www и old-path -> new-path лучше схлопывать в один финальный редирект.

Не держите временные 302 там, где решение уже давно стало постоянным.

Не редиректите удалённый контент на нерелевантную главную страницу просто “чтобы не было 404”.

Проверяйте редиректы не только браузером, но и как HTTP-цепочку: промежуточные переходы, final URL, время ответа и проблемы.

Перед выкладкой карта миграции должна быть выборочно проверена на самых трафиковых и самых часто линкуемых URL.

Риски

Чего делать не стоит

Ниже паттерны, которые чаще всего делают слой редиректов «рабочим», но вредным.

301 -> 302 -> 200

Смешивает постоянную и временную семантику, усложняет путь краулера и создаёт лишнюю точку отказа.

Любые старые URL вести на главную страницу

Это плохой UX и слабое соответствие намерению. Для SEO это часто хуже, чем честный 404/410 или релевантная целевая страница.

Редирект только через front-end router

Браузер может показать корректный экран, но HTTP-ответ останется неправильным для поисковиков и внешних клиентов.

Оставить meta refresh с мыслью «потом переделаем»

Обычно это «потом» не наступает. В итоге миграция живёт на слабом механизме редиректа месяцами.

Краткий безопасный вывод для SEO

Если URL переехал навсегда, почти всегда нужен 301.

Если изменение временное, используйте 302.

Если это API или форма и надо сохранить HTTP-метод, смотрите в сторону 307 или 308.

Если идея в том, чтобы сделать redirect через JS или meta refresh, значит архитектурно решение почти наверняка выбрано не то.

FAQ

301 всегда лучше 302?

Нет. 301 лучше только для постоянного изменения. Если изменение временное, честнее и правильнее использовать 302.

Можно ли использовать 308 вместо 301?

Можно, но для большинства контентных SEO-сценариев 301 остаётся более понятным и ожидаемым выбором. 308 полезнее там, где важно сохранить HTTP-метод.

Когда лучше 404 или 410 вместо редиректа?

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

После чтения мануала редиректы всё равно нужно проверять на реальной цепочке

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

Связанные маршруты

Используй мануал вместе с live-инструментами и подробными статьями