How to Detect WP Rocket on Any Website (API Guide)

WP Rocket is the best-known premium caching plugin for WordPress. Unlike most plugins in its category it has no free tier, which makes it an unusually strong signal: a site running WP Rocket has an owner who pays for performance tooling. That makes detection useful far beyond curiosity — it confirms the site runs WordPress, flags a budget for paid plugins, and tells performance consultants exactly what caching layer they would be working with or against.

What Is WP Rocket and Why Detect It

WP Rocket is a caching and performance optimization plugin for WordPress. It generates static cached copies of pages, minifies and combines CSS and JavaScript, lazy-loads images and scripts, preloads links, and can remove unused CSS entirely. It is a paid product with no free version, sold on an annual license.

Reasons teams detect it:

• WordPress confirmation. WP Rocket only runs on WordPress, so a positive detection doubles as a CMS detection.
• Budget qualification. Because there is no free tier, every WP Rocket site represents an owner who already pays for site tooling. Vendors selling hosting, maintenance plans, or performance services treat that as a pre-qualified segment.
• Performance audits. Before quoting a speed-optimization job, consultants need to know what is already installed. Recommending a caching setup to a site that already runs WP Rocket is an instant credibility loss; knowing it is there changes the entire proposal.
• Competitive analysis. If a competitor's site is fast, knowing whether the speed comes from WP Rocket, a CDN, or server-level caching like Varnish tells you what you would need to match it.

Manual Ways to Detect WP Rocket

WP Rocket modifies the HTML it serves, rewrites asset URLs, and touches response headers, so it leaves several distinct fingerprints you can check by hand.

Check the HTML Source for WP Rocket Signatures

The most famous WP Rocket marker is the comment it appends to optimized pages. The exact wording has varied across versions, but it always names the plugin:

<!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket... -->

A one-liner catches it, along with any other mention of the plugin in the source:

$ curl -s https://example.com | grep -io "wp rocket" | head -1
WP Rocket

Two more HTML-level markers show up depending on which features are enabled. If the site uses WP Rocket's lazy-load or preload features, its inlined scripts define JavaScript globals named RocketLazyLoadScripts, RocketPreloadLinksConfig, or rocket_lazy. And if the Remove Unused CSS feature is on, the page carries an inline stylesheet with the id wpr-usedcss:

$ curl -s https://example.com | grep -o 'id="wpr-usedcss"'
id="wpr-usedcss"

Look for Minified and Cached File Paths

When minification is enabled, WP Rocket rewrites CSS and JavaScript URLs to its own cache directory under /wp-content/cache/min/. Some pages also reference plugin assets directly from /wp-content/plugins/wp-rocket/:

<link rel="stylesheet"
      href="https://example.com/wp-content/cache/min/1/a1b2c3d4e5.css">
<script src="https://example.com/wp-content/plugins/wp-rocket/assets/js/lazyload/17.8.3/lazyload.min.js"></script>

The /wp-content/ prefix in both paths is a WordPress signature on its own, so this check confirms the CMS and the plugin at once:

$ curl -s https://example.com | grep -o "wp-content/cache/min[^\"']*" | head -2
wp-content/cache/min/1/a1b2c3d4e5.css
wp-content/cache/min/1/f6e5d4c3b2.js

Inspect HTTP Response Headers

Many WP Rocket installs expose the plugin in response headers. The clearest is X-Powered-By, which on some hosts includes the version; sites running WP Rocket's companion Nginx configuration also send X-Rocket-Nginx-Bypass:

$ curl -sI https://example.com | grep -i "x-powered-by\|x-rocket"
X-Powered-By: WP Rocket/3.15.10
X-Rocket-Nginx-Bypass: Yes

The header is the only fingerprint that carries the version number, which matters for security triage: when an advisory lands for a plugin, the version tells you who is exposed. Not every host passes the header through — some CDNs and managed WordPress platforms strip X-Powered-By entirely — so treat its absence as inconclusive rather than negative.

Why Manual Detection Fails at Scale

All of these checks work for one site. They stop working the moment you have a list:

• The fingerprints depend on configuration. The footer comment, the min/ paths, the lazy-load globals, and the headers each appear only when the corresponding feature is enabled. A reliable manual check means testing all of them, because any single one can legitimately be absent.
• Grep gives you a string, not data. You still have to parse the version out of the header, handle redirects, deal with sites that block plain curl user agents, and normalize the output into something a spreadsheet or CRM can ingest.
• You learn nothing else. A grep for wp rocket tells you nothing about the site's theme, page builder, analytics, CDN, or hosting — which is usually the context that makes the detection useful.

An API call solves all three at once: one request per site, every fingerprint tested, structured JSON out, and the full technology stack in the same response.

Detect WP Rocket with the DetectZeStack API

The DetectZeStack API runs its full fingerprint database against a URL — HTML source, script URLs, DOM structure, JavaScript globals, headers, and DNS — and returns everything it finds as structured JSON. WP Rocket is fingerprinted by its HTML comment, its /wp-content/plugins/wp-rocket/ script path, its RocketLazyLoadScripts and RocketPreloadLinksConfig globals, the wpr-usedcss style element, and the X-Powered-By header with version capture.

Try It Free with the Demo Endpoint

The public /demo endpoint runs the same detector pipeline with no authentication. It is IP rate-limited, but perfect for a quick check or for confirming the response shape before you integrate:

