The fastest way to find a website’s tech stack: paste the domain into AI Website Detector’s tech stack scanner, which checks HTML markup, HTTP response headers, script origins, CDN fingerprints, and cookies in a few seconds — no signup, no browser extension. For a deeper audit, browser DevTools, DNS records, and a bit of indirect research (job postings, public repos, subprocessor lists) fill in whatever the automated scan can’t see.

A website’s tech stack is the combination of programming languages, frameworks, content management systems (CMS), hosting providers, CDNs, and third-party scripts that determine how a site loads, ranks, and runs. Knowing it matters well beyond curiosity: developers use it to scope a rebuild before quoting a client, sales teams use it for technographic prospecting, and founders use it to confirm an agency actually delivered what they were billed for.

This guide covers every method that actually works — from one-click scanners to manual header inspection, DNS lookups, and the indirect intelligence gathering most tutorials skip entirely.

Table of Contents

What Is a Website Tech Stack?

A website’s tech stack is really five layers stacked on top of each other, and each layer leaves different fingerprints behind:

Layer Examples Where it’s detected
Front-end React, Next.js, Vue, Tailwind CSS Page source, bundle filenames
Back-end Node.js, Python/Django, PHP/Laravel, Ruby on Rails Response headers, error pages
CMS / builder WordPress, Shopify, Webflow, Wix, Framer File paths, meta generator tags
Hosting & CDN Vercel, AWS, Hetzner, Cloudflare, Fastly DNS records, response headers
Third-party tools Google Analytics, HubSpot, Stripe, Intercom Script tags, cookies

Most people asking “what’s this site built with” really mean the first three layers — CMS and framework. A complete audit, the kind you’d hand to a client, covers all five, including hosting and the third-party tools riding on top.

Why Should You Find Out What Tech Stack a Website Uses?

  • Competitive analysis: see what platform and tools a competitor uses to run checkout, track behavior, or optimize speed.
  • B2B technographic sales: target accounts running specific software (e.g., pitching a Shopify app to stores confirmed to be on Shopify).
  • Migration and rebuild scoping: understand what a successful competitor’s stack looks like before choosing your own.
  • Security and vendor audits: flag outdated CMS versions, unpatched plugins, or unencrypted endpoints.
  • SEO and performance diagnosis: a heavy client-side JavaScript app explains poor Core Web Vitals and indexing issues in ways a quick PageSpeed check alone won’t.
  • Vetting a freelancer or agency: confirm whether a “custom build” claim actually holds up, or whether AI tooling was involved. Build Like pairs stack detection with a step-by-step replication guide for exactly this use case.

Method 1: Use an Automated Tech Stack Scanner

The fastest path covers roughly 80–90% of what a full manual audit would find, without opening a single dev tool.

  • Open the scanner. Go to AI Website Detector’s tech stack tool and paste the full domain, including https://.
  • Run the scan. It checks HTML markup, script sources, HTTP headers, CDN domains, meta generator tags, and cookies against a fingerprint database, then returns a categorized breakdown — CMS, framework, hosting, and third-party tools — rather than a single guess.
  • Layer on the AI check. If the site looks templated but the stack alone doesn’t explain why, run it through the AI probability scanner — it fingerprints 80+ AI builders (Framer AI, Lovable, Bolt, Durable) on top of the stack data.
  • Save the result. Scan pages are timestamped and shareable, so the URL itself works as a citable record in an audit report.

Pro tip: Save the scan URL right after a successful detection. The result page carries the full artifact list and confidence rationale, which you can paste directly into a ticket or client report without reformatting.

Other Tech Stack Lookup Tools Worth Knowing

General-purpose tech profilers are useful for broad market research, though none of them treat AI-builder detection as a core feature the way a specialized scanner does:

  • BuiltWith — the largest historical technology database; strong for market-share research and lead generation, tracking when a technology was first detected or dropped.
  • Wappalyzer — clean, fast breakdowns by category (CMS, UI libraries, payment processors, analytics).
  • W3Techs — strong on server software, SSL issuers, and content-language data at the individual-site level.

