How to Find Out What Technology a Website Is Built With (2026 Guide)
Five reliable ways to identify any website's tech stack — from CMS and JavaScript framework to hosting, CDN and analytics — plus how detection tools actually work and how accurate they are.
Want to know what powers a website — its CMS, JavaScript framework, hosting provider, CDN, and analytics? You can find out in under a minute. The fastest route is an automated detector such as StackOptic, but understanding the underlying signals lets you verify results and read sites that try to hide their stack.
A website's "technology stack" is the full set of software it runs on: the content management system or framework that builds the pages, the server and hosting provider that deliver them, the CDN that caches them, and the third-party scripts — analytics, marketing, payment, support — layered on top. Every one of these leaves traces in the data a site sends to your browser.
Why identify a website's tech stack?
Knowing what a site is built with is useful well beyond curiosity:
- Competitive research — see which platforms and tools rivals rely on before you commit to your own.
- Lead generation and sales — qualify prospects by the technology they already use (for example, every Shopify store is a candidate for a Shopify app).
- Security and due diligence — outdated CMS versions and known-vulnerable plugins are a primary attack surface; spotting them early matters.
- Procurement and migration — estimate the effort to rebuild or migrate a site by understanding its current architecture.
- Hiring and learning — discover the real-world stacks behind sites you admire.
According to the HTTP Archive Web Almanac, the median web page now loads dozens of third-party resources, so most sites expose a rich, readable footprint.
Method 1: Read the page source and meta tags
The single fastest manual check is the HTML source. Right-click any page and choose View Page Source (or press Ctrl/Cmd + U), then scan the <head>.
The most revealing line is the generator meta tag:
<meta name="generator" content="WordPress 6.7" />
This tag is emitted by most content management systems and static-site generators — WordPress, Drupal, Joomla, Hugo, Wix and more — and often includes the exact version. Because W3Techs reports that WordPress powers approximately 43% of all websites and runs on about 62% of all sites whose CMS is known, a generator check resolves the majority of the web on the first look.
Other source-level tells include predictable asset paths and inline markers:
| Signal in the HTML | Likely technology |
|---|---|
/wp-content/, /wp-includes/ | WordPress |
cdn.shopify.com, Shopify.theme | Shopify |
__NEXT_DATA__, /_next/static/ | Next.js (React) |
window.__NUXT__, /_nuxt/ | Nuxt (Vue) |
data-reactroot, React DevTools hook | React |
ng-version attribute | Angular |
/sites/default/files/ | Drupal |
Method 2: Inspect HTTP response headers
Open your browser's developer tools (F12), go to the Network tab, reload the page, and click the first (document) request. The Response Headers frequently name the server software and platform directly:
Server: nginx
X-Powered-By: PHP/8.2
X-Generator: Drupal 10
X-Shopify-Stage: production
Headers are the most authoritative manual signal because they come from the server itself rather than from page markup that a theme could fake. Useful ones include Server, X-Powered-By, X-Generator, X-Drupal-Cache, and platform-specific headers. CDNs leave their own fingerprints — cf-ray and Server: cloudflare indicate Cloudflare, x-vercel-id indicates Vercel, and x-amz-cf-id points to Amazon CloudFront.
A practical caveat: security-conscious sites strip X-Powered-By and rewrite Server precisely to avoid leaking this information, and a CDN in front of the origin can overwrite these values. Absence of a header is not proof of absence of a technology.
Method 3: Fingerprint JavaScript and CSS assets
When markup and headers are sparse, the resources a page loads give it away. In the Network tab, filter by JS and CSS and read the file names and source domains:
- Bundle and chunk names —
react-dom.production.min.js,vue.runtime.global.js, or hashed Webpack/Vite chunks reveal the framework and build tooling. - Global variables — typing
window.React,window.Vue,window.jQuery, orwindow.angularinto the console returns a version or object when that library is present. - CSS conventions — utility classes like
flex items-center gap-2strongly suggest Tailwind CSS;MuiButton-rootindicates Material UI. - Resource domains — requests to
googletagmanager.com,js.stripe.com,static.hsappstatic.net(HubSpot) orwidget.intercom.ioexpose analytics, payment and support tooling.
This asset-level fingerprinting is exactly how automated tools detect the parts of a stack that never appear in the HTML source.
Method 4: Check DNS, WHOIS, and hosting signals
The infrastructure layer is identified outside the browser. A DNS lookup and a WHOIS query on the domain and its IP address reveal:
- Hosting provider / cloud — the IP's owning organisation (AWS, Google Cloud, Hetzner, DigitalOcean) via reverse DNS and IP-range databases.
- CDN and DNS provider —
CNAMEandNSrecords pointing at Cloudflare, Akamai, Fastly or Amazon Route 53. - Mail platform —
MXrecords that name Google Workspace, Microsoft 365, or Zoho, plusSPF/DKIM/DMARCTXTrecords that reveal the email-sending stack.
These signals are durable: they survive front-end redesigns and are hard to fake, which makes them valuable for confirming a hosting or infrastructure guess.
Method 5: Use an automated detection tool
Manual inspection is precise but slow. Automated detectors do all of the above in one pass and add signature databases no human can memorise. As the StackOptic Research Team puts it: "Every layer a website ships — markup, headers, scripts and DNS — is a fingerprint. The job of a detector is simply to read all of them at once and match them against what's known."
A detector requests the page like a real browser, then matches the HTML, headers, cookies, JavaScript globals and network requests against thousands of known signatures. Each signature maps a pattern to a technology and a confidence weight; when enough match, the tool reports the technology. Leading options include:
- StackOptic — analyses the full stack plus Core Web Vitals, security headers, SEO and AI/GEO readiness in one report, free and with no sign-up.
- Wappalyzer — a long-standing browser extension and API focused on stack detection.
- BuiltWith — strong on historical and market-share data across millions of domains.
The advantage of an all-in-one platform is breadth: instead of a list of technologies you get the stack and the performance, security and SEO context around it, so the detection result is immediately actionable.
How accurate is technology detection?
Detection is highly reliable for technologies that announce themselves — CMS platforms, analytics scripts, payment widgets and CDNs are correctly identified the overwhelming majority of the time. Accuracy drops for:
- Server-side and statically rendered frameworks, which can ship clean HTML with no runtime markers.
- Custom or in-house software that matches no public signature.
- Sites behind reverse proxies and CDNs, which can overwrite origin headers.
- Versioned detection, since exact version numbers are often deliberately hidden.
The professional standard is simple: cross-check at least two independent signals before you trust a result. A generator tag confirmed by a matching header and a matching asset path is far more reliable than any one of those alone.
Step-by-step: identify any site's stack in under a minute
- Run the URL through a detector (such as StackOptic) for an instant baseline of the full stack.
- View the page source and find the
<meta name="generator">tag and any/wp-content/,/_next/orcdn.shopify.compaths. - Open the Network tab, reload, and read the document's response headers for
Server,X-Powered-Byand CDN markers. - Filter Network by JS/CSS and note framework bundles, global variables and third-party resource domains.
- Cross-check infrastructure with a DNS/WHOIS lookup for hosting, CDN and mail platform.
- Confirm with two signals before relying on any single finding.
Follow that sequence and you will read almost any website's architecture quickly and confidently — and know when a result deserves a second look.
Common pitfalls that lead to wrong conclusions
A few traps catch people out repeatedly, so they are worth naming:
- Mistaking a shared library for the framework. jQuery or a polyfill in the bundle does not make a site "a jQuery site" — plenty of React, Vue and server-rendered pages still ship small helper libraries alongside their real framework.
- Trusting a cached snapshot. A heavily cached or statically exported page can show asset paths from a build step rather than the live runtime, making a dynamic CMS look like a hand-built static site.
- Letting the CDN stand in for the stack. Seeing Cloudflare in the headers describes the edge, not the framework or the origin host behind it — different layers, different answers.
- Over-reading a single clue. One meta tag or one header is a hypothesis, not a verdict; themes and proxies can add or remove almost any individual signal.
The remedy is always the same: corroborate. A finding backed by two unrelated signals — a generator tag and a matching asset path and a cookie — is far more trustworthy than any one clue alone, and it is exactly what a good automated detector does before assigning a confidence score.
Go deeper
Once you know the broad stack, the next questions are usually about specific layers. Two follow-up guides drill in:
- How to tell if a website is built with WordPress — confirm the CMS and uncover its theme and plugins.
- How to find out where a website is hosted — trace the hosting provider, CDN and origin server.
Ready to try it? Analyse any website with StackOptic and get the full technology stack, performance, security and SEO report in seconds.
Frequently asked questions
What is the easiest way to find out what technology a website uses?
The easiest way is to run the URL through an automated technology detector such as StackOptic, Wappalyzer or BuiltWith. These tools fetch the page, headers and network requests, match them against thousands of fingerprint signatures, and return the CMS, framework, hosting provider, CDN, analytics and more in a single report — no manual inspection required.
Can you tell what CMS a website is using for free?
Yes. Most websites reveal their CMS through the <meta name="generator"> tag in the HTML source, predictable asset paths (for example /wp-content/ for WordPress or cdn.shopify.com for Shopify), and HTTP headers. Free tools surface all of these at once. Because WordPress powers roughly 43% of the web, a CMS check resolves the majority of sites instantly.
How do technology detection tools actually work?
Detection tools request the page like a browser, then look for known patterns: HTML markers, meta tags, JavaScript variables and bundle names, CSS class conventions, cookie names, HTTP response headers and the domains a page loads resources from. Each pattern is a 'signature' mapped to a technology; when enough signatures match, the tool reports that technology with a confidence level.
Why can't you always detect a website's framework?
Server-side rendering, static-site generation and aggressive build tooling can strip the runtime fingerprints a detector relies on. A site built with Next.js, for example, may ship pre-rendered HTML with no obvious React markers. Reverse proxies and CDNs such as Cloudflare can also overwrite the Server header, hiding the origin stack. In these cases analysts combine asset hashes, build-id patterns and subtle header tells to infer the framework.
Is it legal to check what technology a website is built with?
Yes. Technology detection only reads information a website already sends to every visitor — the public HTML, response headers and the resources the page loads. It does not access private data or bypass authentication. It is the same information your browser receives when you open the page.
Analyse any website with StackOptic
Get the full technology stack, performance, security and SEO report in seconds — free.
Analyse a websiteRelated articles
How to Tell If a Website Uses Heap
Heap (Heap Analytics) autocaptures product events. Detect it via the cdn.heapanalytics.com script, the global heap object, heapanalytics.com beacons and _hp2 cookies.
How to Tell If a Website Uses Foundation
Foundation (by Zurb) is a responsive front-end framework. Detect it via its grid classes (row/columns, grid-x/cell), data-* component attributes and the foundation.css/js files.
How to Tell If a Website Uses Crisp
Crisp is a developer-friendly, affordable live-chat and messaging tool. Detect it via the client.crisp.chat/l.js script, the window.$crisp object and the CRISP_WEBSITE_ID value.