Стандартний файл .htaccess WordPress: що в ньому і як його відновити

Стандартний файл .htaccess WordPress — це короткий блок RewriteEngine, який програма записує в .htaccess у кореневій папці вашого сайту, щоб постійні посилання типу /2026/10/nazva-zapysu/ коректно розв’язувались, а не видавали 404. Виглядає він так:

# 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

Це точний блок, взятий з офіційного керівництва WordPress щодо Apache HTTP Server та логіки перезапису, описаної на сторінці HelpHub про гарні постійні посилання. Якщо ваш RewriteBase не / — наприклад, бо WordPress встановлено в підпапці — він відповідатиме цьому шляху замість цього, і це так само нормально й генерується самим WordPress.

Головне

• WordPress генерує цей блок автоматично, лише на Apache та LiteSpeed, щоразу, коли файл доступний для запису і ви зберігаєте Налаштування > Постійні посилання.
• Якщо файл відсутній або пошкоджений, усі постійні посилання, крім головної сторінки, повертають 404, бо без правил перезапису знайти можна лише головну сторінку.
• Усе, що додаєте ви чи плагін, повинно бути над # BEGIN WordPress, ніколи всередині маркерів — WordPress перезаписує все між ними щоразу при збереженні постійних посилань.

Потрібно перебудувати файл із вашим реальним шляхом і додатковими правилами? Генератор .htaccess для WordPress складає правильний файл прямо в браузері.

Що робить кожен рядок

RewriteEngine On увімкнює модуль mod_rewrite Apache для цього каталогу; без цього рядка все наступне не діє.

RewriteBase / повідомляє Apache, що перезаписані шляхи відносні до кореня сайту. WordPress налаштовує це відповідно до того, де сайт реально розташований — установка в підпапці отримує RewriteBase /blog/, а не /.

RewriteRule ^index\.php$ - [L] — це захист без ефекту: якщо запит уже є index.php, перезапис зупиняється, і запит проходить без змін.

Два рядки RewriteCond — це справжня логіка. %{REQUEST_FILENAME} !-f та !-d запитують: “цей запит НЕ відповідає реальному файлу, і НЕ відповідає реальному каталогу?”. Обидва мають бути істинними, щоб спрацювало фінальне правило — так реальне зображення, CSS-файл чи завантажений PDF подаються напряму і ніколи не стикаються з маршрутизацією WordPress.

RewriteRule . /index.php [L] — це те, що робить постійні посилання робочими: усе, що пройшло дві попередні умови — тобто не є реальним файлом чи папкою — надсилається до index.php, і власна маршрутизація WordPress (WP_Query, теги перезапису) вирішує, який запис, сторінку чи архів насправді означає ця URL-адреса.

Коли WordPress відтворює цей файл, а коли не може

WordPress сам намагається записати .htaccess щоразу, коли ви відкриваєте Налаштування > Постійні посилання і натискаєте Зберегти зміни, навіть якщо на екрані нічого не змінилося. Це збереження запускає flush_rewrite_rules(), яка намагається відкрити .htaccess для запису і вставити поточний блок між маркерами.

Ця спроба тихо зазнає невдачі, залишаючи файл відсутнім або застарілим, коли:

• Файл або його батьківська папка недоступні для запису для користувача, під яким працює PHP. На багатьох спільних хостингах PHP працює від імені системного користувача, відмінного від того, хто завантажував файли через FTP, тож права, які виглядають коректно в FTP-клієнті, все одно можуть блокувати запис WordPress.
• Ви використовуєте nginx. .htaccess — це механізм, що працює лише на Apache і LiteSpeed (сама документація Apache щодо AllowOverride пояснює чому: у nginx немає файлу конфігурації на кожен каталог, який він би перечитував при кожному запиті). Еквівалент на nginx — директива try_files всередині блоку server, яку може редагувати лише той, у кого є доступ до сервера; WordPress ніколи не зможе записати її за вас.
• AllowOverride встановлено на None для каталогу вашого сайту в основній конфігурації Apache. Це налаштування, яке взагалі дозволяє .htaccess щось перевизначати; документація Apache прямо каже: при AllowOverride None “файли .htaccess повністю ігноруються” — WordPress може записати ідеальний файл, і він все одно залишиться без ефекту, доки це налаштування не зміниться на рівні сервера.
• Файл було видалено або він ніколи не існував, і щось під час збереження не викликало регенерацію — найчастіше тому, що структура постійних посилань уже була такою ж, тож WordPress не побачив змін для перезапису.

Як відновити його вручну

Якщо записи та сторінки видають 404, поки головна сторінка все ще працює — це типова ознака відсутнього або зламаного .htaccess. Виправте це в два кроки.

