Как исправить 404 на сайте WordPress после смены постоянных ссылок

Смена структуры постоянных ссылок в WordPress почти всегда тянет за собой хвост из 404. Чаще всего это происходит не сразу, а после того как поисковики и старые ссылки начинают ходить по прежним адресам. Если не закрыть вопрос аккуратно, сайт получает битые переходы, просадку поведенческих сигналов и лишний шум в отчётах Search Console.

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

Когда 404 после смены ссылок — это нормальный симптом, а когда ошибка настройки

После изменения структуры URL старые адреса сами по себе не станут рабочими. Если у вас было /2024/05/post-name/, а стало просто /post-name/, то без редиректа старый URL обязан отдавать 404. Ошибка начинается тогда, когда:

  • 404 получают и старые, и новые адреса;
  • редирект ведёт не на новый URL, а на главную;
  • цепочка редиректов растягивается на 2–3 шага;
  • часть записей открывается, а часть — нет из-за конфликтов с плагином кэша, мультисайтом или ручными правилами в .htaccess.

Если сайт на Nginx, то правка только .htaccess ничего не даст. Если используется плагин для редиректов, но в серверной конфигурации уже есть свои правила, можно получить дублирующиеся или конфликтующие перенаправления.

Диагностика: что именно ломается

Сначала нужно понять, где возникает ошибка: на уровне WordPress, веб-сервера или уже в поисковом индексе. Это экономит время, потому что лечить «404» без уточнения причины — почти всегда путь к новым проблемам.

Проверьте, какой ответ отдаёт старый URL

Возьмите один старый адрес и проверьте его заголовки. Если есть доступ к консоли, удобно использовать curl:

curl -I https://example.com/2024/05/post-name/

Нормальные варианты:

  • 301 Moved Permanently — если настроен редирект на новый адрес;
  • 404 Not Found — если редиректа нет и старый URL больше не должен открываться;
  • 200 OK — если адрес почему-то продолжает работать, хотя структура уже изменилась.

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

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

В админке откройте Настройки → Постоянные ссылки и просто сохраните их заново. Это не магия, а способ пересобрать rewrite rules. После миграции структуры URL WordPress иногда продолжает использовать старые правила до пересохранения.

Если после этого новые записи всё равно открываются с 404, проверьте:

  • есть ли файл .htaccess в корне сайта и не перезаписан ли он вручную;
  • не отключены ли rewrite-модули на сервере;
  • не конфликтует ли плагин кэша с правилами редиректа;
  • не используется ли кастомный тип записей с отдельной структурой ссылок.

Пошаговое решение: как вернуть старые URL в рабочее состояние

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

1. Сбросьте правила постоянных ссылок

В админке WordPress откройте настройки постоянных ссылок и нажмите «Сохранить изменения» без правок. Это обновит правила маршрутизации. После этого проверьте несколько новых URL вручную.

Если доступ к админке ограничен, можно временно отключить и включить плагин, который влияет на ЧПУ, но это уже запасной вариант. Лучше сначала проверить серверные правила.

2. Настройте 301-редиректы со старых адресов на новые

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

RewriteEngine On
RewriteRule ^2024/05/(.*)$ /$1 [R=301,L]

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

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

3. Уберите конфликтующие редиректы

Если старый URL сначала уходит на одну страницу, а потом ещё раз перенаправляется на другую, это уже цепочка. Она часто появляется, когда:

  • редирект настроен и в плагине, и в .htaccess;
  • HTTPS включён отдельно, а потом ещё раз принудительно через плагин;
  • сайт переехал с www на без www, а затем ещё менялась структура ссылок.

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

Сравнение подходов: плагин, сервер, ручная правка

ПодходКогда подходитПлюсыМинусы
Плагин редиректовНужно быстро закрыть несколько старых URLУдобно в админке, не требует доступа к серверуДополнительная нагрузка, риск конфликтов
.htaccess / NginxМассовая смена структуры ссылокБыстро, прозрачно, без лишнего PHPНужен доступ к конфигу, легко ошибиться в правилах
Ручная правка ссылок в контентеНесколько важных страницТочный контрольНе решает проблему старых внешних ссылок и индексации

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

После настройки не ограничивайтесь открытием одной страницы в браузере. Проверьте несколько уровней:

  • старый URL отдаёт 301 на новый адрес;
  • новый URL отдаёт 200 без лишних редиректов;
  • внутренние ссылки в меню, хлебных крошках и контенте ведут сразу на новый адрес;
  • в Search Console постепенно уменьшается число ошибок сканирования;
  • в логах сервера нет повторяющихся запросов к старым адресам с одинаковым результатом.

Если есть доступ к инструментам проверки, прогоните несколько URL через curl -I или любой HTTP checker. Важно смотреть именно код ответа, а не только визуальное открытие страницы в браузере.

Что ещё стоит проверить в админке

После смены структуры ссылок иногда ломаются:

  • архивы рубрик и меток;
  • страницы пагинации;
  • кастомные типы записей;
  • канонические URL, если их генерирует SEO-плагин.

Если вы используете SEO-плагин, убедитесь, что он не подставляет старый canonical. Иначе поисковик может видеть новый адрес, но считать каноническим старый, уже нерабочий URL.

Частые ошибки и как их исправить

Редирект ведёт на главную

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

После правки .htaccess сайт начал отдавать 500

Обычно причина в синтаксисе или в том, что правило вставили не в тот блок. Верните резервную копию файла и добавляйте изменения по одному. Если на сервере Nginx, не пытайтесь применять Apache-правила буквально.

Новые записи открываются, старые — нет, хотя редиректы есть

Проверьте, не кэширует ли плагин старый ответ. Иногда CDN или page cache продолжает отдавать старую версию страницы, даже если редирект уже исправлен. Очистите кэш на всех уровнях: плагин, сервер, CDN, браузер.

Редирект работает в браузере, но Search Console всё ещё показывает 404

Это нормально на коротком промежутке времени: поисковик переобходит URL не мгновенно. Но если ошибка держится неделями, проверьте, не закрыт ли старый адрес от сканирования robots.txt или noindex-правилами так, что бот не видит новый маршрут.

Чек-лист перед публикацией изменений

  • Сохранены настройки постоянных ссылок в WordPress.
  • Старые URL отдают 301, а не 302.
  • Нет цепочек редиректов больше одного шага.
  • Новые страницы открываются с кодом 200.
  • Кэш очищен на сайте, сервере и CDN.
  • Проверены рубрики, метки, пагинация и кастомные типы записей.
  • В SEO-плагине не остались старые canonical-адреса.

Практические советы по безопасности и производительности

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

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

Если вам нужно не только убрать 404 после смены ссылок, но и подчистить SEO-технику сайта в целом, имеет смысл отдельно проверить дубли, каноникал и служебные страницы. Для этого иногда используют наборы вроде Clearfy Pro, но выбирать инструмент стоит по задаче, а не по списку функций.

Как убрать дубли страниц в WordPress: noindex, canonical и robots.txt без лишних блокировок
16.09.2026
Как исправить 404 на сайте WordPress после смены постоянных ссылок
20.09.2026