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

Стандартный файл .htaccess WordPress — это короткий блок RewriteEngine, который программа записывает в .htaccess в корне вашего сайта, чтобы постоянные ссылки вроде /2026/10/nazvanie-zapisi/ открывались, а не выдавали 404. Выглядит он так:

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

Эти правила взяты из кода, которым WordPress генерирует блок, и совпадают с собственным руководством WordPress по .htaccess. WordPress также записывает три строки комментария сразу после # BEGIN WordPress, которые предупреждают, что правки между маркерами будут перезаписаны. На работу правил они не влияют.

При установке в подпапке WordPress подставляет путь к подпапке и в RewriteBase, и в последнее правило, например RewriteBase /blog/ и RewriteRule . /blog/index.php [L]. Сети multisite используют другой блок, и WordPress не записывает для них этот файл автоматически.

Главное

• WordPress генерирует этот блок на Apache и LiteSpeed, когда у него есть право записи и включены красивые постоянные ссылки. Достаточно открыть Настройки > Постоянные ссылки.
• Если файл отсутствует или повреждён, постоянные ссылки возвращают 404, а главная страница продолжает открываться, потому что ей не нужны правила перезаписи.
• Всё, что добавляете вы или плагин, размещайте над # BEGIN WordPress, никогда не между маркерами. WordPress заменяет всё между ними при обновлении файла.

Что делает каждая строка

RewriteEngine On включает модуль mod_rewrite Apache для этого каталога; без него правила ниже ничего не делают.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] не меняет URL (именно это означает -) и копирует заголовок Authorization запроса в переменную сервера. WordPress читает эту переменную, чтобы получить имя пользователя и пароль, отправленные в заголовке, например пароль приложения.

RewriteBase / задаёт префикс пути, который Apache использует для переписанных URL. WordPress выставляет его в зависимости от расположения сайта, поэтому установка в подпапке получает RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] — это защита: если запрос уже является index.php, перезапись останавливается и запрос проходит без изменений.

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

RewriteRule . /index.php [L] — это то, что заставляет постоянные ссылки работать. Всё, что прошло эти два условия, отправляется в index.php, а WordPress решает, какую запись, страницу или архив означает этот URL.

Когда WordPress пересоздаёт этот файл, а когда не может

WordPress сбрасывает свои правила перезаписи при каждой загрузке экрана Настройки > Постоянные ссылки, поэтому его достаточно открыть, и нажимать Сохранить изменения не нужно. Если .htaccess отсутствует, WordPress его создаёт, при условии что папка доступна для записи и включены красивые постоянные ссылки. Если файл существует и доступен для записи, WordPress заменяет блок между маркерами.

Это не решает проблему в таких случаях:

• Файл или его папка недоступны для записи пользователю, под которым работает PHP. Экран показывает ошибку о том, что файл .htaccess недоступен для записи, и правила для вставки. На некоторых хостингах PHP работает от имени другого системного пользователя, не того, кому принадлежат файлы, загруженные по FTP, поэтому права, которые выглядят корректно в FTP-клиенте, всё равно могут блокировать WordPress.
• Вы используете nginx. В руководстве WordPress по nginx сказано, что у nginx нет файла конфигурации на уровне каталога, как .htaccess, а WordPress не может менять конфигурацию сервера. Эквивалентная маршрутизация — это директива try_files в конфигурации сервера, которую должен редактировать администратор.
• AllowOverride установлен в None для каталога вашего сайта в основной конфигурации Apache. Документация Apache говорит (цитата на языке оригинала): “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” То есть файлы .htaccess полностью игнорируются, если вы явно не включите их для каталога. WordPress может записать идеальный файл, но он всё равно ничего не сделает. Правилам перезаписи нужен AllowOverride FileInfo (или All), и изменить это, возможно, придётся вашему хостингу.
• Постоянные ссылки установлены в режим «Простые». Простым URL не нужны правила перезаписи, поэтому WordPress не создаёт для них файл.

Как восстановить его вручную

Если записи и страницы выдают 404, а главная страница работает, первым делом проверьте, не отсутствует ли .htaccess и не сломан ли он. Исправьте это в два шага.

1. Сначала попробуйте решение в один клик. Откройте Настройки > Постоянные ссылки в wp-admin и нажмите Сохранить изменения, ничего не меняя. Если WordPress может записать файл, это его пересоздаст. Если не может, экран покажет ошибку и нужные правила.

