Как настроить 301 редирект и не потерять позиции: готовые решения

Что вообще делает 301 редирект и зачем он нужен

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

Для поисковых систем 301 редирект — это сигнал передать накопленный ссылочный вес (то, что SEO-специалисты называют link juice) со старого адреса на новый. Если всё сделать правильно, позиции сохраняются. Если накосячить — можно потерять трафик на пустом месте.

Типичные ситуации, когда без 301 не обойтись:

Сайт переехал на новый домен
Изменилась структура URL (например, убрали /category/ из адресов)
Перевели сайт с HTTP на HTTPS
Удалили страницу и хотите направить пользователя на релевантную замену
Склеиваете зеркала сайта (www и без www)
Объединяете несколько страниц в одну

301 и 302: в чём принципиальная разница

Внешне для пользователя никакой разницы нет — и 301, и 302 перебрасывают его на новый адрес. Но для поисковиков разница огромная.

301 (Moved Permanently) — постоянный редирект. Поисковые системы удаляют старый URL из индекса и передают его вес новому адресу. Браузеры кэшируют этот редирект и при повторном визите сразу идут на новый адрес.

302 (Found / Moved Temporarily) — временный редирект. Поисковики не удаляют старый URL из выдачи, не передают ему ссылочный вес в полном объёме и продолжают индексировать оригинальную страницу. По задумке — это сигнал, что старый адрес скоро снова заработает.

Вот простая шпаргалка, чтобы не путать:

Критерий	301	302
Тип перемещения	Навсегда	Временно
Ссылочный вес	Передаётся на новый URL	Остаётся на старом URL
Старый URL в индексе	Удаляется	Сохраняется
Кэширование в браузере	Да	Нет
Использовать для SEO	Да, основной инструмент	Только для временных задач

В 2016 году представитель Google Гэри Илш подтвердил, что технически все 3xx-редиректы передают PageRank. Но на практике есть нюанс: при 302 поисковики не торопятся обновлять индекс, и старая страница может висеть в выдаче неделями. А Яндекс вообще может подождать до полугода, прежде чем среагирует.

Правило простое: если перенос постоянный — ставим 301 и не мудрим. 302 используется только когда точно известно, что старая страница вернётся. Например, при кратковременных техработах или A/B-тестах лендингов.

Где находится .htaccess и как его не сломать

Прежде чем копировать код из примеров ниже, давайте разберёмся с основами. Файл `.htaccess` — это конфигурационный файл веб-сервера Apache. Он лежит в корневой директории вашего сайта, обычно это `public_html/`.

Несколько правил, которые сэкономят нервы:

Всегда делайте бэкап перед редактированием. Один неверный символ — и сайт выдаёт 500-ю ошибку. Простая копия файла: `cp .htaccess .htaccess.bak`
Файл может быть скрытым. В cPanel включите «Показать скрытые файлы» в настройках файлового менеджера. В FTP-клиенте (тот же FileZilla) эта опция тоже есть в настройках.
Проверяйте, что mod_rewrite включён. На большинстве хостингов он активен по умолчанию, но лучше убедиться. Оберните правила в условие:

<IfModule mod_rewrite.c>
    RewriteEngine On
    # Ваши правила здесь
</IfModule>

Порядок правил имеет значение. Apache читает `.htaccess` сверху вниз. Если первое правило уже сработало и перенаправило запрос, до второго дело может не дойти. Ставьте более конкретные правила выше, а общие — ниже.

Базовые примеры 301 редиректа в .htaccess

Теперь к практике. Вот конкретные сценарии, которые используются чаще всего.

Редирект одной страницы на другую

Самый простой случай — страница поменяла адрес:

Redirect 301 /old-page.html https://example.com/new-page.html

Обратите внимание: в первом аргументе указывается только путь (без домена), а во втором — полный URL.

Если нужно использовать `RewriteRule` (например, для более сложной логики):

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

Флаг `[R=301]` указывает код ответа, а `[L]` (Last) говорит серверу прекратить обработку дальнейших правил.

Редирект всего сайта на новый домен

Ситуация: вы купили новый домен и хотите перенести весь трафик:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.ru [NC]
RewriteRule ^(.*)$ https://new-domain.ru/$1 [R=301,L]

Здесь `$1` — это всё, что идёт после домена. Так `/catalog/shoes/` на старом сайте перенаправит на `/catalog/shoes/` нового домена. Структура сохраняется.

Редирект каталога

Бывает, что переименовываете раздел:

RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]

Все внутренние страницы раздела перенаправятся корректно.

Редирект HTTP на HTTPS: пошаговая инструкция

Перевод сайта на HTTPS — это уже давно не рекомендация, а необходимость. И Google, и Яндекс учитывают наличие SSL-сертификата как фактор ранжирования. Браузеры помечают HTTP-сайты как «Небезопасные», а пользователи видят это и уходят.

Вот код, который добавляется в `.htaccess` после установки SSL-сертификата:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Что тут происходит:

`RewriteCond %{HTTPS} off` — условие: сработает только если запрос пришёл по HTTP
`%{HTTP_HOST}` — подставит текущий домен (не нужно хардкодить имя)
`%{REQUEST_URI}` — сохранит путь и параметры запроса
`[L,R=301]` — 301 редирект, последнее правило

