Файл .htaccess відповідає за частину правил роботи сайту на вебсервері Apache. Помилка в одному символі, невдалий редирект або некоректна автоматична зміна файлу можуть зробити сайт недоступним, спричинити циклічні перенаправлення чи призвести до помилки 500.

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

Роль .htaccess

У WordPress файл .htaccess зазвичай використовується для налаштування постійних посилань, перенаправлень, заборони доступу до окремих файлів і каталогів, захисту системних директорій та інших правил Apache.

Найчастіше він розташований у кореневій папці WordPress — там, де містяться каталоги wp-admin, wp-content і wp-includes. Файл є прихованим, тому у файловому менеджері або FTP-клієнті потрібно ввімкнути показ прихованих файлів.

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

Ознаки пошкодження

На помилку в .htaccess можуть вказувати такі симптоми:

• помилка «500 Internal Server Error» на всіх або окремих сторінках;
• нескінченне перенаправлення між HTTP і HTTPS або між різними адресами сайту;
• помилка 403 Forbidden після додавання правил доступу;
• не відкриваються записи та сторінки, хоча головна сторінка працює;
• після зміни постійних посилань WordPress повертає 404;
• сайт перестав працювати одразу після встановлення плагіна, налаштування SSL або ручної зміни конфігурації.

Водночас аналогічні ознаки можуть бути пов’язані з проблемами PHP, правами доступу, перевищенням лімітів хостингу, несправністю плагіна або помилками бази даних. Детальніше про інші джерела критичної помилки можна прочитати у матеріалі Помилка 500 на сайті: причини та способи відновлення.

Для первинної перевірки перейменуйте файл, наприклад на .htaccess.old, і перевірте сайт. Якщо після цього помилка зникла, причина, імовірно, пов’язана з його вмістом. Не видаляйте файл одразу: збережіть копію для подальшого аналізу.

Стандартні правила WordPress

Для типової установки WordPress у кореневому .htaccess можуть використовуватися такі правила:

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

Якщо сайт встановлений у підкаталозі, значення RewriteBase і шлях у правилах можуть відрізнятися. Також конфігурація залежить від структури хостингу, версії Apache та наявності додаткових модулів.

Після збереження файлу перевірте, що він називається саме .htaccess, а не .htaccess.txt. Кодування зазвичай має бути звичайним текстовим, без службових символів на початку. Права доступу не повинні дозволяти довільний запис для всіх користувачів.

Інший безпечний спосіб відновлення — увійти до панелі WordPress, відкрити «Налаштування» → «Постійні посилання» і натиснути «Зберегти зміни». WordPress спробує сформувати стандартні правила автоматично. Якщо сервер не дозволяє запис у файл, правила потрібно перенести вручну, але робити це слід лише після резервного копіювання.

Додаткові редиректи

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

Особливо обережно потрібно працювати з правилами:

• примусового переходу з HTTP на HTTPS;
• перенаправлення між версіями з www і без www;
• зміни домену або структури URL;
• заборони доступу до IP-адрес, каталогів чи файлів;
• кешування та стиснення контенту;
• захисту адміністративної частини WordPress.

Неправильна умова RewriteCond або правило без прапорця завершення може створити цикл редиректів. Не слід без перевірки копіювати фрагменти з різних сайтів: вони можуть розраховувати на іншу структуру каталогів або конфігурацію сервера.

Перевірка після відновлення

Після створення нового .htaccess перевірте головну сторінку, кілька записів, статичні сторінки, категорії, пошук і сторінку входу в адміністративну панель. Окремо протестуйте сайт у приватному вікні браузера, щоб виключити вплив кешу та збережених перенаправлень.

Переконайтеся, що:

• немає помилок 500, 403 і 404 на сторінках, які раніше працювали;
• HTTP- та HTTPS-версії переходять на потрібну адресу без циклу;
• зображення, таблиці стилів і JavaScript завантажуються коректно;
• у WordPress зберігаються налаштування постійних посилань;
• у журналах сервера не з’являються нові критичні помилки.

Якщо після заміни .htaccess проблема не зникає, причина може бути у плагіні, темі, PHP, правах доступу, базі даних або конфігурації сервера. У такій ситуації краще не змінювати навмання інші системні файли: це ускладнює діагностику й підвищує ризик втрати даних. Спеціаліст може перевірити журнали, резервні копії, серверні налаштування та визначити безпечний спосіб відновлення.