curl -s "https://detectzestack.com/demo?url=https://example.com" | python3 -m json.tool

Full Detection with /analyze

For production use, sign up on RapidAPI and call /analyze with your key. When WP Rocket is present, the response looks like this:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://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 Rocket",
      "categories": ["Caching", "WordPress plugins"],
      "confidence": 100,
      "description": "WP Rocket is a caching and performance optimisation plugin to improve the loading speed of WordPress websites.",
      "website": "https://wp-rocket.me",
      "icon": "WP Rocket.png",
      "source": "http",
      "version": "3.15.10",
      "cpe": ""
    },
    {
      "name": "WordPress",
      "categories": ["CMS", "Blogs"],
      "confidence": 100,
      "description": "WordPress is a content management system.",
      "website": "https://wordpress.org",
      "icon": "WordPress.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": {
    "Caching": ["WP Rocket"],
    "WordPress plugins": ["WP Rocket"],
    "CMS": ["WordPress"]
  },
  "meta": { "status_code": 200, "tech_count": 14, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

A few things worth noticing. WP Rocket is classified under two categories — Caching and WordPress plugins — so it appears twice in the top-level categories map, which lets you filter by either angle. The version field is parsed from the X-Powered-By header when the host exposes it; when the header is stripped, WP Rocket is still detected via its other fingerprints but version comes back empty. And WordPress itself shows up in the same response, because the same page that betrays the plugin fires WordPress's own fingerprints too.

To narrow the output to just the WP Rocket entry, pipe through jq:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  | jq '.technologies[] | select(.name == "WP Rocket")'

Yes/No Checks with /check

If all you want is a boolean, the /check endpoint answers the narrower question “does this site run this specific technology?” directly. The tech parameter is case-insensitive:

curl -s "https://detectzestack.p.rapidapi.com/check?url=https://example.com&tech=WP%20Rocket" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"

{
  "domain": "example.com",
  "technology": "WP Rocket",
  "detected": true,
  "confidence": 100,
  "version": "3.15.10",
  "categories": ["Caching", "WordPress plugins"],
  "response_ms": 1421,
  "cached": false
}

When the technology is not found, detected comes back false with a confidence of 0. This shape is convenient for pipelines that just need to branch on a boolean — no array filtering required.

Batch-Check Multiple Sites at Once

Checking one site is useful; checking a list is where this earns its keep. The POST /analyze/batch endpoint accepts up to 10 URLs per request and scans them concurrently:

curl -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",
      "wordpress.org",
      "wp-rocket.me",
      "example.org"
    ]
  }'

To turn a domain list into a clean list of WP Rocket sites, loop in batches of 10 and filter each result:

import requests

API_URL = "https://detectzestack.p.rapidapi.com/analyze/batch"
HEADERS = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
    "Content-Type": "application/json",
}

def chunk(items, size=10):
    for i in range(0, len(items), size):
        yield items[i:i + size]

domains = ["example.com", "wordpress.org", "wp-rocket.me"]
wp_rocket_sites = []

for batch in chunk(domains):
    resp = requests.post(API_URL, json={"urls": batch}, headers=HEADERS)
    for item in resp.json().get("results", []):
        result = item.get("result")  # None if that URL errored
        if not result:
            continue
        for tech in result.get("technologies", []):
            if tech["name"] == "WP Rocket":
                wp_rocket_sites.append((result["domain"], tech.get("version", "")))

print("Sites using WP Rocket:", wp_rocket_sites)

Each URL in a batch counts as one request against your monthly quota, so a 10-URL batch consumes 10 requests. For the full pattern — rate-limit handling, retries, and CSV output — see How to Batch-Scan 1,000 Websites.

Reading the API Response

Because the same scan surfaces the rest of the stack, the WP Rocket signal is most useful in combination:

All of these combinations come back in a single /analyze response, since the same scan surfaces page builders like Elementor, SEO plugins like Yoast, hosting signals like WP Engine, and CDN detections alongside the caching plugin.

Use Cases: Sales Prospecting and Competitive Analysis

For sales teams, WP Rocket is a budget signal you can filter on. Run a prospect list through /analyze/batch, keep the domains where WP Rocket appears, and you have a segment of WordPress site owners who demonstrably pay for plugins — a far warmer list for hosting upgrades, maintenance retainers, or premium tooling than a raw WordPress census.

For performance consultants, the detection shapes the audit before it starts. A slow site running WP Rocket is not a “you need caching” pitch — it is a configuration and stacking problem, often involving a second cache layer at the host or CDN. Knowing that from one API call, before the first client conversation, is the difference between a generic proposal and a specific one.

For competitive analysis, comparing your stack against a rival's answers the “why is their site faster” question concretely: same CDN but they add WP Rocket, or same plugin but they layer it on managed hosting. The categories map in each response makes stack-vs-stack comparison a simple diff.

Conclusion

WP Rocket is a well-marked technology once you know its fingerprints: an HTML comment that names the plugin, minified assets under /wp-content/cache/min/, lazy-load JavaScript globals, a wpr-usedcss style element, and an X-Powered-By header that carries the version. Manual checks with curl and DevTools work fine for a single site, with the caveat that every fingerprint depends on which features are switched on. For anything more — a prospect list, a performance audit pipeline, a competitive comparison — the DetectZeStack API tests all the fingerprints at once, returns structured JSON with the rest of the tech stack in the same response, and scales to thousands of domains through batching.