Find Companies Using Site Kit: API Detection Guide (2026)

Site Kit by Google is the official Google plugin for WordPress, and with over five million active installations it is one of the most widely deployed plugins in the ecosystem. For anyone prospecting into the WordPress market, that popularity is not the interesting part. The interesting part is what a Site Kit install proves: the site runs WordPress, someone with admin access actively set it up, and that person cares enough about traffic and search performance to wire Google's reporting into their dashboard. This guide shows how to detect it from the outside and turn that signal into a prospect list with the DetectZeStack API. Every response below comes from a live scan of a real site.

What Is Site Kit by Google and Why It Signals a WordPress Lead

Site Kit connects a WordPress site to Google's free webmaster stack: Search Console, Google Analytics, AdSense, Tag Manager, and PageSpeed Insights, all surfaced inside wp-admin. It exists only as a WordPress plugin, which makes it an unusually honest signal. Plenty of technologies can appear on any platform; Site Kit cannot. Detecting it is de facto proof of WordPress underneath, and the same scan almost always confirms WordPress independently anyway.

More useful than the platform confirmation is what the install says about the person behind the site. Site Kit does nothing until an administrator connects a Google account and walks through setup. A site running it has an owner who logs into the dashboard, looks at traffic numbers, and cares about how the site performs in search. That is a very different lead from an abandoned WordPress install serving a stale brochure page, and the two are indistinguishable from the domain name alone.

Why Find Companies Using Site Kit

Sales Prospecting for WordPress Agencies and Plugin Vendors

If you sell WordPress services, plugins, managed hosting, or SEO work, a Site Kit list is pre-qualified twice over. The platform question is settled, so no outreach is wasted on Squarespace or Webflow sites. And the intent question is half-settled: the owner already invests attention in analytics and search visibility, which is exactly the appetite an SEO retainer, a performance plugin, or a site-speed engagement sells into. Someone monitoring their PageSpeed scores through Site Kit is the natural buyer for the service that improves them.

The version number sharpens this further. Site Kit ships updates frequently, and DetectZeStack captures the installed version from the detection signal itself. A site running a current build is actively maintained. A site several versions behind has a WordPress install nobody is tending, which is its own pitch: maintenance plans, security reviews, and care contracts exist for exactly that site.

Competitive and Market Analysis

The same signal works for market research. Because Site Kit is the default way small and mid-size WordPress sites wire up Google Analytics, its presence maps the self-service end of the market: sites run by owners and small teams rather than enterprise marketing departments. If you are sizing a market for a WordPress product, comparing plugin footprints across a vertical, or profiling what a competitor's customer base actually runs, filtering scans for Site Kit separates the actively-managed WordPress web from the abandoned one.

How Site Kit Detection Works

Fingerprints Site Kit Leaves in Page Source

Site Kit writes a generator meta tag into the head of every page the site serves:

<meta name="generator" content="Site Kit by Google 1.183.0"/>

This is the primary fingerprint, and it is a strong one. The tag sits in the raw HTML the server returns, so it is visible to a server-side scanner without executing any JavaScript, and there is no reason for it to exist except that the plugin is installed and active. DetectZeStack matches the tag, returns Site Kit with a confidence of 100, and parses the version number out of the same string into the version field. Few technographic signals hand you a version for free; this one does.

You can confirm the fingerprint by hand on any site: view source, search for Site Kit by Google, and the generator tag is either there or it is not. That works for one domain. It does not work for five hundred, which is what the API is for.

Related Signals: Google Analytics, Tag Manager, and AdSense

Site Kit's whole job is placing Google's tags on the site, so it rarely scans alone. The Google Analytics snippet it installs is detected as its own Google Analytics entry, and sites using Site Kit to manage Tag Manager or AdSense produce Google Tag Manager and Google AdSense detections the same way. Each of these can and does appear without Site Kit; Site Kit is the tell that they were wired up through the WordPress plugin rather than pasted in by hand or deployed by a tag management team. If you want the broader versions of those signals, see the guides on detecting Google Analytics and detecting Google Tag Manager.

