How to find out what a website is built with
The clues any site leaves about its CMS, its framework and its hosting, how far you can trust them, and why it helps to know before a redesign or a migration.
By Javier Tenjo, Full stack developer
On this page
A website does not carry a label saying “built with WordPress, hosted here”. But almost every site gives it away without meaning to. Each tool leaves recognisable traces in its file paths, in the page code and in the headers the server sends, and anyone who knows where to look can reconstruct much of the stack without any special access.
It is not a hacker’s trick. It is reading what the site publishes to every visitor, and it is genuinely useful when you are about to inherit, redesign or migrate a website, or when you want to understand how a competitor works.
The layers of a website
It helps to separate what you are looking for, because each layer leaves different clues:
- The CMS or platform: WordPress, Shopify, Wix, Drupal, Webflow… Where the content is edited.
- The front-end framework: React, Next.js, Astro, Vue… How the part the user sees is built. A site may have a framework and no CMS, or the other way round.
- The server and language: Apache, Nginx, PHP, ASP.NET.
- The CDN: a network placed in front of the server to deliver faster and filter attacks, such as Cloudflare or Fastly.
- The hosting: the provider where the server actually lives.
The clues a website leaves
Response headers
Before the HTML, the server sends headers. Some are very explicit: Server: nginx, X-Powered-By: PHP/8.2 or X-Powered-By: Next.js. Others betray the platform simply by being there: Shopify, Wix and Vercel add their own headers with request identifiers, and Cloudflare stamps every response with cf-ray.
Many well-maintained sites remove these headers on purpose, because revealing the software and its version saves work for anyone hunting known flaws. It is one of the recommendations covered in the article on HTTP security headers.
The generator tag
Many CMSs write a line such as <meta name="generator" content="WordPress 6.5"> into the <head>. It is the most direct clue, and also the easiest to remove: some plugins and themes strip it out.
File paths
This is the most reliable clue, because changing it would mean rebuilding the site. WordPress serves its images and scripts from /wp-content/ and /wp-includes/. Next.js uses /_next/, Astro /_astro/, and Shopify loads from cdn.shopify.com. Looking at where the stylesheets and scripts come from in the page source is usually enough to identify the platform.
Scripts and their attributes
Front-end frameworks leave marks in the HTML: characteristic attributes, names of root elements, embedded data objects with well-known names. The same goes for libraries such as jQuery or Bootstrap, which are often loaded with their name in the path.
The IP and its autonomous system
The domain resolves to an IP address, and every IP belongs to an autonomous system (ASN): a block of addresses run by one organisation, with its own number. If the ASN belongs to Amazon, Hetzner or OVH, you know where the site is hosted. If it belongs to Cloudflare, all you know is that there is a CDN in front.
Where detection falls short
No detection of this kind is complete, and it pays to read it with judgement:
- Whatever loads later does not show if you only look at the server’s first response. A chat widget, a map or a pixel injected by a tag manager through JavaScript is not in the initial HTML.
- Whatever is hidden on purpose stays hidden. Removing the generator tag and server headers is good practice, and plenty of sites do it.
- The CDN masks the hosting. With Cloudflare in front, the server’s real IP is hidden, which is exactly the point.
- Clues can mislead. A migrated site may keep old paths, or a template may include libraries it no longer uses. One clue is a suspicion; two or three that agree are a reasonable conclusion.
- The exact version is rarely reliable from the outside, and it is not what matters anyway. To judge whether a site is neglected, the date of its latest content says more than a version number.
Why it is worth knowing
Before a migration or redesign. Budget and timeline vary hugely depending on the starting point. Moving one WordPress site to another is nothing like getting a shop out of Wix, where there is no database access, or modernising a site built on an abandoned framework. Knowing the starting platform is the first input to any serious estimate, and it shapes things such as a migration that keeps your rankings.
When you inherit a website. It happens often: the previous agency has vanished, nobody has the documentation, and you need to know what is there before touching anything. External detection gives you a starting point while the access details are tracked down.
To understand competitors. Knowing that a competitor runs Shopify or a custom platform, or serves its site behind a CDN, says something about how much it invests and what it can do that you cannot. The aim is not to copy, but to get a sense of scale.
To assess a supplier. If you are offered “a bespoke website” and the portfolio is built with a template builder, that is a fair question to ask before signing.
Checking a website
Our website technology checker carries out the reading described above: it fetches the page you give it once, reviews its headers and its <head>, and shows you the CMS, framework, server, CDN and hosting it finds. Each result comes with the specific evidence that gave it away, so you can confirm it yourself in the source, and the domain’s IP is shown with its autonomous system so you can tell which provider it lives on or which CDN covers it.
If the result looks thin, try an inner page as well as the home page, and remember that a lack of clues is information too: it usually points to a site someone has configured carefully.
No external tool replaces having a website’s access details and documentation. But ten seconds of well-interpreted reading tells you where you are starting from, and that saves a lot of questions at the first meeting.