Сайт не дает загрузить тему, файл слишком большой. Поисковики индексируют служебные страницы, которых в выдаче быть не должно. В логах сервера, попытки доступа к wp-config.php с чужих IP. Три проблемы, а решение одно: файл .htaccess, который уже лежит в корне вашего WordPress-сайта.

Вы наверняка видели его, когда настраивали ЧПУ-ссылки. Но возможности .htaccess этим не ограничиваются: он управляет доступом, безопасностью, редиректами и лимитами загрузки на уровне сервера. И в отличие от плагинов безопасности, не добавляет нагрузки на PHP.

Ниже, четыре практических сценария, с которыми сталкивается каждый администратор WordPress. Каждый снабжен готовым кодом, пояснением и указанием, куда именно его вставлять. Код переписан под Apache 2.4 (актуальная версия на 2026 год), но каждый сниппет включает блок совместимости с Apache 2.2, чтобы вы не гадали, заработает ли на вашем хостинге.

💡 Быстрый обзор:

• Увеличьте лимит загрузки файлов через .htaccess и .user.ini для PHP-FPM.
• Закройте сайт от индексации поисковиками на уровне сервера.
• Отключите просмотр директорий одной строкой.
• Защитите wp-config.php от прямого доступа современным синтаксисом Apache 2.4.

1. Увеличиваем максимальный размер загружаемых файлов

Пытаетесь установить тему или плагин, а WordPress выдает ошибку: «The uploaded file exceeds the upload_max_filesize directive in php.ini». Лимит по умолчанию у многих хостеров, 2 МБ или 8 МБ, и архив темы в него не влезает.

Редактировать php.ini на shared-хостинге нельзя. Но если Apache работает с модулем mod_php, лимит поднимается прямо из .htaccess. Откройте файл в корне сайта (через FTP или файловый менеджер хостинга) и добавьте в конец:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Первая директива задает максимальный объем POST-запроса, вторая, максимальный размер одного загружаемого файла. Оба значения должны совпадать, или post_max_size должен быть чуть больше.

Проверьте результат: зайдите в админку WordPress, Медиафайлы → Добавить новый. Снизу отобразится актуальный лимит.

Важно: если хостинг переведен на PHP-FPM (а таких большинство в 2026 году), директивы php_value в .htaccess не сработают. Проверьте: Инструменты → Здоровье сайта → Информация → Сервер. В строке «Server architecture» ищите упоминание FPM. Для такого хостинга лимит меняется через файл .user.ini в корне сайта:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Формат, как у php.ini, со знаками равенства вместо php_value. Изменения применяются мгновенно, перезагрузка сервера не нужна. Если файла .user.ini в корне нет, создайте его.

2. Закрываем сайт от индексации поисковиками

Ситуация: тестовый сайт на поддомене, staging-копия или лендинг, который не должен попасть в выдачу Google и Яндекса. Простой robots.txt с Disallow: / поисковики могут проигнорировать: это рекомендация, а не запрет.

Железный способ, заблокировать роботов на уровне сервера. Классический подход через SetEnvIfNoCase работает в Apache 2.4 через модуль совместимости mod_access_compat, но он считается устаревшим. Современный метод, перенаправить ботов с пустым User-Agent через mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Что здесь происходит: RewriteCond проверяет User-Agent каждого запроса. При обнаружении ключевых слов bot, spider, crawler или scanner (регистр не важен, флаг [NC]) сервер возвращает 403 Forbidden (флаг [F]).

Четырех шаблонов достаточно, чтобы перекрыть все основные поисковые системы: Googlebot, YandexBot, Bingbot, Yahoo Slurp и десятки менее известных. Перечислять каждого бота по отдельности бессмысленно: только у Google несколько десятков вариантов User-Agent под разные сервисы (поиск, картинки, видео, AdsBot).

Хотите закрыть сайт только от Яндекса, а Google оставить? Сузьте шаблон:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Символ ^ означает «начало строки». Без него правило зацепит и тех ботов, у которых yandex встретится в середине User-Agent.

Важно: если WordPress уже использует mod_rewrite для ЧПУ-ссылок, блок RewriteEngine On уже есть в .htaccess. Дублировать его не нужно, просто добавьте новые RewriteCond и RewriteRule после существующих правил WordPress, но до закрывающего тега </IfModule>.

После изменений проверьте .htaccess на ошибки: опечатка в директивах, и сайт ляжет с ошибкой 500. Синтаксис можно проверить онлайн-валидатором или командой apachectl configtest (доступна не у всех хостеров). Перед правкой обязательно скачайте резервную копию текущего .htaccess.

3. Отключаем просмотр директорий

Зайдите на свой сайт по адресу /wp-content/uploads/. Если вместо 403-й ошибки вы видите список файлов, у вас включен просмотр директорий. Это дыра: любой может изучить структуру папок, найти уязвимый плагин или прочитать загруженный PDF-документ.

Отключается одной строкой в .htaccess:

1
Options -Indexes

Добавьте ее в начало файла, до правил WordPress. Теперь при попытке открыть директорию без индексного файла сервер отдаст 403 Forbidden.

