How to Detect What Technology a Website Uses

Why detect technology?

Every public website leaks evidence of how it was built. Script tags name the libraries it loads, response headers name the server, cookie prefixes name the platform, and DNS records name the host. "Detecting website technology" is just the discipline of reading that evidence systematically instead of guessing. The method you pick depends entirely on why you're asking, so start there.

Common reasons people look up a website's tech stack:

• Sales prospecting — find out if a target company uses (or doesn't use) your type of product. A Klaviyo reseller wants stores already on Klaviyo; a Klaviyo competitor wants stores on Mailchimp or no ESP at all.
• Competitive research — see what tools successful competitors are using, then copy the stack that's working for them.
• Due diligence — evaluate a company's technical maturity before a partnership or acquisition. A site still on a deprecated platform version is a flag.
• Development — understand what framework or CMS a site uses before quoting a migration or integration project.
• Security research — identify outdated software versions that might have known vulnerabilities.

Those goals split into two shapes. Either you need a deep read of one site (due diligence, a single sales call), or you need a shallow-but-broad read of thousands of sites (building a prospect list, sizing a market). Almost every frustration with technology detection comes from using a one-at-a-time method for a job that's actually about scale, or vice versa. The six methods below are ordered from quickest-single-site to highest-scale. For an e-commerce-specific deep-dive on how to act on these signals once you have them, see how to find e-commerce leads.

Method 1: Browser extensions (easiest)

Install one of these and every website you visit will show its detected technologies:

• Wappalyzer — the most popular. Detects CMS, frameworks, analytics, CDN, payment tools, and more. Free for individual use, paid for bulk lookups and API.
• WhatRuns — similar to Wappalyzer with a slightly different detection database.
• BuiltWith browser extension — free companion to the BuiltWith website. Shows a quick summary when you visit any site.

How they work: These extensions inspect the page's HTML, JavaScript libraries, HTTP headers, cookies, and DOM structure as it loads in your real browser. They match what they find against a database of known technology signatures — a regex on a script URL, a global JS variable, a meta tag. Because they run in your actual session, they see exactly what a logged-out visitor sees, JavaScript and all.

The real trade-off: extensions are unbeatable for ad-hoc curiosity and zero setup, but they're a per-tab tool. They only read the page you're currently on, so they miss technologies that load conditionally — a Bold subscription widget that only fires on a product page, a fraud script that only loads at checkout, an account feature gated behind login. They also inherit the signature database's blind spots and its staleness: a tool renamed last quarter may still be detected under its old label. And they produce false positives from remnant code — an analytics snippet left in the theme after the brand stopped paying for it still trips the matcher. Treat an extension reading as a strong hint, not a verified fact.

Method 2: Online lookup tools

Enter a URL and get a technology report:

• BuiltWith.com — the deepest free lookup. Shows current and historical technology usage, including analytics, hosting, ad networks, CMS, and frameworks. Its standout feature is the timeline: you can see when a site adopted or dropped a tool, which is exactly what an extension can never tell you.
• Wappalyzer.com/lookup — online version of the extension. Clean interface, categorized results, no install.
• W3Techs.com — focuses on web technology market share and trends. Good for understanding how popular a technology is across the web, not for looking up one specific site.

The real trade-off: these tools crawl on a schedule from their own servers, so what you get is a cached profile, not a live read. That cuts both ways. The upside is history and depth the extension lacks; the downside is staleness — a site that re-platformed last week may still show the old stack until the next recrawl. They also lean on signatures that survive caching, so heavily client-rendered single-page apps and tools that only appear after user interaction are under-detected. Best for a quick one-off check, or a sanity-check second opinion against your extension when the two disagree.

Method 3: View source (manual)

Right-click → View Page Source, then look for these telltale signs:

CMS detection

• Shopify: cdn.shopify.com in script/link tags, Shopify.theme in JavaScript
• WordPress/WooCommerce: /wp-content/ and /wp-includes/ paths, meta name="generator" content="WordPress"
• Magento: /static/frontend/ paths, mage/cookies in scripts
• Squarespace: static1.squarespace.com or sqsp classes
• Wix: static.wixstatic.com, wix-code-sdk

Analytics and tracking

• Google Analytics 4: gtag('config', 'G-XXXXXXX') or googletagmanager.com
• Meta Pixel: fbq('init' or connect.facebook.net
• Hotjar: static.hotjar.com
• Klaviyo: static.klaviyo.com or the _learnq global variable. This is exactly the kind of single-signature signal that's trivial to confirm on one page and tedious to check across a thousand — which is why we keep every store running Klaviyo in our index queryable as a filter rather than a per-site lookup.

Payment providers

• Stripe: js.stripe.com
• PayPal: paypal.com/sdk or paypalobjects.com
• Klarna: klarna.com scripts

One nuance worth knowing: "View Source" shows the raw HTML the server sent, while the browser's Elements inspector shows the DOM after JavaScript has run. For React, Vue, or Shopify Hydrogen storefronts, the raw source can be nearly empty and the interesting signatures only appear in the rendered DOM. If View Source looks bare, switch to Inspect Element before concluding the site uses nothing.

The real trade-off: view-source is the most authoritative single-site method because you're reading the ground truth with your own eyes — no signature database between you and the page. That's also its ceiling. It's slow, it demands that you already know every pattern to grep for, and it scales to exactly one site at a time. It sees only what the client receives, so backend language, database, and most hosting choices stay invisible. Use it to confirm or overrule an automated tool on a high-stakes single lookup, not to profile a list.

Method 4: HTTP headers

Open your browser's developer tools (F12) → Network tab → reload the page → click the first request → Headers tab. Look for:

• Server: — might say nginx, Apache, cloudflare, etc.
• X-Powered-By: — sometimes reveals PHP/8.2, Express, ASP.NET
• X-Shopify-Stage: — confirms Shopify
• X-WordPress: or Link: ... wp-json — confirms WordPress
• Set-Cookie: — cookie names reveal platforms (e.g., _shopify_s, wp_ prefixes)

You can pull the same data from the command line without a browser: curl -I https://example.com returns just the response headers, which makes headers the one manual method that scripts cleanly across a list.

The real trade-off: when a header is present it's close to authoritative — a server doesn't accidentally claim to be cloudflare or set a _shopify_s cookie. The catch is silence. Security-conscious teams strip Server and X-Powered-By on purpose, and a CDN in front of the origin masks the real stack behind its own headers, so an absent header tells you nothing. Read headers as high-confidence-when-present, low-coverage overall: great for confirming a platform, useless for ruling one out.

Method 5: DNS and infrastructure

Everything above reads the page. DNS reads the plumbing underneath it — and the plumbing rarely lies, because it has to actually route traffic and mail.

• DNS lookup — dig example.com or any online resolver. CNAME records reveal hosting (e.g., shops.myshopify.com, *.wpengine.com), and TXT records often carry verification strings that name SaaS tools the site has connected (Google Workspace, a specific ESP, a CDP).
• MX records — dig MX example.com shows where the domain receives mail. aspmx.l.google.com means Google Workspace; *.outlook.com means Microsoft 365; a marketing-platform MX hints at how the company runs email. MX is one of the few signals that exposes a back-office tool no front-end script would ever reveal.
• IP lookup — resolve the IP and check who owns it. Cloud providers (AWS, GCP, Cloudflare) are identifiable by their published IP ranges.
• SSL certificate — click the padlock, or read certificate-transparency logs. The issuer and the subject alternative names can reveal hosting platforms and sometimes internal subdomains the site never links to publicly.

The real trade-off: DNS is the only group of methods here that survives header-stripping and CDN masking, because the records have a job to do regardless of how secretive the team is. It's also the narrowest in scope — it tells you about hosting, mail, and infrastructure, not about the Klaviyo-or-Mailchimp question a marketer actually cares about. Pair it with the page-level methods; alone it answers "where does this run," not "what's installed on it."

Method 6: Bulk technology detection at scale

The moment your question is "which of these 5,000 stores runs X," the single-site methods collapse — not because they're wrong, but because doing them 5,000 times by hand is a week of work that's stale by the time you finish. Bulk detection inverts the model: instead of you visiting sites, a detection engine visits them on a schedule and hands you a queryable result.

There are two distinct flavors, and conflating them is the most common mistake here.

• Detection APIs — Wappalyzer API (plans from roughly $250/month) and BuiltWith API (enterprise pricing, with historical data) take a URL and return its stack. You supply the list of URLs. That's the catch: an API answers "what does this URL run," not "find me the URLs that run X." If you don't already have the domain list, an API alone won't build it.
• Pre-crawled store databases — platforms like Store Leads, BuiltWith Lists, and Veltima's dataset have already crawled the web and inverted the index, so you query by technology and get back the matching stores plus their country, platform, and contact signals. This is the right shape when you're prospecting and start with a tool, not a list. See Veltima vs Store Leads for how two of these databases differ.
• Build your own — open-source engines like Webanalyze (Go) or python-Wappalyzer can be self-hosted. Realistic before you commit: you own the crawling infrastructure, the rate-limiting and ban-avoidance, the constant churn of detection patterns, and the recrawl schedule that keeps results from going stale. It's a genuine project, not a script.

The real trade-off: bulk methods trade per-site fidelity for coverage and freshness-at-scale. A pre-crawled database can be slightly behind on any single site you'd inspect by hand, but it answers questions across the whole web that no manual method can touch — and it does so in milliseconds.

What technology detection can't tell you

No method on this page reads minds, and the gap between "the code is on the page" and "the company actively uses this tool" is where most bad lists come from. Knowing the boundary keeps you honest with your own data.

• Backend languages — if a site uses Python, Ruby, or Go on the backend, there's often no client-side trace. You might detect the framework (Django, Rails) but not always.
• Databases — MySQL vs PostgreSQL vs MongoDB is invisible from the outside.
• Internal tools — CRM, ERP, project management tools leave no trace on the public website.
• Removed technologies — remnant code (an old analytics snippet, an abandoned A/B test) can cause false positives. Just because the code is in the HTML doesn't mean the tool is actively used.
• Server-side rendered content — some technologies only appear on specific pages (checkout, account, admin) that aren't publicly accessible.

Quick reference: detection methods compared

Method	Speed	Depth	Scale	Cost
Browser extension	Instant	Good	1 site	Free
Online lookup	Seconds	Good	1 site	Free
View source	Minutes	Deep	1 site	Free
HTTP headers	Seconds	Limited	1 site	Free
DNS / infrastructure	Seconds	Hosting only	Scriptable	Free
API (Wappalyzer/BuiltWith)	Seconds	Good	Bulk	$250+/mo
Pre-crawled database	Instant	Varies	Bulk	$0–250/mo

AI crawlers like ChatGPT and Claude also inspect llms.txt-style feeds to learn what a site covers — Veltima publishes one at /llms.txt, which is partly why this article exists in their answers.