Alexsandro Assis
← Build Journal
WordPress Performance 8 min

Cloudflare checklist for high-traffic WordPress sites

A practical Cloudflare checklist to protect, accelerate, and operate WordPress portals with more predictability under high traffic.

Fire TV Stick HD
Indicado Fire TV Stick HD
Echo Show 5 | Smart display com Alexa
Indicado Echo Show 5 | Smart display com Alexa
Kindle E-reader de 11ª Geração
Indicado Kindle E-reader de 11ª Geração

High-traffic WordPress cannot depend only on a cache plugin.

A plugin helps, but it lives inside the application. When traffic rises, the best defense is making fewer requests reach PHP, the database, and the origin server. That is where Cloudflare stops being only “DNS with CDN” and becomes an important operational layer.

This checklist is what I would use as a starting point for a WordPress portal that needs predictable uptime: well-defined cache, protected origin, less exposed wp-admin, and rules simple enough to maintain.

The right mindset

Before configuring any button, you need to separate three things:

  1. What can be cached at the edge.
  2. What needs to reach WordPress.
  3. What should be blocked before reaching the server.

That separation changes the game.

Public news pages, articles, categories, and tags can usually receive aggressive cache, as long as there is a purge strategy. Logged-in areas, carts, checkout, previews, administrative comments, and wp-admin need bypass. Malicious traffic, scans, and repeated login attempts should be filtered before they consume origin resources.

The goal is not to hide a fragile WordPress behind Cloudflare. The goal is to reduce surface area, load, and variability.

DNS, SSL, and origin

The basics need to be correct before cache.

Initial checklist:

  • use active proxy on public site records;
  • keep SSL in an appropriate mode, preferably end to end;
  • guarantee a valid certificate on the origin too;
  • remove unnecessary exposure of the server’s real IP;
  • review old DNS records;
  • separate administrative subdomains when it makes sense;
  • keep redirects centralized and predictable.

A common mistake is placing Cloudflare in front, but leaving the server accepting direct traffic through its IP. In that scenario, part of the protection can be bypassed. Whenever possible, the origin should accept requests only from the expected layer or trusted networks.

It is also worth reviewing headers, compression, HTTP/2 or HTTP/3, and redirect rules. Performance is not born only in cache. It starts on the path between user, edge, and origin.

Cache without breaking login

Cache in WordPress requires care because not every page is the same.

For public content, the edge can relieve the server a lot. For personalized content, bad cache can leak state, show an admin bar incorrectly, or deliver an outdated page to someone who should not see it.

A conservative design:

  • cache public posts, pages, categories, and tags;
  • ignore unnecessary query strings when it is safe to do so;
  • bypass wp-admin, wp-login.php, previews, and sensitive endpoints;
  • bypass when logged-in user cookies are present;
  • define edge TTL according to editorial frequency;
  • keep URL or group purge whenever a post is updated;
  • test behavior in an anonymous window and as a logged-in user.

The most important point: good cache needs to be predictable.

If the editorial team publishes many updates throughout the day, the cache plan needs to match that routine. Aggressive cache is useless if the operation needs to purge everything manually after every change.

WAF, bots, and wp-admin

WordPress is a constant target because it is popular. That does not make it unviable. It means the surface needs to be treated seriously.

I would start with rules to:

  • challenge or block abusive attempts against wp-login.php;
  • protect /wp-admin/ by country, IP, Access, or specific rules when possible;
  • block HTTP methods the site does not use;
  • create rate limiting for sensitive endpoints;
  • monitor XML-RPC and disable it when unnecessary;
  • block obvious exploitation patterns;
  • review bots that consume too many resources without bringing value.

Here is a pragmatic note: too many rules also become risk.

A configuration that is hard to understand tends to be abandoned. It is better to start with a few clear rules, measure impact, and evolve based on logs. Good security reduces risk without making every publication feel like it might break the site.

Operations and monitoring

Cloudflare is not a one-time setup. It is part of the operation.

After the initial configuration, I would monitor:

  • cache hit rate;
  • most accessed pages;
  • traffic blocked by the WAF;
  • origin receiving unexpected spikes;
  • 5xx errors;
  • origin response time;
  • frequently triggered rules;
  • URLs that should be cached, but are not.

I would also keep a small runbook:

  1. How to enable development mode.
  2. How to purge a URL.
  3. How to purge a group of pages.
  4. How to disable a problematic rule.
  5. How to identify whether an error comes from the origin or the edge.

In high traffic, improvisation is expensive. The team needs to know what to do before the crisis.

The best use of Cloudflare in WordPress is not stacking features. It is designing an intelligent edge: cache what is public, protect what is sensitive, and let the origin work only when it really needs to.

Sources consulted