Key Takeaways
- WordPress page rules work best when they match specific paths, not the whole site.
wp-login.php,wp-admin, XML-RPC, REST API routes, WooCommerce checkout, and static assets all need different cache, security, and rate-limiting behavior.- Login, admin, checkout, account, and cart pages should usually bypass cache.
- Static files like images, CSS, JavaScript, theme assets, and uploads are usually good candidates for CDN caching.
- Misconfigured page rules can break login, expose cart data, cause stale content, or create confusing WooCommerce checkout issues.
- WordPress-specific edge rules are useful when you want security and performance controls before traffic reaches WordPress.
What Are WordPress Page Rules?
WordPress page rules are path-based instructions that tell an edge service, CDN, WAF, or reverse proxy how to handle different parts of your site before the request reaches WordPress.
A rule might match a path like /wp-login.php, /wp-admin/*, /wp-json/*, /checkout/, or /wp-content/uploads/*. Once the path matches, the rule can decide whether to cache, bypass cache, apply rate limiting, block suspicious traffic, challenge bots, add security checks, or route the request normally.
This matters because WordPress is not one single type of page. A public blog post, a WooCommerce checkout page, a login form, an admin dashboard, a REST API request, and an uploaded image all behave differently. Treating them all the same is where cache problems and security gaps usually start.
Why WordPress Needs Path-Specific Rules
A simple “cache everything” rule might sound attractive, but WordPress mixes static content, dynamic content, logged-in content, forms, admin actions, API requests, and e-commerce workflows. One broad rule can easily create problems.
The important part is that rules should match how WordPress actually behaves. Admin, login, checkout, cart, API, and static asset paths should not all receive the same cache, security, or rate-limiting treatment.
Common WordPress paths that need special handling include:
/wp-login.php/wp-admin/*/xmlrpc.php/wp-json/*/cart//checkout//my-account//wp-content/uploads/*/wp-content/themes/*/wp-content/plugins/*
A good WordPress page rule strategy starts with the riskiest and most sensitive paths, then moves outward to performance-focused caching rules for static content.
Rules for wp-login.php
The WordPress login page is one of the most commonly targeted paths on any WordPress site. It is often hit by brute force attacks, credential stuffing, malicious bots, and automated scanners looking for weak passwords.
Your wp-login.php rule should almost always bypass cache. Login forms are dynamic, session-aware, and security-sensitive. Caching this path can create broken login behavior or unexpected form issues.
A practical rule strategy for wp-login.php is:
- Bypass cache
- Apply stricter WAF protection
- Use rate limiting for repeated POST requests
- Challenge or block suspicious bot traffic
- Consider geo filtering if admins only log in from known regions
- Keep two-factor authentication enabled inside WordPress
A practical starting point is 10 to 20 POST requests per minute per IP, then challenge or block repeat offenders. Tune the threshold after reviewing normal admin behavior, checkout activity, and false positives.
Rules for wp-admin
The WordPress admin area is dynamic and personalized. It should not be cached by a CDN or edge cache. Admin pages depend on user sessions, permissions, nonces, scripts, AJAX behavior, and plugin-specific dashboard screens.
A typical rule for /wp-admin/* should:
- Bypass cache
- Disable HTML caching
- Avoid JavaScript rewriting features that may break admin screens
- Apply stricter WAF protection
- Allow IP restrictions or geo filtering where appropriate
- Monitor unusual request patterns
Be careful with admin-ajax.php. It lives under the admin path, but many themes and plugins use it for front-end behavior. It should not be cached, but blocking it too aggressively can break public-facing features like forms, filters, carts, or dynamic widgets.
Rules for XML-RPC
XML-RPC is a legacy WordPress endpoint located at /xmlrpc.php. Some older tools, mobile apps, Jetpack features, and integrations may still use it. Many modern sites do not need it at all.
Because XML-RPC can be abused for brute force amplification and automated requests, it is a strong candidate for stricter rules.
Your XML-RPC rule may do one of the following:
- Block it entirely if your site does not use it
- Rate limit it heavily if some integrations depend on it
- Allow only known services or IP ranges where possible
- Bypass cache because API-style responses should not be cached
- Monitor logs for repeated or suspicious requests
Before blocking XML-RPC, test anything that might depend on it. That includes Jetpack, older mobile publishing workflows, remote posting tools, and legacy plugins.
Rules for REST API Routes
The WordPress REST API usually lives under /wp-json/. It supports the block editor, plugins, headless front ends, forms, WooCommerce, mobile apps, and custom integrations.
REST API traffic should be handled carefully. Some endpoints are public and read-only. Others expose user-specific, cart-specific, order-specific, or plugin-specific behavior.
A conservative starting rule for /wp-json/* is:
- Bypass cache by default
- Rate limit suspicious bursts
- Monitor unauthenticated requests
- Review plugin-created endpoints
- Cache only known public read-only endpoints if a developer confirms it is safe
Do not blindly disable the REST API. Many modern WordPress sites need it. The better approach is to understand which routes are public, which are sensitive, and which deserve rate limiting or additional WAF protection.
Rules for WooCommerce Cart, Checkout, and Account Pages
WooCommerce pages need extra care because they are tied to carts, sessions, payment flows, customer accounts, shipping calculations, coupons, taxes, and order state.
These paths should usually bypass cache:
/cart//checkout//my-account//order-pay//order-received/- Custom cart, checkout, account, or payment slugs
Caching the wrong WooCommerce path can show stale cart contents, incorrect prices, wrong shipping totals, or private customer information. That is why checkout-related paths should be treated differently from public product pages or static assets.
For WooCommerce, page rules should usually focus on:
- Bypassing cache for cart, checkout, and account paths
- Applying rate limiting to repeated checkout POST requests
- Monitoring bot traffic and suspicious payment attempts
- Keeping static product images cacheable
- Avoiding aggressive JavaScript rewriting on checkout
WooCommerce performance and security rules should always be tested in staging before production. A rule that looks safe on a blog can behave differently on an active store.
Rules for Static Assets and CDN Caching
Static assets are where CDN caching usually helps the most. Images, CSS, JavaScript, fonts, theme files, plugin assets, and uploaded media can often be cached longer than dynamic HTML.
Good candidates for CDN caching include:
/wp-content/uploads/*/wp-content/themes/*/wp-content/plugins/*- Versioned CSS and JavaScript files
- Images with stable filenames
- Fonts and static media files
A common approach is to cache static files at the edge for several days or weeks, while using shorter browser cache TTLs if assets change often. If your build process uses versioned filenames, you can usually cache static assets more aggressively.
Be more careful with HTML. Public pages can sometimes be cached safely, but only after login, admin, cart, checkout, account, REST API, and other dynamic paths are excluded.
Common Mistakes When Applying WordPress Page Rules
Most WordPress page rule problems come from rules that are too broad, too aggressive, or poorly ordered.
Common mistakes include:
- Using a site-wide cache rule without excluding login, admin, cart, checkout, and account pages
- Caching
wp-login.phporwp-admin - Applying “cache everything” to WooCommerce checkout
- Forgetting that rule priority and order matter
- Missing trailing wildcards on important paths
- Using long browser cache TTLs on HTML that changes frequently
- Letting a WordPress cache plugin and CDN cache fight each other
- Blocking XML-RPC without checking whether integrations depend on it
- Rate limiting the whole site instead of sensitive paths
- Not testing logged-in users, checkout, forms, previews, and admin workflows after changes
The safest approach is to start with explicit bypass rules for sensitive paths, then add broader performance rules only after the exclusions are working.
Example Rule Strategy for a Typical WordPress Site
For a small or medium WordPress site, start specific and then go broad.
A practical rule order might look like this:
- Bypass cache for
/wp-login.php - Bypass cache for
/wp-admin/* - Block or heavily rate limit
/xmlrpc.phpif not needed - Bypass cache for
/wp-json/*, then selectively cache safe public endpoints later - Bypass cache for WooCommerce cart, checkout, account, and payment paths
- Cache static assets under
/wp-content/uploads/*,/wp-content/themes/*, and/wp-content/plugins/* - Apply rate limiting to login, XML-RPC, REST API, and checkout POST requests where appropriate
- Add geo filtering only to sensitive paths if it matches how the site is operated
- Consider public HTML caching only after all dynamic exclusions are tested
Document each rule. Future developers, agencies, or site owners should be able to understand why a rule exists, what path it protects, and what could break if it changes.
Where Atomic Edge Fits in Your WordPress Page Rules Strategy
Atomic Edge provides WordPress-aware edge controls for page rules, rate limiting, cache behavior, and security. Unlike Cloudflare, which commonly uses full nameserver delegation, Atomic Edge can sit in front of a site with a DNS record change such as an A or AAAA record.
For WordPress sites, that means you can treat wp-login.php, wp-admin, XML-RPC, REST API routes, WooCommerce checkout, and static assets differently. Atomic Edge combines edge WAF protection, CDN caching, rate limiting, geo filtering, OWASP Core Rule Set checks, custom WAF rules, traffic visibility, and CDN controls in one dashboard.
Use it when you want WordPress-specific page rules without building everything from scratch in a general-purpose edge platform. It is not a replacement for good WordPress maintenance, updates, or testing. It is a way to make page rules, cache behavior, and security controls more WordPress-aware before traffic reaches the application.
Practical Checklist for Configuring WordPress Page Rules
- Confirm the real login, admin, WooCommerce, API, and custom URLs used by the site.
- Bypass cache for
wp-login.php,wp-admin/*, and alternate login paths. - Decide whether XML-RPC should be blocked, limited, or left available for known integrations.
- Review REST API usage before caching or blocking
/wp-json/*. - Bypass cache for cart, checkout, account, and payment paths.
- Cache uploads, theme assets, plugin assets, images, fonts, CSS, and JavaScript with sensible TTLs.
- Use rate limiting on sensitive paths rather than applying blunt global limits.
- Test login, checkout, previews, forms, search, and account pages after every major rule change.
- Review WAF logs, cache headers, and CDN behavior after deployment.
- Document each rule and revisit it after major plugin, theme, or hosting changes.
Want WordPress-specific page rules without full nameserver delegation? Atomic Edge lets you apply edge rules, CDN caching, rate limits, geo filtering, and WAF protection to the paths that matter most: login, admin, XML-RPC, REST API, WooCommerce checkout, and static assets.