Частая ошибка: `RewriteEngine On` прописывают дважды, и это может вызвать конфликт. Проверьте, нет ли этой строки выше в файле — достаточно одной.

Редирект HTTP на HTTPS + склейка www

Чаще всего эти два правила совмещаются, чтобы у сайта был один канонический адрес:

RewriteEngine On

# Если запрос без www или по HTTP — перенаправляем
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Или наоборот, если нужен вариант без www:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Выбирайте один вариант и придерживайтесь его. Главное — чтобы у каждой страницы был ровно один канонический URL. Иначе поисковики будут видеть дубли.

Массовый редирект: как перенаправить сотни страниц

При редизайне сайта или смене CMS часто меняется вся структура URL. У вас может быть 300, 500, а то и несколько тысяч страниц, которые нужно перенаправить. Руками прописывать каждый `Redirect 301` — это не вариант.

Способ 1: RewriteMap (если есть доступ к конфигурации Apache)

Самый производительный вариант — использовать `RewriteMap` в конфигурации виртуального хоста (не в `.htaccess`, а в `httpd.conf` или `sites-available`). Создаёте текстовый файл с маппингом:

# redirect-map.txt
/old-url-1 /new-url-1
/old-url-2 /new-url-2
/old-url-3 /new-url-3

В конфигурации Apache:

RewriteMap redirects txt:/path/to/redirect-map.txt
RewriteCond ${redirects:%{REQUEST_URI}} !=""
RewriteRule ^ ${redirects:%{REQUEST_URI}} [R=301,L]

Плюс: файл с маппингом легко генерировать скриптом из старого sitemap.xml. Минус: нужен доступ к серверной конфигурации, на шаред-хостинге так не получится.

Способ 2: Массовый Redirect в .htaccess

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

# Массовый редирект при смене структуры
Redirect 301 /blog/post-1 https://example.com/articles/post-1
Redirect 301 /blog/post-2 https://example.com/articles/post-2
Redirect 301 /blog/post-3 https://example.com/articles/post-3
# ... и так далее

Совет из практики: не пишите это руками. Выгрузите старые URL из Screaming Frog или Яндекс.Вебмастера, сформируйте маппинг в Google Sheets (простой формулой `CONCATENATE`), а потом скопируйте готовые строки в `.htaccess`.

Способ 3: Шаблонные правила через RewriteRule

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

# Все URL вида /blog/YYYY/MM/slug стали /articles/slug
RewriteEngine On
RewriteRule ^blog/\d{4}/\d{2}/(.*)$ /articles/$1 [R=301,L]

Или если просто убрали расширение `.html`:

RewriteEngine On
RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Способ 4: Редирект через PHP (для CMS-проектов)

Иногда проще решить задачу на уровне приложения. Если у вас WordPress, Bitrix или самописный PHP-проект:

<?php
$redirects = [
    '/old-page-1' => '/new-page-1',
    '/old-page-2' => '/new-page-2',
    // ...
];

$uri = $_SERVER['REQUEST_URI'];
if (isset($redirects[$uri])) {
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: https://example.com' . $redirects[$uri]);
    exit;
}

Этот код нужно подключить как можно раньше — до инициализации CMS. Работает стабильно, легко дополняется.

Редирект при переезде на новый домен: чек-лист

Переезд сайта на новый домен — одна из самых рискованных операций для SEO. Вот пошаговый алгоритм:

До переезда:

Выгрузите полный список проиндексированных страниц старого сайта. Используйте Screaming Frog, Яндекс.Вебмастер или Google Search Console — что удобнее.
Составьте маппинг old URL → new URL. Каждой старой странице должна соответствовать релевантная новая. Не перенаправляйте всё подряд на главную — поисковики это не любят, да и позиции так не сохранить.
Убедитесь, что новый сайт полностью готов: все страницы на месте, контент перенесён, sitemap.xml обновлён.

Во время переезда:

Настройте 301 редиректы на старом домене. Каждый старый URL должен отдавать 301 с перенаправлением на соответствующий новый.
Обновите внутренние ссылки на новом сайте. Все ссылки должны вести на актуальные адреса, а не на старый домен с редиректом.
Обновите sitemap.xml и robots.txt на обоих доменах.

После переезда:

Добавьте новый домен в Яндекс.Вебмастер и Google Search Console. Подтвердите права.
Воспользуйтесь инструментом «Переезд сайта» в Яндекс.Вебмастере — это ускорит склейку доменов.
Отслеживайте ошибки сканирования. Первые 2–4 недели смотрите в Search Console и Вебмастере, нет ли 404-х по старым адресам. Если есть — добавляйте пропущенные редиректы.
Не снимайте редиректы минимум 6–12 месяцев. Лучше — оставить навсегда. Пока старый домен жив, пусть редиректит.

Ошибки, на которые все натыкаются

Вот самые болезненные грабли при работе с редиректами:

