How to work out what site builder a website is built on

Working out what site builder a website is built on takes a couple of minutes and it changes what you can honestly quote for. A rebuild of a WordPress site with a decade of blog posts and a working contact form plugin is a different job to starting from nothing on a Wix site where none of that content can be exported cleanly. Guess wrong before the call and you either underquote a job that turns out to need far more untangling than you expected, or overquote one that would have been straightforward, and lose it to someone who looked first.

Why the platform changes the job, not just the look

Every site builder has its own idea of what a website is made of, and that shapes what you inherit when you take one over. WordPress stores content in a database that a developer can usually export or migrate, even if the theme and plugins around it are a mess. Wix and Squarespace, by contrast, keep everything inside their own closed system: there is no database handover, no plugin folder to inspect, just a finished page you can look at but not lift content out of in bulk. A joiner in Wakefield whose site was built on Squarespace five years ago is not really asking for a rebuild in the WordPress sense. They are asking you to recreate what exists, by hand, on whatever platform you move them to, which is worth pricing very differently to a WordPress site where the content migrates across.

Start by viewing the page source

Right-click anywhere on the page and choose “view page source”, or press Ctrl+U in most browsers, and you get the raw HTML behind what you are looking at. Search that page for a handful of telltale strings and most sites give themselves away in seconds. WordPress sites nearly always reference wp-content or wp-includes somewhere in their file paths, even on a heavily customised theme. Wix loads assets from static.wixstatic.com or parastorage.com. Squarespace pulls from domains containing squarespace.com or sqsp.net. Shopify stores reference cdn.shopify.com, and Webflow sites load scripts from webflow.io. None of this requires technical skill beyond a Ctrl+F search, and it takes less time than it does to describe.

What the URL structure tells you

The address bar itself is a second clue, and it is worth checking before you even open the source. A WordPress site running WooCommerce often has product URLs containing /product/ or a /wp-json/ path if you try appending it. Shopify stores almost always use /collections/ and /products/ in a fairly rigid pattern, because the platform enforces its own URL structure rather than letting a developer choose one. Wix sites sometimes carry a long, meaningless string of characters somewhere in the URL, a leftover from how the platform generates pages internally. None of these are certainties on their own, but stacked together with what the page source shows, they usually confirm each other.

A browser extension does the same job faster

Once you have done this by hand a few times, a technology-detection browser extension such as Wappalyzer will do the same lookup automatically and flag the platform, along with other details like which analytics tool or booking widget is installed, the moment you land on a page. It is a genuinely useful shortcut once you already understand what it is finding and why, in the same way that reading a speed report properly matters more than the single number at the top, covered in how to test website speed for a client. Knowing how to spot the platform manually means you can still work it out on a site where the extension comes back blank, which does happen on heavily customised builds.

What each platform tells you about the pitch

The platform is not just a technical detail, it is a signal about what kind of rebuild conversation to have. An old WordPress site often comes with specific, nameable problems: an out-of-date theme, a pile of unused plugins, an admin area that takes a visible pause to load, all covered in more depth in old WordPress site problems. A Wix or Squarespace site raises a different set of questions instead: can the business actually add the features they want within the platform's limits, or have they hit a ceiling that only a move to something more flexible will fix. A Shopify store with a slow theme is often a smaller job than either, a theme swap or a cleanup rather than a full rebuild, because the underlying platform is usually sound. Naming the platform correctly in your first email also tends to land better with the business owner than a generic “your website needs updating”, because it shows you actually looked rather than sent the same line to everyone on the list.

Where this fits in a wider audit

Identifying the platform is one line in a proper audit, not the whole of it. It sits alongside speed, mobile behaviour and whether the site has a valid SSL certificate, and it is worth checking early because it changes how you read everything else you find. A cluttered admin area or an odd plugin conflict only makes sense once you know you are looking at WordPress rather than something else entirely. Running through the platform check as one step in a consistent list, rather than an afterthought, is the same discipline covered in a website audit checklist for agencies, where the aim is a result that reads the same way no matter who on the team ran the check.

Patchscout identifies the site builder automatically as part of every audit it runs, alongside speed, mobile behaviour, SSL and Companies House data, so you see it on the results screen rather than working it out by hand for each prospect. The three free searches at app.patchscout.co.uk/signup are enough to see it against a trade and town you already know.