2. Если это не помогло, создайте файл вручную. Подключитесь по FTP/SFTP или через файловый менеджер хостинга и перейдите в корневую папку сайта, обычно ту, что содержит wp-admin. Проверьте, существует ли .htaccess. Его имя начинается с точки, поэтому некоторые файловые менеджеры по умолчанию его скрывают; включите «показывать скрытые файлы».

• Если его нет, создайте новый файл с именем точно .htaccess (без .txt, ничего перед точкой).
• Вставьте правила, которые показал WordPress, или стандартный блок из начала этого руководства. При установке в подпапке измените RewriteBase и последнее правило.
• Сохраните и перезагрузите постоянную ссылку какой-либо записи, чтобы убедиться, что всё работает.

Если всё ещё 404, .htaccess может игнорироваться. Проверьте AllowOverride с вашим хостингом, потому что Apache игнорирует корректный файл, когда эта возможность отключена.

Ваши собственные правила против блока WordPress

Плагин или ручное редактирование могут добавить собственные правила, например редиректы, защиту от хотлинкинга или заголовки кеша. Держите их вне блока WordPress и над ним, чтобы они выполнялись раньше его финального правила, которое перехватывает все остальные запросы:

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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, а для этого достаточно загрузить экран постоянных ссылок. Строки до и после маркеров сохраняются. Про редиректы см. правильно оформленные правила редиректов .htaccess WordPress: там рассказано, где они должны находиться и как избежать циклов.

Ошибка 500 Internal Server Error сразу после редактирования файла указывает на то, что вы только что изменили. Документация Apache говорит, что журнал ошибок, вероятно, назовёт недопустимую директиву или синтаксическую ошибку. Такое могут вызвать правила, скопированные из старого руководства: Order — это недопустимая команда в Apache 2.4, если не загружен mod_access_compat. Отмените правку, чтобы вернуть сайт, а затем прочитайте журнал ошибок.

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

Стандартный блок отвечает только за маршрутизацию постоянных ссылок и заголовок Authorization. Чтобы ужесточить доступ к чувствительным файлам, например заблокировать выполнение PHP в /uploads или запретить прямые запросы к wp-config.php, смотрите правила безопасности .htaccess WordPress, которые действительно помогают. Если постоянные ссылки выдают 404 по другой причине, например из-за неправильной структуры, слоя кеша, отдающего устаревшие правила, или конфликта multisite в подкаталоге, остальные причины разбирает руководство неработающие постоянные ссылки WordPress.

Часто задаваемые вопросы

Что такое стандартный файл .htaccess WordPress? Это блок RewriteEngine, который WordPress записывает между # BEGIN WordPress и # END WordPress в файле .htaccess в корне сайта. Он передаёт заголовок Authorization в PHP и отправляет в index.php любой запрос, который не является реальным файлом или папкой.

Каков точный стандартный код .htaccess WordPress? RewriteEngine On, правило, передающее заголовок Authorization в PHP, RewriteBase /, правило-пропуск для index.php, два условия, проверяющие, что запрос не является реальным файлом или папкой, и финальное правило, отправляющее всё остальное в index.php. Полный блок приведён в начале этого руководства.

Почему все мои записи выдают 404, кроме главной страницы? Такую картину даёт отсутствующий или повреждённый файл .htaccess на Apache. Сервер находит главную страницу без правил перезаписи. Любой другой постоянной ссылке эти правила нужны, чтобы дойти до index.php, поэтому без них Apache ищет несуществующий файл и возвращает 404.

Пересоздаёт ли WordPress .htaccess автоматически? Да, на Apache или LiteSpeed с mod_rewrite, если включены красивые постоянные ссылки и WordPress может туда записывать. Достаточно открыть Настройки > Постоянные ссылки. Для отсутствующего файла нужна папка с правом записи, а существующий файл должен быть доступен для записи. Иначе экран покажет ошибку и правила, которые нужно вставить вручную.

Почему у nginx нет файла .htaccess WordPress? У nginx нет файла конфигурации на уровне каталога, как .htaccess у Apache. Та же маршрутизация записывается как правило try_files в конфигурации сервера nginx, которую должен редактировать администратор, потому что WordPress не может её изменить.

Почему мой .htaccess сломался после сохранения постоянных ссылок? Проверьте, не попало ли собственное правило между маркерами # BEGIN WordPress и # END WordPress. WordPress заменяет всё между ними при обновлении файла, поэтому такое правило теряется. Держите собственные правила над маркерами.

Источники

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Исходный код WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Соберите чистый, корректный .htaccess со стандартным блоком постоянных ссылок и теми правилами безопасности или редиректов, которые вам действительно нужны, с помощью бесплатного генератора .htaccess для WordPress.