MikeL

Posted on Jul 8 • Originally published at detectzestack.com

How to Find Companies Using WP Engine (API Guide 2026)

#techstack #webdev #api

WP Engine is the managed WordPress host that companies graduate to when their site becomes revenue-critical. Its plans start well above commodity shared hosting, so “uses WP Engine” is one of the rare technographic signals that encodes budget as well as technology: it tells you the company runs WordPress, cares enough about that site to pay a premium for it, and has already delegated the hosting layer to a vendor.

This guide covers what a WP Engine detection tells you about a company, the exact DNS CNAME and HTTP header signals that reveal the platform, and how to turn a raw domain list into a WP Engine-confirmed lead list with the DetectZeStack API—starting with a single curl command you can run right now, no API key required.

Why Find Companies Using WP Engine?

Technographic data—what technology a company actually runs—often qualifies a prospect better than firmographics alone. A WP Engine detection is a specific, verifiable fact about a company’s infrastructure, and it feeds two distinct workflows.

Sales Prospecting for WordPress Agencies and Plugin Vendors

It confirms WordPress with budget attached. Every WP Engine customer runs WordPress—the platform hosts nothing else—and pays managed-hosting prices to do it. If you sell WordPress plugins, themes, maintenance retainers, performance audits, or agency services, a WP Engine list is a WordPress list pre-filtered for willingness to spend on the site.
It maps the buyer. A company on managed hosting has already decided not to run its own servers. The conversation is with a marketing or web team that owns the site as a business asset, not with an infrastructure team—which changes both the pitch and the pain points: plugin conflicts, page speed, redesigns, content workflows.
It stacks with other filters. WP Engine alone is a solid segment; WP Engine plus a page builder or a marketing tool detection is a sharp one. Because a tech detection API returns the whole stack in one response, intersecting filters costs nothing extra—the same trick our Elementor prospecting guide uses at the plugin layer.

Competitive and Migration Intelligence

Hosting-switch campaigns. If you sell a competing platform or migration services, a WP Engine-confirmed list is your total addressable market, enumerated. Rescanning the same list on a schedule shows who has left the platform—and who just arrived.
Market sizing. Scanning a vertical for managed WordPress adoption shows how seriously that segment treats its web presence, and how the managed-hosting share shifts over time between WP Engine, Kinsta, Pantheon, Flywheel, and the rest—all of which are detectable from the same DNS layer.

How WP Engine Reveals Itself (Detection Signals)

WP Engine shows up in two independent layers: the DNS records that route traffic to the platform, and the HTTP headers its cache tier stamps on every response. A site that hides one layer frequently gives away the other.

Layer	Signal	What It Means
DNS CNAME	*.wpengine.com	The domain points at a classic WP Engine install hostname
DNS CNAME	*.wpenginepowered.com	The newer install hostname pattern (e.g. wp.wpenginepowered.com)
DNS CNAME	*.wpeproxy.com	The domain routes through WP Engine’s proxy network
HTTP header	X-Powered-By: WP Engine	The response was served by the WP Engine platform
HTTP header	WPE-Backend: ...	WP Engine’s cache tier names the backend that produced the response
HTTP header	X-Pass-Why / X-WPE-Loopback-Upstream-Addr	Cache-diagnostic headers unique to WP Engine’s stack

DNS CNAME Records Pointing to *.wpengine.com

Every WP Engine install gets a platform hostname, and custom domains reach it through DNS. The classic pattern is a CNAME to <install>.wpengine.com; newer installs use <install>.wpenginepowered.com, and traffic routed through the platform’s proxy network resolves through *.wpeproxy.com hostnames. A single dig shows it:

$ dig www.example.com CNAME +short
examplesite.wpengine.com.

$ dig www.another-example.com CNAME +short
wp.wpenginepowered.com.

All three suffixes are unambiguous—no one CNAMEs to a WP Engine hostname without being a customer. DetectZeStack matches all of them and follows the full CNAME chain to find them, since a domain often resolves through a vanity or CDN host first. For the mechanics of chain resolution, see DNS-Based Technology Detection.

