How to find out what platform a website is built on

The quickest way to find out what platform a website is built on is to run it through a free detection tool like the Wappalyzer or BuiltWith browser extension, or paste the address into a lookup site such as BuiltWith, W3Techs or WhatCMS. If you want to confirm the result yourself, open the page source and look for telltale file paths: wp-content means WordPress, cdn.shopify.com means Shopify, static.wixstatic.com means Wix and /_next/ means Next.js. HTTP headers, a few common URLs and a DNS lookup fill in the rest. Most sites give themselves away in under a minute, though some hide it on purpose.

Quick reference: the clues for each platform

The rest of this guide explains each method, starting with the easiest.

Method 1: browser extensions

Detection extensions sit in your toolbar and check each page you visit. Click the icon and you get a list of technologies grouped by type: CMS, ecommerce, JavaScript framework, analytics, tag manager, CDN, payment processor and more.

• Wappalyzer. Published by Wappalyzer Pty Ltd, it is available in the Chrome Web Store and for other browsers. It shows icons for each detected technology and often a version number.
• BuiltWith Technology Profiler. BuiltWith's extension gives a similar list from the same data BuiltWith uses on its website.

Extensions are the best choice when you are researching many sites, because you just browse and click. They read the page as your browser loaded it, which means they can catch scripts that only load after the page starts running.

Method 2: lookup websites

If you do not want to install anything, paste the address into a lookup site:

• BuiltWith (builtwith.com) shows the current technology profile, and for many sites a history of tools that were added or removed over time. That history is useful when you want to know whether a competitor recently switched platforms.
• Wappalyzer has a lookup on its website that uses the same detection rules as its extension.
• W3Techs has a site info page where you enter a domain and see the content management system, server software, languages and other technologies it found.
• WhatCMS (whatcms.org) focuses on identifying the CMS. It says it checks pages for thousands of signals, including generator tags, image paths, custom headers and session names.

Free tiers usually limit how many lookups you can run or how much detail you see. Paid plans add bulk lookups, lead lists and exports, which matters more to sales teams than to someone checking one site.

Method 3: read the page source

Tools are pattern matchers. You can match the same patterns yourself. Right-click the page, choose View page source (or press Ctrl+U, Cmd+Option+U on a Mac), then use Find to search the code.

What to search for:

• wp-content or wp-includes. These are WordPress folders for themes, plugins, uploads and core files. If you see them, it is almost certainly WordPress, even if everything else is hidden.
• cdn.shopify.com. Shopify stores load theme files and product images from this domain.
• static.wixstatic.com. Wix serves images and media from here.
• squarespace. Squarespace sites load files from Squarespace domains and include the name in scripts and comments.
• data-wf-page and data-wf-site. Webflow adds these attributes to the page's html tag.
• meta name="generator". Many platforms add a generator tag that names the software, sometimes with a version number. WordPress, Wix, Webflow and many other systems add one by default. Its absence proves nothing, because it is easy to remove.
• /_next/. Next.js serves its JavaScript and CSS from paths that start with /_next/static/. You may also see a script called NEXT_DATA or calls to self.__next_f, depending on the version. We cover the framework in Next.js for business websites.

Tip: if View Source shows very little HTML and lots of scripts, the site may build the page in the browser with JavaScript. In that case, open DevTools (F12) and look at the Elements tab, which shows the page after scripts have run.

Method 4: HTTP headers in DevTools

Every page comes with response headers, small labels the server sends before the content. Some name the software. To see them:

1. Open DevTools (F12) and go to the Network tab.
2. Reload the page.
3. Click the first request (the page itself) and look under Response Headers.

Headers worth checking:

• x-powered-by. Next.js adds x-powered-by: Next.js by default, according to the Next.js docs, though developers can turn it off with one setting. Other stacks use the same header, for example PHP sometimes shows its version here.
• Powered-By. Shopify storefronts send Powered-By: Shopify. Headless Shopify storefronts built on Hydrogen and hosted on Oxygen can show Shopify, Oxygen, Hydrogen, as documented on http.dev.
• Link. WordPress adds a Link header pointing to its REST API, with rel="https://api.w.org/", on front-end pages. The WordPress developer docs describe this, along with a matching link tag in the page head.
• server. This usually names the web server or the edge network (nginx, Apache, cloudflare) rather than the CMS. It tells you more about hosting than about the platform.

Headers change over time. Shopify, for example, used to send an X-ShopId header and has since stopped. Treat any single header as one clue, not proof.

Method 5: try common URL paths

Some platforms use fixed addresses. Add these to the domain and see what happens:

• /wp-admin or /wp-login.php. On WordPress, these usually redirect to a login screen. Look, but do not try to sign in to a site that is not yours.
• /wp-json/. A WordPress site with the REST API turned on returns a page of structured data listing the site name and available routes.
• /products.json or /collections. Many Shopify stores answer on these paths.
• /sitemap.xml. The format and the tool named in the sitemap sometimes reveal the platform or the SEO plugin (Yoast, Rank Math and others sign their sitemaps).

Security-minded site owners often block or rename login paths. We recommend that to our WordPress clients in WordPress security hardening, so a 404 here does not rule anything out.

Method 6: DNS and hosting lookups

This is the step where people mix up two different questions:

• What is it built on? The platform or CMS: WordPress, Shopify, Webflow, a custom Next.js app.
• Who hosts it? The company whose servers deliver the site: WP Engine, SiteGround, Netlify, Vercel, AWS.

A DNS lookup (any free DNS checker, or nslookup in a terminal) shows the site's IP address, CNAME records and nameservers. Those often point to a hosting company or CDN. Hosted platforms like Shopify, Squarespace and Wix run their own servers, so DNS pointing at them is a strong platform clue. But a WordPress site on WP Engine and a Next.js site on Vercel only tell you the host, and a CDN like Cloudflare in front hides even that. See our DNS glossary entry and choosing web hosting for how these pieces fit together.

Why the platform can be hidden

Sometimes every method comes back empty or contradictory. Common reasons:

• Clues were removed on purpose. Generator tags, version numbers and headers are easy to strip, and many security guides recommend it.
• The site is headless. A headless CMS stores the content, and a separate front end, often Next.js or another framework, displays it. Detection tools will spot the framework but may not see Contentful, Sanity or a headless WordPress behind it. Our explainer on what a headless CMS is covers how that works.
• Static exports. Some sites are built with a framework and exported as plain HTML files, leaving few signatures.
• Custom builds. A site written from scratch has no platform to detect.
• Mixed setups. The marketing pages may run on Webflow while the store runs on Shopify on a subdomain. Check each section separately.

When tools disagree, trust what you can see in the source and headers yourself.

Why you would want to know

• Competitor research. Seeing what a competitor runs, and which analytics, chat, booking or review tools they added, shows what they invest in. BuiltWith history can reveal recent platform switches.
• Writing an RFP or briefing an agency. Knowing your current platform, and the platform of sites you admire, helps vendors scope accurately. Our guide to web agency questions and website RFPs lists what to include.
• Planning a redesign. Moving from Wix to WordPress or from WordPress to Shopify affects URLs, redirects and content export. Start with how to choose a website platform and plan the move with redesigning without losing SEO.
• Hiring. If you know the site runs on Webflow or Shopify, you can hire someone who specializes in it instead of a generalist.
• Inheriting a site. New marketing managers often take over a website with no documentation. Identifying the platform is the first step to finding logins, the host and the person who built it.

A simple routine

1. Run the Wappalyzer or BuiltWith extension.
2. View source and search for wp-content, cdn.shopify.com, wixstatic, squarespace, data-wf and /_next/.
3. Check response headers in the Network tab.
4. Try /wp-json/ and /sitemap.xml.
5. Run a DNS lookup to see the host.

If you found the platform and now want to know what a rebuild would take, try our website cost calculator or talk to us about your site.