301-редиректы в WordPress без плагина: как настроить и не потерять позиции

301-редиректы в WordPress без плагина настраиваются одним файлом и парой строк, но именно на этом этапе сайты теряют позиции чаще, чем на любых текстах: адрес меняют вечером, редирект ставят «примерно», а через месяц половина старых страниц отдаёт 404, вторая половина ведёт на главную, и поисковик перестаёт понимать, где у сайта что. Сам механизм простой — сервер получает запрос старого адреса и отвечает: «страница переехала навсегда, вот новый адрес». Дорого стоит не механизм, а мелочи вокруг него.

Ниже — где физически ставить правило и почему сервер быстрее плагина, как переносить адреса при смене структуры постоянных ссылок, чем опасны цепочки и петли, что делать со старыми адресами на .html и как проверять коды ответов не по одному, а сотнями за раз. В SEO с 2005 года, и переезд адресов — та задача, где цена ошибки видна только через два-три обновления индекса, когда откатывать уже поздно.

Где ставить редирект: сервер, PHP или плагин

Запрос к сайту проходит несколько слоёв, и редирект можно поставить на любом из них. Разница — в том, сколько работы сервер успеет проделать до того, как ответит браузеру или роботу.

Уровень веб-сервера. Это .htaccess в Apache или конфигурация nginx. Запрос обрабатывается до запуска PHP: интерпретатор не стартует, WordPress не грузится, база данных не опрашивается. Ответ 301 уходит за единицы миллисекунд. Правило переживает обновление ядра, смену темы и деактивацию плагинов.

Уровень PHP через плагин редиректов. Запрос доходит до index.php, WordPress поднимает ядро, подключает плагины, обращается к базе за списком правил и только потом отдаёт 301 — полный цикл загрузки CMS ради одного заголовка. На десятке правил разница незаметна, на нескольких тысячах это лишние запросы к базе на каждом обращении робота.

Автоматика самого WordPress. Ядро умеет угадывать адрес: если запрошенный URL похож на существующий, отдаётся 301 на найденную запись. Как основа переезда механизм опасен — угадывает он не всегда так, как нужно, а результат нигде не зафиксирован.

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

Какой код ответа выбирать

Код в ответе сервера — это не формальность, а инструкция поисковику, что делать с накопленными сигналами старого адреса.

• 301 Moved Permanently. Переезд навсегда. Старый адрес выпадает из индекса, вес и ссылочные сигналы переносятся на новый. Это рабочий вариант для 95% задач.
• 302 Found и 307. Временный переезд. Старый адрес остаётся в индексе, поисковик ждёт возвращения. Уместно, когда страница действительно вернётся: техработы, временная акция, региональная подмена.
• 308 Permanent Redirect. То же, что 301, но с сохранением метода запроса. Для обычного сайта разницы нет, для форм и API — есть.
• 410 Gone. Страница удалена намеренно и замены нет. Робот исключает её быстрее, чем при 404. Годится для устаревших акций, снятых с производства товаров без аналога, удалённых разделов.
• 404 Not Found. Не ошибка настройки, а честный ответ. Страницы, у которых нет замены по смыслу, обязаны отдавать 404 — это нормальное состояние сайта.

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

Правила для типовых задач и смены структуры ссылок

В WordPress файл .htaccess лежит в корне сайта и уже содержит блок между строками # BEGIN WordPress и # END WordPress. Этот блок трогать нельзя — ядро перезаписывает его при сохранении настроек постоянных ссылок. Свои правила ставьте выше блока WordPress, иначе внутренний обработчик перехватит запрос раньше вашего правила.

Одиночный перенос страницы:

Redirect 301 /staraya-stranica/ https://site.ru/novaya-stranica/

Обратите внимание: слева указывается путь без домена, справа — полный адрес со схемой. Перепутанные местами части — самая частая причина, по которой правило «не работает».

Смена структуры постоянных ссылок — самый массовый случай. Допустим, записи публиковались по схеме с датой (/2019/07/nazvanie-zapisi/), а вы переводите блог на схему /nazvanie-zapisi/. Все старые адреса надо накрыть одним шаблонным правилом, а не тысячей отдельных:

