How to Detect a Wix Website: Signatures + API Guide

Wix is one of the largest hosted website builders in the world, powering everything from restaurant landing pages to small-business storefronts. Because Wix hosts and serves every site it publishes, it leaves a consistent set of fingerprints on every page—which makes “is this site built on Wix?” one of the easier platform questions to answer definitively, once you know where to look.

This guide walks through the three layers where Wix reveals itself—HTTP headers, HTML and JavaScript markers, and DNS—then shows how to automate the check with a single API call so you can scan a whole list of domains.

Why Detect if a Website Is Built on Wix

Knowing a site runs on Wix is useful well beyond curiosity:

• Lead qualification. Agencies and SaaS products that sell to small businesses use “built on Wix” as a proxy for company size and technical sophistication. A Wix site usually means a small team without a dedicated developer—exactly the profile some products target and others deliberately avoid.
• Competitive research. Studying which site builder a market segment defaults to (Wix vs Squarespace vs self-hosted WordPress) tells you a lot about buyer behavior in that vertical.
• Migration and sales prospecting. Web design agencies and hosting companies prospect for Wix sites specifically because those owners are candidates for a redesign or a move to a more flexible stack.
• Platform capability limits. If you are integrating with a partner or vendor, knowing they are on Wix tells you what is and is not possible—custom server-side code, for instance, is constrained on the platform.

Whatever the reason, the detection methods are the same. Let us start with the most reliable signal.

Wix HTTP Header and Server Signatures

The single most dependable way to identify a Wix site is its HTTP response headers. Wix’s server-side rendering layer stamps every published page with a family of x-wix-* headers. Because they are added by the platform’s infrastructure rather than by the site owner, they are present on every Wix site and are not something a non-technical owner can turn off.

The X-Wix-Request-Id and Wix Server Headers

Run a headers-only request with curl -I and grep for the Wix family:

$ curl -sI https://www.wix.com | grep -i "x-wix"
x-wix-request-id: 1720512000.123456789012345
x-wix-renderer-server: prod
x-wix-server-artifact-id: wix-thunderbolt

Three headers do the heavy lifting:

• x-wix-request-id — A per-request trace identifier present on essentially every Wix response. This is the strongest single signal. If you see it, the site is served by Wix.
• x-wix-renderer-server — Identifies the Wix rendering tier that produced the page.
• x-wix-server-artifact-id — Names the internal Wix serving artifact (you will often see values referencing Wix’s “thunderbolt” rendering system).

The advantage of header detection is that it does not require downloading or parsing the full page body—a lightweight HEAD request is enough. The one caveat is that a site placed behind a separate reverse proxy or CDN could, in principle, strip these headers. In practice that is rare for Wix sites, because most Wix owners use the platform end to end. When headers are inconclusive, the HTML markers below fill the gap.

HTML and JavaScript Markers That Reveal Wix

Even if headers were somehow stripped, the page body itself is saturated with Wix fingerprints. These live in the HTML source and load with every published Wix site.

The static.parastorage.com and Parastorage Fingerprints

Wix serves its application code and framework bundles from a dedicated static host, static.parastorage.com. Every Wix site loads scripts from this domain, so a single search of the page source confirms the platform:

$ curl -s https://www.wix.com | grep -o "static\.parastorage\.com" | head -1
static.parastorage.com

$ curl -s https://www.wix.com | grep -i 'meta name="generator"'
<meta name="generator" content="Wix.com Website Builder">

The markers to search for in the HTML:

• static.parastorage.com — The script host for Wix’s own code bundles. Appears in <script src> tags on every Wix page.
• The generator meta tag — <meta name="generator" content="Wix.com Website Builder"> is emitted by the platform and is an unambiguous declaration.
• static.wixstatic.com — Wix’s media CDN, which serves images and other assets. You will see it referenced throughout the markup for a typical Wix page.
• JavaScript globals — Wix’s runtime defines objects such as wixBiSession and wixPerformanceMeasurements on the page. These are visible if you inspect the rendered page in a browser console, though for server-side detection the header and script-host signals are simpler.

Wix DNS Signatures for Custom Domains

Wix sites published on a free *.wixsite.com subdomain are obvious from the URL alone. When an owner connects a custom domain, the DNS configuration still gives Wix away. Wix-hosted custom domains commonly resolve through Wix’s own DNS infrastructure:

$ dig www.example.com CNAME +short
example.wixdns.net.

