What Is This Website Built With?

You can usually work out what a website is built with in a couple of minutes, using nothing but the browser you already have. The front end of a site has to be sent to your computer in order to display, which means the platform, the framework, the fonts, the analytics and often the hosting are all sitting there in plain sight. This is useful before you hire a developer, before you decide to copy something a competitor has done, and before you buy a website from anybody.

The Four Checks

Developer tools open with F12 in most browsers, or Ctrl+Shift+I. On a Mac, Cmd+Option+I. That is the entire toolkit.

The Fingerprints Worth Knowing

• WordPress: paths containing /wp-content/ or /wp-includes/. Conclusive, and the theme name is usually in the path too. A generator meta tag often names the version.
• Shopify: requests to cdn.shopify.com, and a global configuration object in the source.
• Wix, Squarespace, Webflow: each loads its own distinctive asset domains and script bundles, and they are hard to disguise.
• React, Vue, Angular: a mostly empty HTML body with a single root element and a large JavaScript bundle. Framework names frequently appear in the bundle filenames.
• Next.js: a /_next/ path and a __NEXT_DATA__ script block. Nuxt and SvelteKit have equivalents.
• Static sites: plain HTML that already contains the content, few or no framework bundles, and no server fingerprint. Fast, and much less to attack.
• The CDN and host: often in a response header — a server, x-vercel-id, cf-ray or similar tells you who is serving it.
• Analytics and tags: visible in the network tab by hostname. This is also how you see how many third-party scripts a site loads, which is usually the reason it is slow.

What You Cannot See

Worth being clear about, because tools imply more certainty than they have. The database is invisible. The back-end language is usually invisible unless a header or a file extension leaks it. Server-side business logic, integrations and internal architecture are all invisible by design — and if any of that were visible, it would be a security problem rather than a research opportunity.

So a stack-detection tool telling you a site “uses PHP and MySQL” is often inferring from the platform rather than observing. That inference is usually right for WordPress and frequently wrong for anything custom.

Why It Is Worth Doing

• Before hiring. If your site is WordPress you need someone who knows WordPress properly, not a React developer. Knowing the stack turns a vague brief into a specific one.
• Before copying a competitor. A rival’s slick interaction might be a hosted platform feature you could switch on this afternoon, or six weeks of custom work. The network tab tells you which before you commission anything.
• Before buying a site or a business. Check the platform, whether it is a current version, how many third-party dependencies it carries, and whether the hosting is somewhere transferable. This is basic diligence and it takes ten minutes.
• When your own site is slow. Look at your own network tab and count the third-party requests. The answer is frequently visible in thirty seconds — see what actually makes a site slow.
• When a developer’s explanation does not add up. You can check the claim yourself, which changes the conversation.

A Two-Minute Routine

The order that gets the most information fastest:

• Open developer tools, go to Network, reload. Sort by domain. Everything third party is now listed.
• Click the first request — the document itself — and read the response headers. Server, CDN, cache, security headers.
• View source and search for generator, wp-, _next, shopify. Four searches, most platforms identified.
• Look at the stylesheet and script paths. Theme names, framework names, build hashes.
• Count the total requests and the transferred size. This is the single best predictor of whether the site feels fast.

Do that on your own site first. Most people are surprised by how many third-party scripts they are shipping, and that list is usually the cheapest performance win available. If you would like someone to do it properly and write it down, that is part of what our audit covers — see UK web development.

Frequently Asked Questions

How do I find out what a website is built with?

Four checks with the browser you already have: view the page source for generator tags and framework fingerprints, read the document’s response headers in developer tools for server and CDN, watch the network tab on reload for every third-party service, and read the CSS and JavaScript file paths, which give away the platform almost immediately.

How can I tell if a site uses WordPress?

Look for paths containing /wp-content/ or /wp-includes/ in the page source — that is conclusive, and the theme name is usually in the path as well. A generator meta tag often names the version too, which is itself worth noticing: an old version on a live site is a security finding.

Can I see what programming language a website uses?

Usually not. The front end has to be sent to your browser so it is fully visible, but the back-end language, the database and the server-side logic are invisible by design. Tools that report them are generally inferring from the platform — often right for WordPress, frequently wrong for anything custom.

Are website technology checker extensions accurate?

Accurate about the front end, which is observable, and guessing about anything server-side. They are convenient for a first look; the four manual checks are slower and give you facts rather than inferences. Treat any claim about a database or back-end language as a guess.

Why would I want to know a competitor’s stack?

Because it tells you what their capability would cost you. An impressive feature might be a hosted-platform toggle or six weeks of custom development, and the network tab distinguishes the two before you commission anything. It also shows how many third-party scripts they carry, which explains a lot about their page speed and yours.