RewriteRule ^[0-9]{4}/[0-9]{2}/(.*)$ /$1 [R=301,L]

Читается так: путь начинается с четырёх цифр, слеша, двух цифр и слеша — отдай постоянный редирект на всё, что идёт дальше. Флаг R=301 задаёт код, L останавливает обработку правил.

Перенос целого раздела с сохранением вложенности:

RewriteRule ^blog/(.*)$ /stati/$1 [R=301,L]

Склейка версий адреса сайта — задача, которую надо закрыть до всех остальных. Сайт обязан быть доступен по одному варианту: один протокол, один вариант домена, один вариант слеша на конце. Пока этого нет, любые ваши редиректы будут удваиваться. Если на сайте параллельно идёт переезд на защищённый протокол, порядок и типовые ошибки собраны в разборе HTTPS, который убивает SEO: 4 ошибки переезда, после которых трафик падает в 0.

Важное правило: адрес меняют один раз и по делу. Каждая смена структуры — потеря части сигналов и несколько недель нестабильных позиций.

Цепочки, петли и редирект на главную

Три ошибки, которые превращают правильный по замыслу переезд в потерю трафика.

Цепочка. Адрес A ведёт на B, B ведёт на C, C — на D. Возникает, когда сайт переезжал несколько раз и правила накапливались слоями: сначала на защищённый протокол, потом на другую структуру, потом при перестройке разделов. Каждое звено — отдельный запрос к серверу и отдельная строчка в бюджете обхода. Робот проходит короткие цепочки, но длинные обрывает и до конечной страницы не доходит. Лечится сведением: все старые адреса должны вести на конечный адрес напрямую, одним прыжком, а промежуточные правила переписываются.

Петля. A ведёт на B, B ведёт обратно на A. Браузер показывает ошибку слишком большого числа перенаправлений, страница не открывается вообще. Классический источник — правило добавления слеша на конце, конфликтующее с правилом его удаления, или конфликт настроек сервера и плагина. Проверяется просто: откройте адрес и посмотрите цепочку в инструментах разработчика.

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

Ситуация	Правильное решение	Что происходит при ошибке
Страница переехала на новый адрес	301 на конкретную новую страницу	302 — старый адрес висит в индексе, вес не переносится
Страница удалена, замены по смыслу нет	404 или 410	301 на главную — мягкие ошибки и падение релевантности главной
Товар снят, есть аналог	301 на карточку аналога	301 на раздел каталога — пользователь ищет товар и уходит
Две статьи об одном и том же	301 слабой на сильную + перенос содержимого	Редирект без переноса текста — теряются запросы удалённой статьи
Сайт временно на техработах	503 с заголовком Retry-After	301 на заглушку — страницы вылетают из индекса
Накопились правила от прежних переездов	Свести цепочки в один прыжок	Цепочка из 3+ звеньев — робот не доходит до конечного адреса

Что делать со старыми адресами .html

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

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

Массовое правило для случая, когда структура сохранилась и меняется только расширение:

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

Такое правило снимает .html и добавляет слеш. Применять его можно, только если для каждого старого адреса существует новый с тем же путём. Иначе вы получите 301 на 404 — робот делает лишний прыжок и всё равно упирается в ошибку.

Адреса, у которых замены нет, честнее отдавать 410. Страницы, которые собрали много внешних ссылок, стоит воссоздать на новом адресе с обновлённым содержимым и увести на них старые — это возвращает и ссылочный вес, и переходы. Как поисковик реагирует на битые адреса и что происходит с их весом, показано в материале 404, 301, 302: как битые ссылки и неправильные редиректы крадут вес страниц.

Как проверять коды ответов пачкой

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

Один адрес с полной цепочкой из командной строки:

curl -sIL https://site.ru/staraya-stranica/ | grep -E "HTTP/|Location"

Флаг -I запрашивает только заголовки, -L идёт по всей цепочке переадресаций. В выводе вы увидите каждый шаг: сколько было прыжков, какие коды отдавались и куда вёл каждый. Здоровый результат — один блок с 301 и один финальный с 200.

Список адресов из файла:

while read u; do echo -n "$u "; curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$u"; done < urls.txt

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

