Безопасность структуры папок WordPress: как заблокировать доступ к папке «wp-includes»

Безопасность структуры папок WordPress подразумевает не полную блокировку доступа к папке «wp-includes», а именно запрет на выполнение PHP-файлов из этой директории и отключение просмотра содержимого папки. Папка wp-includes содержит важные JavaScript, CSS и статические файлы, необходимые для работы ядра WordPress; полная блокировка вызовет сбои в дизайне сайта, редакторе или функционале плагинов. Правильный способ — для Apache использовать правила в .htaccess, для Nginx — добавить location-блок в конфигурацию сервера, чтобы запретить прямой запуск PHP, а затем проверить сайт на ошибки с помощью ответов 403/404 и тестов критичных страниц.

Одна из распространённых ошибок в безопасности WordPress — полагаться только на сложные пароли или плагины безопасности. Злоумышленники сканируют каталоги с ядром, устаревшие плагины, неправильные права доступа и открытые списки файлов. Папка wp-includes — частая цель таких сканирований. В этом руководстве вы найдёте практические шаги по ограничению доступа к wp-includes, узнаете, какие правила могут повредить сайту, получите примеры конфигураций для Apache и Nginx, методы тестирования и чек-лист для обслуживания. Для повышения защиты сайта рекомендуем ознакомиться с Хостинг WordPress и базовыми мерами безопасности, например SSL сертификат.

Что такое папка wp-includes и почему её нужно защищать?

Папка wp-includes — одна из основных директорий ядра WordPress с ключевыми библиотеками. В ней располагаются компоненты темы, блоковый редактор, REST API, обработка медиа, классы, функции и множество JavaScript-файлов. Говоря проще, wp-includes — это «моторный отсек» WordPress, который не предназначен для прямого посещения пользователями.

Обычному пользователю не нужно открывать адрес site.com/wp-includes/. Однако в исходном коде страниц часто встречаются ссылки на статические ресурсы из этой папки: стандартные скрипты WordPress, эмодзи-скрипты или элементы редактора. Поэтому при защите важно не блокировать статические файлы, а именно запретить выполнение PHP-файлов через веб.

Это ключевой принцип профессиональной безопасности структуры папок WordPress. Случайная блокировка папок может привести к белому экрану, неработающему административному панелю, сбоям в блоковом редакторе или нарушению дизайна. Задача — сохранить необходимые файлы доступными и одновременно уменьшить поверхность атаки.

Что даёт блокировка доступа к wp-includes?

Запрет на выполнение PHP из папки wp-includes не остановит все атаки, но значительно уменьшит потенциальные точки взлома. Вредоносные скрипты часто пытаются загрузить или вызвать PHP-файлы из доступных директорий. Запрет таких действий для wp-includes создаёт дополнительный барьер.

Преимущества этого подхода:

Ограничение вызова PHP-файлов ядра по прямым URL.
Предотвращение просмотра содержимого папки, если включён листинг директорий.
Снижение утечек информации при автоматических сканированиях.
Защита на уровне веб-сервера даже без плагинов безопасности.
Усиление многоуровневой безопасности вместе с WAF, SSL, обновлённым PHP и правильными правами доступа.

Важно понимать, что это лишь один из уровней защиты. Если у вас устаревшие плагины, слабые пароли или скомпрометирован FTP, одного запрета PHP из wp-includes недостаточно. Полноценная безопасность — это комплекс из хостинга, приложений, управления пользователями и регулярного обслуживания. Для базовой защиты рекомендуем ознакомиться с материалами Безопасный веб-хостинг и защиты домена Безопасность домена.

Типичные ошибки при блокировке wp-includes

Полная блокировка папки

Частая ошибка — полностью запрещать HTTP-запросы к wp-includes с кодом 403. На первый взгляд логично, но WordPress загружает из этой папки некоторые статические файлы, поэтому могут возникнуть проблемы: не откроется блоковый редактор, не загрузятся JS-скрипты, а дизайн сайта может нарушиться даже на фронтенде.

Внедрение правил без тестирования

Ошибка даже в одном символе в .htaccess или конфигурации Nginx может привести к ошибке 500. На сайтах с высокой посещаемостью внедрять без тестов рискованно. Сначала сделайте резервную копию, попробуйте на staging-среде и только потом переводите на живой сайт. Если в Hostragons есть инструменты staging или резервного копирования, можно использовать Резервное копирование веб-хостинга.

Полное доверие плагинам безопасности

Плагины полезны, но правила на уровне веб-сервера блокируют запросы на более раннем этапе. Если Apache или Nginx отклоняет запрос ещё до запуска PHP, уменьшается нагрузка на сервер. Поэтому даже при использовании плагинов важно иметь базовые правила на сервере.

Чек-лист перед применением

Подготовка перед ограничением доступа к wp-includes снижает риск сбоев. Рекомендуем выполнить следующие шаги, особенно для живых сайтов:

