How to Detect Vercel on Any Website

Vercel is one of the most recognizable hosting platforms on the modern web. It is the company behind Next.js, and it powers a large share of the React and Jamstack sites shipped in the last few years. Knowing whether a site runs on Vercel is a useful signal: it tells you something about the team's tooling, their deployment model, and—more often than not—the front-end framework sitting on top of it.

The good news is that Vercel is unusually easy to fingerprint. It leaves clear evidence in HTTP response headers, in DNS records, and in the TLS handshake. This guide walks through each of those signals, shows you how to spot them by hand, and then shows how a single DetectZeStack API call returns Vercel—along with the Next.js and React stack it usually hosts—in clean JSON you can run at scale.

What Is Vercel and Why Detect It

Vercel is a cloud platform for static front ends and serverless functions. A developer connects a Git repository, and Vercel builds the project, deploys it to a global edge network, and serves it with automatic HTTPS and preview deployments for every branch. It is a Platform-as-a-Service (PaaS) in the same family as Netlify, Cloudflare Pages, and Render—you push code, the platform handles the infrastructure.

A confirmed Vercel detection is a compact but informative data point:

• It signals a modern, Git-driven deployment stack. Teams on Vercel almost always ship from a framework build—Next.js, SvelteKit, Nuxt, Astro, Remix—rather than hand-maintained servers. That shapes what else you will find on the page and how the team likely works.
• It frequently travels with Next.js. Vercel maintains Next.js and is the default place to host it, so a Vercel detection is a strong prior for a React and Next.js front end. It is a prior, not a guarantee—which is exactly why a full scan is worth running.
• It is a technographic qualifier. For sales teams selling developer tooling, observability, or edge services, “hosts on Vercel” is a clean segment. For competitive research, it maps which companies in a market have adopted the serverless-edge model.

The same detection pipeline applies to any platform DetectZeStack recognizes. We have companion guides for detecting AWS hosting and Google Cloud—the fingerprints change, the workflow stays the same.

Signals That Reveal a Site Runs on Vercel

Vercel is detectable from three independent layers, and each one is useful in a different situation. HTTP headers are the loudest and most specific signal. DNS is the one that cannot be stripped. TLS is a weak corroborator. Together they make Vercel one of the more reliable hosting fingerprints out there.

HTTP Headers, DNS, and TLS Fingerprints

HTTP response headers are the primary Vercel signal. Every response served by Vercel's edge network carries a small set of identifying headers:

• server: Vercel — The clearest tell. Vercel identifies itself directly in the Server header. Older deployments may still show server: now, a holdover from the platform's original name (Now).
• x-vercel-id — Present on every Vercel response. It encodes the edge region and a request identifier (for example, iad1::abc123-1700000000000-def456), which also tells you which Vercel PoP served the request.
• x-vercel-cache — Reports the edge cache outcome: HIT, MISS, STALE, PRERENDER, or BYPASS.
• x-now-trace — A tracing header still emitted on some responses, another artifact of the platform's Now-era naming.

Any one of these confirms Vercel. They are also easy to check by hand, which we do below.

DNS records are the fingerprint that cannot be hidden. When a company points a custom domain at Vercel, they create a CNAME record aimed at Vercel's DNS infrastructure. The canonical target is cname.vercel-dns.com, and Vercel also routes newer domains through numbered shards such as vercel-dns-016.com. These records are public, always available, and cannot be removed without moving the domain off Vercel—so DNS is the layer that catches a Vercel site even when someone has stripped or rewritten the response headers.

TLS certificates are a weaker corroborator. Vercel provisions certificates automatically through Let's Encrypt, so a Vercel-hosted domain typically presents a Let's Encrypt issuer in the TLS handshake. On its own that proves nothing—countless platforms use Let's Encrypt—but combined with the header and DNS signals it is one more consistent data point.

Detect Vercel Manually in Your Browser

You can confirm every one of these signals yourself with tools you already have. Start with the headers—a single curl -I is the fastest check:

$ curl -sI https://vercel.com | grep -i "server\|x-vercel"
server: Vercel
x-vercel-cache: HIT
x-vercel-id: iad1::abc123-1700000000000-def456

That server: Vercel line is all you need. If the site rewrites its Server header, the x-vercel-id and x-vercel-cache headers usually survive, so widen the grep to catch them. In a browser you can see the same thing without the terminal: open DevTools, go to the Network tab, reload the page, click the top document request, and read the Response Headers panel.

Next, confirm it from the DNS layer, which is harder to fake:

$ dig vercel-hosted-example.com CNAME +short
cname.vercel-dns.com.

A CNAME pointing at cname.vercel-dns.com (or a numbered vercel-dns-0NN.com shard) confirms the domain is served by Vercel, independent of whatever the HTTP headers say. Note that an apex domain often uses an A record to a Vercel anycast IP rather than a CNAME, so the CNAME check is most reliable on the www or a subdomain.

Manual checks are perfect for a one-off answer. They stop scaling the moment you have a list. Headers require a live request per domain, DNS requires parsing the CNAME chain, and doing this across hundreds of sites means writing your own concurrency, retry, and timeout handling—plus reconciling the header signal against the DNS signal yourself. That is the gap a detection API closes.

Detect Vercel Programmatically with the DetectZeStack API

When DetectZeStack analyzes a page, it checks all three layers at once. It fingerprints the Vercel response headers, resolves the domain's DNS CNAME against a set of hosting signatures, and inspects the TLS certificate—then merges the results into one technology list. Vercel comes back under the PaaS category.

Live curl Example

You can 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. Here we filter the response down to just the Vercel entry:

$ curl -s "https://detectzestack.com/demo?url=vercel.com" \
  | jq '.technologies[] | select(.name == "Vercel")'
{
  "name": "Vercel",
  "categories": ["PaaS"],
  "confidence": 100,
  "description": "Vercel is a cloud platform for static frontends and serverless functions.",
  "website": "https://vercel.com",
  "icon": "vercel.svg",
  "source": "http",
  "version": "",
  "cpe": ""
}

Vercel is matched off its response headers, so it comes back with source: "http" at confidence: 100—an unambiguous header match. The version and cpe fields are empty because Vercel is a hosting platform, not a versioned software package with a CPE identifier. When the headers are stripped but the domain still points at cname.vercel-dns.com, the same detection arrives from the DNS layer instead, reported as source: "dns" at confidence: 80. Either way you learn the same fact—the two layers back each other up.

