Brand Extractors·3 min read

Reading a Site's Tech Stack: CMS, Framework, Analytics

Ten minutes before a discovery call, the most useful research isn't the prospect's About page, it's their HTML. Reading a site's tech stack tells a salesperson what the migration pitch is, tells a developer what the rebuild estimate looks like, and tells both whether the company invests in its web presence. Every platform leaves fingerprints in the page source, and the Tech Stack Detector matches them automatically. Here's what those fingerprints are and how to read the results with appropriate skepticism.

Open the tool All insights

What a tech stack reveals before anyone answers the phone

Recon that takes one paste.

For sales, the stack is qualification data. A prospect on WordPress with no analytics beyond a bare Google Analytics tag is a different conversation from one running Next.js, Segment, and Stripe. The first might need everything; the second has an engineering team and a budget.

For developers, the stack scopes work. Knowing a site runs Shopify before the estimate call means you price theme customization, not a ground-up build. Agencies also scan their own client rosters periodically, since sites accumulate marketing scripts nobody remembers approving.

Reading a site's tech stack from raw HTML

Pattern matching, not magic.

Detection is string matching against known signatures. The page HTML is fetched once, then tested against patterns each technology can't help leaving behind: script URLs, meta tags, DOM attributes, path conventions. No code runs on the target and nothing needs an account.

Confidence comes from match counts. Two or more independent patterns hitting the same technology earns a high badge, one match earns medium. That distinction is worth respecting, because a single string can occur for boring reasons, while three WordPress markers in one document are close to proof.

CMS fingerprints hiding in the stack

Platforms announce themselves.

CMS fingerprints are the loudest signals in any page source. WordPress ships wp-content and wp-includes paths plus a generator meta tag stating its version. Shopify loads assets from cdn.shopify.com. Webflow scatters data-wf attributes, Wix serves from static.wixstatic.com, and Ghost and Drupal both volunteer generator tags.

These are hard to hide because they're structural: the CMS controls how assets are organized, so its conventions leak into every page it renders. Even sites that strip the generator tag rarely bother rewriting their asset paths.

A worked stack detection

From page source to sales notes.

Run a local bakery chain's site and the raw HTML might contain wp-content/themes/astra, a generator tag reading WordPress 6.5, a script from googletagmanager.com/gtm.js, and a newsletter form posting to list-manage.com.

The readout: WordPress, high confidence, on the Astra theme; Google Tag Manager, medium; Mailchimp, medium. Translated for the call notes: self-managed WordPress with a mainstream theme, some marketing tooling in place, no ecommerce detected. If you sell managed hosting or a Shopify migration, you now know exactly which door to knock on.

Frameworks vs libraries detection in the stack

Why Next.js and React aren't the same finding.

Frameworks vs libraries detection trips people up because the signals nest. React is a library, and its markers, react-dom bundles, data-reactroot attributes, appear on their own when a team wired React up manually. Next.js is a framework built on React, and it leaves distinct evidence: the __NEXT_DATA__ script block and _next/static asset paths.

So a Next.js hit implies React even when React shows separately at medium confidence, and the same logic applies to Nuxt over Vue. Read the framework as the finding and the library as the confirmation, not as two technologies.

Mistakes that mislead a stack readout

Detection is evidence, not testimony. These are the misreadings to avoid.

Quoting a medium-confidence hit as fact; a blog post that mentions Cloudflare in its text can trigger the same string match as actual Cloudflare headers.
Assuming absence means non-use. Headless CMS setups render to plain HTML, and a Contentful or Sanity backend leaves no client-side trace.
Forgetting that one page is one sample; the marketing site and the app at app.example.com routinely run entirely different stacks.
Treating detected analytics as active. Sites carry dead tags for years after switching vendors.

Tips for stack research that holds up

Scan more than the homepage. A product page or blog post often loads platform assets the landing page lazy-loads or omits, and comparing two scans catches sites mid-migration.

Cross-check the big claims cheaply: the company's job listings name the real stack, engineering blogs confirm frameworks, and response headers verify hosting. A detection plus one corroborating source is solid enough for an estimate or a call.

Tech Stack Detector vs related tools

Different layers of the same site.

The Tech Stack Detector reads the engineering layer. For the marketing layer of the same research, the Meta Tag Analyzer audits how well the site handles titles and descriptions, which hints at SEO maturity. The Brand Font Detector and Brand Asset Pack cover the design layer, typography and visual assets. Run stack plus meta plus brand on one prospect and you've profiled their entire web operation in a quarter hour.

Try it now

Open Tech Stack Detector

The tool is one click away. No sign up, no upload, no payment.

Open Tech Stack Detector

Write a review