301, 302, 307 и 308 редиректы в SEO: как настроить без потери трафика

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

Ошибочно настроенный редирект может привести к выпадению страниц из индекса, циклам, цепочкам, потере части поискового трафика, конфликтам с canonical, лишним обходам Googlebot и Яндекс-робота. Особенно опасны массовые ошибки при миграциях, когда тысячи старых адресов перенаправляют на главную, создают длинные цепочки или оставляют временный 302 там, где переезд уже стал постоянным.

В этом руководстве разберём различия между 301, 302, 307 и 308, статус «Ошибка переадресации» в Google Search Console, правила для миграций и интернет-магазинов, связь редиректов с sitemap и canonical, а также практическую диагностику через curl, серверные конфигурации и массовый краулинг.

Главная мысль: хороший SEO-редирект ведёт пользователя и поискового робота сразу на наиболее релевантный конечный URL и соответствует реальному состоянию страницы.

Содержание

• Что такое редирект
• 301, 302, 307 и 308: в чём разница
• 301 Moved Permanently
• 302 Found
• 307 Temporary Redirect
• 308 Permanent Redirect
• Как Google обрабатывает постоянные и временные редиректы
• Как Яндекс обрабатывает редиректы
• Когда нужен редирект, а когда 404
• Страница с переадресацией в Search Console
• Ошибка переадресации в Search Console
• Цепочки редиректов
• Циклы редиректов
• Редирект и canonical
• Редирект и sitemap.xml
• HTTP → HTTPS и www → без www
• Редиректы при изменении структуры URL
• Редиректы при переносе сайта
• Редиректы в интернет-магазинах
• JavaScript и meta refresh
• Как проверить редирект через curl
• Примеры для Nginx и Apache
• Массовая диагностика редиректов
• Что делать после исправления
• Типичные ошибки
• Чек-лист
• FAQ
• Вывод

Что такое редирект

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

Упрощённо:

Пользователь / робот
        ↓
https://example.ru/old-page/
        ↓
HTTP 301 + Location: /new-page/
        ↓
https://example.ru/new-page/
        ↓
200 OK

В SEO важны две вещи:

1. Код перенаправления — постоянный или временный.
2. Конечный URL — действительно ли он соответствует старой странице.

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

Когда редирект нужен

Типичные сценарии:

• страница получила новый URL;
• сайт переезжает на новый домен;
• HTTP-версия переводится на HTTPS;
• www и non-www объединяются;
• изменяется структура каталога;
• объединяются две похожие страницы;
• старая модель товара заменена новой;
• временно недоступный раздел переносится на информационную страницу;
• устраняются дубли URL.

Когда редирект не нужен

Не стоит использовать редирект только потому, что вы не хотите видеть 404.

Если страница удалена и релевантной замены нет, правильнее вернуть 404 или 410. Подробно это разобрано в статье про 404 и Soft 404.

301, 302, 307 и 308: в чём разница

Основное различие — постоянство перенаправления и сохранение метода HTTP-запроса.

Google рассматривает 301 и 308 как постоянные редиректы, а 302, 303 и 307 — как временные. Яндекс использует ту же базовую классификацию: 301/308 — постоянные, 302/303/307 — временные.

Официальные источники:

• Google: Redirects and Google Search;
• Яндекс: Обработка редиректов;
• Яндекс: Справочник кодов HTTP.

Когда использовать 301 Moved Permanently

301 — основной SEO-код для постоянного переноса страницы.

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

Пример:

/blog/old-seo-guide/
   ↓ 301
/blog/new-seo-guide/
   ↓ 200

Подходящие сценарии для 301

• смена URL статьи;
• перенос карточки товара на новый постоянный адрес;
• переезд сайта на другой домен;
• объединение нескольких дублей в один основной документ;
• HTTP → HTTPS;
• www → non-www или наоборот;
• изменение структуры каталогов;
• замена старой посадочной страницы новой с тем же интентом.

Google прямо рекомендует постоянные серверные редиректы, когда URL окончательно меняется. В документации по миграциям Google также отмечает, что 301 и другие постоянные редиректы не приводят к потере PageRank сами по себе.

301 не означает «перенаправить куда-нибудь»

Качество цели важнее самого кода.

Плохо:

/product/iphone-15-pro/
   ↓ 301
