Every website is assembled from parts: a host, a content management system or framework, a theme or front-end library, and a handful of third-party scripts for analytics, payments or chat. Most sites reveal a surprising amount about those parts in the code they send to your browser. You just need to know where to look, and how much weight to give each clue.
This guide walks through the methods we rely on when we build detection rules for TechScan AI, from viewing the page source to reading DNS records. It also covers the part most guides skip: what you can’t reliably detect.
What “built with” actually means
When people ask what a site is built with, they usually mean one of several layers:
- Infrastructure: the hosting provider, CDN and web server.
- Platform: a CMS such as WordPress or Drupal, a hosted builder such as Shopify, Squarespace or Wix, or a custom application.
- Front end: the theme, JavaScript framework and CSS tooling that shape what you see.
- Third-party services: analytics, tag managers, advertising pixels, payment providers, chat widgets and fonts.
Each layer leaves different traces, so it helps to know which one you’re trying to identify before you start.
Start with the page source
Open the page, then view its source: Ctrl + U on Windows and Linux, or Cmd + Option + U on a Mac in Chrome. Use your browser’s find function to search the source for the clues below.
| Look for | Example | Suggests |
|---|---|---|
| Generator meta tag | <meta name="generator" content="WordPress …"> | The CMS, sometimes with a version. Often removed for security. |
| Asset paths | /wp-content/, /wp-includes/ | WordPress |
| Asset hosts | cdn.shopify.com | Shopify |
| Framework data | a __NEXT_DATA__ script, /_next/ paths | Next.js |
| Framework attributes | ng-version, data-v- prefixes, id="__nuxt" | Angular, Vue, Nuxt |
| Third-party script hosts | googletagmanager.com, js.stripe.com | Google Tag Manager, Stripe |
Shopify storefronts usually expose a Shopify.theme object in an inline script, which often includes the theme’s name. On WordPress sites, the folder names under /wp-content/themes/ and /wp-content/plugins/ are especially revealing; we cover those in detail in how to tell which WordPress theme and plugins a site is using.
One caution: “View source” shows the HTML the server sent. Sites built as single-page applications add much of their content later with JavaScript. For those, open Developer Tools (F12) and inspect the Elements panel, which shows the page as it is now, after scripts have run.
Read the response headers
Headers are metadata sent with every response, and they often name the infrastructure. In Developer Tools, open the Network panel, reload the page, select the first request (the document itself) and look at Response Headers.
servermay name the web server or edge network, such asnginx,Apacheorcloudflare.x-powered-bysometimes reveals the runtime or framework, such asPHP/8.2orExpress, though many sites remove it.- Platform-specific headers are strong signals:
cf-raypoints to Cloudflare,x-vercel-idto Vercel andx-nf-request-idto Netlify.
Watch the network requests and cookies
Many services load after the initial page, sometimes only after you accept a cookie banner or scroll. Keep the Network panel open while you use the page and filter by domain. Requests to google-analytics.com, connect.facebook.net or a chat provider’s domain tell you which tools are actually running, not just which ones are referenced.
Cookie names are another clue. In the Application panel under Cookies, names such as _ga (Google Analytics) or _fbp (Meta Pixel) identify the services that set them.
Check DNS for hosting and email
DNS records describe where a domain points, and they’re public. From a terminal you can run nslookup on Windows, or dig on macOS and Linux:
dig example.com A
dig www.example.com CNAME
dig example.com MX
dig example.com TXTA CNAME pointing at a platform’s domain often names the host directly. MX records reveal the email provider. TXT records frequently include SPF entries and verification tokens that list the services a company uses to send email.
Where a detection tool helps
Checking all of this by hand is slow, and the number of possible fingerprints is large. Detection tools automate the matching: browser extensions such as TechScan AI and Wappalyzer, and lookup services such as BuiltWith.
The most useful tools also show why they reached a conclusion. TechScan AI lists the signals behind each detection (the script, resource, markup or metadata it matched) along with a confidence level, so you can verify a result rather than take it on trust. That matters most when two technologies leave similar traces.
What you can’t reliably detect
Every method above depends on what a site chooses to expose. Some things are usually invisible from the outside:
- Back-end internals: databases, queues and server-side languages behind a proxy rarely leave front-end traces.
- Headless setups: a static front end can hide the CMS that produced its content.
- Bundled assets: build tools and optimisation plugins combine and rename files, which removes tell-tale paths.
- Removed headers and meta tags: many sites strip version information on purpose.
- Consent-gated scripts: tools that load only after a visitor accepts cookies won’t appear until you do the same.
Treat every result as evidence, not proof. One strong signal, such as a platform-specific header, outweighs several weak ones, such as a common class name.
A quick checklist
- View the source and search for generator tags, asset paths and script hosts.
- Inspect the live DOM in Developer Tools for framework attributes.
- Read the document’s response headers.
- Watch network requests and cookies while you use the page.
- Look up DNS records for hosting and email clues.
- Confirm with a detection tool that shows its evidence, and note anything that couldn’t be determined.
