301-редиректы и SEO: как не потерять вес

Что такое 301-редирект и почему SEO держится на нём

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

Связка «301 редирект seo» становится критичной в четырёх ситуациях:

• смена домена или переход с http на https;
• слияние www и без-www, смена структуры URL;
• удаление и объединение разделов;
• переезд на новый CMS-движок с другими адресами.

В каждом из этих случаев вы либо аккуратно передаёте накопленный вес, либо теряете его. Причём потеря — не мгновенная и не всегда заметная: это медленное проседание позиций в течение 2–6 недель, которое сложно связать с событием, случившимся месяц назад.

Разберём, как именно передаётся вес, чем 301 отличается от 302 и 307, почему цепочки редиректов съедают весь эффект и как проверить свою конфигурацию командой curl.

Как редирект передаёт вес: механика

Когда поисковый робот встречает 301, он видит перенаправление и обрабатывает его так:

1. Запоминает пару «старый URL → новый URL» как постоянную замену.
2. Пересчитывает ссылки. Внутренние и внешние ссылки, ведущие на старый адрес, начинают учитываться в пользу нового. Полностью или с небольшими поправками — зависит от того, насколько уверенно поисковик определил постоянство редиректа и нет ли противоречий.
3. Переносит историю. Накопленные сигналы страницы — не «копия», а именно перенос: старый URL постепенно перестаёт показываться, новый занимает его место.
4. Заменяет URL в индексе. Если редирект корректен и постоянен, старый адрес выпадает из выдачи, новый появляется.

Что при этом не переносится автоматически и требует ручной работы:

• оценки в выдаче, привязанные к брендовым запросам старого домена;
• внешние ссылки, которые вы можете обновить сами (и стоит обновить — это ускоряет процесс);
• разметка Schema.org и метаданные — их нужно корректно перенести на новые страницы;
• позиции страниц, у которых не нашлось однозначной новой версии.

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

301, 302, 307, 308: в чём разница и что выбрать

Разница — в семантике и в том, как браузер обращается с методом запроса.

Практические правила:

• Переезд, смена домена, http → https, склейка www — всегда 301 (или 308, если важна корректность методов для API).
• A/B-тест, страница в разработке, временная акция — 302 или 307. Не используйте 301 «на время»: поисковик запомнит замену, и когда вы вернёте старую версию, восстановление позиций займёт месяцы.
• REST API и формы — 307/308, чтобы метод и тело запроса не терялись при перенаправлении.

Частая ошибка: настроить 302 при переезде на HTTPS и не понимать, почему через полгода в индексе всё ещё обе версии. Технически сайт работает, но вес остаётся на http-адресах, которые не предназначены для показа.

Цепочки редиректов: как теряется вес

Цепочка (redirect chain) — это когда адрес перенаправляется не сразу на финальную страницу, а через один или несколько промежуточных. Например:

http://www.example.com/page  →301→  https://www.example.com/page  →301→  https://example.com/page

Тут три адреса и два перехода. Что происходит с точки зрения SEO:

• Потеря скорости. Каждый хоп — отдельный раундтрип туда-обратно. На мобильной сети 50–100 мс на переход складываются в заметную задержку, а скорость входит в Core Web Vitals.
• Потеря краулингового бюджета. Робот тратит время на обход редиректов вместо страниц. На сайте из 10 000 URL это ощутимо.
• Размывание сигналов. Часть внешних ссылок ведёт на первый адрес в цепочке, часть на второй, часть на финальный. Вес приходит разными путями и хуже консолидируется.
• Риск обрыва. Если в середине цепочки адрес отвечает 404 или 500, вся передача веса прекращается. Один битый хоп — и весь редирект перестаёт работать.

Целевое состояние — ровно один хоп до финального URL. Не «цепочка из правил веб-сервера, которая в итоге приводит куда надо», а одно правило, которое сразу отдаёт 301 на канонический адрес.

Циклы, петли и редирект на самого себя

Отдельный класс проблем — редиректы, которые никуда не ведут.

• Цикл (loop). A → B → A. Браузер показывает ERR_TOO_MANY_REDIRECTS, страница недоступна полностью.
• Редирект на самого себя. https://example.com/x → https://example.com/x. Браузер обычно справляется, но робот видит противоречивый сигнал: адрес как бы и перемещён, и уже находится на месте.
• Редирект на несуществующую страницу. 301 ведёт на URL, который отдаёт 404. Вес не передаётся, потому что передавать некуда.

Циклы почти всегда рождаются при наложении нескольких слоёв конфигурации: правила nginx плюс правила CMS плюс настройки CDN, каждая из которых считает, что знает правильный протокол и правильный хост.

Проверить конкретный URL на цикл можно так:

curl -sS -o /dev/null -w '%{num_redirects}\n' -L --max-redirs 10 https://example.com/page

• -o /dev/null — тело ответа не нужно, анализируем только заголовки и метаданные.
• -w '%{num_redirects}' — выводит количество фактически выполненных переходов.
• --max-redirs 10 — ограничивает цепочку: если после десяти переходов результата нет, curl сообщит Maximum (10) redirects followed, и это симптом петли.

Норма — 1. Значения 0 (редиректов нет вообще, хотя должны быть) и 2+ (цепочка) требуют разбора конфигурации.

Как проверить редиректы: три команды

1. Заголовки ответа без следования

curl -sSI http://example.com/page

• -I — запрос методом HEAD, сервер отдаёт только заголовки.
• -s — тихий режим без прогресс-бара.

Ожидаемый вывод:

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 15 Sep 2026 10:12:00 GMT
Location: https://example.com/page