Цепочки редиректов. Страница A редиректит на B, а B — на C. Каждый промежуточный шаг — это потеря скорости и небольшая утечка ссылочного веса. Google обрабатывает до 10 редиректов в цепочке, Яндекс может остановиться раньше. Решение — всегда перенаправлять напрямую с A на C.

Циклические редиректы. A → B → A. Браузер показывает ошибку `ERR_TOO_MANY_REDIRECTS`, страница не открывается вообще. Обычно это случается, когда правила в `.htaccess` конфликтуют друг с другом или с настройками CMS.

302 вместо 301. Особенно коварная штука: сайт работает нормально, пользователи ничего не замечают, а Яндекс месяцами держит в выдаче старые URL и не передаёт вес новым. Проверяйте коды ответа через curl или любой онлайн-сервис вроде httpstatus.io.

Редирект без сохранения пути. Когда все страницы старого сайта ведут на главную нового. Это плохо и для пользователей (они не попадают туда, куда хотели), и для SEO (поисковики не могут сопоставить контент).

Забыли про trailing slash. `/about` и `/about/` — для Apache это два разных адреса. Если не обработать оба варианта, часть пользователей получит 404.

Не обновили [внутренние ссылки](/blog/vnutrennyaya-perelinkova-sajta). Поставили редиректы, но внутри сайта ссылки всё ещё ведут на старые URL. Каждый клик — это лишний запрос через редирект. Замедляет сайт и создаёт ненужную нагрузку.

Как проверить, что редиректы работают правильно

После настройки обязательно проверяйте результат. Вот набор инструментов:

curl в терминале — быстро и точно:

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

В ответе должен быть `HTTP/1.1 301 Moved Permanently` и заголовок `Location:` с правильным новым адресом.

Браузер в режиме инкогнито. Обычный режим может показать закэшированный результат. Инкогнито гарантирует чистый запрос.

Яндекс.Вебмастер / Google Search Console. Смотрите отчёты о покрытии и ошибки сканирования. Там видно, если роботы встретили неожиданный редирект или цепочку.

Screaming Frog. Для массовой проверки — просканируйте сайт и отфильтруйте все ответы с кодами 3xx. Сразу увидите цепочки, некорректные редиректы и 302 вместо 301.

Не только .htaccess: другие способы настройки редиректов

Файл `.htaccess` — решение для серверов Apache. Но мир не ограничивается Apache, и вот что ещё можно использовать:

Nginx. Если сайт крутится на Nginx (а в 2026 году это очень распространённый вариант), редиректы настраиваются в конфигурации сервера:

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

Для отдельных страниц:

location = /old-page {
    return 301 /new-page;
}

Nginx работает быстрее, чем `.htaccess`, потому что не перечитывает конфиг при каждом запросе.

CMS и плагины. WordPress: Redirection (бесплатный плагин, удобный интерфейс). Bitrix: встроенный механизм в настройках URL. В большинстве современных CMS есть штатные средства для управления редиректами.

Уровень приложения. Next.js, Nuxt, Laravel — у каждого фреймворка свой механизм. Например, в Next.js редиректы описываются в `next.config.js`:

module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path',
        destination: '/new-path',
        permanent: true, // 301
      },
    ]
  },
}

Cloudflare и CDN. Если сайт за Cloudflare, редиректы можно настроить через Page Rules или Bulk Redirects прямо в панели. Удобно для проектов, где нет прямого доступа к серверу.

Пара слов про производительность

Каждый редирект — это дополнительный HTTP-запрос. Один-два — не критично, но если цепочки или сотни правил в `.htaccess`, это может замедлить отклик сервера.

Что можно сделать:

Используйте `RewriteMap` вместо сотен отдельных `Redirect 301` — это значительно быстрее
Ставьте флаг `[L]` после каждого правила, чтобы Apache не проверял оставшиеся
По возможности переносите редиректы из `.htaccess` в конфигурацию виртуального хоста Apache — `.htaccess` перечитывается при каждом запросе, а серверный конфиг загружается один раз
Если перешли на Nginx — тем более не используйте `.htaccess` (он вообще не поддерживается, если нет отдельного модуля)

Когда 301 редирект — не лучшее решение

Есть ситуации, когда вместо редиректа лучше использовать другие подходы:

Страница временно недоступна — ставьте 302 или 307, а не 301. Иначе поисковики удалят её из индекса.
Страница удалена без замены — если нет релевантной альтернативы, честнее отдать 410 (Gone). Это прямой сигнал поисковику: контент удалён навсегда, не ищите замену.
Редирект с забаненного домена — плохая идея. 301 «склеит» домены, и все санкции старого домена переедут на новый.
Каноникализация дублей — если одинаковый контент на разных URL, иногда достаточно тега `<link rel="canonical">` вместо редиректа.

Итого

301 редирект — инструмент простой, но требующий аккуратности. Одна ошибка в `.htaccess` может положить сайт, а неправильно настроенные перенаправления будут месяцами съедать позиции.

Короткий алгоритм действий:

Определиться с типом редиректа (301 или 302)
Сделать бэкап `.htaccess`
Написать правила
Проверить через `curl -I`
Открыть в инкогнито-режиме
Мониторить в Вебмастере и Search Console ещё 2–4 недели