Вы заходите на сайт, кликаете по ссылке на свежую статью, и вместо текста белая страница с «404 Page Not Found». Знакомая картина.

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

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

💡 Быстрый обзор:

• Сбросьте настройки постоянных ссылок в админке одним кликом, для большинства сайтов проблема уходит мгновенно
• Если сброс не дал результата, переименуйте .htaccess и сбросьте ещё раз: WordPress создаст чистый файл с корректными rewrite-правилами
• Проверьте плагины методом исключения: деактивируйте все разом и включайте по одному после каждого сброса ссылок
• На сервере Apache вручную включите mod_rewrite и пропишите AllowOverride All в конфиге виртуального хоста

Почему постоянные ссылки WordPress перестают работать

Постоянная ссылка, это неизменяемый URL записи, страницы или рубрики. WordPress хранит структуру permalink-ов в базе данных и отдаёт «красивые» URL через модуль mod_rewrite веб-сервера Apache. Разрыв в любом звене этой цепочки даёт 404.

Установка нового плагина. Некоторые плагины вмешиваются в механизм формирования URL: перезаписывают .htaccess, добавляют свои правила редиректа или конфликтуют с уже активными расширениями. SEO-плагины, решения для кэширования и плагины безопасности в зоне особого риска, все они работают с URL на низком уровне.

Обновление ядра, темы или плагинов. Мажорное обновление WordPress или смена версии PHP на хостинге делают старые плагины несовместимыми. Результат, конфликт, который обрушивает rewrite-правила. Обновления безопасности пропускать нельзя, но перед каждым крупным апдейтом делайте бэкап и проверяйте совместимость на staging-копии.

Перенос сайта на новый домен или сервер. Миграция WordPress, одна из самых частых причин битых ссылок. Меняются абсолютные пути, сериализованные данные в базе и настройки веб-сервера. Даже добавление SSL-сертификата после переезда способно сломать постоянные ссылки, потому что требует правки .htaccess для редиректа HTTP→HTTPS. Если вы недавно перемещали установку WordPress в подкаталог, проверьте permalink-структуру сразу после миграции.

Восстановление резервной копии. Восстановление сайта из бэкапа иногда воскрешает и старые проблемы. Если резервная копия сделана до того, как вы настроили постоянные ссылки, 404 возвращаются. Даже продвинутые плагины резервного копирования не гарантируют идеального восстановления rewrite-правил после сложных миграций.

Повреждение .htaccess. Файл .htaccess, связующее звено между WordPress и Apache. В нём хранятся директивы mod_rewrite, отвечающие за «красивые» URL. Плагин дописывает мусор, вы случайно удаляете файл через FTP, а некоторые хостинг-панели сбрасывают его при смене настроек. Без рабочего .htaccess постоянные ссылки превращаются в ?p=123.

Как исправить неработающие постоянные ссылки: пошаговое руководство

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

Шаг 1. Сбросить настройки постоянных ссылок

Самый быстрый и безопасный способ. WordPress хранит структуру постоянных ссылок в базе данных, а при сохранении настроек заново генерирует rewrite-правила. Этот процесс разработчики называют «flush rewrite rules».

Зайдите в админку, перейдите в Settings → Permalinks:

Временно переключитесь на любую другую структуру, например, «Plain» вместо «Post name», и нажмите Save Changes. Затем верните исходный вариант и сохраните снова. Менять настройки насовсем не нужно: важен сам факт сохранения, который заставляет WordPress перестроить правила.

Перезагрузите сайт и проверьте, открываются ли записи. Заработало? Проблема решена. Нет, двигаемся дальше.

Шаг 2. Проверить и пересоздать файл.htaccess

Если сброс не помог, источник проблемы почти наверняка в .htaccess. Файл лежит в корне сайта, там же, где wp-config.php и папки wp-content, wp-includes.

Подключитесь к серверу через FTP (FileZilla, WinSCP) или файловый менеджер в панели хостинга:

Найдите .htaccess, кликните правой кнопкой и переименуйте в .htaccess_old. Не удаляйте файл, внутри могут быть критичные правила вроде редиректа HTTP→HTTPS или настроек сжатия:

После переименования WordPress перестаёт видеть старый файл. Зайдите в админку и сбросьте постоянные ссылки как в Шаге 1, система создаст новый, чистый .htaccess с корректными rewrite-правилами. Старый файл оставьте как резервную копию.

Шаг 3. Найти конфликтующий плагин

Проблема появилась после установки конкретного плагина? Деактивируйте его и сбросьте постоянные ссылки повторно, скорее всего, этого достаточно.

Когда виновник неизвестен, действуйте методом исключения:

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

Найденный конфликтующий плагин замените альтернативой из каталога WordPress.org. О проблеме сообщите разработчику: часто они знают о несовместимости и могут подсказать обходной путь.

Шаг 4. Настроить сервер: AllowOverride и mod_rewrite

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

Сначала убедитесь, что модуль mod_rewrite включён. Именно он преобразует «красивые» URL в понятные WordPress запросы. Проверьте и активируйте его командой:

