How Tech Stack Detection Actually Works Under the Hood

You land on a competitor's site or a client's product and the first thing you want to know is: what's this built on? Before you write a single line of integration code, before you estimate a migration, before you write a proposal — you want to detect website technology stack details without burning 30 minutes on research. The answer is usually visible in under a minute if you know what to look at.

Websites leave fingerprints at every layer

HTTP headers, HTML structure, JavaScript globals, cookie names, DNS records, asset URL patterns — each one is a signal. No single signal is definitive, but 4–5 of them together form a reliable technology map.

HTTP response headers reveal the server stack

Response headers are the richest source of server-side tech stack detection signals:

HTML and DOM fingerprints for framework detection

Every major framework leaves predictable traces in the DOM it generates. If you know where to look, the framework is obvious:

• Next.js — __NEXT_DATA__ script tag, _next/static asset paths
• Nuxt — __NUXT__ global, _nuxt/ assets
• WordPress — /wp-content/ in asset URLs, wp-json REST endpoint
• Shopify — Shopify.theme global, cdn.shopify.com assets
• React — __reactFiber or __reactProps on DOM nodes

SSL and DNS signals for finding CMS and hosting

The SSL certificate issuer points to the hosting provider. Let's Encrypt is common on Netlify, Vercel, and self-hosted servers. AWS Certificate Manager means AWS. Cloudflare issues its own certificates for anything sitting behind their CDN.

DNS nameservers are equally specific: *.ns.cloudflare.com, dns1.p01.nsone.net (Heroku), ns*.awsdns-*.com.

How onHover's Site Stack detector works

Open the Site Stack tool and it reads the page's response headers via the background service worker, scans the DOM for framework globals, checks asset URL patterns, and queries DNS records. Results group by category: Hosting, CDN, Framework, CMS, Analytics, and SSL.

It won't get everything right on heavily customized enterprise setups. But for the vast majority of sites you'll encounter — startups, SaaS products, e-commerce stores — it gives you an accurate technology map in under 2 seconds. That's usually enough to answer the question that prompted you to check in the first place.

Why knowing the stack matters before you start

There's a version of this where you just want to satisfy curiosity. But in practice, stack detection is a professional tool with concrete uses.

Before writing integration code, knowing the target stack lets you avoid incompatible library versions before you've written a single line. Integrating with a Next.js 13 app running the App Router is a different task than integrating with a Pages Router setup — and knowing which one in advance saves you from discovering the difference mid-PR.

Before estimating a migration, different stacks have wildly different migration costs. Moving a 200-page WordPress site to Next.js is a 2–3 month project. Moving a 200-page Webflow site to Astro is a few weeks. Stack detection is the first step in any realistic estimate — you can't scope what you don't understand.

When writing a client proposal, the stack shapes what you can recommend. If a client is already on Vercel with Next.js, recommending Gatsby makes no sense. If they're on a shared cPanel host running PHP 7.4, your recommendations look different than if they're on AWS with a containerized stack. Knowing before the discovery call makes you look prepared — because you are.

For competitive intelligence, stack decisions tell a story. A competitor switching from WordPress to Next.js signals they're investing in performance and developer experience. A move from self-hosted to Vercel suggests they're scaling and optimizing for deployment speed. onHover's Site Stack detector gives you this intel in 2 seconds rather than 20 minutes of manual investigation across DevTools, Wappalyzer, and DNS lookup tools.

JavaScript global variables: the richest detection layer

Open your browser console and type window.React on any React site. If it's there, you'll see the React object. Type window.React.version and you'll see the exact version. This is manual detection — and it works, but only if you know which globals to check.

Framework authors expose globals deliberately. React does it for React DevTools. Next.js exposes __NEXT_DATA__ so plugins and error boundaries can read routing and page props. Shopify exposes window.Shopify for theme developers and third-party app integrations. Vue keeps window.Vue accessible. Angular leaves window.angular or its version-specific equivalents.

The problem with doing this manually is you have to already know what you're looking for. You can't check every possible global for every possible framework each time. onHover's Site Stack feature in the Chrome extension systematically checks all known framework globals in one pass — so instead of manually guessing which one to try next, you get a full readout.

Once you find them, you can go deeper. window.React.version tells you whether you're looking at React 17, 18, or 19. window.__NEXT_DATA__.buildId tells you the Next.js build identifier. These details matter when you're debugging a compatibility issue or planning an integration against a specific version.

Cookie names as CMS fingerprints

Cookies are underused as a detection signal. Most people check headers and globals but skip the Application tab entirely. That's a miss.

WordPress writes specific cookie names on login: wordpress_* and wp-settings-* show up even on the frontend if a user is logged into wp-admin. Drupal has its own session cookie patterns. Shopify leaves _shopify_s and _shopify_sa_p for session and attribution. Auth systems are equally specific — next-auth.session-token and __Secure-next-auth.session-token are dead giveaways for NextAuth.js. These cookie fingerprints show up in the Application tab — or in onHover's Site Stack readout — without any network requests needed.

Analytics and marketing stack detection

The analytics and marketing tools a company uses are as revealing as their frontend framework. Each tool leaves a distinct global and often a network request to a recognizable domain.

The ones we check regularly: window.ga (Google Analytics UA — the old version), window.gtag (GA4), window._hsq (HubSpot), window.fbq (Meta Pixel), window.klaviyo, window.Intercom.

Detecting the analytics stack tells you things about a company's maturity that their marketing page won't. A site with HubSpot and Intercom has a growth team that takes pipeline seriously. A site still running UA instead of GA4 has either a low-touch analytics setup or tech debt they haven't gotten to. For sales and BD research, this is genuinely useful context — you walk into a conversation knowing what tools they're invested in before you've said hello.

A/B testing tools are equally revealing. Optimizely, VWO, and LaunchDarkly all leave recognizable globals and fire requests to their respective CDNs. A company running an A/B testing platform is actively experimenting — that tells you something about their culture and their growth stage. onHover's Chrome extension surfaces all of this in the same Site Stack readout, grouped by category, without needing to dig through the Network tab manually.

When detection fails and why

Stack detection isn't magic. There are real limits, and knowing them helps you calibrate how much to trust the results.

Modern bundlers tree-shake aggressively. A React app compiled with certain webpack or esbuild configs may not leave window.React on the global scope at all. Custom framework forks with renamed globals won't match any known pattern. Cloudflare Workers can completely rewrite response headers before they reach the browser — you might see clean generic headers on a site that's actually running a complex origin stack. Bespoke enterprise CMSs built entirely in-house have no public fingerprints to match against. White-labeled Shopify apps sometimes mask their Shopify origin well enough that the usual signals don't appear.

The practical rule we use: treat detection results as strong hints for startups and SMBs, and as uncertain hints for large enterprise. Smaller companies haven't invested in the security engineering effort required to actively obscure their stack. Large enterprises often have. The Site Stack detector in onHover's developer toolkit is excellent for the 80–90% of sites where obfuscation isn't a priority — and for the rest, you at least know to dig deeper rather than assuming the surface-level result is the full picture.

Tech stack detection is a core part of SEO competitive research — how it fits into a broader SEO workflow is covered on the onHover for SEO Specialists page.

Frequently asked questions