Ви заходите на сайт, клацаєте посилання на свіжу статтю, і замість тексту, біла сторінка з «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 → повторне скидання. Ця послідовність із двох дій лагодить більшість випадків і не потребує ані спеціальних знань, ані доступу до сервера. Почніть із неї наступного разу, і, скоріш за все, далі йти не доведеться.