How to Detect What Technologies a Website Uses

Knowing what a site runs on is useful for competitive research, sales qualification, security review, and debugging. The trick is doing it with evidence rather than a lucky guess. A site that loads jquery.min.js might use jQuery, or it might just ship one legacy plugin that does. Strong detection combines multiple independent signals and reports which one fired. You can run exactly that at /#tool, where each detected technology is listed next to the evidence that identified it.

Six evidence sources, ranked by reliability

Detection tools look at the same surfaces in roughly the same order. Understanding them lets you verify any result by hand.

1. HTTP response headers

The response headers are the least ambiguous signal because the server or its infrastructure writes them. A Server header of nginx, Apache, LiteSpeed, or Microsoft-IIS identifies the web server. X-Powered-By often reveals the application runtime, such as PHP/8.2.1 or Express. X-Generator and X-Drupal-Cache are explicit.

Headers are also where CDNs announce themselves. Cloudflare typically sends cf-ray and cf-cache-status; Fastly sends x-served-by and x-cache; CloudFront sends x-amz-cf-id; Vercel sends x-vercel-id; Netlify sends x-nf-request-id. A single cf-ray header is enough to say Cloudflare is in front of the origin, regardless of what the HTML contains.

2. Cookie names

Cookie names leak framework identity through their defaults. PHPSESSID implies PHP. JSESSIONID implies a Java servlet container. ASP.NET_SessionId implies ASP.NET. _rails_session or a name ending in _session_id suggests Ruby on Rails. laravel_session points at Laravel. These names come from framework defaults that developers rarely rename, so they are a strong secondary signal.

3. Generator meta tags

Some platforms volunteer their identity:

<meta name="generator" content="WordPress 6.5">
<meta name="generator" content="Joomla! - Open Source Content Management">
<meta name="generator" content="Ghost 5.8">
<meta name="generator" content="Hugo 0.126.0">
<meta name="generator" content="Drupal 10 (https://www.drupal.org)">

When present, a generator tag is close to definitive. Static site generators such as Hugo and Jekyll and CMS platforms such as WordPress, Joomla, and Ghost all emit one by default. It can be removed, but many sites leave it in place.

4. HTML markup patterns

Frameworks stamp the DOM with identifiers that survive minification. Examples:

• Next.js: a <script id="__NEXT_DATA__" type="application/json"> block, or a root element with id="__next".
• React: data-reactroot on the mount node, or the __REACT_DEVTOOLS_GLOBAL_HOOK__ global.
• Vue: scoped-style attributes matching data-v- followed by eight hex characters.
• Nuxt: a window.__NUXT__ payload and URLs under /_nuxt/.
• Svelte: generated class names of the form svelte- plus a short hash.
• Angular: an ng-version attribute on the app root.
• Astro: astro-island custom elements or data-astro-cid- attributes.

These are structural and hard to fake accidentally, because they are produced by the build tool rather than written by a developer.

5. Asset URL paths

The paths of scripts and stylesheets are a fingerprint. This is the single most productive signal for CMS detection:

• wp-content/uploads/..., wp-includes/js/...: WordPress.
• cdn.shopify.com/... plus a Shopify.theme object: Shopify.
• static1.squarespace.com/...: Squarespace.
• static.wixstatic.com/...: Wix.
• /assets/... served from a versioned, hashed build folder can indicate a modern bundler, though the pattern alone is weak.

6. Third-party script domains

Every analytics, chat, payment, and support tool loads from a recognizable host. googletagmanager.com is Google Tag Manager, connect.facebook.net is the Meta Pixel, js.stripe.com is Stripe, widget.intercom.io is Intercom, browser.sentry-cdn.com is Sentry, and static.cloudflareinsights.com is Cloudflare’s analytics beacon. These are trivially reliable because the vendor’s own domain is in the URL.

Worked examples

“What CMS does this site use?” — a WordPress check

Suppose the source contains https://example.com/wp-content/themes/twentytwentyfour/style.css and the response headers include X-Powered-By: PHP/8.2. That is two independent signals: the wp-content path structure and the PHP runtime. A PHPSESSID cookie would make three. Any one alone is suggestive; together they are conclusive enough to report WordPress with PHP.

You can confirm with the generator tag, if the site did not remove it: <meta name="generator" content="WordPress 6.5">.

Detecting Next.js

Look for /_next/static/ in script URLs. Next.js serves its client bundle from that path with content hashes in the filename. The __NEXT_DATA__ JSON script is a second indicator. If the site is hosted on Vercel, an x-vercel-id header adds infrastructure confirmation. All three together describe not just the framework but the deployment platform.

Confirming React

React itself leaves quieter traces than frameworks built on it. Check for data-reactroot or the devtools global. More often, the clearest evidence is a bundle URL containing react-dom.production.min.js or a React reference in inline script. Be cautious: many sites embed a React widget inside an otherwise server-rendered page, so “React” may describe one component, not the whole application.

Spotting Cloudflare

You do not need the HTML at all. A cf-ray header with a value like 84f3...-IAD and a cf-cache-status of HIT identify Cloudflare as the CDN. A server: cloudflare header confirms it. This matters because Cloudflare changes how other results should be read: TTFB may reflect the edge cache, and the origin server header may be hidden behind it.

Why evidence matters more than a label

Black-box detectors that output a bare list of names are hard to trust. Two failure modes are common:

• False positives from leftovers. A site that migrated off WordPress may leave a stray /wp-content/ image or a cached plugin script. Reporting WordPress would be wrong.
• False negatives from minification. A build step can rename classes and inline small scripts, erasing a framework’s fingerprints.

An evidence-backed detector shows the matched string for every result. That lets you judge the signal quality yourself. A technology confirmed by three sources is worth acting on; one matched by a single generic substring deserves a second look. This is the design of the technology detector here: each entry carries the evidence that triggered it, so nothing is presented as an unexplained guess.

Practical workflow

1. Fetch the page and read the response headers first for server, runtime, CDN, and cache information.
2. Search the HTML for <meta name="generator">; this is the fastest CMS answer when present.
3. Scan script and stylesheet URLs for vendor and build-tool paths such as wp-content, _next, _nuxt, cdn.shopify.com, and known third-party domains.
4. Check cookies for framework-default names.
5. Combine at least two signals before writing down a conclusion, and note which source each came from.

The blog index has related deep dives on response headers and source inspection. Run a few sites you already know well through the analyzer as a calibration exercise; when the detected evidence matches what you know to be true, you will trust the tool on the sites you know nothing about.

Takeaway

Pick one competitor’s homepage and identify its CMS using only the generator tag and asset paths, writing down the exact string that gave it away. Then fetch the same URL through the analyzer and compare your evidence list against its output. That one exercise turns a black-box answer into a skill you can apply to any site, including ones no detection database has seen yet.