Создайте резервную копию текущих .htaccess и конфигураций Nginx.
Обновите ядро WordPress, темы и плагины.
Проверьте, что версия PHP актуальна и поддерживается.
Убедитесь в правильности прав доступа: папки — 755, файлы — 644.
Ограничьте права на запись для критичных файлов wp-config.php и .htaccess.
Если используете кэш, CDN или плагины безопасности, запланируйте очистку кэша после изменений.
Составьте список для тестирования ключевых страниц: админка, главная, посты, контакт, оплату.

Эти меры займут около 10-15 минут, но сэкономят часы поиска ошибок при неверных настройках. Для корпоративных проектов лучше проводить изменения в часы низкой нагрузки.

Блокировка PHP в wp-includes через .htaccess (Apache)

Для сайтов на Apache и shared-хостингах самый распространённый способ — использовать файл .htaccess в корне сайта. Добавьте в него правила, которые запретят вызов PHP из wp-includes. Перед изменениями скачайте копию файла или сделайте резервную копию через панель хостинга.

Отключение листинга директорий

Если на сервере включён просмотр содержимого папок, это может раскрывать структуру сайта. Добавьте в основной .htaccess следующую строку:

Options -Indexes

Это предотвратит отображение списка файлов в папках без index-файла. Большинство современных хостингов по умолчанию отключают листинг, но проверка не повредит.

Тестирование после изменений

После внедрения правил проверьте:

Откройте siteadres.com/wp-includes/ — список файлов не должен отображаться.
Попробуйте напрямую вызвать известный PHP-файл из wp-includes — должен быть ответ 403 или 404.
Проверьте главную страницу, статьи и админку на корректную работу.
В инструментах разработчика браузера смотрите консоль и сетевой трафик на ошибки 403/404.
Если используете кэш или CDN — очистите их.

Если возникают ошибки 500, верните прежний .htaccess из резервной копии.

Блокировка PHP в wp-includes на Nginx

На VPS, выделенных или управляемых серверах с Nginx .htaccess не работает. Правила нужно добавлять в конфигурацию сайта, обычно в блок server. Для этого нужен доступ по SSH и права на редактирование конфигурационных файлов. Если вы не уверены, обратитесь в службу поддержки хостинга.

Особенности при работе с Nginx

Убедитесь, что правило добавлено в правильный server-блок, если на сервере несколько сайтов.
Если используете CDN или обратный прокси, очищайте кеш перед тестами.
Проверьте, что PHP-FPM обрабатывает только нужные файлы.
Анализируйте логи access.log и error.log для быстрого выявления проблем.

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

Сравнение методов защиты

В таблице приведены основные способы ограничения доступа к wp-includes:

Сравнение методов защиты
Метод	Подходящая среда	Преимущества	Важные моменты
.htaccess	Apache и LiteSpeed	Простота внедрения, доступно на большинстве shared-хостингов	Ошибки в синтаксисе вызывают 500 ошибку
location в Nginx	VPS, выделенные серверы, управляемые хостинги	Высокая производительность, блокировка на уровне сервера	Требуется доступ к настройкам и знания Linux
Плагины безопасности	Пользователи без технических навыков	Удобный интерфейс, автоматизация	Не всегда работают на уровне сервера
WAF и CDN	Сайты с высоким трафиком и атаками	Фильтрация вредоносных запросов на раннем этапе	Неправильные правила могут блокировать легитимных пользователей
Права доступа	Все сайты WordPress	Основной уровень безопасности	Не блокирует доступ по URL напрямую

Лучший результат достигается в комплексе: правильные права, обновления, SSL, резервные копии, серверные правила и дополнительные инструменты. Для корпоративных проектов имеет смысл выбирать Корпоративный Хостинг с расширенной защитой и изоляцией.

Права доступа и владельцы файлов

Ограничение доступа к wp-includes не будет эффективным при неправильных правах. Рекомендуемые значения для WordPress — 755 для папок и 644 для файлов. Эти настройки позволяют серверу читать файлы без избыточных прав на запись. В некоторых хостингах могут быть свои особенности, учитывайте рекомендации панели управления.

Особенно опасно разрешать права 777 — это открывает двери для загрузки вредоносных скриптов. Даже для папок, где разрешена запись (например, wp-content/uploads), рекомендуется блокировать выполнение PHP. Папка wp-includes в норме не должна быть доступна для записи пользователем.

Для проверки можно контролировать:

Папка wp-includes — 755
PHP-файлы внутри wp-includes — 644
wp-config.php — желательно 600 или максимально ограниченные права
.htaccess — 644 без лишних прав на запись

Эти настройки могут различаться в зависимости от сервера. Неправильные права могут привести к невозможности обновления сайта или чтения файлов. После изменений рекомендуется проверить состояние сайта и логи ошибок.

Выполняют ли плагины безопасности эту задачу?

Плагины типа Wordfence или iThemes Security могут автоматически рекомендовать жесткие правила. Они обеспечивают защиту от brute force, мониторинг изменений файлов, сканирование на вредоносное ПО и безопасность логина. Но конкретно по блокировке доступа к wp-includes их действия могут отличаться.

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

При использовании плагинов проверьте:

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

Одновременное использование нескольких плагинов безопасности может привести к конфликтам и снижению скорости сайта из-за перекрывающихся правил.

Как проверить защиту wp-includes: практический тест

