Подписывайтесь на Telegram-канал Анатолия Половинкина основателя компании TolkaDigital
Главная - Глоссарий - Редирект

Редирект

Redirect

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

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

Редирект работает через стандартные HTTP-статусные коды и заголовок Location в ответе сервера. Когда браузер или поисковый робот обращается к адресу, сервер возвращает HTTP-статус (например, 301 или 302) вместе с указанием нового URL в заголовке Location. Браузер автоматически повторяет запрос уже к новому адресу, и пользователь чаще всего не замечает этого перехода — страница просто открывается. Поисковые роботы обрабатывают редиректы иначе: они анализируют тип кода, решают, нужно ли передать ссылочный вес, и обновляют индекс в зависимости от семантики кода. Именно разное поведение роботов и браузеров делает выбор типа редиректа принципиально важным. Технически редирект — неотъемлемая часть протокола HTTP, без которой современный веб не работал бы.

Редиректы появились вместе со стандартом HTTP/1.0, формализованным в 1996 году в документе RFC 1945. Разработчики интернета изначально предусмотрели коды 301 и 302 для управления перемещением ресурсов — ответ на практическую необходимость, а не теоретическая конструкция. В 1999 году стандарт HTTP/1.1 (RFC 2616) расширил набор кодов, добавив 303, 307 и другие, чтобы точнее описать поведение при редиректе POST-запросов. С распространением поисковых систем в 2000-х редиректы приобрели критическое значение для SEO: поисковики начали по-разному интерпретировать постоянные и временные перемещения. Google официально подтвердил в 2016 году в блоге Webmaster Central, что 301 и 302 редиректы передают PageRank практически одинаково, хотя скорость обновления индекса может отличаться в несколько раз. Сегодня редиректы — обязательный инструмент при любой значимой технической работе с сайтом: смена домена, реструктуризация URL, перевод на HTTPS или удаление страниц.

В digital-маркетинге редиректы решают задачи, которые невозможно закрыть никаким другим способом. При смене домена без правильного редиректа сайт теряет весь накопленный ссылочный вес и органический трафик — по опыту агентств, восстановление после такой ошибки занимает от 6 месяцев до 2 лет. При переходе на HTTPS редирект с http:// на https:// одновременно защищает пользователей и сохраняет позиции в поиске, потому что Google с 2014 года учитывает наличие HTTPS как сигнал ранжирования. В рекламных кампаниях редиректы применяют для трекинга кликов: пользователь сначала проходит через трекинговый URL, который фиксирует переход в аналитике, а потом автоматически оказывается на целевой странице. UTM-метки в коротких ссылках для email-рассылок и постов в соцсетях часто реализованы именно через редиректы с транзитного адреса. Редиректы также помогают корректно обработать удаленные страницы, направляя пользователя на близкий по теме раздел вместо ошибки 404.

Для бизнеса неправильно настроенные редиректы означают прямые потери выручки. По данным исследований Ahrefs и SEMrush, страницы с ошибкой 404 снижают вероятность завершения сессии покупкой на 12-15%. Когда крупный интернет-магазин меняет структуру URL без редиректов, он теряет 30-60% органического трафика в первые три месяца — такие данные фиксируют агентства при аудитах после миграций. Маркетологу важно понимать разницу между типами редиректов, потому что ошибка в выборе кода напрямую влияет на передачу ссылочного веса и скорость переиндексации. Например, использование 302 вместо 301 при постоянном переносе страницы заставляет Яндекс и Google дольше удерживать старый URL в индексе, что порождает дубли контента и «размывает» ссылочную силу. Редирект — не техническая мелочь, которую можно делегировать разработчику без контроля, а стратегический инструмент управления трафиком и видимостью сайта в поиске.

