WordPress Detector | Plugins & Site Technology

Find WordPress signals in your website list

WordPress Detector: Check supplied websites for exposed WordPress and plugin signals. Return matched technologies, versions when exposed, CMS and hosting fields for agency qualification. Public HTML and headers only; hidden plugins can be missed.

Start with a small example

1. Open Input, switch to JSON and paste the example below. Replace the example startUrls with your own research targets when ready.
2. Check the live Pricing tab and set a run spending limit.
3. Run the Actor, then open the Workflow output view. Inspect url, matchesFilter, matchedTechnologies, cms, hosting, error.
4. Export JSON for nested data or CSV for a spreadsheet. Review a small sample before increasing the scope.

{
  "startUrls": [
    "https://techcrunch.com",
    "https://wordpress.org",
    "https://www.shopify.com"
  ],
  "filterTechnologies": [
    "WordPress",
    "WooCommerce",
    "WordPress Block Editor",
    "Elementor",
    "WPBakery",
    "Divi"
  ],
  "onlyMatching": false
}

At the rate checked September 9, 2026, 3 saved rows cost $0.009 in Actor event fees ($3.00 per 1,000 rows). Actual returned rows determine the event fee. Taxes and other account services may be separate.

What can I use it for?

• Selling to WordPress site owners. Hosting providers, plugin and theme vendors, maintenance agencies and security services all need lists of sites that are actually on WordPress. This makes one from any domain list.
• WooCommerce prospecting. Keep only the sites where WooCommerce appears in matchedTechnologies to target online stores specifically.
• Security and maintenance audits. Spot sites publishing an outdated WordPress version, or running a page builder you support, across a whole client portfolio.
• Migration campaigns. Find sites on competing platforms by excluding WordPress matches, or find WordPress sites on a hosting provider you want to win business from.
• Market research. Measure WordPress and WooCommerce share within an industry, region or keyword set.

What data does it return?

One record per website:

Field	Meaning
url, finalUrl, statusCode, title	What you asked for, where it resolved to, and the page title
matchesFilter	true when the site runs any of the WordPress signals you listed
matchedTechnologies	Which signals were found, e.g. ["WordPress", "WooCommerce", "Elementor"]
cms	The CMS detected — WordPress for a match, or whatever else the site runs
ecommerce	WooCommerce when the store plugin is present
programmingLanguages, webServer, hosting, cdn	Infrastructure — PHP, Nginx, WP Engine, Kinsta, Cloudflare and so on
analytics, tagManager, advertising, marketingAutomation	Tracking and marketing stack
security	reCAPTCHA, Wordfence and similar where detectable
technologyCount	Total technologies detected
technologies	The complete list with categories, versions and confidence scores — this is where the WordPress version appears
error	null on success, otherwise why the site could not be checked

Sites that time out or refuse the connection are still returned with an error, so input and output line up one to one.

Illustrative output

Values explain the output shape; they are not a live result or guaranteed field coverage.

{
  "url": "https://wordpress.org",
  "finalUrl": "https://wordpress.org/",
  "statusCode": 200,
  "title": "Blog Tool, Publishing Platform, and CMS – WordPress.org",
  "matchesFilter": true,
  "matchedTechnologies": ["WordPress", "WordPress Block Editor"],
  "cms": "WordPress",
  "ecommerce": null,
  "webServer": "Nginx",
  "programmingLanguages": "PHP",
  "tagManager": "Google Tag Manager",
  "technologyCount": 9,
  "technologies": [
    { "name": "WordPress", "categories": ["CMS", "Blogs"], "version": "7.2", "confidence": 100, "website": "https://wordpress.org" },
    { "name": "PHP", "categories": ["Programming languages"], "version": null, "confidence": 100, "website": "https://php.net" }
  ],
  "error": null
}

How to use it

1. Paste your domains under Websites to check, upload a file, or pass them through the API as startUrls.
2. Leave WordPress signals to look for at its defaults for a broad check, or trim the list to WordPress alone for a strict one. Add WooCommerce on its own to find stores only.
3. Switch on Store only matching websites if you want to pay only for the WordPress sites and discard the rest.
4. Click Start and download the results as JSON, CSV or Excel from the Output tab, or read them from the dataset via the API.

Input example

{
  "startUrls": [
    "https://techcrunch.com",
    "wordpress.org",
    "https://www.shopify.com"
  ],
  "filterTechnologies": ["WordPress", "WooCommerce"],
  "onlyMatching": false
}

Raise Max concurrency for large lists. Turn on Proxy configuration only if some target sites block the platform's IP range — most do not.