Для уверенности, что защита работает правильно, одного запуска сайта недостаточно. Вот 7 шагов практического теста, подходящего как для малых бизнес-сайтов, так и для крупных e-commerce проектов:

1. Откройте главную страницу в режиме инкогнито и проверьте, нет ли визуальных сбоев.
2. Посетите страницу блога, категории и результаты поиска.
3. Зайдите в админ-панель, проверьте работу блокового редактора и медиабиблиотеки.
4. В инструментах разработчика проверьте вкладку Console на наличие ошибок.
5. Во вкладке Network убедитесь, что статические файлы из wp-includes не блокируются.
6. Попробуйте напрямую обратиться к PHP-файлу в wp-includes — ожидайте ошибку 403 или 404.
7. Проверьте логи сервера на наличие новых или повторяющихся ошибок.

Тест занимает около 5 минут и быстро выявляет ошибки конфигурации. Для сайтов с WooCommerce дополнительно проверьте корзину, оплату и личный кабинет. Даже небольшие сбои JavaScript могут снизить конверсию.

Дополнительные меры безопасности структуры WordPress

Защита wp-includes — хороший старт, но безопасность WordPress нужно рассматривать комплексно. Дополнительные рекомендации:

Не пытайтесь скрыть версию WordPress — лучше своевременно обновляйте ядро.
Удаляйте неиспользуемые темы и плагины полностью.
Используйте сложные и нестандартные имена админ-пользователей.
Включите двухфакторную аутентификацию.
Если не используете XML-RPC — ограничьте к нему доступ.
Для wp-login.php настройте ограничение по количеству попыток или дополнительную авторизацию.
Внедрите ежедневное автоматическое резервное копирование и проверку восстановления.
Используйте HTTPS на всём сайте — без SSL данные пользователей под угрозой.

SSL не блокирует доступ к wp-includes, но защищает сессии, формы и админ-панель. Поэтому SSL — базовый уровень безопасности в любых руководствах по WordPress. В статье можно органично вставить ссылки на Купить SSL сертификат и Установка бесплатного SSL.

Когда стоит обратиться к профессионалам?

Добавить правило в .htaccess на простом Apache-хостинге может большинство пользователей. Но для сложных конфигураций с Nginx, мультисайтов, WooCommerce, высоконагруженных новостных или корпоративных порталов лучше привлечь экспертов. Безопасность должна быть не только технически корректной, но и обеспечивать стабильность работы сайта.

Рекомендуется обратиться к специалистам, если:

На сервере размещено несколько сайтов WordPress.
Используются Nginx, Varnish, CDN и WAF в комплексе.
После изменений увеличилось количество ошибок 403, 404 или 500.
Ранее сайт подвергался заражению вредоносным ПО.
На сайте есть платёжные системы, личные кабинеты или обработка персональных данных.

Надёжный хостинг, изоляция ресурсов, регулярные бэкапы и профессиональная поддержка — невидимые, но ключевые элементы безопасности. При выборе инфраструктуры обращайте внимание не только на дисковое пространство, но и на качество резервного копирования, файрвола, поддержку PHP и SSL, а также уровень технической поддержки. В этом контексте полезны материалы Пакеты хостинга Hostragons и Перенос сайта на WordPress.

Вывод

В рамках безопасности структуры папок WordPress правильный способ ограничить доступ к wp-includes — не блокировать всю папку целиком, а запретить выполнение PHP-файлов и отключить просмотр содержимого. Для Apache достаточно добавить правило в .htaccess, для Nginx — в конфигурацию location. Перед внесением изменений обязательно создавайте резервные копии и тщательно тестируйте работу сайта в панели и на фронтенде.

Кратко: не блокируйте статические файлы, ограничьте доступ к PHP, отключите листинг директорий, проверьте права доступа и регулярно обновляйте систему. Для более надёжной и удобной работы изучите предложения Hostragons по хостингу, доменам и SSL, а также получите помощь в настройке.

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

Безопасно ли полностью блокировать папку wp-includes?

Обычно не рекомендуется. В папке wp-includes находятся необходимые для WordPress JavaScript, CSS и другие статические файлы. Полная блокировка нарушит отображение сайта и работу админки. Безопаснее запретить доступ только к PHP-файлам.

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

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

Работает ли .htaccess на Nginx?

Нет. .htaccess используется только на серверах Apache и LiteSpeed. На Nginx нужно настраивать ограничения через location-блоки в конфигурации сервера и проверять изменения командой nginx -t.

Обеспечит ли эта мера полную безопасность сайта?

Нет. Запрет PHP в wp-includes — важный уровень защиты, но недостаточный сам по себе. Нужно также обновлять WordPress, использовать сильные пароли, двухфакторную аутентификацию, SSL, создавать резервные копии, настраивать файрвол и правильно выставлять права доступа.

Если я использую плагин безопасности, нужно ли дополнительно блокировать wp-includes?

Зависит от функционала плагина. Некоторые добавляют правила в .htaccess, другие работают только на уровне приложения. Для надежной защиты лучше комбинировать плагин с серверными настройками, чтобы не оставлять дыр.