Есть файл, который правится один раз — и забывается на годы. Потом меняется хостинг, обновляется WordPress, кто-то ставит новый плагин, и сайт внезапно начинает вести себя странно: ссылки уходят в цикл, картинки не грузятся, админка не открывается. Всё это — .htaccess. Маленький файл в корне сайта, который управляет перенаправлениями, доступом и ещё десятком вещей. И именно он чаще всего становится виновником «необъяснимых» поломок.
Разберём файл по блокам — как читать его сверху вниз и что проверять в каждом.
Почему этот файл опасен
У .htaccess есть неприятное свойство: правила в нём срабатывают каскадом. Одна строка может изменить поведение всех остальных, а ошибка в синтаксисе — уронить весь сайт с ошибкой 500. Причём никакого «предупреждения» не будет: просто перестанет открываться.
Вторая особенность — файл может быть не один. Свой .htaccess есть в корне, иногда в подпапках, а часть правил добавляют плагины и сам WordPress. Поэтому прежде чем что-то менять, сохраните копию текущего файла. Это не формальность: без копии восстановить рабочее состояние бывает нечем.
Блок 1. Перенаправления и канонический адрес
Самый верхний и самый важный блок. Здесь решается, какой адрес сайта считается главным: с www или без, по http или https. Правильная настройка объединяет все варианты в один, чтобы поисковик не считал их разными сайтами.
Проверьте, что перенаправление ведёт в одну точку и не зацикливается. Классическая проблема — когда правило с http на https конфликтует с настройкой хостинга, и браузер выдаёт «слишком много перенаправлений». Сайт при этом недоступен полностью.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Обратите внимание на флаг L — он останавливает обработку после срабатывания правила. Без него может выполниться следующее, и адрес изменится дважды. И проверьте, что порядок правил соответствует логике: сначала https, потом www, а не наоборот.
Блок 2. Основа WordPress
Стандартный блок, который WordPress добавляет сам. Он отвечает за красивые ссылки и работу внутренней маршрутизации. Выглядит примерно так:
# BEGIN WordPress
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressТрогать его вручную не нужно. Но проверить стоит две вещи. Первая — что он вообще есть и не повреждён: если строки потерялись, часть страниц начнёт отдавать 404. Вторая — что правила не дублируются: иногда WordPress добавляет блок повторно, и это создаёт лишние циклы обработки.
Если внутри этого блока появились посторонние строки, добавленные вручную, — их лучше вынести выше или ниже. При обновлении настроек WordPress перезапишет блок и всё лишнее пропадёт.
Блок 3. Редиректы старых адресов
Здесь живут правила вида «старая страница → новая». Их добавляют при редизайне, смене структуры или переносе разделов. Проверять нужно три вещи.
Во-первых, каждый редирект должен вести сразу на конечный адрес, без цепочки из двух-трёх переходов. Цепочки замедляют загрузку и теряют вес. Во-вторых, не должно быть редиректов на несуществующие страницы — они превращаются в 404. В-третьих, правила не должны конфликтовать с блоком WordPress: если редирект стоит после него, он может не сработать вовсе.
И следите за кодами. 301 — постоянный редирект, его используют в 99% случаев. 302 — временный, поисковик не переносит на новый адрес вес. Если при переезде случайно поставили 302, страница останется в индексе по старому адресу.
Блок 4. Доступ и безопасность
Сюда обычно попадают правила, закрывающие служебные файлы: wp-config.php, логи, папку с резервными копиями. Полезная штука, но с ней легко перестараться.
Проверьте, что правила не закрывают то, что должно быть доступно. Например, запрет на все файлы с расширением .php в папке загрузок — хорошая идея, а запрет на admin-ajax.php сломает половину форм и корзину. Иногда такие правила добавляют «для безопасности», а потом неделю ищут, почему не работает заявка.
Отдельно — запрет доступа к админке по IP. Если вы его настроили, убедитесь, что ваш собственный адрес не меняется (у мобильных операторов он плавает) и что в списке есть запасной IP на случай блокировки.
Блок 5. Кэш и сжатие
Правила для срока хранения файлов и gzip-сжатия. Сами по себе безобидны, но именно они иногда мешают увидеть результат обновления. Если после правок на сайте вы видите старую версию — сначала проверьте кэш, а не код.
Проверьте, что срок хранения не установлен слишком большим для файлов, которые меняются: CSS, JavaScript, шрифты. Если браузер держит их год, а вы обновили стили, посетители увидят старую версию. Для статики сроки большие — это нормально, для динамики — нет.
Если сайт перестал открываться
Самая частая причина ошибки 500 — синтаксическая ошибка в .htaccess. Порядок действий простой.
- Не паниковать и не менять файл наугад.
- Через файловый менеджер хостинга или FTP переименовать .htaccess в .htaccess.bak.
- Проверить, открылся ли сайт. Если да — дело точно в нём.
- Вернуть файл и искать ошибку построчно: лишние кавычки, незакрытые директивы, неверные флаги.
- Если не получается — восстановить из резервной копии.
Важно: без .htaccess WordPress обычно работает, но красивые ссылки перестанут открываться. Это временное состояние, но оно даёт доступ к админке и возможность спокойно починить файл.
Красные флаги
- В файле есть правила, происхождение которых никто не помнит.
- Редиректы выстроены цепочкой из двух-трёх шагов.
- Сайт открывается по http, и перенаправления на https нет.
- В блоке WordPress появились посторонние строки.
- Запрет доступа закрывает нужные файлы.
- Срок кэширования одинаковый для статики и динамики.
- Файл меняли без копии.
Что в итоге
.htaccess — это не место для экспериментов. Читайте его сверху вниз, блок за блоком: перенаправления, основа WordPress, старые адреса, доступ, кэш. В каждом проверяйте, что правила не конфликтуют и ведут туда, куда должны. И всегда сохраняйте копию до правок — это единственная страховка от ошибки 500.
Мы обычно начинаем проверку этого файла с того, что смотрим, какие правила реально работают, а какие остались от старых экспериментов. Иногда достаточно убрать пару строк, чтобы сайт перестал зацикливаться, а иногда — переписать перенаправления под новую структуру. Напишите или оставьте заявку — посмотрим на ваш .htaccess и скажем, что стоит поправить, чтобы он не подвёл в самый неподходящий момент.