301 и 302 редиректы для SEO: выбор, настройка и проверка

301 и 302 редиректы для SEO выбирают по смыслу переноса: 301 сообщает о постоянном изменении адреса, 302 — о временном перенаправлении. Для поиска это сигналы выбора основного URL, а не гарантия позиций или фиксированного процента передачи «веса». Надёжная настройка включает соответствие старой и новой страницы, корректный ответ сервера, проверку всей цепочки и обновление внутренних ссылок.

Как работают 301 и 302 редиректы

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

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

Почему неверно говорить, что 302 «не передаёт вес»

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

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

Когда применять 301, а когда 302

Постоянный перенос страницы

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

Смена адреса не обязательно означает смену смысла. Для старой карточки товара сначала выясните, есть ли полноценная замена. Категория или главная страница не становятся подходящим назначением только потому, что возвращают 200. При отсутствии замены может быть уместен корректный ответ об отсутствии ресурса, а не массовое перенаправление всего удалённого содержимого.

Временная замена маршрута

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

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

Другие коды и методы запросов

Для обычного перехода по ссылке часто достаточно обсуждать GET-запросы. В формах и программных интерфейсах важны ещё метод и тело запроса. Коды 307 и 308 предназначены для временного и постоянного перенаправления с сохранением метода; поведение 301 и 302 для POST имеет исторические особенности. Не применяйте правило для страниц ко всем запросам приложения без проверки.

Карта 301 и 302 редиректов до настройки сервера

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

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

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

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

Настройка редиректов в Nginx и Apache

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

Nginx: точное соответствие и return

Для одной страницы можно использовать точный location внутри подходящего server. У return после кода стоит адрес назначения; исходный путь задаётся отдельно в location. В исходном примере с двумя адресами после кода была синтаксическая ошибка.

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

Для временного маршрута с тем же принципом меняют код на 302, если это соответствует задаче. Точное совпадение ограничивает пример одним путём. Отдельно решите судьбу строки запроса: в показанном фиксированном назначении параметры явно не добавляются. Не копируйте сохранение всех параметров по привычке, особенно для служебных и чувствительных значений.

Проверьте конфигурацию штатной командой nginx -t в своей среде. После успешной проверки применяется предусмотренная вашим развёртыванием процедура перечитывания конфигурации. Полный останов и запуск сервера не является обязательным универсальным шагом. Резервная копия и понятный способ возврата нужны до изменения рабочего маршрута.

Apache: точный шаблон RedirectMatch

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

RedirectMatch 301 ^/old-page[.]html$ https://example.com/new-page.html

Обычный Redirect и RedirectMatch имеют разные правила сопоставления. Не считайте их взаимозаменяемыми для всех адресов. Допустимость директив в .htaccess зависит от конфигурации сервера; также проверьте взаимодействие с существующими правилами приложения и нормализации адресов. В примере нет универсальной политики переноса параметров.

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

Системы управления сайтом и плагины

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

Как проверить 301 и 302 редиректы

Первый ответ и вся цепочка

Начните с GET-запроса без автоматического перехода: он покажет ответ исходного адреса. Затем проверьте цепочку с переходами. В примерах curl содержимое ответа отбрасывается, заголовки выводятся в терминал. Команды предназначены для чтения условного адреса.

curl -sS -D - -o /dev/null https://example.com/old-page.html
curl -sS -L --max-redirs 10 -D - -o /dev/null https://example.com/old-page.html

В Windows вместо /dev/null используйте подходящий для оболочки способ отбрасывания вывода; при необходимости вызывайте curl.exe, чтобы не попасть на одноимённую команду оболочки. Ключ -I выполняет HEAD-запрос. Он удобен для заголовков, но при различиях обработки HEAD и GET не заменяет проверку обычного перехода.

В цепочке проверьте каждый код и Location, а не только последний 200. Назначение должно открывать нужное содержимое, не требовать неожиданной авторизации и не вести обратно к исходному адресу. Отдельно проверьте вариант без кеша и ответ на том уровне инфраструктуры, которым пользуются посетители.

Негативные сценарии проверки

• Исходный адрес перенаправляет сам на себя или возвращается через другой URL.
• Назначение выдаёт 404, ошибку сервера или страницу, не соответствующую запросу.
• Правило неожиданно захватывает похожий, но самостоятельный путь.
• Параметр теряется там, где нужен для функции, или сохраняется там, где создаёт проблему.
• HTTP, HTTPS и варианты хоста дают противоречивые маршруты.
• Кешированный ответ отличается от свежей конфигурации.

При цепочке A → B → C запрос к исходному адресу требует двух последовательных перенаправлений. Прямое A → C оставляет один. Убирается один переход, но нельзя заранее обещать точное ускорение в миллисекундах: оно зависит от сети, соединений, кеша и времени ответа серверов.

Редиректы при переезде сайта и после запуска

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

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

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

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

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

Что включить в отчёт команды

Отделяйте технический результат от поискового. «Все проверенные старые адреса ведут на соответствующие страницы» и «изменился органический трафик» — разные наблюдения. Для вывода о причинах нужны контекст релиза, даты обхода, изменения содержания и другие возможные факторы.

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

Вопросы и ответы