What Is This Website Built With? How to Read Any Site's Stack

“What is this website built with?” is one of those questions that sounds like it has a single answer and almost never does. A site can be a framework rendering a CMS through a site builder’s hosting, and all three are legitimate answers to the question. The useful skill is not naming one tool, it is reading the layers: the framework that renders the page, the CMS that manages the content, the builder or platform that hosts it, and whether any of it is custom. Each layer leaves its own public signals, and once you know which signal points at which layer, you can read most sites in a minute.

This is the umbrella guide. It covers how to tell the layers apart, the signals each one leaves, the free tools that read them, and the point at which you stop checking sites one at a time and need technographics at scale. For the deep dives, this guide links out to the specific walkthroughs as it goes.

The layers: framework, CMS, site builder, custom#

Before reading signals, it helps to know what you are sorting them into. “Built with” spans a few different layers, and a site can sit on several at once.

• A framework is the code layer that builds and renders the page. React, Vue, Next.js, Angular and similar tools live here. A framework signal tells you how the frontend is constructed, not necessarily how content is managed.
• A CMS is the content management system, the place content is created and edited. WordPress is the dominant one, with Drupal, Joomla and many headless options alongside it. The CMS is often what a marketing team actually touches.
• A site builder is a hosted, all-in-one platform that bundles design, content and hosting. Wix, Squarespace and Shopify (for ecommerce) are the common ones. With a builder, the framework and CMS are largely decided for you.
• A custom build has no off-the-shelf platform underneath. It is bespoke code, sometimes on a framework, sometimes not, with no standard fingerprints to find.

The reason “what is this built with” has layered answers is that these combine. A site can be Next.js (framework) pulling from a headless WordPress (CMS), or it can be a Squarespace site (builder) where the framework and CMS questions do not really apply. Reading the stack means identifying which layers are present, not forcing one label.

The signals, by layer#

Every detector reads public output the site already serves. Here is which signal points at which layer, so you can do the reading yourself with nothing but a browser.

The meta generator tag (CMS and builders)#

View the page source (Ctrl+U) and search for generator. A <meta name="generator"> tag often names the CMS or builder outright: WordPress 6.x, Drupal, Wix, Squarespace and others stamp it in. It is the single most direct giveaway for the content layer, though plenty of sites omit or strip it, so its absence proves nothing. For the full view-source method around the CMS layer specifically, the guide on how to detect the CMS a website uses walks through every signal in detail.

JavaScript globals and bundle names (frameworks)#

Frameworks leave tells in the rendered page and the scripts it loads. A React site often exposes a root element and React-specific markers; a Next.js site serves a /_next/ asset path and a __NEXT_DATA__ script block; a Vue or Nuxt site has its own recognizable globals and asset paths. Searching the source for _next, __NEXT_DATA__, or framework-specific class and attribute patterns identifies the frontend layer. These are real, verifiable signals, not guesswork.

Response headers (server and platform)#

Open developer tools (F12), go to the Network tab, reload, and click the first document request. The response headers carry their own fingerprints. x-powered-by sometimes names the underlying technology, server names the web server, and some platforms add custom headers that effectively brand the response. Headers can be stripped or spoofed, so they are corroboration rather than proof, but a platform-specific header is a strong hint.

File paths and asset domains (platform)#

The asset paths in the source are some of the most reliable signals there are. /wp-content/ and /wp-includes/ mean WordPress. cdn.shopify.com and a Shopify.theme object mean Shopify. static1.squarespace.com means Squarespace. static.parastorage.com points at Wix. These domains and paths are how the platform serves its own files, so they are hard to fake and easy to read.

Cookies (tools and platforms)#

In developer tools, the Application or Storage tab lists the cookies a site set. The names are the giveaway: WordPress sets wordpress_ and wp- prefixed cookies, and many analytics, CRM and chat tools set distinctively named cookies the moment a page loads. Cookie names are a quick way to spot tools that do not advertise themselves in the HTML.

Going deeper on the platform: themes and stores#

Once you know the platform, the next question is often how it was put together. For the two biggest platforms, that comes down to the theme, and the same view-source approach applies.

