How to Find What Technology a Website Uses: 11 Methods

Search this question and you will be handed a browser extension. As an opening move that is fine, and as the whole answer it is not. An extension reads what the page sent your browser and matches it against a signature list, which covers the analytics, the tag manager, the CDN, the site builder and the front-end framework in about ten seconds. It cannot see anything the page did not send, and a large share of what people mean by “what technology a website uses” was never sent.

The eleven methods below are ordered by how much work they take rather than by how good they are. The three free checks that follow the extension, page source, response headers and public DNS, resolve most disagreements in under five minutes and cost nothing.

1. 1Write down which of the five questions you are asking. CMS, JavaScript framework, hosting, CDN and server-side language are five separate questions with five separate methods, and only four of them reliably have an answer. Deciding first is what stops you accepting whatever a tool happens to print.
2. 2Run two lookup tools and treat the disagreement as the finding. Two fingerprint-based products looking at the same page will not return the same list. Anything both agree on is safe. Anything only one reports is a hypothesis you now check by hand, and it is usually either a removed technology still sitting in a stale profile or a self-hosted one that only the other tool recognised.
3. 3Read the page source for the generator tag and the asset paths. Search the raw HTML for the word generator rather than for a full attribute, because attribute order varies between platforms. Then look at where images, stylesheets and scripts are served from: a path containing a platform's own directory name identifies the publisher more reliably than any meta tag.
4. 4Open the network panel and read the response headers. Reload with developer tools open, click the first document request and read its response headers. The server and CDN usually name themselves. Then sort the request list by host: each host outside their own domain is a supplier somebody signed a contract with, and the list is complete in a way a detection profile never is.
5. 5Try the platform's own giveaway URLs. Named platforms answer for themselves. A site running the most common CMS responds at its JSON endpoint and its login path, exposes a predictable feed, and serves its uploads from a directory with its name in it. One request settles a question two detectors disagreed about.
6. 6Query public DNS and read the certificate. The address record and the network behind it identify the hosting provider, the mail records name the email platform, and the text records list the SaaS vendors that required domain verification. The certificate adds the issuer, and the public certificate logs add every hostname the organisation has ever certificated.
7. 7Record the method and the date beside every technology you write down. A technology list with no date is unusable within a quarter, and a list with no method cannot be rechecked or challenged. Two columns, technology and how you established it, is the difference between a finding somebody can act on and a screenshot of a browser extension.

Everything on this page rests on one boundary. Your browser receives an HTML document and then fetches whatever that document asks for. Every identification method available to you, tools included, works on that material. Technology that never appears in it is invisible, and no amount of checking changes that.

That result is the whole shape of this problem in one measurement. The layer that identifies itself readily is the one closest to the visitor, and it is also the layer that changes most often and matters least. The further you go from the browser, the quieter it gets, until at the database there is nothing to hear at all. Everything in the bottom three rows of that table has to come from somewhere other than a browser, and in practice it comes from what a company writes when it needs to hire, which is covered under job postings as a source. A second finding sits inside the first: the marketing site sits on an edge platform in most of these cases, which tells you it is built and deployed separately from whatever runs behind the login.

People type seven different questions into this search and get one generic answer. Routing the question to the right method first takes ten seconds and saves you from accepting a partial answer as a complete one.

This is asked more often than every other version of the question combined, and it has an unusually clean answer, so it is worth doing separately. Start with the prior. W3Techs reported on 7 August 2026 that the most widely used content management system runs 41.2% of all websites and holds a 59.1% share among sites that use a content system at all, with 30.4% of sites using none of the systems it monitors. Before you check anything, the base rate is already in favour of a yes.

Six tells, any one of which is close to conclusive:

• A generator line in the page source naming the platform, frequently with the version number attached.
• Images, themes and plugin assets served from the platform’s own content directory, which appears in the URL of almost every asset on a default installation.
• Its JSON endpoint returning structured data rather than a not-found page.
• Its standard login path resolving to the familiar sign-in form.
• A feed at the conventional address, which most installations expose without being asked.
• Class names on the body element that the platform generates, naming the page type and the template.

The caveat is the one nobody writes down. A headless installation keeps the content system as an editing back end and serves visitors from a separate front end, which emits none of those six tells. So a positive result is strong evidence and a negative result is weak evidence, and the honest way to report it is that the public front end shows no sign of the platform rather than that the company does not use it.

These products work by fingerprinting. Each technology has a set of signatures, a script filename, a cookie name, a header value, a variable the page defines, and the tool reports whatever matches. That design produces one reliable behaviour and three predictable failures.