/

Лучше:

/product/iphone-15-pro/
   ↓ 301
/product/iphone-16-pro/

но только если новая модель действительно является логичной заменой для пользователя.

Если релевантной страницы нет:

/product/old-model/
   ↓
404 или 410

Когда использовать 302 Found

302 говорит поисковой системе, что перенос временный.

Типичные сценарии:

• краткосрочная техническая страница;
• A/B-тест;
• временное перенаправление на альтернативный раздел;
• временная замена страницы на период работ;
• эксперимент, после которого исходный URL вернётся.

Google рекомендует использовать временный редирект, если вы хотите сохранить исходный URL как основной адрес в поиске.

Для A/B-тестирования Google отдельно рекомендует 302, а не 301, если пользователи временно отправляются с исходной страницы на вариант теста.

Ошибка: годами оставлять 302 после постоянного переезда

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

Проверьте старые правила редиректов после:

• редизайна;
• миграции CMS;
• смены домена;
• изменения ЧПУ;
• переноса каталога.

Если временная ситуация стала постоянной, обновите редирект на постоянный.

Что такое 307 Temporary Redirect

307 — временное перенаправление, при котором клиент должен сохранить исходный метод запроса.

Это особенно важно для запросов вроде:

POST /checkout/

Если такой запрос временно перенаправляется, 307 явно говорит сохранить метод и тело запроса.

В обычном SEO для HTML-страниц чаще встречается 302, но 307 абсолютно корректен и распознаётся Google и Яндексом как временный редирект.

307 в браузере и HSTS

Разработчики иногда видят в DevTools внутренний 307 Internal Redirect, связанный с HSTS и переводом HTTP на HTTPS. Это не обязательно реальный серверный ответ вашего приложения.

Поэтому при SEO-аудите проверяйте ответ сервера отдельно через curl, а не делайте вывод только по браузерной панели Network.

Что такое 308 Permanent Redirect

308 — постоянный редирект с сохранением HTTP-метода и тела запроса.

Для Google это постоянное перенаправление того же класса, что и 301. Яндекс также относит 308 к постоянным редиректам.

Пример:

HTTP/1.1 308 Permanent Redirect
Location: https://example.ru/new-url/

301 или 308 для SEO

Для обычной страницы сайта оба варианта могут быть корректными.

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

Не нужно менять рабочие 301 на 308 только ради «современности». Для SEO важнее:

• постоянство сигнала;
• релевантная цель;
• отсутствие цепочек;
• корректный конечный 200;
• отсутствие конфликтующих canonical и sitemap.

Как Google обрабатывает постоянные и временные редиректы

Google использует тип редиректа как сигнал каноникализации.

Упрощённо:

301 / 308
→ новый URL должен стать основной версией

302 / 303 / 307
→ перенос временный, исходный URL может оставаться основной версией

Это не означает, что один HTTP-код полностью определяет индекс. Google учитывает и другие сигналы:

• внутренние ссылки;
• sitemap;
• canonical;
• внешние ссылки;
• стабильность редиректа;
• содержимое конечной страницы.

Постоянный редирект — сильный canonical-сигнал

Если URL навсегда переехал, постоянный редирект помогает объединить сигналы старого и нового адреса.

Но не создавайте конфликт:

/old/ → 301 → /new/
/new/ rel=canonical → /old/

Такой сценарий сообщает поисковику две противоположные вещи.

Как Яндекс обрабатывает редиректы

Яндекс распознаёт стандартные HTTP-коды 3xx и разделяет их на постоянные и временные.

Основная классификация:

301 / 308 → постоянный перенос
302 / 303 / 307 → временный перенос

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

Для межхостовых редиректов особенно важно, чтобы:

• новый хост был доступен;
• конечные страницы возвращали 200;
• robots.txt не блокировал обход;
• старые URL перенаправлялись на соответствующие новые страницы.

Когда нужен редирект, а когда 404

Простой алгоритм:

Старый URL больше не нужен?
│
├─ Есть новая релевантная версия
│  └─ 301 / 308
│
└─ Замены нет
   └─ 404 / 410

Не превращайте 404 в 301 автоматически

Массовая логика:

любой несуществующий URL → 301 → главная

— плохая практика.

Она:

• скрывает реальные битые ссылки;
• ухудшает пользовательский опыт;
• создаёт нерелевантные редиректы;
• может приводить к классификации как Soft 404;
• усложняет диагностику миграций.

Подробнее: Ошибка 404 и Soft 404 в SEO.

«Страница с переадресацией» в Google Search Console

Статус Page with redirect сам по себе не означает ошибку.

Если URL намеренно перенаправляется, Google не обязан индексировать исходный адрес как отдельную страницу.

Например:

http://example.ru/page/
→ 301 →
https://example.ru/page/

HTTP-версия закономерно может отображаться как страница с переадресацией.

Когда статус нормален

• старый URL после миграции;
• HTTP-версия;
• вариант www/non-www;
• старый ЧПУ;
• объединённый дубль;
• удалённая страница с реальной заменой.

Когда стоит проверять

Проблема есть, если в этом статусе оказался URL, который должен самостоятельно индексироваться.

Тогда выясните:

1. Кто установил редирект.
2. На какой URL он ведёт.
3. Соответствует ли конечная страница исходному интенту.
4. Нет ли правила на уровне CDN, Nginx, CMS или приложения.
5. Не попал ли редирект в sitemap.

«Ошибка переадресации» в Google Search Console

Google выделяет отдельный статус Redirect error.

К нему относятся, в частности:

• слишком длинная цепочка;
• цикл редиректов;
• некорректный или пустой URL в Location;
• цепочка, приводящая к чрезмерно длинному URL.

Такой статус нужно исправлять, если URL должен корректно перенаправляться или индексироваться.

Начинайте с полного пути

Не проверяйте только первый ответ.

Нужно увидеть всю цепочку:

A → B → C → D → 200

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

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

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

Плохо:

http://example.ru/page
→ https://example.ru/page
→ https://www.example.ru/page
→ https://www.example.ru/page/
→ https://www.example.ru/new-page/
→ 200

Лучше:

любой старый вариант
→ https://www.example.ru/new-page/
→ 200

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

Чем вредны цепочки

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

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

Циклы редиректов

Цикл означает, что браузер или робот никогда не достигает конечной страницы.

Пример:

/page-a/
→ /page-b/
→ /page-a/
→ /page-b/
→ ...

Или:

http://www.example.ru/
→ https://example.ru/
→ https://www.example.ru/
→ https://example.ru/

В браузере пользователь обычно увидит ошибку вроде ERR_TOO_MANY_REDIRECTS.

Частые причины циклов

• конфликт Nginx и CMS;
• одновременно активные правила www/non-www;
• CDN делает HTTPS-редирект, а origin возвращает обратно на HTTP;
• плагины WordPress дублируют серверные правила;
• приложение не знает реальный протокол за reverse proxy;
• неправильная обработка X-Forwarded-Proto;
• несколько уровней инфраструктуры меняют URL независимо друг от друга.

Редирект и canonical

Redirect и rel="canonical" решают похожие, но не одинаковые задачи.

Редирект

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

A → 301 → B

Canonical

Страница A остаётся доступной, но сообщает поисковику, что предпочтительная версия — B.

<link rel="canonical" href="https://example.ru/b/">

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

Если обе версии нужны пользователям, но для поиска следует объединить сигналы, canonical может быть уместнее.

У нас есть отдельный материал про rel=canonical.

Не создавайте конфликт сигналов

Проверьте:

старый URL → 301 → новый URL
новый URL → canonical на самого себя

Это логично.

А вот:

старый URL → 301 → новый URL
новый URL → canonical → старый URL

— конфликт.

Редирект и sitemap.xml

В sitemap желательно перечислять конечные канонические URL, которые вы хотите видеть в поиске.

Не стоит оставлять:

/old-page/ → 301

в актуальной карте сайта, если целевая версия уже:

/new-page/ → 200

После миграции

Проверьте:

• новый sitemap содержит новые URL;
• старые URL удалены из актуальной карты;
• внутренние ссылки обновлены;
• canonical указывает на новые адреса;
• старые URL продолжают перенаправлять на соответствующие новые.

Подробнее о картах сайта: Sitemap.xml: настройка и ошибки.

Редиректы HTTP → HTTPS и www → без www

У сайта должна быть одна последовательная основная версия.

Например:

http://example.ru/page/
http://www.example.ru/page/
https://www.example.ru/page/

