Записи WordPress повертають 404, а головна сторінка працює

Якщо головна сторінка завантажується без проблем, а кожна окрема запис і сторінка повертає 404, значить, правила перезапису URL, на які покладається WordPress, відсутні або пошкоджені у вашому файлі .htaccess. Найшвидше рішення: перейдіть до Параметри → Постійні посилання у wp-admin і натисніть Зберегти зміни, нічого не змінюючи. Це змусить WordPress повторно згенерувати блок перезапису. Якщо 404 не зникають, значить, ваш .htaccess недоступний для запису веб-сервером, Apache налаштований ігнорувати його, або ви на Nginx (який взагалі не використовує .htaccess).

Чому головна сторінка працює, а записи — ні

Ваша головна сторінка працює тому, що запит до / обслуговується напряму з index.php у кореневому каталозі. Жодного перезапису не потрібно.

Запит до /2026/my-post/ — це інша річ. Цей шлях не є реальною текою на диску. Щоб WordPress відповів на нього, Apache має внутрішньо перенаправити запит до index.php, після чого WordPress зчитує REQUEST_URI, зіставляє його з правилами перезапису, збереженими в опції rewrite_rules у базі даних, визначає змінні запиту (WP::parse_request()) і завантажує потрібну запис.

Саме передача керування від Apache до index.php і є тим, що ламається. Вона повністю залежить від цього блоку в .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Два рядки RewriteCond означають: якщо запитуваний шлях не є реальним файлом (!-f) і не є реальним каталогом (!-d), надіслати його до index.php. Приберіть цей блок — і Apache шукатиме буквальний каталог /2026/my-post/, не знайде його і поверне свій власний 404 — ще до того, як WordPress побачить запит.

Чому WordPress перезаписує .htaccess, коли ви зберігаєте постійні посилання

Це та частина, яку більшість посібників пропускає. Коли ви натискаєте «Зберегти» на екрані постійних посилань, WordPress викликає flush_rewrite_rules(). На Apache з доступним для запису .htaccess це запускає save_mod_rewrite_rules(), який повторно генерує наведений вище блок через WP_Rewrite::mod_rewrite_rules() і записує його назад за допомогою insert_with_markers().

insert_with_markers() торкається лише рядків між # BEGIN WordPress та # END WordPress. Усе за межами цих маркерів залишається без змін. Усе всередині відкидається й перезаписується. Новіші версії WordPress навіть виводять попередження прямо у файлі:

Any changes to the directives between these markers will be overwritten.

Тож твердження «WordPress перезаписує мій .htaccess» правдиве, але з нюансом: він переписує лише свій власний позначений блок і лише тоді, коли файл доступний для запису. Якщо файл не доступний для запису, збереження нічого не робить на диску без жодного повідомлення. WordPress показує жовте сповіщення на екрані постійних посилань, де просить вставити правила вручну, і якщо ви пропустите це сповіщення, ваш блок перезапису залишиться відсутнім, а кожна запис і далі повертатиме 404.

Як це виправити, по порядку

1. Збережіть постійні посилання заново. Параметри → Постійні посилання → Зберегти зміни. Жодних правок не потрібно. Це повторно запускає скидання та переписує блок. Це вирішує більшість випадків, зокрема застарілі правила після міграції.

2. Перевірте, що .htaccess існує і доступний для запису. Він міститься в тій самій теці, що й wp-config.php. Це прихований файл, тож увімкніть «показувати приховані файли» у вашому FTP-клієнті або скористайтеся командою:

ls -la /path/to/wordpress/.htaccess

Якщо його немає, створіть його і вставте правильний блок. Якщо ваша інсталяція міститься в підкаталозі, RewriteBase та кінцева ціль перезапису мають відповідати цьому шляху — помилка тут є найпоширенішою причиною того, чому вручну вставлений блок усе одно дає 404. Наш генератор .htaccess створює точний блок для шляху вашої інсталяції, тож вам не доведеться вгадувати.

3. Переконайтеся, що Apache дозволено читати .htaccess. Якщо у віртуального хоста стоїть AllowOverride None, Apache повністю ігнорує файл незалежно від його вмісту. Вам потрібно AllowOverride All (або принаймні FileInfo) на каталозі WordPress. Це в конфігурації сервера, а не в .htaccess, тож потрібен доступ до сервера:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Переконайтеся, що mod_rewrite увімкнено. На Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. На Nginx .htaccess немає. Перезаписи натомість прописуються в блоці server:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Швидка діагностика: чий це 404?

Придивіться до сторінки 404. Якщо це неоформлена сторінка помилки Apache чи хостингу, значить, Apache так і не дістався до WordPress — це проблема .htaccess або конфігурації сервера (кроки 2–4). Якщо це оформлена сторінка 404 вашого шаблону, значить, WordPress отримує запит, але не може його зіставити — правила в базі даних застаріли, і повторне збереження постійних посилань (крок 1) є рішенням. Саме ця відмінність економить більшості людей годину вгадувань.

Чого не варто робити

Не вимикайте спершу всі свої плагіни. Чистий симптом «записи дають 404, головна працює» — це проблема перезапису, а не конфлікт плагінів. Вимкнення плагінів — рефлекторна відповідь на форумах, і вона майже ніколи не стосується цього.

Не робіть chmod 777 для вашого .htaccess. WordPress потрібно, щоб файл був доступний для запису користувачеві веб-сервера, а це не те саме, що доступний для запису всім. 644 з правильним власником — цілком нормально й безпечно; 777 — це діра в безпеці, яка все одно не виправить маршрутизацію.

Не вставляйте власні правила перезапису всередині маркерів # BEGIN WordPress / # END WordPress. Вони будуть стерті наступного разу, коли хтось збереже постійні посилання. Розміщуйте власні директиви вище рядка # BEGIN WordPress.

Не перевстановлюйте WordPress. Файли ядра справні. Це один відсутній блок тексту, а не пошкоджена інсталяція.

Не звинувачуйте свій шаблон. Маршрутизація постійних посилань — це ядро WordPress. Шаблон не може її спричинити й не може її виправити.

Досі не вдається?

Якщо ви заново зберегли постійні посилання, переконалися, що блок присутній і доступний для запису, та встановили AllowOverride All, залишається один підозрюваний — плагін безпеки або правило на рівні хостингу, яке за вашою спиною повторно генерує чи блокує .htaccess. Перевірте час зміни файлу одразу після збереження постійних посилань — якщо він не змінився, значить, щось блокує запис. Згенеруйте чистий блок за допомогою генератора .htaccess, вставте його і повторно перевірте з жорстким оновленням сторінки.