API Example: Detect Site Kit on Any Domain with DetectZeStack

Try It Free with the /demo Endpoint

The /demo endpoint needs no API key and no signup, so start there. CSS-Tricks, the long-running web development site, is a live example:

curl -s "https://detectzestack.com/demo?url=css-tricks.com" \
  | jq '.technologies[] | select(.name == "Site Kit")'

Which returns:

{
  "name": "Site Kit",
  "version": "1.183.0",
  "categories": [
    "Analytics",
    "WordPress plugins"
  ],
  "confidence": 100,
  "description": "Site Kit is a one-stop solution for WordPress users to use everything Google has to offer to make them successful on the web.",
  "website": "https://sitekit.withgoogle.com/",
  "icon": "Google.svg",
  "source": "http"
}

Four fields matter here. categories places Site Kit under both Analytics and WordPress plugins, so it surfaces whichever way you slice a scan. confidence is 100 because the generator tag matched exactly rather than through a weaker heuristic. source is http, meaning the detection came from the HTML response rather than a DNS or TLS signal. And version is 1.183.0, read straight out of the tag; at the time of this scan that was the current Site Kit release, which tells you this install is up to date.

The full response carries the rest of the stack, and the rest of the stack is the context that makes the lead specific. Here is the same scan, trimmed to the shape of the full /analyze response:

{
  "url": "https://css-tricks.com",
  "domain": "css-tricks.com",
  "technologies": [
    { "name": "Site Kit",         "categories": ["Analytics", "WordPress plugins"], "confidence": 100, "version": "1.183.0", "source": "http" },
    { "name": "WordPress",        "categories": ["CMS", "Blogs"],                   "confidence": 100, "version": "",        "source": "http" },
    { "name": "Google Analytics", "categories": ["Analytics"],                      "confidence": 100, "version": "",        "source": "http" },
    { "name": "Jetpack",          "categories": ["WordPress plugins"],              "confidence": 100, "version": "",        "source": "http" },
    { "name": "PHP",              "categories": ["Programming languages"],          "confidence": 100, "version": "",        "source": "http" },
    { "name": "MySQL",            "categories": ["Databases"],                      "confidence": 100, "version": "",        "source": "http" },
    { "name": "Cloudflare",       "categories": ["CDN"],                            "confidence": 100, "version": "",        "source": "http" },
    { "name": "jQuery",           "categories": ["JavaScript libraries"],           "confidence": 100, "version": "3.5.1",   "source": "http" }
  ],
  "categories": {
    "Analytics": ["Google Analytics", "Site Kit"],
    "WordPress plugins": ["Site Kit", "Jetpack"],
    "CMS": ["WordPress"],
    "CDN": ["Cloudflare"]
  },
  "meta": { "status_code": 200, "tech_count": 15, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1337
}

Read that as a sales brief. This is a WordPress site on PHP and MySQL, behind Cloudflare, running Jetpack alongside Site Kit, with Google Analytics wired in. One API call did the platform research an SDR would otherwise do by hand, and the categories map makes it a single lookup to consume programmatically.

For authenticated use, the same scan runs through /analyze with your RapidAPI key:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=css-tricks.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

And when you only need a yes or no, /check answers directly. Note the URL-encoded space in the technology name; the parameter is case insensitive and the response echoes back the canonical name:

curl -s "https://detectzestack.p.rapidapi.com/check?url=css-tricks.com&tech=Site%20Kit" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
  "domain": "css-tricks.com",
  "technology": "Site Kit",
  "detected": true,
  "confidence": 100,
  "version": "1.183.0",
  "categories": ["Analytics", "WordPress plugins"],
  "response_ms": 412,
  "cached": false
}

Scanning Domain Lists with /analyze/batch

Batch is how you work through a list. It accepts up to 10 URLs per request, scans them concurrently, and wraps one result per URL with a per-item error field so a single bad domain does not fail the batch:

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": ["css-tricks.com", "example.com", "wordpress.org"]}' \
  | jq -r '.results[]
      | select(.result.technologies[]?.name == "Site Kit")
      | .result.domain'

