301 редирект через htaccess: полное руководство

301-редирект сообщает браузеру и поисковой системе, что ресурс постоянно переехал на другой URL. В Apache его часто задают в .htaccess; но прежде чем копировать правило, нужно понять, что именно перенаправлять, какую задачу решает новый адрес и где фактически работает сайт — Apache, Nginx, CDN или комбинация серверов.

Самая дорогая ошибка — не опечатка в регулярном выражении, а неверная карта перенаправлений: например, отправить весь удалённый каталог на главную. Формально сервер отвечает 301, но пользователь не получает нужную информацию. Поисковики могут трактовать такие переходы как soft 404.

Как выбрать правильный HTTP-ответ

Не превращайте любой 404 в 301. Страница ошибки с полезным меню и поиском по сайту должна всё равно возвращать HTTP 404.

Перед правкой: бэкап и проверка сервера

.htaccess обрабатывает Apache при разрешённом использовании конфигурации на уровне каталогов. Если сайт обслуживает Nginx, этот файл может вообще не участвовать в формировании ответа. В MODX, WordPress и других CMS есть собственные правила маршрутизации: они способны перехватывать URL до или после вашего правила. Сделайте резервную копию и проверьте порядок директив.

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

Рецепт 1: один старый адрес на новый

Для простого сопоставления путей под Apache доступна директива Redirect:

Redirect 301 /old-page/ /new-page/

Убедитесь, что новая страница существует, соответствует прежнему интенту и возвращает 200. Если нужен сложный контроль query-параметров или хоста, удобнее использовать mod_rewrite. Не дублируйте одно и то же перенаправление одновременно в CMS, CDN и .htaccess.

Рецепт 2: HTTP → HTTPS и выбор зеркала

В простом случае, когда HTTPS настроен и принято решение использовать адрес без www, можно применять канонизацию на сервере. Однако за обратным прокси переменная HTTPS может не отражать внешнее соединение. Это пример, который обязательно проверяют в своей инфраструктуре:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.ru$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [R=301,L,NE]

Сначала убедитесь, что конфигурация proxy/CDN корректно передаёт схему и не вызовет цикл. Для некоторых серверов условие надо строить на доверенном X-Forwarded-Proto или вынести перенаправление на фронтовой прокси. Не доверяйте произвольным X-Forwarded-заголовкам, если входящий прокси не контролируется вами.

Рецепт 3: изменить путь в разделе

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

Внутри .htaccess путь в RewriteRule обычно записывается без ведущего /. Если правило в подкаталоге, относительная точка входа может отличаться. Не составляйте выражение без ограничителей, если оно может захватить множество похожих адресов.

Что делать с параметрами URL

При смене URL следите за query string. Apache может перенести старые параметры дальше по цепочке, хотя новый URL в них не нуждается. Например, ?utm_source=old не должен превращаться в часть основной новой структуры; но важный фильтр товара может быть значимым. Отдельно составьте таблицу параметров, которые необходимо сохранить, отбросить или перенести.

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

Почему перенаправление всех 404 на главную вредно

Предположим, старой карточки example.ru/product/model-a/ больше нет. Пользователь кликает на сохранённую ссылку, а вместо ожидаемой модели видит главную. Наличие статуса 301 не делает главную релевантной заменой. Поисковик может распознать ситуацию как soft 404, а люди будут возвращаться назад или покидать сайт.

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

Порядок правил и конфликты CMS

Запишите внешнюю канонизацию хоста/HTTPS до правил внутреннего роутинга. Конкретные перенаправления старых URL должны сработать до универсального правила, отправляющего запрос в index.php. Смешение Redirect и RewriteRule, дублирование в плагинах и настройках CDN — частая причина циклов или цепочек из нескольких 301.

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

Тестирование через curl и обход сайта

curl -I https://example.ru/old-page/
curl -IL --max-redirs 10 https://example.ru/old-page/
curl -I https://example.ru/not-found-123/

-I делает HEAD-запрос: некоторые приложения обрабатывают HEAD и GET по-разному, поэтому при странном результате повторите тест обычным GET и проверьте заголовки/тело. Для больших миграций автоматизируйте список пар «старый → целевой», сравнивайте фактический конечный URL и HTTP. После установки новых правил обновите внутренние ссылки и sitemap, чтобы обход не тратился на лишние переходы.

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

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

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

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

Можно ли настраивать всё через плагин CMS? Да, если он управляет ответом на нужном уровне и не конфликтует с веб-сервером. Результат проверяют HTTP-запросами, а не только интерфейсом плагина.