На большинстве современных хостингов эта опция включена по умолчанию, но проверьте, особенно если сайт переезжал между серверами или вы работаете с VPS, где Apache настраивали вручную.

4. Защищаем wp-config.php от прямого доступа

wp-config.php, самый важный файл WordPress. В нем лежат ключи безопасности, префикс таблиц и доступ к базе данных: имя БД, пользователь, пароль, хост.

Сам файл написан на PHP и при прямом открытии в браузере отдает пустую страницу, движок WordPress его не выполняет. Но если на сервере временно отключится обработка PHP (сбой конфигурации, обновление модуля), содержимое wp-config.php может отдаться как обычный текст. Вместе с паролем базы данных.

Закрываем доступ через .htaccess. Большинство статей в интернете предлагают устаревший синтаксис Apache 2.2, который не работает в Apache 2.4.6 и выше. Вот современный вариант с обратной совместимостью:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

Блок IfModule проверяет наличие модуля mod_authz_core (появился в Apache 2.4.6). Если модуля нет, применяется синтаксис 2.2. Если есть, современная директива Require all denied. Один код работает на обеих версиях Apache.

После добавления правил любое обращение к wp-config.php через браузер получит 403 Forbidden, даже если PHP-обработчик не работает. WordPress обращается к файлу напрямую через файловую систему, так что на работу сайта правило не влияет.

Тот же подход применим к любому конфиденциальному файлу: замените wp-config.php на имя нужного, например, phpinfo.php или .env.

⁉️🤔 Частые вопросы

Можно ли вообще обойтись без.htaccess** в WordPress?**

Да, если сайт работает на Nginx, а не на Apache. Nginx не поддерживает .htaccess, все правила задаются в конфигурации сервера (nginx.conf или файл в sites-available/). На shared-хостингах почти всегда Apache, и .htaccess доступен. На VPS с Nginx правила переносятся в секцию server {}: синтаксис другой, но логика та же. Например, аналог Options -Indexes в Nginx, autoindex off;.

Что делать, если после изменения.htaccess сайт упал с ошибкой 500?

Немедленно верните резервную копию .htaccess, которую вы сделали до правок (вы ведь ее сделали?). Подключитесь по FTP, удалите измененный .htaccess и загрузите сохраненный оригинал. Сайт оживет мгновенно. Ошибка 500 после правки .htaccess почти всегда вызвана опечаткой в директиве или конструкцией, которую не поддерживает ваша версия Apache.

Почему php_value в.htaccess не работает на моем хостинге?

Скорее всего, хостинг использует PHP-FPM вместо mod_php. Проверьте: Инструменты → Здоровье сайта → Информация → Сервер. Если в строке «Server architecture» указано FPM, php_value в .htaccess игнорируется. Используйте файл .user.ini в корне сайта (см. раздел 1) или обратитесь в поддержку хостинга. На VPS лимиты меняются в пуле PHP-FPM (www.conf), но это требует доступа к конфигурации сервера.

Как проверить, что.htaccess действительно работает?

Самый простой тест, правило из раздела 3 (Options -Indexes). Зайдите на /wp-content/uploads/ до и после добавления. Был список файлов, стала 403-я ошибка? Файл работает. Другой способ: добавьте в .htaccess строчку с заведомой синтаксической ошибкой и откройте сайт. Ошибка 500 подтвердит, что Apache читает .htaccess. Сразу после проверки удалите тестовую строку.

Безопасно ли использовать код из статьи на живом сайте?

Да, все приведенные сниппеты протестированы на Apache 2.4 (актуальная версия на 2026 год) и включают блоки совместимости с Apache 2.2. Единственное обязательное условие: перед любой правкой .htaccess скачайте текущую версию файла на компьютер. Пятисекундная операция экономит часы восстановления в случае опечатки. И не редактируйте .htaccess через плагины, только FTP или файловый менеджер хостинга: плагин может добавить экранирование, которое сломает синтаксис.

Чем подход к защите wp-config.php в статье отличается от того, что пишут на других сайтах?

Большинство статей копируют синтаксис Apache 2.2: Order allow,deny и Deny from all. Эти директивы принадлежат модулю mod_access_compat, который объявлен устаревшим в Apache 2.4 и может быть отключен на современных серверах. Наш сниппет использует Require all denied из модуля mod_authz_core, это актуальный стандарт для Apache 2.4.6 и выше. При этом блок <IfModule> сохраняет работоспособность на старых серверах.

Что ставить в конфигурацию.htaccess прямо сейчас

Файл .htaccess, компактный, но мощный инструмент. Из четырех описанных приемов два закрывают уязвимости с минимальными усилиями: отключение просмотра директорий и защита wp-config.php. Это одна строка и один блок кода, которые можно добавить прямо сейчас, на работу сайта они не влияют.

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

Держите резервную копию .htaccess перед каждой правкой. Ошибка в синтаксисе ложит сайт мгновенно, и так же мгновенно исправляется, если копия под рукой. С этим правилом .htaccess превращается из страшного файла в рабочий инструмент.