It is worth knowing what these companies sell, because it explains what they optimise. The large lookup services are prospecting products: their published positioning is about building lists of companies that have adopted a technology, and one states that it covers more than 125,000 of them. Breadth of coverage and speed of detecting an addition are what that business needs. Detecting a removal earns nothing, which is precisely why removals lag, and why a researcher and a lead-generation product want different things from the same database.

Survey services answer a different question again, and their numbers will not match a per-site lookup. W3Techs publishes its methodology: it surveys what it calls the relevant web, excluding sites with no meaningful content and duplicates, ranks using Google’s Chrome User Experience Report together with a customised Tranco list, and treats a website rather than a page as the unit, folding subdomains into their parent. So its figures describe a defined sample of sites, not the site in front of you. Its own server-side language table makes the point exactly: the leading language is given as a share of the websites whose server-side language is known, which is a much smaller population than the web.

1. Technology lookup tools

Install one as an extension and keep a second as a web lookup so you are never relying on one signature set. Read the result as a list of candidates rather than as an inventory. The fields worth taking seriously are the ones with an obvious marker: analytics, tag managers, consent platforms, chat widgets, CDNs and site builders. The fields worth distrusting are anything described as a server technology, which is generally inferred from a header the site did not have to send.

2. The page source and its generator tag

Open the raw HTML and search for the word generator on its own, not for a full attribute, because platforms write those attributes in different orders and a search for the exact string will miss some of them. Where it exists it names the publishing system in one line and often the version too. Then read the asset paths: the directory a site serves its images and stylesheets from is frequently more diagnostic than any tag, because it survives when somebody strips the tag for security reasons.

3. Browser developer tools

Reload with the network panel open and group what comes back by the host that served it. Each separate host outside their own domain is a supplier somebody chose and pays for, and that inventory is complete in a way no detection profile is, because it is what actually happened rather than what matched a pattern. Accept the consent banner and reload a second time: a great deal of a site’s third-party estate only loads after consent, which is why an extension that fires on first paint under-reports.

4. HTTP response headers

Click the first document request in the network panel and read its response headers. The server and CDN normally name themselves, security headers hint at the framework generating them, and the cookie names in the set-cookie lines identify vendors directly, because most platforms use a distinctive prefix. As the thirty-site check above shows, what you will almost never see here is a language, and its absence is the norm rather than a sign of unusual secrecy.

5. Platform-specific paths and well-known files

Named platforms answer for themselves if you ask at the right address. Content systems expose predictable endpoints, login paths and feeds. Beyond that, the standardised security contact file tells you who handles vulnerability reports and sometimes which security platform they use, and a humans file, where a team bothered to write one, occasionally lists the entire stack in plain language because it was written for humans rather than for you.

6. robots.txt and the XML sitemap

Two files most people skip and both are diagnostic. The disallow list in robots.txt routinely names the admin area of the software running the site, since that is precisely what a site owner wants kept out of search. The sitemap gives you the real URL structure, and URL patterns are platform fingerprints in themselves. The sitemap also tells you how large the site actually is, which is a useful correction when a competitor’s navigation implies far more content than exists.

7. Public DNS records

DNS is published for the entire internet to read, so querying it is as public as reading a phone book. The address record and the network that owns that address identify the host. The mail records name the email platform. The name server records name whoever runs their DNS, which is often their CDN. And the text records are the quiet goldmine: a great many business platforms refuse to activate an account until the customer publishes a short proof string in exactly this place, which turns the record set into a signup list the company wrote itself.

8. The TLS certificate and public certificate logs

Click the padlock and read the certificate: the issuer identifies the certificate provider, and the subject alternative names list every hostname the certificate covers. Then go further. Certificates are logged publicly and permanently by design, so a search of those logs returns every hostname ever certificated for a domain. Subdomain names are unusually honest about internal tooling, because nobody chooses them for marketing reasons, and this is the single method on this page that most often surprises people.

9. Their public repositories and package manifests

Where a company publishes its site or its libraries in the open, the guessing stops. A dependency manifest is an exact, versioned list written by the people who built the thing, and the commit history dates every addition. This is uncommon for marketing sites and common for developer-facing companies, so check it first when the competitor sells to engineers and skip it quickly when they do not.

10. Archived copies of the same pages

Every other method on this list describes today. An archived capture of the same address carries the generator tag, the asset paths and much of the third-party JavaScript that were live on the day it was taken, so comparing an old capture with the current page dates a migration to within a crawl or two. That date is usually the interesting part: a marketing site moving from a builder to a framework almost always means an engineering team took ownership, and that has consequences for how fast the competitor can now ship a landing page.

11. Aggregate technology surveys