A CNAME target ending in .wixdns.net is a Wix signal at the DNS layer—useful because it works even when you cannot fetch the page (for example, if the origin blocks automated HTTP requests). DNS-based detection catches the platform before a single byte of HTML is downloaded. For the broader mechanics of this approach, see DNS-based technology detection.

Detect Wix at Scale With the DetectZeStack API

Running curl and dig by hand is fine for one domain. It does not scale to hundreds. The DetectZeStack API combines all three layers—HTTP headers, HTML markers, and DNS—into one request and returns a normalized JSON result, so you never have to write the grep-and-parse logic yourself.

Single-URL curl Example

You can try it right now with no API key against the free /demo endpoint:

$ curl -s "https://detectzestack.com/demo?url=wix.com" | jq '.'
{
  "url": "https://wix.com",
  "domain": "wix.com",
  "technologies": [
    {
      "name": "Wix",
      "categories": ["CMS", "Blogs"],
      "confidence": 100,
      "description": "Wix provides cloud-based web development services, allowing users to create HTML5 websites and mobile sites.",
      "website": "https://www.wix.com",
      "icon": "Wix.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    },
    {
      "name": "React",
      "categories": ["JavaScript frameworks"],
      "confidence": 100,
      "description": "React is an open-source JavaScript library for building user interfaces.",
      "website": "https://reactjs.org",
      "icon": "React.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": { "CMS": ["Wix"], "JavaScript frameworks": ["React"] },
  "meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1043
}

The source field tells you which layer caught Wix: http for the header and HTML markers, dns when the confirmation came from a *.wixdns.net CNAME. A result with "name": "Wix" at confidence: 100 is a definitive match.

To pull just the Wix verdict out of the response, filter with jq:

$ curl -s "https://detectzestack.com/demo?url=wix.com" | \
  jq '.technologies[] | select(.name == "Wix") | {name, source, confidence}'
{
  "name": "Wix",
  "source": "http",
  "confidence": 100
}

For production use with higher rate limits, call the RapidAPI-hosted /analyze endpoint with your key. The response shape is identical to /demo:

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

Batch Scanning Many Domains

The real payoff is checking a list. Say you have a file of prospect domains and you want to keep only the ones built on Wix. A short bash loop does it, recording the detection source per row so you can see whether the match came from HTTP or DNS:

$ cat domains.txt
somebusiness.com
anothersite.com
example.com

$ while read domain; do
    result=$(curl -s "https://detectzestack.p.rapidapi.com/analyze?url=$domain" \
      -H "X-RapidAPI-Key: YOUR_KEY" \
      -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com")
    wix=$(echo "$result" | jq -r '.technologies[] | select(.name == "Wix") | .source')
    if [ -n "$wix" ]; then
      echo "$domain,Wix,$wix"
    fi
  done < domains.txt
somebusiness.com,Wix,http
anothersite.com,Wix,dns

The output is a clean CSV of confirmed Wix sites and the layer that confirmed each one. Deduplicate it, enrich it with the rest of the detected stack, and you have a targeted lead list. For a more robust pipeline with rate-limit handling and retries, see how to batch scan 1,000 websites, and for turning platform detection into a full prospect list, find companies using a given platform walks through the same pattern applied to WordPress.

Wix vs Other Site Builders and CMS Platforms

Wix is one of several hosted builders and content management systems you will run into when scanning a market. Each leaves a distinct fingerprint, and the same detection approach—headers, HTML markers, DNS—applies to all of them. Here is how the most common ones compare:

The takeaway: Wix is on the easier end of the spectrum because its x-wix-request-id header is a single, unambiguous tell. Platforms like WordPress require checking multiple weaker signals together, which is exactly why an API that evaluates every layer in one pass is more reliable than any single manual check. If you are trying to identify the platform generically rather than confirming a specific one, how to detect what CMS a website uses covers the decision tree across all of these.

Conclusion

Detecting Wix comes down to three layers of evidence. The x-wix-request-id HTTP header is the fastest and most reliable confirmation. The static.parastorage.com script host and the Wix.com Website Builder generator meta tag corroborate it in the HTML. And for custom domains, a *.wixdns.net CNAME confirms Wix at the DNS layer even when you cannot fetch the page. For a single site, curl and dig get you there in seconds. For a whole list, the DetectZeStack API rolls all three checks into one call and returns a clean, filterable result—so you can go from a raw domain list to a confirmed Wix lead list without writing any parsing logic.