Comparing the Options

Tool Speed Confidence scoring Detects AI builders Free, no signup
AI Website Detector Instant Yes, with rationale Yes (core feature) Yes
BuiltWith Instant Partial Rarely a priority Limited free lookups
Wappalyzer Instant Yes Rarely a priority Generous free tier
W3Techs Fast N/A No Yes
Browser DevTools Minutes Manual judgment Possible with effort Yes, built in

Method 2: Use Browser Extensions for Passive Detection

If you analyze websites frequently while browsing, an extension beats copy-pasting URLs into a scanner every time. Extensions monitor network requests, injected scripts, and DOM structure in real time as a page renders — which makes them particularly good at catching JavaScript libraries and tracking pixels that load dynamically after the initial HTML.

  • Wappalyzer extension (Chrome, Firefox, Edge) — a toolbar icon reveals every detected technology, grouped by category.
  • WhatRuns (Chrome) — one-click detection, with an option to get alerted when a followed site changes its stack.

Method 3: Manual Inspection With DevTools

Automated tools sometimes miss custom implementations, headless architectures, or obfuscated stacks. A manual pass gives you primary-source evidence — worth doing whenever a scan returns low confidence or the result needs to hold up to scrutiny.

Search the page source

Right-click any page and choose View Page Source (Ctrl+U / Cmd+Option+U), then Ctrl+F for these patterns:

  • WordPress: wp-content/ or wp-includes/ — asset paths often name the theme and plugins directly.
  • Shopify: cdn.shopify.com or Shopify.theme.
  • Next.js: __NEXT_DATA__ or /_next/static/ asset paths.
  • Nuxt.js: __NUXT__ or data-n-head.
  • Webflow: uploads-ssl.webflow.com or the wf-page attribute.
  • Google Tag Manager: gtm.js?id=.
<!-- Next.js frontend -->
<script id="__NEXT_DATA__" type="application/json">{"props":{"pageProps":...}}</script>

<!-- WordPress CMS -->
<link rel='stylesheet' id='wp-block-library-css'
  href='https://example.com/wp-includes/css/dist/block-library/style.min.css' />

Check response headers in the Network tab

Open DevTools (F12), go to Network, reload the page, and click the top document request. Look at Response Headers for:

  • server — web server or CDN software (nginx, Apache/2.4.51, cloudflare).
  • x-powered-by — back-end runtime (Express, PHP/8.2, Next.js).
  • x-vercel-id or cf-ray — hosting/CDN provider (Vercel, Cloudflare).
  • x-generator — direct CMS disclosure on some platforms (e.g., Drupal).
HTTP/2 200 OK
content-type: text/html; charset=UTF-8
server: cloudflare
x-powered-by: Next.js
x-nextjs-cache: HIT
cf-ray: 8329abf123456789-FRA

You can pull the same headers from a terminal without opening a browser at all:

curl -I https://example.com

The MDN HTTP headers reference is worth bookmarking if you’re not sure what a given header means.

Check cookies and bundle paths

The Application tab shows platform-specific cookies — Shopify sets _shopify_*, Wix sets wixSession. These are harder to obfuscate because they’re tied to backend session infrastructure, not just front-end markup. Bundle filenames are similarly sticky: Next.js ships /_next/static/, Nuxt ships /_nuxt/, and both survive most CDN rewriting because they’re relative paths baked into the HTML.

Pro tip: Framework fingerprints in the compiled bundle are far more reliable than visual similarity. A site that “looks like” a Framer template might be a hand-built Next.js clone — confirm with markup, never with aesthetics alone.

Tech Stack Signals Cheat Sheet

Platform Signal Where to look Reliability
WordPress /wp-content/, /wp-json/wp/v2/, generator meta tag view-source, Network High
Shopify cdn.shopify.com, Powered-By: Shopify, _shopify_* cookies Network, headers High
Webflow webflow.io script src, w-nav/w-container classes view-source, Elements High
Wix static.wixstatic.com, .wix- classes, wixSession cookie Network, Application High
Next.js /_next/static/, __NEXT_DATA__ block view-source High
Cloudflare cf-ray header, cloudflare in Server Response headers High
Vercel x-vercel-id header Response headers High
Framer Assets from framerusercontent.com Network High
Custom / hand-coded No CMS paths; backend framework header (Django, Laravel, Rails) view-source, headers Medium

