Стандартный файл .htaccess WordPress: что в нём и как его восстановить

Стандартный файл .htaccess WordPress — это короткий блок RewriteEngine, который программа записывает в .htaccess в корне вашего сайта, чтобы постоянные ссылки вроде /2026/10/nazvanie-zapisi/ корректно разрешались, а не выдавали 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.