1. Спочатку спробуйте рішення в один клік. Перейдіть у Налаштування > Постійні посилання в панелі керування WordPress і натисніть Зберегти зміни, нічого не змінюючи. Якщо файл доступний для запису, лише цього достатньо, щоб його відтворити — і справу зроблено.

2. Якщо це не допомогло, створіть файл вручну. Підключіться через FTP/SFTP або файловий менеджер хостингу, перейдіть у папку, де встановлено WordPress (ту, що містить wp-config.php), і перевірте, чи .htaccess взагалі існує — це прихований файл, деякі файлові менеджери приховують його за замовчуванням; увімкніть “показувати приховані файли”.

• Якщо він відсутній, створіть новий файл з назвою точно .htaccess (без .txt, нічого перед крапкою).
• Вставте стандартний блок вище, скоригувавши RewriteBase, якщо WordPress знаходиться в підпапці.
• Збережіть і перезавантажте постійне посилання якогось запису, щоб підтвердити, що все працює.

Якщо після цього все ще 404, причина змінилася з “.htaccess відсутній” на “.htaccess ігнорується” — запитайте хостинг про AllowOverride, бо правильний файл у каталозі, де Apache наказано його ігнорувати, поводиться точно так само, як відсутність файлу.

Ваші власні правила проти блоку WordPress

Плагін або ручне редагування можуть додати власні правила — редиректи, захист від хотлінкінгу, заголовки кешу. Це окремий блок, відмінний від того, що генерує WordPress, і ці два блоки ніколи не повинні перетинатися:

# Правила, додані вами чи плагіном — НАД маркерами WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # приклад: захист від хотлінкінгу, правила кешу тощо.
</FilesMatch>

# 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

Усе, розміщене між # BEGIN WordPress і # END WordPress, тихо видаляється при наступному збереженні екрана Постійних посилань, бо WordPress вважає всю цю ділянку своєю і переписує її повністю. Це найпоширеніша причина скарг “моє власне правило зникло” — його ніколи не видаляли навмисно, воно просто було всередині блоку, який WordPress вважає своїм. Щодо редиректів зокрема, див. правильно оформлені правила редиректів .htaccess WordPress — там розказано, де вони мають бути, і як уникнути циклів.

Це також найпоширеніша причина раптової помилки 500 Internal Server Error одразу після редагування файлу: правило, скопійоване з форуму, написаного для іншої версії Apache (синтаксис Order/Deny з 2.2, змішаний із синтаксисом Require з 2.4), ламає розбір усього файлу, включно з блоком WordPress нижче, і падає весь сайт — а не лише та частина, яку ви торкалися.

За межами стандартного блоку

Стандартний блок відповідає лише за маршрутизацію постійних посилань. Якщо ви також хочете посилити доступ до чутливих файлів або додати ту невелику кількість правил .htaccess, які справді зменшують поверхню атаки — блокування виконання PHP у /uploads, відмову прямим запитам до wp-config.php — дивіться правила безпеки .htaccess WordPress, які справді допомагають. А якщо постійні посилання видають 404 з іншої причини — неправильна структура постійних посилань, шар кешу, що віддає застарілі правила, конфлікти мультисайту в підкаталогах — непрацюючі постійні посилання WordPress розглядає інші причини.

Поширені запитання

Що таке стандартний файл .htaccess WordPress? Це блок RewriteEngine, який WordPress записує між # BEGIN WordPress і # END WordPress, щоб постійні посилання розв’язувались у index.php, а не видавали 404.

Який точний стандартний код .htaccess WordPress? RewriteEngine On, RewriteBase /, правило-пропуск для index.php, дві умови, що перевіряють, що запит не є реальним файлом чи каталогом, і фінальне правило, яке надсилає все інше до index.php. Повний блок наведено на початку цього посібника.

Чому всі мої записи видають 404, крім головної сторінки? Головну сторінку можна знайти без жодних правил перезапису; будь-якому іншому постійному посиланню вони потрібні. Відсутній або пошкоджений .htaccess на Apache створює саме таку картину.

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

Чому в nginx немає файлу .htaccess WordPress? .htaccess працює лише на Apache та LiteSpeed. У nginx немає файлу конфігурації на каталог, і він повністю ігнорує .htaccess; та ж маршрутизація пишеться як правило try_files у блоці server nginx.

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

---

Зберіть чистий, правильний .htaccess — стандартний блок постійних посилань плюс будь-які правила безпеки чи редиректів, які вам справді потрібні — за допомогою безкоштовного генератора .htaccess для WordPress.