WP Engine Cache Headers and Server Fingerprints

WP Engine fronts every install with its own caching and proxy tier, and that tier writes identifiable headers into responses. The clearest is X-Powered-By: WP Engine; alongside it the platform emits WPE-Backend (naming the backend that produced the response) and cache diagnostics like X-Pass-Why and X-WPE-Loopback-Upstream-Addr. One curl -I surfaces them:

$ curl -sI https://www.example.com | grep -iE "x-powered-by|wpe|x-pass"
X-Powered-By: WP Engine
WPE-Backend: apache
X-Pass-Why:

Any one of these headers confirms the platform. They are also the reason a WP Engine detection doubles as a WordPress detection: the platform hosts WordPress exclusively, so the header implies the CMS even on sites that have stripped every conventional WordPress fingerprint—a useful backdoor when the methods in our WordPress detection guide come up empty.

Why Header Checks Alone Miss Hardened Sites

Neither layer is complete on its own. A CDN or security proxy in front of WP Engine can strip or overwrite the platform headers, so a header-only check returns a false negative for exactly the security-conscious companies you may most want to find. In those setups DNS often still tells the truth—or the reverse: a domain whose DNS routes through a CDN hides the WP Engine CNAME while the platform headers pass through the edge untouched. The practical rule: check both layers, and treat a hit on either as a confirmation. That is what the API does in a single request.

Manual Detection Methods (and Their Limits)

For one domain, the two commands above—dig ... CNAME +short and curl -sI ... | grep -iE "wpe|x-powered-by"—are all you need. The limits appear when the task changes shape:

Scale. Checking two layers by hand across a 1,000-domain prospect list is a script-writing project with retries, timeouts, and rate limiting to solve before you see a single result.
Chain resolution. dig +short shows one CNAME hop. Real domains resolve through chains—vanity host to CDN to platform—and the WP Engine hostname may sit two hops deep, where a naive check misses it.
Context. A manual check answers exactly one question. An API scan returns the entire stack—CMS, page builder, analytics, marketing tools—so the same request that confirms WP Engine also scores the lead.

Detect WP Engine with the DetectZeStack API

The API runs the header and DNS checks together, follows CNAME chains, and returns everything else it finds along the way.

Single Domain Check with /analyze (curl example)

Try it right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
| jq '.technologies[] | select(.name == "WP Engine")'
{
"name": "WP Engine",
"categories": ["PaaS", "Hosting"],
"confidence": 100,
"description": "WP Engine is a website hosting provider.",
"website": "https://wpengine.com",
"icon": "wpengine.svg",
"source": "http",
"version": "",
"cpe": ""
}

The source field tells you which layer produced the evidence. A source: "http" entry at confidence 100 came from the platform headers—X-Powered-By: WP Engine, WPE-Backend, or one of the cache diagnostics. When only DNS gives it away, the same technology comes back with source: "dns" at confidence 80 under the Hosting category instead—reliable, but one step removed from a live header match. A header-level hit also implies WordPress, so expect a WordPress entry alongside it.

For production use, call /analyze with your API key. The complete response is shaped like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"url": "https://example.com",
"domain": "example.com",
"technologies": [
{
"name": "WP Engine",
"categories": ["PaaS", "Hosting"],
"confidence": 100,
"description": "WP Engine is a website hosting provider.",
"website": "https://wpengine.com",
"icon": "wpengine.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "WordPress",
"categories": ["CMS", "Blogs"],
"confidence": 100,
"description": "WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. Features include a plugin architecture and a template system.",
"website": "https://wordpress.org",
"icon": "WordPress.svg",
"source": "http",
"version": "",
"cpe": "cpe:2.3:a:wordpress:wordpress:*:*:*:*:*:*:*:*"
}
],
"categories": {
"PaaS": ["WP Engine"],
"Hosting": ["WP Engine"],
"CMS": ["WordPress"],
"Blogs": ["WordPress"]
},
"meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
"cached": false,
"response_ms": 1842
}