Method 4: Inspect DNS Records and Infrastructure

Front-end scanners can’t always tell you where a site is hosted, which mail provider it uses, or which vendors it’s verified for. DNS records fill those gaps. Use a free lookup tool like MXToolbox, or query directly from a terminal:

# Query nameservers and mail servers
dig example.com NS +short
dig example.com MX +short
  • NS records reveal DNS management and CDN providers (e.g., ns1.cloudflare.com).
  • MX records reveal the email provider (ASPMX.L.GOOGLE.COM = Google Workspace; mail.protection.outlook.com = Microsoft 365).
  • TXT records often contain verification tokens for HubSpot, Salesforce, Google Search Console, or Mailchimp — a quiet but reliable list of connected SaaS tools.

Pair this with the hosting lookup tool to confirm the hosting provider and CDN in a single step rather than parsing raw DNS output by hand.

Method 5: Indirect Intelligence Gathering

When a stack is genuinely obscured — reverse-proxied, stripped of headers, behind a bot-blocker — indirect research often reveals what direct inspection can’t.

  • Job postings. Engineering job descriptions on LinkedIn or a company’s careers page frequently list the exact stack to attract qualified applicants — e.g. “3+ years with PostgreSQL, Redis, Django, and AWS Lambda” confirms the database, cache layer, framework, and infrastructure in one sentence.
  • Engineering blogs and public repos. Company engineering blogs and a public GitHub org often expose open-source tooling, config files, and architecture write-ups.
  • StackShare. Thousands of companies — including plenty of well-known ones — publicly document their databases, DevOps pipelines, and monitoring tools here.
  • Privacy policies and subprocessor lists. Under GDPR/CCPA, many SaaS companies must disclose third-party subprocessors. Search a site for “Subprocessor List” or “Privacy Policy” to get an exact vendor inventory — CRM, analytics, payments, hosting.

Why Detection Sometimes Fails

Every method above relies on the site leaving fingerprints somewhere in HTML, headers, or DNS. That assumption breaks in a few predictable ways.

Server-side rendering hides client-side markers. A Next.js or Nuxt front end sitting on headless WordPress or Shopify can render HTML that looks fully custom. Check for a /wp-json/wp/v2/ or GraphQL endpoint rather than relying on visible markup.

CDNs rewrite asset domains. A site behind Cloudflare or a custom CDN can serve assets from its own domain instead of the platform’s default, quietly defeating domain-based fingerprinting. Response headers and cookie names tend to survive this even when asset domains don’t.

Bot-blocking returns false negatives. Some sites serve stripped-down pages to detected headless browsers. If a scan comes back “unknown,” retry from a different network or browse the site as a real user and check DevTools directly.

Intentional obfuscation is rare but real. White-label agencies occasionally strip generator tags and rename CSS classes before handoff. DNS history and the Wayback Machine are the last useful signals here — an earlier, less-scrubbed snapshot often still exists.

When nothing produces a clean answer, document the uncertainty rather than force a verdict: what you found, what you couldn’t confirm, and how confident you actually are.

A 6-Step Tech Stack Audit Workflow

Use this sequence when a result needs to hold up in a client report, competitive analysis, or migration scoping document.

  1. Define the goal. Migration scoping, vetting a freelancer’s claim, or benchmarking a competitor’s martech — the goal determines which layer matters most.
  2. Run the automated scan. Start with the tech stack detector and capture the full categorized output.
  3. Confirm with DevTools. Check view-source, the Network tab, and response headers for the top two or three findings. Two independent signals agreeing is the general bar for a high-confidence claim.
  4. Check DNS and hosting separately. Run dig/curl -I or use the hosting lookup tool — this matters most for migration scoping, since hosting and CDN choices directly affect cost and performance.
  5. Flag anything AI-related. If an AI builder might be involved, run the domain through the AI probability scanner — a modern stack alone doesn’t confirm or rule out AI involvement.
  6. Document the findings. Scan URL, confirming view-source snippet, header output, and a confidence rating (high/medium/low) per layer — that’s the package that actually gets used in a handoff.