The wrong tool for one site and the right tool for a market. A survey service tells you what share of a defined sample uses each system, which converts “they use an unusual platform” from an impression into a number. Use it to set expectations before you look, to sanity-check a surprising finding, and to answer the category-level question of what your buyers are most likely running, which matters when you are deciding which integrations to build.

1. 1Find the request. If a tool reports a vendor, the page should be talking to that vendor. Filter the network panel by the vendor’s domain and reload. No request, no current relationship, whatever the profile says.
2. 2Check more than one page type. A home page, a pricing page, a blog post and a documentation page are frequently four different systems on one domain. A finding from a single page describes that page.
3. 3Reload after accepting consent. Marketing and analytics vendors are commonly held back until a visitor consents, so a first load in a strict privacy region shows a fraction of the real estate.
4. 4Prefer a statement over an inference. A generator tag, a dependency file or a company’s own engineering post is the organisation saying what it runs. That is worth more than any number of matched signatures and it can be quoted without a caveat.
5. 5Write down how you know. Beside every technology, record the method and the date. A list you cannot re-derive is a list nobody can challenge or refresh, which means it will quietly go stale and still be cited.

The distinction that matters here is between asking a server for something it publishes and asking it for something it does not. The first is what the web is; the second is where computer misuse legislation starts, and the boundary is closer on this topic than on any other in this cluster because the methods look so similar from the outside.

• Published means published, in every direction. A page, its assets, its robots file, its sitemap, its DNS records and its certificate logs are all offered to anybody who asks. Reading them, at the pace a person reads, is unremarkable and needs no justification.
• Guessing at addresses is where care begins. Requesting a documented endpoint is fine. Working through a list of likely admin paths, or trying default credentials on the login page you found, is not research and no competitive question makes it one.
• Never test what you do not own. Vulnerability scanning, port scanning and anything that puts load on a site you have no relationship with are unauthorised access questions in most jurisdictions. The correct response to noticing a genuine flaw is the contact in their security file, not a note in a competitive document.
• An account you hold comes with terms. Inspecting a competitor’s product while signed in as a paying customer falls under the agreement you accepted, and those agreements frequently restrict benchmarking and republication. Signing up under a false company to see more is misrepresentation, and it reads badly in exactly the situations where the research gets scrutinised.

• The application behind the login. Everything here describes a marketing site, which is usually built and deployed separately. Proxy: their API reference, their developer documentation and the component list on their status page, which is the closest public description of how the product is divided up.
• Which detected vendors they actually pay for. A tag can be a free tier, a trial or a leftover. Proxy: the vendor’s own customer list and case studies, which name paying accounts because that is what a case study is for.
• How the site is built and deployed. Build tooling, deployment pipeline and testing leave no trace in a response. Proxy: their public repositories where they exist, and their engineering writing, which is often surprisingly candid because it is a recruiting asset.
• Whether a technology is used everywhere or once. One page tells you about one page, and experiments run on a fraction of visitors are invisible to a single load. Proxy: check four different page types, and check twice from different sessions.
• When they adopted or dropped something. A live page has no memory and detection profiles record their own observation date rather than the event. Proxy: archived captures of the same address, which carry the tags and asset paths that were live on the day.

Re-run the full pass quarterly and keep it to fifteen minutes: two lookup tools, the generator tag, the response headers, the network domain list and the DNS text records. Record the result in the same two-column form every time, technology and how you established it, so the comparison against last quarter is mechanical rather than a re-reading.

Between passes, three things are worth noticing when they happen rather than three months later: a new consent or payments vendor, which usually precedes a new market; a new verification string in their DNS text records, which means a service was purchased; and the generator tag changing or vanishing, which means the site itself was rebuilt. Keep the output beside the rest of the product picture in a competitor teardown, and remember that a technology list is an input to a commercial question rather than an answer to one, which is the difference between a detection report and product intelligence.

The awkward property of this work is that the finding is cheap and the timing is everything. It takes ten minutes to establish what a competitor’s site runs today, and that answer is worth very little on its own. What is worth something is the week a payments vendor appears alongside a new currency selector, or the week their marketing site stops emitting a builder’s generator tag, because both of those are decisions with months of work already behind them. A quarterly check finds the finished result and misses the decision, and nobody is going to load a rival’s network panel every Monday to catch it.

Noticing small published changes across several competitors, continuously, is the part of this job that rewards software over discipline, which is what competitive intelligence software is for. Flares follows the surfaces a company controls, their pages, their documentation and their published changes, and raises the ones that moved, so a quiet change arrives as an event rather than as something you find later while looking for something else. The login remains a wall and stays one. No monitoring product knows what database a competitor runs, and anybody claiming otherwise is reading the same headers you are.