все ведут на:

https://example.ru/page/

Избегайте двойного перехода

Плохо:

http://www.example.ru/page/
→ https://www.example.ru/page/
→ https://example.ru/page/

Лучше:

http://www.example.ru/page/
→ https://example.ru/page/

Это особенно важно при сочетании:

• Cloudflare/CDN;
• reverse proxy;
• Nginx;
• CMS;
• контейнеров;
• балансировщиков нагрузки.

Каждый слой должен понимать, кто отвечает за канонизацию URL.

Редиректы при изменении структуры URL

Пример старой структуры:

/catalog/phones/apple/model-x/

Новая:

/smartphones/apple/model-x/

Нужна таблица соответствий:

Не делайте одно общее правило без проверки

Массовый regex-редирект может случайно отправить:

• товары не в те категории;
• фильтры на несуществующие URL;
• статьи на коммерческие страницы;
• старые параметры в бесконечные цепочки.

Перед запуском миграции протестируйте выборку всех типов URL.

Редиректы при переносе сайта

Миграция домена — один из самых чувствительных сценариев.

Базовый план:

1. Составить полный список старых URL.
2. Для каждого определить новый аналог.
3. Настроить постоянные серверные редиректы.
4. Проверить конечный 200.
5. Обновить внутренние ссылки.
6. Обновить canonical.
7. Сформировать новый sitemap.
8. Проверить robots.txt.
9. Проверить Search Console и Яндекс.Вебмастер.
10. Следить за 404, 5xx и redirect error после запуска.

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

Редирект должен быть постраничным

Правильно:

old.ru/catalog/a/ → new.ru/catalog/a/
old.ru/catalog/b/ → new.ru/catalog/b/

Плохо:

old.ru/* → new.ru/

Такой массовый редирект на главную теряет соответствие страниц.

Редиректы в интернет-магазинах

Интернет-магазины создают много пограничных сценариев.

Товар сменил URL

Если карточка та же:

301 → новый URL товара

Товар заменён новой моделью

301 уместен, если новая модель действительно является прямой заменой.

Товар удалён без аналога

404 / 410

Не отправляйте всё на категорию только ради сохранения редиректа.

Категория переименована

Старая категория может вести 301 на новую, если интент и ассортимент сохраняются.

Фильтр больше не существует

Если релевантной посадочной страницы нет, не нужно автоматически редиректить фильтр на широкую категорию.

JavaScript и meta refresh

Серверные HTTP-редиректы предпочтительнее для SEO, потому что робот видит перенаправление сразу в ответе сервера.

Meta refresh

Пример:

<meta http-equiv="refresh" content="0; url=https://example.ru/new/">

Google может интерпретировать мгновенный meta refresh как постоянный перенос, а задержанный — как временный.

Но это запасной вариант, а не первая рекомендация.

JavaScript redirect

window.location.href = '/new-page/'

Google способен обрабатывать JavaScript-редиректы после рендеринга, но если рендеринг не состоялся, робот может не увидеть перенаправление.

Поэтому для важных SEO-URL используйте серверный 301/308 или временный 302/307 там, где это возможно.

Подробнее: JavaScript и индексация сайта.

Как проверить редирект через curl

Первый ответ:

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

Ожидаемый результат:

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

Посмотреть всю цепочку

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

Итог должен завершаться:

HTTP/2 200

Получить конечный URL

curl -L -s -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.ru/old-page/

Ограничить число переходов

curl -L --max-redirs 10 -I https://example.ru/old-page/

Это помогает быстро обнаруживать циклы и чрезмерные цепочки.

Примеры редиректов для Nginx и Apache

Nginx: одна страница

location = /old-page/ {
    return 301 https://example.ru/new-page/;
}

Nginx: HTTP → HTTPS

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

Apache mod_alias

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

Apache mod_rewrite

RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

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

Массовая диагностика редиректов

Для крупного сайта используйте краулер или собственный скрипт.

Соберите минимум:

• исходный URL;
• первый HTTP-код;
• каждый Location;
• количество переходов;
• конечный URL;
• конечный код;
• canonical конечной страницы;
• наличие исходного URL в sitemap;
• внутренние ссылки на старый адрес.

Что искать в отчёте

Сегментируйте:

301 → 200
302 → 200
301 → 301 → 200
301 → 404
301 → 5xx
loop
redirect to homepage
redirect to unrelated page

Именно такие группы позволяют быстро понять масштаб проблемы.

Обновляйте внутренние ссылки

Даже если старый URL корректно перенаправляется, внутренние ссылки сайта лучше вести сразу на конечный адрес.

Это:

• уменьшает количество запросов;
• упрощает архитектуру;
• сокращает задержки;
• снижает зависимость от старых правил.

Что делать после исправления редиректов

После массового изменения:

1. Перекраульте сайт.
2. Проверьте отсутствие циклов.
3. Проверьте конечные 200.
4. Убедитесь, что sitemap содержит новые URL.
5. Обновите внутренние ссылки.
6. Проверьте canonical.
7. Проверьте Search Console.
8. Проверьте Яндекс.Вебмастер.
9. Смотрите серверные логи и 404.
10. Не удаляйте постоянные редиректы слишком рано.

Если важная новая страница уже исправлена и доступна, можно запросить повторный обход. Инструкция: как запросить переиндексацию страницы.

Типичные ошибки с редиректами

Все старые URL ведут на главную

Смысл исходных страниц теряется.

302 используется для постоянного переезда

Поисковой системе сообщается, что изменение временное.

Редирект ведёт на 404

Получается:

301 → 404

Проверьте конечную страницу.

Длинные цепочки

Каждый новый редизайн добавляет ещё один переход вместо обновления старого правила.

Цикл HTTP/HTTPS

Один слой инфраструктуры переводит на HTTPS, другой возвращает на HTTP.

В sitemap остаются старые URL

Карта сайта и сервер сообщают разные сигналы.

Canonical указывает назад

Новый URL после 301 канонизируется на старый.

Внутренние ссылки остаются старыми

Робот постоянно проходит лишний редирект.

JavaScript используется там, где доступен серверный redirect

Перенаправление становится зависимым от рендеринга.

Редирект скрывает Soft 404

Нерелевантный 301 на главную не превращает удалённую страницу в полезный документ.

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

Быстрое дерево решений

URL изменился?
│
├─ Нет → редирект не нужен
│
└─ Да
   │
   ├─ Изменение постоянное?
   │  ├─ Да → 301 / 308
   │  └─ Нет → 302 / 307
   │
   └─ Есть релевантная цель?
      ├─ Да → перенаправить на неё
      └─ Нет → рассмотреть 404 / 410

FAQ

Какой редирект лучше для SEO: 301 или 308?

Оба являются постоянными. Для обычных страниц 301 остаётся самым распространённым вариантом. 308 полезен, когда важно сохранить метод запроса.

301 передаёт PageRank?

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

Можно ли использовать 302 несколько месяцев?

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

Сколько редиректов допустимо в цепочке?

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

Нужно ли оставлять старые URL в sitemap после 301?

В актуальном sitemap лучше перечислять конечные канонические URL, которые должны индексироваться.

Нужно ли менять внутренние ссылки, если 301 уже работает?

Да. Внутренние ссылки желательно обновить на конечные URL, чтобы не создавать лишние переходы.

Что делать со старой страницей без аналога?

Вернуть корректный 404 или 410, а не перенаправлять на нерелевантную страницу.

Почему Search Console показывает «Страница с переадресацией»?

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

Почему Search Console показывает «Ошибка переадресации»?

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

Вывод

Редирект — это часть архитектуры сайта, а не универсальный способ избавиться от ошибок.

Для постоянного переезда используйте 301 или 308, для временного — 302 или 307. Старый URL должен вести непосредственно на наиболее релевантный конечный документ. Если замены нет, честный 404/410 обычно лучше нерелевантного перенаправления.

Особое внимание уделяйте миграциям: таблице соответствий URL, цепочкам, canonical, sitemap, внутренним ссылкам и конечным кодам ответа. Один неверный regex или конфликт между CDN, Nginx и CMS способен создать тысячи циклов и ошибок переадресации.

После настройки проверяйте не только браузер, но и реальные HTTP-ответы, Search Console, Яндекс.Вебмастер и массовый краулинг. Тогда редиректы действительно помогают сохранить структуру сайта и поисковые сигналы, а не становятся новой причиной проблем с индексацией.