How detection works

WordPress announces itself in several places on the first response: the generator meta tag (which also carries the version), wp-content and wp-includes paths in stylesheet and script URLs, the wp-json REST link header, and cookies set by WooCommerce and common plugins. The detector fetches each homepage once and checks the headers, cookies, HTML, script sources and meta tags against more than 7,600 technology fingerprints, adding implied technologies — a WooCommerce hit implies WordPress and PHP — at a lower confidence so you can tell direct evidence from inference. Because the page's JavaScript is never executed, signals that only appear after scripts run are not evaluated; for WordPress that rarely matters, and the trade-off buys speed and a far lower cost per site.

The fingerprint database is the open-source webappanalyzer technology dataset, used under the GNU GPL v3. The matching engine in this actor is original code.

Pricing

You pay per website saved to the dataset. With Store only matching websites on, that means per WordPress site found; with it off, per site checked. There are no subscriptions, seats or minimums, and you can cap the maximum spend of a run before it starts.

Scope and responsible use

The actor requests only the publicly served homepage of each URL you provide, exactly as a browser would. It requires no login, no cookies and no credentials, does not crawl beyond the page you give it, does not probe wp-admin, xmlrpc.php or any other endpoint, and does not attempt to bypass any access control or bot-protection challenge. You are responsible for using the results in accordance with the laws that apply to you and the terms of the websites you check.

Limitations

• Very large media homepages that deliberately stall automated traffic can exceed the request timeout; they come back as rows with an error rather than being dropped.
• Sites that deliberately hide WordPress fingerprints (security plugins that rename wp-content, strip the generator tag and remove REST links) can be missed or reported at lower confidence.
• Headless WordPress sites that serve a separate front end expose few signals on the homepage.
• The WordPress version is reported only when the site publishes it; many hardened sites remove it.
• Only the URL you supply is fetched, so a WordPress blog living under /blog/ on an otherwise non-WordPress site is not found unless you pass that path.

Something not detected?

Open an issue on this actor's Issues tab with the URL and what you expected. Include a reproducible input and the expected signal so the report can be investigated.

Interpret empty results and errors

A null technology field means no recognized signal was found in the inspected response; it does not prove absence. A returned error means that URL was not successfully analyzed. With onlyMatching: true, non-matches and errors are omitted from the dataset, so a zero-row result cannot distinguish an unavailable site from no matches. Start with onlyMatching: false when checking coverage.

Every saved row, including an error row, incurs the configured per-row event fee. Proxy selection and run duration can affect operating costs. Do not increase concurrency or enable a more expensive proxy merely to work around an unclear result.

For a reproducible problem, open this Actor’s Issues tab with a small public input, expected behavior and relevant error text. Remove tokens and confidential information. No response-time or uptime guarantee is offered.

Use the result in an automation

In Make or n8n, use the Apify integration to run this Actor with the same JSON input, wait for completion, then retrieve its default dataset. Route failed runs and error rows to a review step before sending valid results to your spreadsheet or CRM. Scheduling does not make these Actors emit only new records: deduplicate downstream using the source URL or record ID.

For Node.js, install the official apify-client package and set your own APIFY_TOKEN environment variable. The following example starts a paid run with a small spending limit.

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const input = {
  "startUrls": [
    "https://techcrunch.com",
    "https://wordpress.org",
    "https://www.shopify.com"
  ],
  "filterTechnologies": [
    "WordPress",
    "WooCommerce",
    "WordPress Block Editor",
    "Elementor",
    "WPBakery",
    "Divi"
  ],
  "onlyMatching": false
};
const run = await client.actor('keystonelabs/wordpress-site-detector').call(input, {
  memory: 512, timeout: 180, maxTotalChargeUsd: 0.10
});
if (run.status !== 'SUCCEEDED') throw new Error('Run did not succeed: ' + run.id);
const { items } = await client.dataset(run.defaultDatasetId).listItems({ limit: 100 });
console.log(items);

The first 100 rows are retrieved in this example. Use the dataset API pagination for a larger result. Keep credentials out of shared inputs and source files.

A useful next step

• Website Tech Stack Detector | Bulk URL Lookup: qualify a website list by its technology. This is a separate Actor with its own input and price.

Understand the run at a glance

Open Run summary in Output for counts of unique URLs, analyzed responses, failures, matches and saved rows. It remains useful when onlyMatching produces an empty dataset. The summary is written at normal completion and does not add a billable dataset row. Failed or aborted runs may not have a final summary; check run status first. The summary contains counts only, not a second copy of scraped content.