Здесь важна вторая строка — код ответа, и строка Location — куда именно ведёт редирект. Если Location указывает на промежуточный адрес, а не на финальный, у вас цепочка. Если код 302 вместо 301 — сигнал о временности, вес не переносится.

2. Полная цепочка переходов

curl -sS -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' -L http://www.example.com/page

• -L — curl сам следует всем редиректам.
• %{http_code} — итоговый код последнего ответа (ожидается 200).
• %{num_redirects} — сколько переходов было.
• %{url_effective} — финальный URL, на котором остановился обход.

Формат ответа 200 1 https://example.com/page — идеальный: один переход, финальная страница отдаёт 200. 200 3 https://example.com/page означает, что до правильного адреса вы добрались, но через три хопа. 404 2 https://example.com/page — двойная проблема: и цепочка, и финальная 404.

3. Массовая проверка через карту сайта

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

while read -r url; do
  printf '%s -> ' "$url"
  curl -sS -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' \
       -L --max-redirs 5 "$url"
done < old-urls.txt

• while read -r url — построчное чтение файла old-urls.txt.
• printf '%s -> ' — печатает исходный адрес перед результатом.
• Остальное — та же схема с curl.

Результат — таблица вида «старый URL → код, число хопов, финальный адрес». Дальше отбираете строки, где код не 200 или хопов больше одного, и чините именно их. Такой же массовый прогон делает https://uptimechecker.ru/redirect-check — удобно, когда нужно быстро увидеть цепочку глазами и зафиксировать её до и после правок.

Таблица: симптом → причина → решение

meta refresh и JavaScript-редиректы: почему это плохо

Многие CMS умеют делать редирект так:

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

или через JavaScript:

window.location.replace('https://example.com/new');

Для SEO это худший вариант:

• <meta refresh> обрабатывается медленнее и заметно хуже, чем HTTP-301: поисковик может не применить замену URL вообще.
• JavaScript-редирект зависит от того, выполняет ли робот скрипты, и насколько быстро. Внешние ссылки на такой адрес почти не передают вес.
• Пользователь видит вспышку пустой страницы до перехода.

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

Проверить, не отдаёт ли страница «редирект» без HTTP-кода, можно так:

curl -sSI https://example.com/old-page | grep -iE '^HTTP|^location'
curl -sSL https://example.com/old-page | grep -i 'http-equiv="refresh"'

Первая команда покажет HTTP-статус и заголовок Location, если он есть. Вторая — поищет мета-редирект в теле. Если статус 200, а мета-тег найден, значит редирект реализован неправильно: для робота страница живая и никакой замены URL не происходит.

План безопасного переезда на 301-редиректах

Если предстоит смена адресов, порядок действий снижает риск потери веса:

1. Составьте карту соответствия. Для каждого старого URL определите новый. Правило «всё на главную» — крайняя мера, поисковики воспринимают её как мягкую 404 и не переносят вес.
2. Сделайте редиректы на уровне сервера, до логики CMS. В nginx это блок server для старого домена с одной директивой return 301 https://new.example.com$request_uri;.
3. Исключите перекрёстные срабатывания. Правило для старого домена не должно применяться к новому — иначе получите цикл.
4. Проверьте цепочки. Массовый прогон старых URL должен показать 200 и 1 хоп в каждой строке.
5. Обновите sitemap.xml, canonical, внутреннюю перелинковку на новые адреса.
6. Обновите внешние ссылки, которые контролируете. Это ускоряет передачу сигналов.
7. Держите редиректы минимум год — обычно больше. Удаление 301 через месяц после переезда означает потерю всего, что ещё не успело перенестись.
8. Добавьте новые адреса в мониторинг сразу после переезда: ошибка в конфигурации редиректов обнаруживается не сразу, а по падению трафика.

Отдельно следите за связкой редиректов и HTTPS. Если вы одновременно меняете домен и протокол, делайте это одним шагом: http://old.example.com/page → https://new.example.com/page, а не через промежуточный https://old.example.com/page. Разбор типичных ошибок при переходе на защищённый протокол — в статье «SSL-сертификат и SEO: как HTTPS влияет на ранжирование».

Смежные проверки, которые ловят последствия плохих редиректов

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

• Доступность — финальный URL должен отдавать 200 стабильно, а не только в момент проверки. Проверяйте на https://uptimechecker.ru/check.
• DNS — если новый домен ещё не резолвится на всех резолверах, редирект будет работать нестабильно. Проверка записей: https://uptimechecker.ru/dns-check.
• 404 и мягкие 404 — редирект, ведущий на страницу с кодом 200 и текстом «страница не найдена», не переносит вес. Как это исправлять — в статье «Ошибка 404 Not Found: причины и что делать».
• Карта сайта и robots.txt — должны содержать только актуальные адреса.

Инфраструктурный мониторинг вроде Zabbix такие вещи не показывает: он следит за состоянием серверов и сервисов изнутри, а не за тем, что видит поисковый робот и внешний посетитель. Это разные задачи, и они хорошо дополняют друг друга: внутренний мониторинг отвечает на вопрос «работает ли сервис», внешняя проверка — «доходит ли до пользователя то, что должно доходить».

Проверьте свои редиректы

Начните с одного запроса на https://uptimechecker.ru/redirect-check: сервис покажет всю цепочку переходов, промежуточные адреса и финальный ответ — то, что поисковый робот видит при обходе вашего сайта. Если цепочка длиннее одного хопа или финальный адрес не отдаёт 200, стоит поправить конфигурацию до того, как это заметит поисковик.