Как работает редирект

  1. Пользователь или бот запрашивает URL. Браузер или поисковый робот отправляет GET-запрос на сервер по указанному адресу. Запрос содержит заголовки с информацией о клиенте (User-Agent), принимаемых форматах и языке. Именно на этом этапе сервер получает информацию о том, кто обращается к странице — это важно, поскольку некоторые редиректы настраивают по-разному для ботов и живых пользователей (хотя такая практика может быть расценена Яндексом и Google как клоакинг).
  2. Сервер проверяет конфигурацию редиректов. Сервер (Apache, Nginx, LiteSpeed и другие) последовательно проверяет правила, прописанные в конфигурационных файлах — .htaccess для Apache или server/location блоки для Nginx. Правила обрабатываются сверху вниз, поэтому порядок их записи имеет значение: более специфичные правила должны стоять выше общих, иначе общее правило перехватит запрос раньше. На этом же этапе могут срабатывать правила на уровне CMS — например, настройки в WordPress или Bitrix, которые генерируют собственные редиректы через PHP.
  3. Сервер возвращает HTTP-ответ со статус-кодом и заголовком Location. Вместо тела страницы сервер отдает минимальный ответ: строку статуса (например, «HTTP/1.1 301 Moved Permanently») и заголовок Location с новым URL. Само тело ответа при редиректе обычно пустое или содержит короткий HTML с текстом для устаревших клиентов, которые не умеют обрабатывать редиректы автоматически. Весь этот обмен занимает миллисекунды, но при цепочках редиректов каждый дополнительный шаг добавляет задержку в 50-300 мс.
  4. Браузер или бот читает заголовок Location и выполняет повторный запрос. После получения кода 3xx браузер автоматически отправляет новый GET-запрос на URL из заголовка Location. Для пользователя это выглядит как моментальная смена адреса в строке браузера. Поисковый робот действует иначе: он фиксирует оба URL и тип связи между ними, затем принимает решение об обновлении индекса в соответствии с семантикой кода.
  5. Целевая страница загружается и отдается пользователю. После всех переходов браузер загружает конечную страницу в штатном режиме. Если между исходным и конечным URL было несколько промежуточных редиректов (цепочка), пользователь этого не видит, но время загрузки увеличивается. Google рекомендует сокращать цепочки редиректов до одного шага — каждый дополнительный переход снижает передачу PageRank приблизительно на 10-15% по экспертным оценкам.
  6. Поисковый робот обновляет индекс в соответствии с типом редиректа. При коде 301 робот со временем заменяет старый URL новым в своем индексе и переносит накопленный ссылочный вес. При коде 302 старый URL остается в индексе как основной, а новый рассматривается как временное расположение. Яндекс фиксирует изменение обычно за 2-6 недель, Google — за 1-4 недели, хотя для крупных сайтов этот процесс может растянуться на несколько месяцев из-за частоты обхода.