Связанные материалы: canonical для товара, HTML base, внутренняя оптимизация.

Источники: Google — ошибки обхода и удалённые страницы; Google — выбор canonical; документация Apache mod_rewrite.

Массовая миграция URL: как готовить таблицу соответствий

При редизайне или смене CMS у проекта может быть несколько тысяч старых адресов. Попытка заменить весь каталог одним правилом /old/(.*) → /new/$1 выглядит экономичной, но опасна: новая структура часто не повторяет старую, разделы могли объединиться, карточки исчезнуть, а часть слегов начать означать другие сущности.

Для каждого старого URL задайте действие: оставить 200, перенаправить на эквивалентную страницу, вернуть 404/410, или оставить содержательный архив. Добавьте столбцы: старый URL, новый URL, старый интент, новый интент, HTTP-код, внутренние входящие ссылки, наличие в sitemap и приоритет проверки. Наличие «похожего слова» в новом адресе не является достаточным доказательством соответствия.

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

Проблемы с query string и редиректы на самого себя

В Apache условия обработки строки запроса и сохранения параметров зависят от конкретной директивы. Если при редиректе на новую карточку сохраняется старый ?id=123, итоговый URL может оказаться формально доступным, но с ненужным параметром. Иногда параметр критичен, например идентификатор конкретной вариации, а иногда представляет собой лишь сортировку или устаревшую метку кампании. Решение нужно принимать по назначению URL и бизнес-логике, а не «удалять все параметры ради SEO».

Редирект на самого себя часто появляется при неудачном сочетании условия по HTTPS и поведения прокси. Когда TLS завершается на внешнем балансировщике, Apache может видеть внутренний HTTP и пытаться перенаправлять запрос на тот же публичный HTTPS-адрес без конца. Поэтому правила канонизации лучше проверять вместе с инфраструктурой, а не на локальном тесте с другой схемой подключения.

Когда использовать 308 вместо 301

Оба статуса обозначают постоянное перенаправление. В отличие от 301, статус 308 сохраняет HTTP-метод и тело запроса; это важно для API и форм, где POST нельзя бездумно превращать в GET. Для обычных GET-адресов сайта 301 часто является привычным решением, но интеграции, платежи и формы требуют отдельного тестирования. Не перенаправляйте конечные точки POST по аналогии с информационными HTML-страницами без согласования с разработчиком.

Диагностика неожиданного 301

Если адрес неожиданно перенаправляется, выясните, на каком уровне это происходит: CDN, прокси, Nginx, Apache, PHP/CMS, плагин маршрутизации или браузерный кэш. Временно отключать всё подряд на рабочем сайте не нужно. Снимите цепочку заголовков, сравните запрос через внешний домен и безопасную внутреннюю точку доступа, посмотрите серверные конфигурации и журнал применения правил.

Чтобы избежать путаницы, фиксируйте не только статус, но и Location, конечный URL, число переходов, схему, хост и наличие параметров. Ошибка может выглядеть как «редирект работает» при фактически неправильной конечной странице.

Мини-протокол внедрения и отката

1. Сохранить копию .htaccess или актуального файла правил и дату изменения.
2. Применить изменения на тестовой среде со сравнимой конфигурацией прокси.
3. Запустить таблицу автоматических проверок по старым и новым URL.
4. Убедиться, что бизнес-критичные формы, кабинет, оплата, изображения и загрузки не затронуты.
5. Внести на продакшен с возможностью быстрого отката.
6. Проверить журналы 404/5xx и цепочки редиректов после публикации.
7. Обновить внутреннюю навигацию, XML Sitemap и документацию миграции.

Сохранение одной копии конфигурации не является полноценным бэкапом, если изменения затрагивают CMS, CDN и БД. При значимой миграции нужен общий план восстановления, тесты и назначенные ответственные.

Архивные иллюстрации и первоначальные наблюдения

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

Показать архивные иллюстрации (2)

Ответы на частые вопросы (FAQ)

Связаться в Telegram

Следующие страницы вас также могут заинтересовать:

• Робототехника
• SEO-продвижение образовательного сайта: 7 лет — от старого HTML до AI Search
• Паллетирование: что это такое, технологии, оборудование и роботизация
• Промышленные роботы: что это, виды, устройство и применение
• Машинное зрение в робототехнике: что это, как работает и где применяется

Обновлено: 11.10.2026