On WordPress, the active theme lives in the /wp-content/themes/ path and its real name sits in the theme’s style.css header, with child themes and page builders complicating the picture. The dedicated walkthrough on the WordPress theme detector covers exactly which signals to read and how builders like Elementor can mask the base theme.

On Shopify, the theme shows up in the Shopify.theme JavaScript object and the asset URLs on cdn.shopify.com, and the presence of a marketplace id tells you off-the-shelf versus custom. The Shopify theme detector guide reads those signals and explains what the theme does and does not reveal.

When the layers combine: headless and modern stacks#

The cleanest sites to read are single-platform ones: a Squarespace site is Squarespace, a classic WordPress site is WordPress, and the signals all agree. The interesting cases are the combined stacks, and they are increasingly common, so it is worth knowing how they read.

A headless setup runs a CMS purely as a content backend and renders the frontend with a separate framework. The visitor sees the framework, not the CMS. So you might find strong Next.js signals, a /_next/ path and a __NEXT_DATA__ block, with no /wp-content/ paths anywhere, even though WordPress is managing the content behind an API. From the outside, the CMS can be effectively invisible. Reading the framework correctly and noting the absence of any platform path is the honest result: “Next.js frontend, content layer not detected” is more accurate than guessing a CMS that does not announce itself.

Modern marketing sites complicate this further by stacking a framework, a hosting platform and a tag manager that loads a dozen third-party tools. The page source can name React, a /_next/ path, a Vercel or Netlify header, and a Google Tag Manager container that pulls in analytics, a chat widget and a pixel. None of these contradict each other; they are different layers, and a careful read lists them as such rather than forcing one label.

The takeaway is to resist the urge to give one answer. “What is this built with” on a modern site is legitimately a short list: the framework, the platform or host, the CMS if one is exposed, and the tools loaded on top. A read that names the layers it can see and is plain about the ones it cannot is worth more than a confident single guess.

The free tools that read it for you#

You do not have to read source by hand on every site. Free tools automate the same reading.

• Browser extensions like Wappalyzer and WhatRuns identify the stack on click: CMS, framework, analytics, ad tags, hosting and more, read straight from the code the page serves. They are free for single-site lookups and are the fastest way to answer “what is this built with” for one site.
• Online checkers let you paste a URL and read the stack without installing anything, which is handy on a machine where you cannot add an extension.
• A gap-first stack checker reads the same signals but leads with what is absent, which is the angle that matters if you are qualifying the site rather than just identifying it.

For a side-by-side of the detectors and where each one fits, including the free tiers and the paid lines, see the comparison of BuiltWith and Wappalyzer alternatives.

When you need technographics at scale#

Reading one site is free and fast. The moment you want to read a list, the economics change, and that is where technographics tools earn their price.

If you are doing market research, building a list of every site on a given platform, or prospecting at volume, you need a crawled database that has already detected the stack across millions of sites, plus the ability to filter by technology and pull contact data. That is a different class of tool from a per-page detector, and it is genuinely paid, because maintaining that database and fingerprint library is the expensive part. The honest rule is simple: read by hand or with a free extension for one site, reach for technographics when you need the stack across many.

For prospecting specifically, the stack is only half the read. What a site is missing, no CRM, no pixel, no chat widget, no booking tool, is frequently the entire pitch, because each gap maps to a service an agency sells. That is the lens Website Technology Checker is built around: it reads the same public fingerprints any detector does, then leads with the gaps and scores them for how clearly they signal an opportunity. To find the sites to check in the first place, a lead scraper pairs naturally with a stack-and-gaps read, and where the follow-up runs on Instagram, Inflowave handles that channel once a gap check flags a business worth contacting.

A fast routine for any site#

For a single site, the routine is short. Open the page source and search for generator. Look at the script URLs for framework tells like _next. Read the asset domains and paths for the platform (wp-content, cdn.shopify.com, parastorage). Glance at the response headers and cookie names for the server and the tools. Within a minute you will know the framework, the CMS or builder, and most of the surrounding stack, and where detection is solid versus where it is honestly blank.

For many sites at once, the manual route does not scale and you lean on tools, ideally one that surfaces the gaps and not just the inventory. Detection is the easy half. The value is in reading the stack to understand the site, reading the gaps to know what to say, and only then reaching out. If you want the gap-first piece of that the moment it ships, the waitlist is the place to start, free at launch.