1
sudo a2enmod rewrite

Модуль уже был включён, появится предупреждение, это нормально. Теперь перезапустите Apache:

1
sudo systemctl restart apache2

На CentOS/RHEL команда перезапуска отличается:

1
sudo systemctl restart httpd

Второй обязательный компонент, директива AllowOverride All. Она разрешает файлу .htaccess переопределять конфигурацию сервера в рамках директории сайта. Откройте конфигурационный файл Apache: на Ubuntu это /etc/apache2/sites-available/ваш-сайт.conf, на CentOS, /etc/httpd/conf/httpd.conf. Найдите секцию <Directory> и приведите её к такому виду:

1
<Directory /var/www/ваш-сайт/>
2
    AllowOverride All
3
</Directory>

Путь /var/www/ваш-сайт/ замените на реальный путь к корневой папке WordPress на вашем сервере. После правки перезапустите Apache командой выше, затем сбросьте постоянные ссылки в админке.

Эти два серверных действия, AllowOverride All плюс mod_rewrite, закрывают практически все оставшиеся сценарии поломки постоянных ссылок на Apache.

Видео: пошаговое восстановление постоянных ссылок

Если вам удобнее смотреть, а не читать, вот короткое руководство, которое показывает весь процесс от сброса permalink-настроек до восстановления .htaccess на реальном сайте:

⁉️🤔 Частые вопросы

Почему после сброса постоянных ссылок ошибка 404 остаётся?

Сброс через админку перезаписывает rewrite-правила в базе данных. Но если .htaccess физически недоступен для записи, неправильные права доступа, WordPress не сможет обновить файл на сервере. Проверьте права: обычно требуется 755 для директорий и 644 для файлов. Также убедитесь, что .htaccess существует физически: после переименования в Шаге 2 WordPress создаёт новый при следующем сбросе. Сам сброс не меняет URL существующих записей и не ломает индексацию.

Можно ли просто удалить.htaccess?

Нет. Без .htaccess на Apache-сервере WordPress откатывается к «простым» ссылкам вида ?p=123, это некрасиво и вредит SEO. Правильный порядок: переименовать старый файл с сохранением резервной копии, затем сбросить настройки постоянных ссылок в админке. WordPress создаст новый .htaccess автоматически. Никогда не удаляйте файл без возможности восстановления: в нём могут быть критичные правила редиректа HTTP→HTTPS или настройки сжатия.

Что делать, если сайт на Nginx?

На Nginx файла .htaccess нет, все rewrite-правила прописываются в конфигурации сервера. Стандартный блок для WordPress: location / { try_files $uri $uri/ /index.php?$args; }. Проверьте конфигурационный файл сайта (обычно /etc/nginx/sites-available/ваш-сайт), добавьте этот блок в секцию server и перезагрузите Nginx: sudo systemctl reload nginx. Шаги 1 и 3, сброс ссылок и проверка плагинов, работают для Nginx точно так же, как для Apache.

Какой плагин чаще всего ломает постоянные ссылки?

Статистически лидируют SEO-плагины, они напрямую манипулируют URL, и решения для кэширования: они создают статические копии страниц и могут «запомнить» битую версию. На третьем месте плагины безопасности, которые модифицируют .htaccess для блокировки подозрительных запросов. После отключения кэширующего плагина обязательно очистите кэш браузера или откройте сайт в режиме инкогнито, статическая закэшированная версия с 404 может показываться даже после исправления.

Нужно ли проверять целостность базы данных?

В редких случаях причина в повреждённой таблице wp_options, где хранятся настройки постоянных ссылок. Если ни один из описанных методов не помог, зайдите в phpMyAdmin, найдите таблицу wp_options и проверьте запись с option_name = 'rewrite_rules'. Значение выглядит как мусор или повреждённый сериализованный объект, удалите эту запись, затем сбросьте настройки постоянных ссылок в админке. WordPress пересоздаст rewrite-правила заново. Большинству пользователей этот шаг не понадобится: подавляющее большинство проблем решаются методами 1-3.

Что делать, если ничего не помогло

Мы прошли путь от простого сброса настроек до серверной конфигурации Apache и Nginx. Для абсолютного большинства сайтов один из этих методов закрывает проблему.

Если 404 всё ещё висят, свяжитесь с технической поддержкой хостинга. Опишите проблему и перечислите шаги, которые вы уже выполнили. Часто причина в специфике хостинг-окружения: отключённый mod_rewrite на уровне провайдера, нестандартная конфигурация PHP-FPM или кастомные правила файрвола, блокирующие запросы к index.php. Поддержка хостинга видит серверную часть, скрытую от вас, и решает такие проблемы за минуты.

Главное правило, которое стоит запомнить: сброс постоянных ссылок → переименование.htaccess → повторный сброс. Эта последовательность из двух действий чинит большинство случаев и не требует ни специальных знаний, ни доступа к серверу. Начните с неё в следующий раз, и, скорее всего, дальше идти не придётся.