For the full stack on a domain rather than a filtered slice, call /analyze with your API key. Because Vercel so often hosts Next.js, a typical scan fans out into several related detections in one pass:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=nextjs.org" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
  "url": "https://nextjs.org",
  "domain": "nextjs.org",
  "technologies": [
    {
      "name": "Next.js",
      "categories": ["JavaScript frameworks", "Web frameworks"],
      "confidence": 100,
      "description": "Next.js is a React framework for developing single page Javascript applications.",
      "website": "https://nextjs.org",
      "icon": "Next.js.svg",
      "source": "http",
      "version": "",
      "cpe": "cpe:2.3:a:zeit:next.js:*:*:*:*:*:*:*:*"
    },
    {
      "name": "React",
      "categories": ["JavaScript frameworks"],
      "confidence": 100,
      "description": "React is an open-source JavaScript library for building user interfaces or UI components.",
      "website": "https://reactjs.org",
      "icon": "React.svg",
      "source": "http",
      "version": "",
      "cpe": "cpe:2.3:a:facebook:react:*:*:*:*:*:*:*:*"
    },
    {
      "name": "Vercel",
      "categories": ["PaaS"],
      "confidence": 100,
      "description": "Vercel is a cloud platform for static frontends and serverless functions.",
      "website": "https://vercel.com",
      "icon": "vercel.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": {
    "JavaScript frameworks": ["Next.js", "React"],
    "Web frameworks": ["Next.js"],
    "PaaS": ["Vercel"]
  },
  "meta": { "status_code": 200, "tech_count": 3, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

One page, three detections. Vercel is the hosting platform; Next.js is the framework running on it; React arrives by implication because Next.js is built on it. The top-level categories map groups every detection, so you can pull all hosting platforms with .categories["PaaS"] 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.

One field matters for list building: meta.scan_depth. A value of "full" means the HTTP fetch succeeded and header fingerprinting ran, so a missing Vercel entry is a real negative. A value of "partial" means the site blocked or timed out the HTTP request and only the DNS and TLS layers completed—on a "partial" scan, Vercel can still surface from the cname.vercel-dns.com DNS record, which is exactly why the DNS layer earns its keep. Domains that come back "partial" with no detection belong in a retry queue, not your rejects file.

Vercel, Next.js, and the Rest of the Stack

It is tempting to treat “Vercel” and “Next.js” as the same detection. They are not, and keeping them separate is where the real value is. Vercel is a hosting platform; Next.js is a front-end framework. Vercel makes Next.js and is the most common place to run it, which is why they show up together so often—but the relationship runs one way, not both.

• Vercel without Next.js is common. Vercel happily hosts SvelteKit, Nuxt, Astro, Remix, plain static HTML, and more. A Vercel detection with no Next.js entry means the team chose the platform but a different framework—itself a useful distinction.
• Next.js without Vercel is common too. Next.js is open source and runs anywhere Node.js runs: AWS, Google Cloud, a self-managed server, Netlify, Cloudflare. A Next.js detection with no Vercel entry tells you they use the framework but host it elsewhere.
• Both together is the default path. When you see Vercel and Next.js in the same scan—plus React by implication—you are looking at a team that adopted the full first-party stack.

Because DetectZeStack reports each of these as its own entry in the technologies array, you can segment on exactly the combination you care about. Filter for Vercel to find the hosting platform, filter for Next.js to find the framework, or require both to find the teams that went all-in. For the framework side of this pairing, see how to detect if a website uses Next.js, and for turning that framework signal into a prospect list, find companies using Next.js.

Common Use Cases for Vercel Detection

Once you can detect Vercel reliably, a handful of practical workflows open up:

• Technographic prospecting. If you sell developer tooling, edge functions, observability, or a database that pairs well with serverless, “hosts on Vercel” is a high-intent segment. Scan a domain list, keep the Vercel hits, and route them to the right play.
• Competitive and market mapping. Scanning the sites in a category shows you how far the serverless-edge model has spread—who is on Vercel, who is on a traditional CDN and origin setup, and who is on a hyperscaler like AWS or Google Cloud.
• Lead enrichment. Add a “hosting platform” field to records you already have. A Vercel tag alongside the framework and language gives sales and marketing a sharper picture of each account's stack.
• Migration and adoption tracking. Re-scan the same domains over time and watch the Vercel signal appear or disappear. A site that gains a server: Vercel header just migrated onto the platform—a timely trigger for outreach.

All four run on the same primitive: one /analyze call per domain, filtered for the Vercel entry. Scale it with POST /analyze/batch, which accepts up to 10 URLs per request and returns one result object per URL in the same shape as a single analysis—so the filtering logic is identical whether you scan one domain or a thousand. For a production batch pipeline with retries and throughput tuning, see how to batch scan 1,000 websites.

Get Your API Key and Start Detecting Vercel

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

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

Conclusion

Detecting Vercel comes down to reading three layers well. The server: Vercel, x-vercel-id, and x-vercel-cache response headers are the loudest signal and confirm Vercel at a glance. The cname.vercel-dns.com DNS record is the signal that survives when headers are stripped. The Let's Encrypt certificate is a quiet corroborator. A single DetectZeStack /analyze call checks all three and returns Vercel under PaaS—usually alongside the Next.js and React stack it hosts—so you can tell not just that a site runs on Vercel, but what it is running there. Swap the jq filter and the same pipeline segments by framework, hosting platform, or backend runtime instead.