Cloudflare часто подключают к WordPress за несколько минут. Меняют DNS, включают проксирование и считают работу законченной. На простом сайте это иногда проходит без последствий. На рабочем проекте с формами, личным кабинетом, WooCommerce или нестандартной авторизацией такая настройка легко создаёт проблемы, которые проявятся не сразу.

Я настраиваю Cloudflare не как отдельную панель с переключателями, а как часть инфраструктуры сайта. Сначала смотрю, что именно работает на WordPress, какие страницы динамические, где нельзя отдавать старый HTML и какие запросы должны доходить до origin без агрессивного кеша.

Что я проверяю до изменения настроек

Перед включением правил важно понять текущую схему. Где находится DNS, какой SSL используется на сервере, есть ли редиректы, кеширующий плагин, reverse proxy, WooCommerce, REST API и внешние интеграции.

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

DNS и SSL должны быть предсказуемыми

Первый слой это корректные DNS записи и понятная SSL схема между посетителем, Cloudflare и origin сервером. Я проверяю A и CNAME записи, почтовые записи, поддомены и то, какие хосты действительно должны проходить через proxy.

Для HTTPS важно избежать бесконечных редиректов и смешанной логики, когда часть перенаправлений делает WordPress, часть nginx или Apache, а часть Cloudflare. Чем проще цепочка, тем легче её поддерживать.

Кеширование WordPress требует исключений

Главная ошибка при ускорении WordPress через Cloudflare это попытка кешировать весь HTML одинаково.

Публичные страницы действительно можно отдавать с edge эффективнее. Но админка, страницы входа, персональные данные и многие динамические запросы требуют другой логики. Для WooCommerce отдельно исключаются корзина, checkout, личный кабинет и запросы, связанные с состоянием покупателя.

В отдельном материале я уже разбирал безопасные Cache Rules для WooCommerce. Для обычного WordPress принцип тот же. Сначала определяем динамику, потом строим кеш вокруг неё, а не наоборот.

WAF не должен превращаться в генератор ложных блокировок

Cloudflare WAF полезен против части автоматизированных атак и подозрительных запросов, но максимальная строгость не всегда означает лучшую защиту.

На сайте могут работать webhook endpoints, REST API, платёжные callback запросы и внешние сервисы. Если правило блокирует легитимный трафик, бизнес получает не защиту, а потерянные события.

Поэтому после настройки я проверяю не только открытие главной страницы, но и реальные рабочие сценарии.

Что проверяется после настройки

• Главная и внутренние страницы открываются по HTTPS.
• WordPress админка работает без циклических редиректов.
• Авторизация не кешируется как публичная страница.
• Формы отправляются корректно.
• REST API и webhooks получают ожидаемые ответы.
• Для WooCommerce работают корзина, checkout и кабинет.
• Статические файлы действительно отдаются через CDN.
• WAF не блокирует нормальные интеграции.

Cloudflare и кеширующий плагин должны работать вместе

Если на WordPress уже стоит WP Rocket, LiteSpeed Cache или другой кеширующий слой, Cloudflare нельзя настраивать в отрыве от него. Два независимых кеша с разными правилами могут давать старый HTML, задерживать обновления или усложнять очистку после изменения страницы.

Я определяю, какой слой отвечает за страницу, какой за статику и как должна происходить очистка. Иногда лучше оставить HTML на origin и использовать Cloudflare в основном для CDN, WAF и сетевой защиты. Иногда edge cache действительно оправдан. Это зависит от проекта.

Когда настройка особенно полезна

Услуга подходит, если Cloudflare уже подключён, но настройки делались наугад, сайт периодически показывает старые страницы, возникают ошибки SSL, WAF блокирует API или хочется добавить CDN и защиту без риска для рабочих функций.

Также можно подключить Cloudflare с нуля и сразу собрать понятную конфигурацию, которую не придётся потом разбирать по десяткам случайно включённых правил.

Что я могу сделать

Могу проверить текущую конфигурацию, привести в порядок DNS и SSL, настроить proxy, кеширование, Cache Rules, WAF и исключения для динамических страниц. Если сайт связан с внешними сервисами, отдельно проверю API и webhooks.

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

Чтобы оценить настройку, пришлите адрес сайта и коротко опишите, что сейчас не устраивает. Если Cloudflare уже подключён, достаточно написать, какие проблемы наблюдаются и какие функции сайта критично сохранить. Связаться со мной можно через страницу контактов A.S Groups.