Key Takeaways

  • Point
  • Details
  • Start with an automated scan
  • A tech stack scanner covers CMS, framework, hosting, and third-party tools in one pass, no signup required.
  • Confirm with two manual signals
  • View-source and the Network tab corroborate or challenge the scan using primary-source evidence.
  • DNS fills in what HTML can’t
  • MX, NS, and TXT records reveal hosting, email, and connected SaaS vendors that never touch the page source.
  • Indirect research covers the rest
  • Job postings, StackShare, and subprocessor lists reveal back-end stacks that headers never disclose.
  • Document before you conclude
  • A confidence-rated finding with evidence beats a confident-sounding guess whenever a result needs defending.
  • According to W3Techs’ usage statistics, a content management system still powers a large majority of all identifiable websites, with WordPress alone accounting for the biggest single share — which is exactly why CMS-layer fingerprints (file paths, generator tags, REST endpoints) remain the single most reliable signal in any tech stack audit.

Tech Stack, SEO, and AI-Built Websites

A site’s tech stack directly shapes its SEO footprint:

  • Core Web Vitals: unoptimized client-side rendering (heavy React or Angular without SSR/SSG) tends to degrade LCP and INP.
  • Crawlability: search engines process static HTML faster than client-rendered JavaScript — a stack check often explains an indexing problem that a PageSpeed score alone won’t.
  • AI-assisted publishing: a growing share of sites combine a standard CMS pipeline with AI-generated content or an AI-first builder. A modern stack (Next.js + Tailwind + Shadcn/Lucide) is a signal of possible AI involvement, not proof — run the domain through the AI probability scanner for a direct verdict, or browse the AI Website Detector blog for deeper detection guides.

Frequently Asked Questions

What is the fastest way to find a website’s tech stack?

Paste the domain into a tech stack detector for an instant, no-signup scan covering CMS, framework, hosting, and third-party tools, with a confidence rationale for each finding.

Can a website completely hide its tech stack?

Not entirely. A site can strip headers like X-Powered-By, hide CMS meta tags, and route traffic through a reverse proxy, but front-end code, JavaScript bundles, and third-party requests still have to reach the browser — which leaves detectable fingerprints even after obfuscation.

Why does a scanner sometimes return “unknown”?

Usually server-side rendering, a CDN rewriting asset domains, or bot-blocking on the target site. Retry the scan, or fall back to manually checking response headers and cookies, which tend to survive these edge cases.

Is it legal to inspect a website’s tech stack?

Yes. HTTP headers, HTML source, and DNS records are public data your browser already downloads to render the page. Attempting to exploit a vulnerability found this way, without permission, is a separate and illegal act.

Does tech stack detection also reveal if a site was built with AI?

A modern stack is a signal but not proof. For a direct answer, run the domain through the AI probability scanner, which layers builder fingerprinting and JavaScript-bundle artifact scanning on top of stack detection.

How do headless CMS setups complicate detection?

In a headless setup, the CMS (e.g. Contentful or Strapi) is separated from the front end (e.g. Next.js). A scanner may easily spot Next.js while the backend CMS stays invisible unless its API endpoint or asset URLs expose it.

What should go into a tech stack audit report?

The scan output URL, a view-source snippet confirming the key finding, relevant response headers, DNS/hosting notes, and a confidence rating (high/medium/low) for each stack layer assessed.

Related Tools

Recommended

Conclusion

Finding a website’s tech stack is a core skill for developers, SEO specialists, security researchers, and marketers alike. Start with an automated scan for a fast, categorized baseline, confirm the important findings with DevTools and DNS lookups, and fall back to job postings, public repos, and subprocessor lists when a stack is deliberately obscured. That combination — not any single tool — is what makes a finding defensible.

Ready to run your first scan? Check any website’s tech stack free — no account required.