How to Find Out What a Website Is Built With (3 Free Routes)

Three routes get you there, and two of them need no tool at all. Read the page source for fingerprints, which means the generator meta tag, the asset paths and the cookie names. Read the HTTP response headers and the DNS records for the server, the host, the CDN and the email provider. Or run a lookup that matches both against a library of known signatures. What none of them reads is the part of a stack that never reaches a visitor, which is most of the back end. That last point matters here because none of the 11,242 listings in the Revised directory as of 16 September 2026 serves a page at all, so for a dropped domain the only readable stack is the one in its archived snapshots.

The reason any of this works is written into the protocol. From RFC 9110, the HTTP semantics specification, section 10.2.4, read on 16 September 2026:

The "Server" header field contains information about the software used by the origin server to handle the request, which is often used by clients to help identify the scope of reported interoperability problems, to work around or tailor requests to avoid particular server limitations, and for analytics regarding server or operating system use.

What fingerprints does a site leave in its own HTML?

The generator meta tag is the most direct one. MDN defines meta name="generator" as "The identifier of the software that generated the page", and plenty of platforms fill it in by default, version number included.

Asset paths are the next most reliable, because a platform has to serve its own files from somewhere and that somewhere is named after it:

Cookie names are the third, and they identify the language or framework rather than the CMS. PHPSESSID is PHP. JSESSIONID is Java. csrftoken with sessionid is Django. laravel_session is Laravel. ASP.NET_SessionId is .NET. _shopify_y is Shopify. Anything starting wordpress_ is WordPress.

Script tags give away the analytics, tag manager, chat widget, error tracker and payment processor, usually by hostname alone.

What do the HTTP headers tell you?

Run one request and read the response headers. The Server header names the web server software, per the specification quoted above. X-Powered-By names the application layer when the framework has not been configured to remove it.

A handful of headers identify infrastructure rather than software. cf-ray and cf-cache-status mean Cloudflare. x-vercel-id means Vercel. x-amz-cf-id means Amazon CloudFront. x-served-by with a Fastly-shaped value means Fastly. x-github-request-id means GitHub Pages.

Set-Cookie in the response is where the cookie names above show up, and it is often more reliable than the HTML because a cached page may be stripped of markup a live response still carries.

What does DNS tell you?

DNS answers a different set of questions from the headers, and the answers are harder to hide.

Name server records identify the DNS provider, which is frequently also the registrar or the CDN. MX records identify the email provider, which is a useful tell about the size and age of an operation. A CNAME on the apex or on www pointing at a platform hostname names the platform outright. A records point into a hosting provider's address range, which a reverse lookup will name.

Four commands cover all of it:

curl -sI https://example.com
curl -s https://example.com | grep -i -E 'generator|wp-content|_next|shopify'
dig +short NS example.com
dig +short MX example.com

What can a technology lookup add?

Scale and history. A lookup service crawls the whole web continuously and matches every page against a library of thousands of signatures, so it recognises patterns you would not think to grep for, and it can tell you what a site ran last year as well as today. Wappalyzer and BuiltWith are the two best-known, and our own technology lookup queries an index of the same kind, free and with no signup.

What a lookup cannot do is see anything the crawler could not. Its result is a floor, not an inventory.

What is undetectable?

The back end, mostly. A site behind a reverse proxy reveals the thing that served the file rather than what ran behind it, and a site exported to static HTML at build time reveals no runtime at all. Note what still shows in both cases: a static build usually keeps its framework's asset paths, so /_astro/ or /_next/static/ will name the generator even when nothing is executing. What goes missing is the layer underneath. A headless setup is the common modern case, where the front end fingerprints cleanly and the content management system behind it leaves no trace on the page.

Deliberately removed signatures are the second category. WordPress exposes a filter for exactly this purpose, documented as the_generator, which "Filters the output of the XHTML generator tag, for display". Any competent build removes or rewrites it, and RFC 9110 recommends the same restraint for headers: "An origin server SHOULD NOT generate a Server header field containing needlessly fine-grained detail."

MDN, on the Server header, puts the practical limit of all this hiding well: "It's debatable whether obscuring the information in this header provides much benefit because fingerprinting server software is possible via other means."

Everything behind a login is the third category, along with anything served differently to crawlers than to browsers. A short result is a limit of detection rather than a verdict about the site.

How do you check what an expired domain used to run?

You cannot check a live response, because there is nothing live. A dropped name resolves nowhere, which makes every header-based and cookie-based method above return nothing.

Archived snapshots are the substitute. Open the Wayback Machine on the name, pick a capture from the site's active years, and view the source of that capture. Generator tags, asset paths and script hostnames are all preserved in the stored HTML, so the platform, the analytics and often the payment processor read straight off it.

Two cautions on reading a capture. Archived pages are frequently incomplete, so an absent fingerprint means the crawler missed the file rather than the site lacking the feature. And the stack you find tells you what the last owner ran, which has no bearing on what you should build, only on whether the surviving link profile points at the kind of pages you intend to publish. Our guides to rebuilding the site on a domain you bought and technical SEO cover the build side, and Core Web Vitals covers the measurements that follow it.

Using the Revised directory for this

1. Run any live domain through the technology lookup for its stack by category, and read a short result as detection failing rather than as a simple site.
2. Open the directory to see the dropped names themselves. As of 16 September 2026 it holds 11,242 listings across 30 top-level domains, all confirmed expired and available, with 11,242 of them re-checked for availability inside the last 30 days.
3. Read archived site history rather than a live response on anything listed. The expired domain checker returns current registration status, the archived snapshot count and the span of years the site was captured, which is what tells you whether there is a stack in the archive to read at all.
4. Start from newly listed domains when you want names whose captures are most likely to still be complete, or from expired .com domains, which holds 8,278 of the listings with 6,943 passing a low spam screen.
5. Filter to Open listings to work with named domains for nothing. 3,373 of the 11,242 listings, about 30%, show the name and the exact counts with no account, and 2,201 of the 8,278 .com listings are open. Search and filters need no account, and the free plan reveals 10 masked names a month.
6. Read the referring domains in the backlink checker before the stack. What linked a site matters more than what it was built on, and every listing here is spam-screened before it goes up.

FAQ

How do I find out what a website is built with for free? Read the page source for a generator meta tag, asset paths like /wp-content/ or /_next/static/, and script hostnames. Then run curl -sI on the URL and read the Server, X-Powered-By and Set-Cookie headers. Both are free and need nothing installed beyond curl.

How can I tell if a site is WordPress? Look for /wp-content/ or /wp-includes/ in asset URLs, a /wp-json/ route, or a cookie starting wordpress_. The generator meta tag says so outright when it has not been removed, and it can be removed with a one-line filter, so its absence proves nothing.

Can I see what CMS a site uses if they hide it? Often, yes. Generator tags and server headers are easy to strip, but asset paths, cookie names and platform hostnames are load-bearing and much harder to disguise. A static export behind a proxy hides the runtime and the origin, and usually still names the framework through its asset paths.

Does the technology a site uses affect its SEO? Only through what it produces. Search engines read the HTML, the response times and the status codes, not the platform name. A slow or badly configured build on any stack ranks worse than a careful one on the same stack.

How do I find out what an expired domain used to run? Open its archived snapshots and view the source of a capture from the site's active years. A dropped domain resolves nowhere, so there is no live response to read, and the stored HTML is the only record of the old stack.

Why does a lookup show fewer technologies than I expected? Because detection only sees what a crawler received. Anything behind a login, anything loaded after the crawl, and any signature the site removed will be missing. Treat the result as a minimum.