Аудит .htaccess: почему сайт отдаёт 500 и какие правила не работают
Перетащите файл — инструмент найдёт BOM, мёртвые директивы, правила с высоким риском ошибки 500 и признаки стороннего вмешательства. Файл читается в вашем браузере и никуда не отправляется.
Текст вставлен вручную, поэтому байтовый блок проверок пропущен. Чтобы увидеть BOM, CRLF и невидимые символы — перетащите сам файл.
Чистый .htaccess не лечит взлом. Если сайт скомпрометирован, вредоносный код живёт в PHP, а .htaccess — лишь его следствие: дроппер перепишет файл обратно через минуты после того, как вы его почистите. Порядок действий обратный — сперва найти исполняемый код, потом наводить порядок в конфиге.
Здесь появится исходный файл с номерами строк.
Знаком ! отмечены строки с находками: красные — ошибки, янтарные — предупреждения. Невидимые и непечатаемые символы показаны точкой · — в самом файле на их месте пусто.
Очистка убирает BOM, переводит переносы на LF, удаляет непечатаемые символы, заменяет неразрывные пробелы на обычные и дописывает перенос в конце. Директивы не меняются. Файл сохраняется как htaccess-clean.txt — переименуйте его в .htaccess перед загрузкой на сервер.
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<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 записывает сам. Свои правила ставьте выше строки # BEGIN WordPress: всё между маркерами перезаписывается каждый раз, когда вы сохраняете настройки постоянных ссылок.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
Для multisite на поддоменах блок тот же, но без префикса ^([_0-9a-zA-Z-]+/)? в трёх последних правилах: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] и RewriteRule ^(.*\.php)$ $1 [L].
Замена блока сама по себе не восстанавливает пермалинки: после правки зайдите в Настройки → Постоянные ссылки и нажмите «Сохранить» — WordPress проверит блок и при необходимости перепишет его.
Файл читается в вашем браузере — его содержимое никуда не отправляется и нигде не сохраняется.
Почему именно файл, а не вставленный текст
Самая частая причина ошибки 500 после редактирования .htaccess вообще не видна в тексте. Это BOM — три невидимых байта в начале файла, которые добавляет Блокнот Windows при сохранении в UTF-8. Apache считает их частью первой директивы и не может её разобрать. Поэтому инструмент принимает именно файл: только так можно прочитать байты и увидеть BOM, переносы в стиле Windows и невидимые символы внутри строк. Вторая группа проблем — директивы, которые ничего не делают, но выглядят рабочими. mod_gzip_on — это синтаксис Apache 1.3, на современных серверах он молча игнорируется, а люди годами считают, что сжатие включено. Блок ExpiresByType, завёрнутый в проверку mod_headers.c вместо mod_expires.c, тоже не сработает — и без подсказки этого не заметить. Третье — php_value и php_flag. Они работают только когда PHP подключён как модуль Apache. На современных хостингах с PHP-FPM такая строка либо игнорируется, либо сразу даёт 500. И отдельно о безопасности: если в файле найдены правила, которые редиректят посетителей в зависимости от того, с какого поисковика они пришли, или скрывают редирект от администратора — это типичный признак компрометации. Но чистый .htaccess не лечит взлом: почти всегда где-то в файлах живёт PHP-скрипт, который перепишет его обратно.