Each URL in a batch counts as one request against your monthly quota, so a 10-URL batch costs 10 requests. Batching saves round trips and wall-clock time, not quota. For working through lists in the hundreds or thousands, the batch scanning guide covers pacing, retries, and cost in detail.

Building a Site Kit Prospect List Step by Step

Putting it together: read domains from a file, scan them in batches of 10, keep the Site Kit sites, and write a CSV your CRM can ingest, with the plugin version captured for qualification.

import csv
import requests

API = "https://detectzestack.p.rapidapi.com/analyze/batch"
HEADERS = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
    "Content-Type": "application/json",
}
BATCH_SIZE = 10  # API maximum per request


def scan(domains):
    """Scan up to 10 domains, yielding (domain, technologies, status_code)."""
    resp = requests.post(API, headers=HEADERS, json={"urls": domains}, timeout=60)
    resp.raise_for_status()
    for item in resp.json()["results"]:
        result = item.get("result")
        if not result:
            print(f"  skipped {item['url']}: {item.get('error', 'no result')}")
            continue
        status = result.get("meta", {}).get("status_code")
        yield result["domain"], result.get("technologies", []), status


def main():
    with open("domains.txt") as f:
        domains = [line.strip() for line in f if line.strip()]

    prospects = []
    for i in range(0, len(domains), BATCH_SIZE):
        chunk = domains[i:i + BATCH_SIZE]
        print(f"Scanning {i + 1}-{i + len(chunk)} of {len(domains)}...")
        for domain, techs, status in scan(chunk):
            if status != 200:
                # No page HTML means no generator tag to inspect.
                print(f"  {domain}: status {status}, inconclusive")
                continue
            site_kit = next((t for t in techs if t["name"] == "Site Kit"), None)
            if site_kit:
                names = [t["name"] for t in techs]
                prospects.append({
                    "domain": domain,
                    "site_kit_version": site_kit.get("version", ""),
                    "google_analytics": "Google Analytics" in names,
                    "stack": ", ".join(names),
                })
                print(f"  {domain}: Site Kit {site_kit.get('version', '')}")

    with open("site_kit_prospects.csv", "w", newline="") as f:
        writer = csv.DictWriter(
            f,
            fieldnames=["domain", "site_kit_version", "google_analytics", "stack"],
        )
        writer.writeheader()
        writer.writerows(prospects)

    print(f"\n{len(prospects)} Site Kit sites out of {len(domains)} domains.")


if __name__ == "__main__":
    main()

The site_kit_version column is the qualification lever. Sort by it: sites on a current build are actively maintained and buy growth services; sites several releases behind are maintenance and care-plan leads. Pair the list with the Elementor detection guide if you sell into page-builder sites specifically, since the same scan reports both plugins at once.

Site Kit Detection vs Manual Inspection

The API's real advantage over manual inspection is not speed alone; it is that every scan returns the whole stack. Confirming Site Kit by hand tells you Site Kit is there. The same API call also tells you the site runs WordPress on Cloudflare with Jetpack and Google Analytics, which is the difference between a domain name and a lead. For the platform-level version of this list, the finding companies using WordPress guide applies the same mechanics one layer down.

Get Started with the DetectZeStack API

Plans are the standard DetectZeStack tiers, and every URL scanned counts as one request:

Results are cached for 24 hours by default, and a cache hit comes back with "cached": true. The free plan's 100 monthly requests are enough to validate the whole pipeline on a real slice of your target list before paying anything.

Conclusion

Site Kit is a quietly excellent prospecting signal: it proves WordPress, it proves an engaged site owner, and it hands you a version number that separates maintained sites from neglected ones. Detection is a single generator tag, which means one API call settles it, and the same call returns the rest of the stack as context. Start with /demo on a site you know, move to /check for booleans and /analyze/batch for lists, and keep the status_code guard in every pipeline you build.