Виды редиректов

  • 301 — постоянный редирект. Сообщает браузеру и поисковым роботам, что страница переехала навсегда на новый адрес. Передает практически весь накопленный ссылочный вес (по данным Google — до 99%), что делает его стандартным выбором при миграции сайта, смене домена или переводе на HTTPS. Например, интернет-магазин, перешедший с domain.ru на newdomain.ru, должен настроить 301-редиректы с каждой страницы старого сайта, чтобы сохранить позиции и трафик. Браузеры кешируют 301 редиректы, поэтому отменить или изменить их сложнее, чем 302.
  • 302 — временный редирект. Указывает, что страница временно перемещена на другой адрес, но вернется на прежнее место. Поисковики сохраняют старый URL в индексе как основной и не переносят на него ссылочный вес с нового адреса. Применяется для A/B-тестирования лендингов, сезонных промо-страниц и технических обходных решений в период разработки. Использование 302 вместо 301 при постоянном переносе — одна из самых частых SEO-ошибок.
  • 307 — временный редирект HTTP/1.1. Функционально аналог 302, но с важным отличием: запрещает менять метод запроса при переходе. Если клиент отправил POST-запрос, то при 307 он должен повторить POST на новый адрес, а не переключаться на GET. Используется в API, формах и там, где метод запроса важен для корректной обработки данных. Для SEO-задач в большинстве случаев не нужен — здесь достаточно 301 или 302.
  • 308 — постоянный редирект HTTP/1.1. Аналог 301, который также запрещает менять метод запроса. Введен стандартом RFC 7538 в 2015 году: 301 не гарантировал сохранение метода POST при переходе, а 308 это гарантирует. Поддержка кода расширяется, но для обычного редиректа страниц сайта он не нужен — 301 остается де-факто стандартом.
  • Meta refresh. Редирект, реализованный через HTML-тег в секции head страницы: <meta http-equiv=»refresh» content=»0;url=https://new.url»>. Работает на стороне браузера, а не сервера, поэтому обрабатывается медленнее и менее предсказуемо с точки зрения SEO. Google относится к нему как к слабому сигналу перемещения и плохо передает ссылочный вес. Яндекс также не рекомендует его использовать для постоянных переносов. Единственный допустимый сценарий — вынужденная необходимость при отсутствии доступа к серверным настройкам.
  • JavaScript-редирект. Переход выполняется через JavaScript-код (window.location.href = «https://new.url»). Поисковые роботы рендерят JavaScript, но с задержкой по сравнению с серверными редиректами: Googlebot обычно обрабатывает JS-редиректы, но на это может уходить от нескольких дней до нескольких недель. Яндекс рендерит JavaScript менее предсказуемо. Для SEO-критичных переходов JavaScript-редирект — нежелательный выбор; он допустим только там, где переход контролируется логикой приложения и не влияет на индексацию.

Сравнение редиректа и канонического тега

Параметр Редирект 301 Canonical-тег
Передача ссылочного веса Полная (до 99% по данным Google) Частичная — рекомендация, а не команда
Изменение URL в браузере Да, пользователь видит новый адрес Нет, URL остается прежним
Доступность старой страницы Нет, страница недоступна по старому URL Да, страница по-прежнему открывается
Типичный сценарий Постоянный перенос, смена домена, HTTPS Дубли с параметрами, версии для печати, пагинация
Влияние на краулинговый бюджет Снижает нагрузку: бот со временем перестает обходить старый URL Бот обходит обе страницы, расходуя бюджет на дубль
Риск игнорирования поисковиком Минимальный — жесткая директива Умеренный — поисковик может проигнорировать canonical при конфликте сигналов

Пример использования

Интернет-магазин автозапчастей с трафиком 82 000 визитов в месяц провел редизайн сайта и одновременно сменил структуру URL: категории переехали с /catalog/brand/model/ на более короткий формат /zapchasti/brand/. Разработчики выполнили перенос без редиректов, посчитав, что «поисковики сами разберутся». Через 6 недель органический трафик упал на 61% — с 82 000 до 32 000 визитов в месяц. Яндекс и Google удалили старые URL из топа, но не проиндексировали новые как их замену, поскольку не получили никаких сигналов о переносе. Потери выручки за этот период составили около 1,4 млн рублей при среднем чеке 6 800 рублей.

После аудита SEO-специалисты настроили 301-редиректы с каждого из 2 400 старых URL на соответствующие новые адреса через правила в .htaccess. Дополнительно обновили карту сайта (sitemap.xml) и отправили обновленные URL на переобход через Яндекс.Вебмастер и Google Search Console. Через 8 недель трафик восстановился до 79 000 визитов — 96% от исходного уровня. Полная нормализация заняла 4 месяца. Стоимость работ по настройке редиректов составила 45 000 рублей, что в 31 раз меньше потерянной выручки. Это наглядно показывает, что редиректы — не технический вопрос, а вопрос сохранения бизнес-результатов.

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

Чем отличается 301 от 302 с точки зрения SEO, если Google говорит, что они передают вес одинаково?

Заявление Google о равной передаче веса касается только этого конкретного аспекта — количества передаваемого PageRank. Однако ключевое различие не в весе, а в поведении поисковика по отношению к индексу. При 301 робот со временем заменяет старый URL новым в индексе, и именно новый начинает ранжироваться. При 302 робот сохраняет старый URL как основной и не торопится заменять его, ожидая, что перемещение временное. На практике это означает, что при использовании 302 для постоянного переноса два URL могут конкурировать в индексе несколько месяцев, размывая ссылочную силу. Яндекс в этом вопросе ведет себя консервативнее Google и медленнее обрабатывает временные редиректы. Дополнительный нюанс: браузеры кешируют 301, что ускоряет повторные посещения для пользователей, но делает откат сложнее. Вывод: для постоянного переноса всегда используйте 301, даже если вы уверены, что «вес передается одинаково».

Насколько длинной может быть цепочка редиректов, прежде чем это начнет вредить SEO?

Google официально обрабатывает цепочки до 10 переходов, но рекомендует укладываться в 1-2 максимум. Каждый дополнительный переход в цепочке добавляет задержку в 50-300 мс и, по экспертным оценкам, снижает передачу ссылочного веса на 10-15% за звено. Для Яндекса нет официальных данных, но практика показывает аналогичное поведение. Хуже всего работают «петли редиректов» — когда страница A ведет на B, B на C, а C снова на A: в этом случае и браузер, и бот просто прекращают попытки. На практике цепочки часто возникают при последовательных редизайнах: страница переехала год назад с URL1 на URL2, а теперь с URL2 на URL3. Правильное решение — перенастроить все старые правила так, чтобы они сразу вели на конечный URL. Для инвентаризации цепочек удобен Screaming Frog: он визуализирует все переходы за один обход сайта.

Нужно ли настраивать редиректы при переходе на HTTPS, если сайт небольшой?

Да, и размер сайта здесь не имеет значения. Google с 2014 года использует HTTPS как сигнал ранжирования — пусть и небольшой, но совокупно с другими факторами он влияет на позиции. Яндекс также учитывает HTTPS в коммерческом ранжировании. Без редиректа с http:// на https:// у вас фактически два отдельных сайта в индексе: один на HTTP, другой на HTTPS. Это классический сценарий дублей контента, который размывает ссылочный вес между двумя версиями. Кроме SEO, есть практический вопрос: пользователи, у которых в закладках или во внешних ссылках сохранен старый HTTP-адрес, попадут на незащищенную версию. Правильная схема: 301-редирект с каждого http-адреса на соответствующий https-адрес, включая вариант без www и с www, в зависимости от предпочтительного вида домена. Настройка занимает 15-30 минут через .htaccess или серверный конфиг и один раз решает проблему на все время жизни сайта.

Все термины