When you want to find what technology a website uses, you are really reading signals. Lookup tools automate that reading at scale; your browser can do it by hand for one site. Both approaches rest on the same evidence, which means they share the same blind spots. Knowing the manual method makes you better at judging any tool’s output, and saves a lookup when you only need one answer.
How lookup tools detect a stack
BuiltWith explains the principle plainly in its FAQ: “Every website gives off ‘signals’ that they are using a particular technology.” It says it indexes the web “in the same way that Google does”, by crawling sites rather than buying data from third parties, and that a free lookup on a domain shows the technologies it uses.
Wappalyzer is another well-known detection tool. Whichever you use, the logic is the same: fetch the page, look for known fingerprints, report the matches. A tool is only as good as its fingerprint library and how recently it visited the site, which is why two tools can return different stacks for the same domain.
That is also the honest answer to anyone hunting for BuiltWith alternatives or Wappalyzer alternatives. The alternative to any of them is the method underneath, and it costs nothing but a few minutes.
Find what technology a website uses by hand: five places to look
These checks need nothing more than a browser and its developer tools. Work through them in order; most stacks give themselves away by the second or third.
| Where to look | What to search for | What it can reveal | Blind spot |
|---|---|---|---|
| Page source | Script and stylesheet paths, generator meta tags | CMS, theme, JavaScript framework, analytics and ad tags | Scripts loaded only after consent or interaction |
| HTTP response headers | Server, caching and CDN headers | Web server, CDN, hosting layer | Headers can be stripped or rewritten |
| Cookies | Cookie names in browser storage | Analytics, consent tools, e-commerce platform, CMS sessions | Many cookies only appear after a login or a purchase step |
| Typical CMS paths | Folders such as /wp-content/ | The content management system | Headless setups hide the CMS behind a separate front end |
/ads.txt | Authorised ad systems | Ad networks and resellers | Lists permissions, not live ads |
Reading the page source and headers
Open the page source and search for src= and href=. The paths that follow are the most reliable clue on the page. A theme folder name, a framework’s bundle file, a tag manager container or an ad network’s script domain all identify themselves. Many CMSs also add a generator meta tag near the top of the <head>, though plenty of sites remove it.
Then open the network panel in developer tools, reload, and click the first document request. The response headers often name the server software or show headers added by a CDN or caching layer. They are easy to remove, so treat a missing header as no information rather than evidence of absence.
One distinction trips people up. “View source” shows the HTML the server sent; the elements panel in developer tools shows the page after JavaScript has run. On a site built with a client-side framework, the raw source can be almost empty while the rendered page is full of components and third-party tags. Check both. The difference between them is itself a clue to how the site is built, and to how much work a search crawler has to do to see the content.
CMS paths, cookies and ads.txt
Content management systems use predictable folder structures. A /wp-content/ path in image or script URLs suggests WordPress; other platforms have their own telltale paths and admin login URLs. Trying a platform’s standard login path will often confirm the CMS, though some sites move or protect it.
Cookies come next. In developer tools, open the storage or application panel and read the cookie names. Analytics tools, consent platforms and e-commerce systems usually set cookies with recognisable prefixes, and a session cookie can name the platform outright.
No single clue is proof. A cookie name can be reused, a folder can be renamed, and a script can be left behind after a tool is dropped. Look for two or three signals that agree before you write anything down, and note where each one came from so that you, or a colleague, can check it again later.
Finally, load /ads.txt. It lists the ad systems a site authorises to sell its inventory, which is the quickest view of its ad tech. Our guide to ads.txt and sellers.json explains each field, and how to check if a website is monetized combines this with affiliate and product signals for a fuller picture of how a site earns.
Why the stack matters for SEO research
Knowing a competitor’s stack is rarely interesting for its own sake. It becomes useful when it explains something else. A site that suddenly changed CMS or front-end framework may also have changed its URLs, rendering or internal links, which is worth knowing if its rankings moved at the same time. A site on a heavy JavaScript framework may be slower to render than a static one. A site whose ad scripts disappeared may have changed its monetization model.
It also helps when you are sizing up a site to buy or compete with. The stack tells you how hard it would be to run, migrate or replicate. Pair it with the sites you actually compete with and you can see whether winners in your niche share a setup, or whether the stack makes no difference at all. Do not assume a platform switch will fix rankings on its own.
The limitation: server-side technology leaves no trace
Everything above depends on signals the site sends to your browser. Technology that runs only on the server, such as a database, a back-office system, an internal search index or an email platform called from the server, may leave nothing visible at all. A site behind a CDN may show the CDN’s headers rather than its own. A headless setup may expose the front-end framework and hide the CMS entirely.
Lookup tools face the same limit, because they read the same signals. Treat their results as “technologies we detected”, not “the full stack”. When a detail matters, such as which CMS a site you are buying runs on, ask the owner and verify in the admin. For more on reading third-party evidence carefully, see the data archive.
Frequently asked questions
How can I tell what CMS a website uses?
Check the page source for CMS paths and a generator meta tag. A /wp-content/ path, for example, suggests WordPress. A lookup tool can confirm it.
How do technology lookup tools work?
They look for signals. BuiltWith says every website gives off signals that it uses a particular technology, and that it indexes the web in the same way Google does.
Can I find a website’s technology without a tool?
Yes. Read the page source, response headers, cookie names, typical CMS paths and the site’s ads.txt file using your browser’s developer tools.
Why do tools miss some technologies?
Server-side or hidden technologies may not leave visible signals in the page or its headers, so neither tools nor manual checks can see them.
The takeaway Source, headers, cookies, CMS paths and ads.txt reveal most of a public stack. Lookup tools read the same signals, so they share the same blind spot: the server side.
