What is this site actually built with? Three checks and 13 signals

When you inherit a site — or want to change your own — the first thing you need is not the code. It's what the thing is built with.

Because the stack decides what is possible afterwards.

• Whether you can change it at all. A WordPress site's heading font might live in one theme setting. On Webflow you may not even get the HTML. A headless CMS means editing a content model.
• Whether the images can be saved. WordPress serves from /wp-content/uploads/, Shopify from cdn.shopify.com, Prismic from images.prismic.io — and each pipeline takes a different set of transform parameters. Miss the pipeline and you don't know what to tune.
• Cache and render strategy. Headless leans on CDN caching for API JSON and an HTML shell; classic PHP leans on full-page and object caches; hosted builders give you the fewest knobs.
• Whether you can touch the code. Some platforms give you a panel. Some give you everything.

In one line: identify the platform first, then optimise. The other order wastes your time.

---

Three checks

Check 1: View source, then search it

Open the page → Ctrl+U (Cmd+Option+U on Mac) → search the HTML for the vendor name you suspect.

The distinction that matters: if the name only shows up in body copy or a comment, it proves nothing. What counts is the name appearing inside a src, href or data- attribute — that is a resource the browser was told to load.

A concrete example: you search for prismic and find it inside a <p> tag. That site may just have published an article about Prismic. But if it appears in src="https://images.prismic.io/...", that is hard evidence.

So the question is never "is this word here" — it is where the word appears.

Check 2: Read the response headers, especially the cookies

Open dev tools → Network → reload → click the first document request. Look at:

• x-powered-by, x-generator, server
• the names inside set-cookie — the most valuable of the lot

Why are cookies stronger than meta tags? Because meta tags are written by a human, cookies are issued by the platform. A cookie called wp-settings-1 or _shopify_s is the platform introducing itself.

⚠️ One trap: CDNs strip headers. Put Cloudflare or Vercel in front and a lot of the original headers are simply gone. So "I don't see it" is not the same as "it isn't there". It's one vote, not a verdict.

Check 3: Compare against a site you already know

The same platform leaves the same shape on every site that runs it: the same asset host, the same path prefixes, the same admin endpoints.

That is the whole reason CMS detection works at all — not guessing, but shape matching.

• A single keyword → maybe a false positive
• Keyword + matching host + matching path → that is confirmation

---

13 signals worth memorising

• WordPress: /wp-content/, /wp-includes/, /wp-json/, the wp-emoji-release script, wp-* cookies
• Shopify: cdn.shopify.com, cdn.shopifycdn.com, /cdn/shop/, Shopify.theme in page scripts
• Wix: static.wixstatic.com, static.parastorage.com, the inline viewer model JSON
• Squarespace: static1.squarespace.com, Static.SQUARESPACE_CONTEXT
• Webflow: website-files.com, website-images-assets.com, data-wf-* on <html>
• Prismic: images.prismic.io, /prismic-assets/, slice markers, prismic-toolbar
• Contentful: images.ctfassets.net, assets.ctfassets.net
• Sanity: cdn.sanity.io, the project id referenced in page scripts
• Ghost: /ghost/, /content/ paths, ghost-* meta tags, the Ghost admin SDK
• Drupal: /sites/default/files/, drupalSettings, the X-Generator response header
• Joomla: /media/jui/, /media/system/, /components/com_
• Craft CMS: the CRAFT_CSRF_TOKEN cookie, /cpresources/
• Strapi: a /uploads/ path together with an api. host or /api/ JSON endpoints

---

A real example

Let's practise on a site everyone knows: the TechCrunch homepage.

In the source, these two lines are decisive:

<link rel="https://api.w.org/" href="https://techcrunch.com/wp-json/" />
<script src="https://techcrunch.com/wp-includes/js/dist/i18n.min.js?ver=..." id="wp-i18n-js"></script>

/wp-json/ and /wp-includes/ are WordPress-only paths, and they sit inside href and src — the browser genuinely loads them.

In the response headers it is even more direct:

x-powered-by: WordPress VIP <https://wpvip.com>
link: <https://techcrunch.com/wp-json/>; rel="https://api.w.org/"
server: cloudflare

x-powered-by names the platform outright, and the link header hands you the REST API address.

Note that last line: server is cloudflare, not the origin. That is the "CDNs strip headers" problem in the wild — with a CDN in front, you see one layer less.

---

The two most common mistakes

Mistake one: finding the brand name in body copy and calling it done.

Documentation sites, comparison posts and job ads list several vendors at once. None of that is proof of an install.

Mistake two: concluding from a single signal.

Plenty of sites sit behind Cloudflare. Cloudflare is a CDN — it says nothing about which CMS runs underneath.

The right approach is to read the signals in layers:

• Vendor-specific hosts (strong) > path prefixes (strong) > cookies (strong)
• Response headers (medium — CDNs strip them)
• Brand strings in page copy (weak)

---

If you'd rather not check by hand

Paste the URL into prismicaudit.com/tools/cms-checker. It runs 100+ detectors across CMS, frameworks, hosting, CDN and third-party scripts, and lists the raw evidence behind every hit — not just a yes/no.

I care about giving evidence rather than verdicts, because you should be able to check the answer yourself.

---

The checks described here work on any site. Vendor names are used only to describe identification fingerprints; this tool is not affiliated with any of them.