Edge Routing · WP Engine · WordPress plugin

Let the WordPress plugin reach AI agents on WP Engine

Plugin installed and connected, but the Run checks say a page cache answers first? WP Engine serves agents a cached copy before WordPress runs. One Web Rule fixes it: no support ticket, and an instant undo. Plugin 0.1.3 or later.

Why WP Engine needs this

WP Engine runs its own page cache in front of WordPress. An AI agent asking for a page is usually answered straight from a stored copy, before WordPress, and therefore the NORG Edge Router plugin, ever runs. The agent gets the ordinary human page and the plugin never sees the request.

A WP Engine Web Rule with the Internal rewrite action runs before that cache lookup. It quietly rewrites an agent's request for / to /?norg_edge=1, a separate address the plugin answers and marks Cache-Control: private, no-store, so WP Engine does not cache it. Human visitors are untouched: they never match the rule and keep getting the fast cached page.

1

Add the rewrite rule (one Web Rule)

In the WP Engine User Portal, open the environment, then Web Rules → Rewrite Rules → Add rule, and enter it exactly as below. The Source ^(/[^?]*) matches every path; the Destination ${1}?norg_edge=1 re-requests that same path with the plugin's marker, keeping the original query string.

User Portal -> the environment -> Web Rules -> Rewrite Rules -> Add rule

Action:        Internal rewrite
Domain:        All domains
Source:        ^(/[^?]*)
Destination:   ${1}?norg_edge=1
Query string:  Keep (keep the original query string)
Comment:       NORG AI agent cache bypass   (optional)

Condition 1  Type: Header        Name: User-Agent
             Operator: Regex matches (~)
             Value: (GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User)

Condition 2  Type: Query string  (this type has no Name field)
             Operator: Negative regex matches (!~)
             Value: norg_edge=

Condition 2 is a Negative regex match (!~) on norg_edge=. The Query string type has no Name field: it matches the whole query string, which stops the rule rewriting its own output into a loop.

The user-agent expression in Condition 1 is the set of agents NORG diverts today. The authoritative list for a given site is the read-only box AI user agents to exclude from any cache in front of WordPress on the plugin's status page; when an operator is enabled or disabled in NORG, the rule is updated to match.

No support ticket, no cache exclusion. The Web Rule is all it takes. Allow up to ~15 minutes for the rule to apply across the environment.

Two things to get right

  • Use Internal rewrite, never a Permanent or Temporary redirect. A redirect sends the agent away to a visible ?norg_edge=1 URL instead of serving the mirror in place.
  • Do not add Googlebot or Bingbot to the user-agent list. The rule is for AI agents only; search-engine crawlers must keep getting the normal pages.
2

Check it worked

In WP Admin → NORG Edge Router, click Run checks. When the rule is live the row AI agents reach plugin reports reached: the plugin is now answering agent requests.

Run checks outcomes
OutcomeMeaning
reachedA simulated GPTBot request from the server itself came back through PHP. The rule is working.
cache_interferenceThe request was answered by the page cache and never reached the plugin. The rule is missing, mistyped, its user-agent expression does not include the agent tested, or a cached copy is still being served (wait 10 minutes and run again).
unverifiableThe loopback request could not connect to the site’s own hostname. Common on staging hostnames behind a password; check the rule from outside with curl instead.

A stale cached copy can still make the check report cache_interference for up to 10 minutes after the rule is added. If so, wait and run the checks again before concluding anything is wrong.

From outside, the no-store header on a marked request proves the rule is in place:

# A marked request must come back no-store whoever sends it
curl -sI "https://your-site.example/?norg_edge=1" | grep -i cache-control
#   cache-control: private, no-store

# An ordinary browser request must NOT be forced no-store
curl -sI "https://your-site.example/" | grep -i cache-control
3

Undo if needed

To reverse the change, go back to User Portal → Web Rules → Rewrite Rules and delete the rewrite rule. Nothing else was changed, so removing the rule returns the site to exactly how it behaved before: AI agents receive the cached human page again and the plugin stays installed and idle for them.

To stop serving mirrors without touching WP Engine, tick Disable in the plugin settings or define NORG_EDGE_DISABLED as true in wp-config.php; every visitor gets the normal site on the next request. Deactivating or deleting the plugin removes its options and transients.

What the marker does

Any request carrying ?norg_edge gets an uncacheable response, whoever sent it and whatever the outcome. The plugin (0.1.3 and later) sends the no-store headers for a marked request at the earliest plugin stage and again at template_redirect, so a host or cache plugin that sets its own Cache-Control later is overridden. A person who types ?norg_edge=1 into a browser gets the normal page, uncached. An AI agent whose source address fails the operator's range check also gets the normal page, uncached. A verified agent gets the mirror. Nothing is ever stored under a marked URL, so no cache can show a mirror to a person.

HTTP/2 200
cache-control: private, no-store
cdn-cache-control: private, no-store
x-norg-edge: mirror          # or "stripped" when no mirror exists yet; absent for an unverified caller

Marked requests run PHP instead of being answered from the cache. The volume is AI-crawler traffic only; WP Engine's usage metrics and the plugin's status page show it. Every setting and header the plugin has is in the technical reference; the architecture around it is on the solution architecture page, and the install steps on the plugin guide.

If a Cloudflare zone fronts WP Engine

A Cloudflare Worker on the zone keeps agent traffic off WP Engine entirely, but Cloudflare's Orange-to-Orange arrangement with WP Engine is CNAME-based: an apex pointed at WP Engine with A records bypasses the zone's Workers. The fix is a two-record DNS change, with backup and undo, on Fix a WP Engine site that Cloudflare bypasses. Where DNS is not to be touched, the plugin and the rule on this page work unchanged behind Cloudflare; the plugin reads the visitor address from CF-Connecting-IP automatically.