Инструмент	Что показывает	Когда применять
curl в терминале	Полную цепочку кодов и заголовков	Точечная проверка спорного адреса
Скрипт по списку адресов	Код и конечный URL для сотен строк	Приёмка переезда, регулярный контроль
Настольный краулер	Внутренние ссылки, ведущие на редиректы	Поиск цепочек и ссылок на старые адреса
Проверка ответа сервера в панели вебмастера	Что видит именно робот поисковика	Когда браузер и робот получают разное
Отчёт по страницам входа в аналитике	Живые старые адреса, по которым идут люди	Составление карты соответствий перед переездом
Логи сервера	Реальные обращения робота и полученные им коды	Разбор ситуации «переехали, а трафик не вернулся»

Отдельно проверьте внутренние ссылки: после переезда по сайту продолжают идти ссылки на старые адреса — в меню, в текстах, в виджетах, в карте сайта, и каждая заставляет робота делать лишний прыжок.

Когда редирект не нужен и что вместо него

Редирект — не универсальное лекарство от дублей и ошибок. Есть ситуации, где он вредит.

Две страницы должны обе остаться доступными. Товар в двух категориях, версия для печати, страница с параметром сортировки — здесь нужен canonical, а не 301: физически страницы должны открываться, просто в индексе остаётся одна. Разница между инструментами разобрана в гайде Полный гайд по канониклам, редиректам и дублям: разбираем раз и навсегда.

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

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

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

Чеклист до и после переноса адресов

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

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

После. Прогнать весь список старых адресов скриптом: каждый должен отдавать ровно один 301 и конечный код 200. Найти краулером внутренние ссылки на редиректы. Отправить новые адреса на переобход. Через две недели сверить трафик по разделам — просадка в одном разделе почти всегда означает, что там правило сработало не так, как задумано.

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

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

Сколько держать 301 после переезда? Минимум год, а лучше постоянно. Внешние ссылки на старые адреса живут годами, и снятое через месяц правило превращает их все в 404.

Правда ли, что при 301 теряется часть веса? Современные поисковые системы переносят сигналы практически полностью при условии, что новый адрес релевантен старому по содержимому. Потери начинаются там, где редирект ведёт не туда: на главную, на раздел, на страницу другой тематики.

Сколько времени поисковик переклеивает адреса? Ориентир — два-три обновления индекса: несколько недель для небольшого сайта и до нескольких месяцев для крупного каталога. Ускоряет переобход в панели вебмастера и обновлённая карта сайта.

Можно ли ставить редирект в файле темы через PHP? Технически да, через хук инициализации с функцией wp_redirect и указанием кода 301. Но правило исчезнет при смене темы и сработает после полной загрузки ядра. Это худший из вариантов по надёжности.

Что делать, если хостинг на nginx и .htaccess не читается? Правила пишутся в конфигурации сервера директивой rewrite ... permanent или return 301. На панельном хостинге для этого обычно есть поле пользовательских директив; учтите, что панель может перезаписывать конфиг при изменении настроек сайта, и после каждой такой правки блок нужно проверять заново.

Нужно ли удалять старые адреса из индекса вручную? Нет. При корректном 301 поисковик сам заменит старый адрес новым. Ручное удаление имеет смысл только для страниц, которые вы отдаёте как 410 и хотите убрать быстрее.

Коротко

• Редирект на уровне сервера отрабатывает до запуска PHP и переживает смену темы и плагинов; плагин поднимает всё ядро ради одного заголовка.
• Свои правила в .htaccess ставятся выше блока WordPress — иначе внутренний обработчик перехватит запрос первым.
• 301 переносит сигналы, 302 оставляет старый адрес в индексе, 410 ускоряет удаление, 404 — нормальный ответ для страниц без замены.
• Редирект на главную вместо релевантной страницы плодит мягкие ошибки, не переносит вес и портит поведенческие сигналы главной.
• Цепочки надо сводить в один прыжок, а внутренние ссылки после переезда — переписывать на конечные адреса.
• Проверка делается пачкой: список старых адресов прогоняется скриптом, а всё, что не 301 или ведёт на главную, разбирается вручную.