The top-level categories map groups every detection by category so you can slice the stack without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level, not inside meta.

meta.scan_depth matters for list building. A value of "full" means the HTTP fetch succeeded and the header check ran. A value of "partial" means the site blocked or timed out the HTTP request and only the DNS and TLS layers completed. Because WP Engine is also detectable from its CNAME suffixes, a "partial" scan can still confirm it—but an absent WP Engine entry on a "partial" scan is an unknown, not a no. Those domains belong in a retry queue.

Scanning a Lead List with /analyze/batch

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["example.com", "example.org", "example.net"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response, plus batch-level counters:

{
"results": [
{ "url": "example.com", "result": { "...full analysis..." : "" } },
{ "url": "example.org", "result": { "...full analysis..." : "" } },
{ "url": "example.net", "result": { "...full analysis..." : "" } }
],
"total_ms": 2341,
"successful": 3,
"failed": 0
}

Building a WP Engine Prospect List Workflow

Because each batch result matches the single-domain shape, the filtering logic is identical at any scale. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10, and appends every WP Engine-confirmed domain to wpengine_leads.csv with the detection source and tech count:

#!/usr/bin/env bash
# find-wpengine.sh — filter a domain list down to WP Engine-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,source,tech_count" > wpengine_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| ($r.technologies[] | select(.name == "WP Engine")) as $wpe
| [$r.domain, $wpe.source, ($r.meta.tech_count | tostring)]
| @csv' >> wpengine_leads.csv
done

wc -l wpengine_leads.csv

A 1,000-domain list becomes 100 batch calls. Recording $wpe.source per row lets you split header-confirmed hits from DNS-only ones downstream, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). Three refinements worth making before outreach:

Split by source. An http-sourced hit at confidence 100 means the platform headers are live on the response right now. A dns-sourced hit at confidence 80 means the domain routes to a WP Engine hostname. Both are real customers; the first is the stronger opener.
Cross-reference the rest of the stack. The full technologies array came back with every row you kept. WP Engine plus Elementor is an agency-built marketing site; WP Engine plus WooCommerce is a store with revenue riding on uptime—different pitches to different buyers. The broader version of this segmentation is covered in finding companies using WordPress.
Score by meta.tech_count. Tech count is a rough proxy for stack maturity, useful for prioritizing which confirmed leads get personal outreach first.

Feeding these signals into a scoring model is covered in our lead enrichment pipeline guide, and the throughput, retry, and rate-limit mechanics are in how to batch scan 1,000 websites.

Widen the net to all managed WordPress hosts. WP Engine’s neighbors—Kinsta (.kinsta.cloud), Pantheon (.pantheonsite.io), Flywheel (.flywheelsites.com), and WordPress VIP (.go-vip.net)—are all detectable from their own CNAME suffixes in the same scan. If your real qualifier is “pays for managed WordPress” rather than “WP Engine specifically,” widen the jq filter to match any of them; every result row already contains the data.

Get Started with a Free API Key

The free Basic plan includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

Get a key at rapidapi.com/mlugoapx/api/detectzestack.
Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
Run the batch script above against your first 100 domains.

Conclusion

Finding companies using WP Engine comes down to reading two layers well: the X-Powered-By: WP Engine, WPE-Backend, and cache-diagnostic response headers, and the .wpengine.com, .wpenginepowered.com, and .wpeproxy.com DNS CNAMEs. Headers are the strongest signal; DNS is the reliable backup that still works when the HTTP fetch is blocked—and every confirmed hit doubles as a WordPress confirmation with hosting budget attached. A single /analyze call answers the one-domain question, /analyze/batch turns a raw list into a WP Engine-confirmed lead list, and the source and meta.scan_depth fields tell you how much to trust each row. Swap the jq filter and the same pipeline segments by Kinsta, Pantheon, or any other detectable technology instead.

DEV Community