Если на сайте WordPress меняются URL, структура рубрик или нужно убрать старые адреса после миграции, 301-редирект часто делают «на глаз». В итоге появляются цепочки, петли, лишние переходы и просадка индексации. Ниже — рабочая схема для .htaccess: как поставить редирект, как не сломать админку и как проверить, что всё отрабатывает именно как 301.
Когда редирект нужен, а когда лучше не трогать .htaccess
301 уместен, если старый адрес должен навсегда вести на новый: смена slug у записи, перенос раздела, склейка http и https, переход с www на без www, исправление дублей со слешем и без него. Если задача временная, нужен 302. Если вы просто хотите скрыть страницу из поиска, редирект не заменяет noindex и canonical.
Для WordPress важно не смешивать уровни логики: часть редиректов может делать сам сайт, часть — сервер. Если в .htaccess уже есть правила от WordPress, кэш-плагина или CDN, порядок строк имеет значение.
Диагностика проблемы перед правкой
Сначала проверьте, что именно сейчас происходит с URL. Это экономит время и помогает не создать петлю. Откройте старый адрес в браузере и посмотрите цепочку переходов через DevTools или командой curl.
curl -I https://example.com/staryj-url/В ответе смотрите три вещи:
HTTP/1.1 301 Moved Permanently— нужен именно такой статус;- заголовок
Location— куда ведёт редирект; - нет ли второго или третьего перехода после первого.
Если адрес сначала уходит на http, потом на https, потом ещё раз на новый slug, это уже цепочка. Она не всегда критична, но лучше свести её к одному шагу.
Что проверить в WordPress до редактирования файла
Посмотрите настройки Постоянные ссылки в админке. Если структура URL менялась недавно, WordPress мог уже сгенерировать часть нужных правил. Также проверьте, не делает ли редирект плагин безопасности, SEO-плагин или серверный конфиг хостинга. Дублирующие правила — частая причина циклов.
| Подход | Когда использовать | Минус |
|---|---|---|
| .htaccess | Apache, быстрый редирект на уровне сервера | Можно сломать сайт при ошибке в синтаксисе |
| Плагин редиректов | Нужно управлять правилами из админки | Дополнительная нагрузка и зависимость от плагина |
| functions.php | Точечная логика для темы или дочерней темы | Не подходит для массовых правил и миграций |
Пошаговое решение: редирект в .htaccess
Перед изменениями сделайте копию файла. На Apache стандартный файл WordPress обычно лежит в корне сайта. Если у вас есть доступ только через FTP, редактируйте аккуратно: одна лишняя строка может дать 500 ошибку.
1. Редирект одного старого URL на новый
Самый безопасный вариант — точечное правило. Его лучше ставить выше стандартного блока WordPress, если редирект должен сработать до внутренних правил CMS.
RewriteEngine On
RewriteRule ^staryj-url/?$ https://example.com/novyj-url/ [R=301,L]Здесь ^staryj-url/?$ ловит адрес со слешем и без него. Флаг L останавливает обработку после совпадения, а R=301 отдаёт постоянный редирект.
2. Склейка http на https
Если сайт уже работает по HTTPS, отдельное правило на схему помогает убрать дубли. Но если хостинг или прокси уже делает это на своём уровне, не дублируйте правило в .htaccess.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Это правило не зависит от конкретного URL и переводит весь сайт на защищённый протокол.
3. Склейка www и без www
Выберите один канонический вариант и придерживайтесь его везде: в настройках сайта, в sitemap, в canonical и в редиректах. Иначе поисковик увидит разные версии одного и того же адреса.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Если нужен вариант с www, меняется только целевой хост.
Как не создать петлю редиректов
Петля возникает, когда правило отправляет запрос туда, откуда он снова попадает в то же правило. Типичный случай — одновременно включён редирект в плагине и в .htaccess, а ещё в настройках WordPress указан другой адрес сайта.
Проверяйте:
- совпадает ли
WordPress AddressиSite Addressс каноническим доменом; - не делает ли хостинг принудительный редирект на уровне панели;
- нет ли отдельного правила для
wwwи ещё одного для https, которые конфликтуют между собой; - не ведёт ли старый URL на промежуточную страницу, которая потом редиректит ещё раз.
Если редиректов много, лучше сначала собрать карту старых и новых адресов в таблицу и проверить каждый маршрут вручную.
Проверка результата после внедрения
После правки не ограничивайтесь открытием страницы в браузере. Браузер может показать уже закэшированный ответ. Проверьте заголовки ответа и финальный URL.
curl -I https://example.com/staryj-url/
curl -I https://example.com/novyj-url/Что должно быть видно:
- старый адрес отдаёт
301; - в
Locationуказан сразу конечный URL; - новый адрес открывается без дополнительного редиректа, если он уже канонический;
- нет цепочки из нескольких
301подряд.
Дополнительно проверьте страницу в Google Search Console, если она уже была в индексе. Там полезно смотреть, какой URL выбран как канонический и не остались ли старые адреса в отчётах об обходе.
Частые ошибки и как их исправить
Правило стоит ниже блока WordPress
Если редирект не срабатывает, а WordPress уже обработал запрос, правило может просто не дойти до нужной строки. Перенесите точечные редиректы выше стандартного блока # BEGIN WordPress.
Смешаны слеш и отсутствие слеша
Один адрес ведёт на /page, другой на /page/. Для Apache это разные шаблоны, если не учесть оба варианта. Используйте /?$ в конце правила, если нужно покрыть оба случая.
Редирект на несуществующий адрес
Иногда старый URL отправляют на новый, которого ещё нет или он закрыт другим правилом. В результате пользователь видит 404 уже после перехода. Сначала создайте целевую страницу, потом включайте 301.
Несовместимость с кэшем
После правки старый ответ может продолжать отдаваться из кэша браузера, плагина или CDN. Очистите кэш сайта, серверный кэш и, если есть, кэш на стороне Cloudflare или другого прокси.
Практические советы по безопасности и производительности
Не храните в .htaccess десятки однотипных правил, если задача повторяется регулярно. Для массовых миграций удобнее временно использовать плагин редиректов или серверный конфиг, а потом убрать лишнее. Чем длиннее файл, тем сложнее отлаживать конфликтующие строки.
Если вы часто меняете структуру контента, держите отдельную таблицу соответствий старых и новых URL. Это снижает риск случайно отправить трафик на неправильную страницу и помогает быстро восстановить логику после обновлений темы или плагинов.
Для сайтов на WordPress с активной SEO-оптимизацией полезно проверять редиректы после каждого изменения постоянных ссылок, установки кэша и обновления плагинов безопасности. Именно такие изменения чаще всего незаметно переписывают маршрутизацию.