How to Use BuiltWith for Competitor Analysis

BuiltWith is usually described as a technology checker, which undersells it and sends people to the wrong page. A checker answers what is running on a site now. This is an archive of what its indexers have observed on a domain since the early 2000s, and every observation is stamped with a month. That single difference changes what the source is good for: not identification, which a free browser extension does adequately in ten seconds, but chronology, which nothing that reads the live page can produce at all.

The company’s published answer about provenance matters here, because it is unusual. It states that it indexes the internet the way a search engine does, refreshing across billions of pages weekly, and that it takes no data from third parties. So the record is first-hand and its coverage does not depend on anybody having visited the site. The cost of that design is that it can be refused: a domain that blocks traffic from cloud networks or from identified indexing bots gets tagged as returning an error, which is far more useful than a silently short profile.

What it cannot give you is the present tense with any precision, and that is worth being blunt about. A last-found month says a technology was seen at some point in that month, not that it is there this afternoon. If the question is simply what one website is built with today, the browser answers it faster and more reliably. Come here for when something arrived, how long it lasted, and what went in its place.

1. 1Open the detailed profile rather than the summary. The short profile lists what is currently detected and reads like every other technology checker. The detailed view is the one that carries the history, and it is a separate page. Go there first, because everything worth having on this source lives in columns the summary does not print.
2. 2Read the two date columns before you read any technology name. First detected and last found sit to the right of each row. Read them as a pair and the row stops being an inventory entry and becomes a lifespan. A vendor that arrived four years ago and is still found last month is embedded. One that arrived and left inside seven months was an experiment that failed.
3. 3Filter down to what has been removed. The profile has a control for hiding removed technologies, which means it also has one for showing only those. Turn it the other way and you are looking at a list of decisions a competitor made and then reversed, each with the month it ended. Nothing else in competitive research hands you that.
4. 4Work the rows that show categories and dates but no name. Without a paid account most rows read as an upgrade prompt where the vendor name should be, and every one of them still shows its full category tags and both dates. A row tagged marketing automation, lead scoring and account based marketing, running from March 2022 to September 2025, narrows to a handful of products before you have spent anything.
5. 5Open the relationship profile and the subdomain roster. The relationship tab lists other sites sharing a technology identifier or a host with this one, which is how a company's second brand, its regional sites and sometimes its agency surface. The subdomain roster underneath is a list of hostnames the indexers have seen, and product names appear there before they appear anywhere else.
6. 6Take any interesting technology to its trends page. A profile answers a question about one company. The trends page for a single technology answers the market version of it: how many sites run it now, how many have dropped it, and where those sites are. Live against expired is the honest way to read whether something is gaining or shedding.
7. 7Pull the profile as a file. The domain feed returns the same record as JSON, XML, CSV or XLSX, and a report built on a paid plan exports to CSV or Excel with nothing held back. Take the four date fields with it. They are what makes the file worth keeping rather than a snapshot you will re-take next quarter.
8. 8Date your own copy and diff it next quarter. Save the file with the date you pulled it. One file is a description; two files three months apart are a change log, and the change log is what you actually brief anybody on. The archive holds the past well and it will not tell you which of last quarter's changes mattered to you.

Two columns sit to the right of every technology on a profile: the month it was first detected and the month it was last found. Most people scan past them to read the vendor names, which is exactly backwards. The names describe a company’s taste. The interval between the dates describes its decisions, and a decision is what you are actually trying to brief somebody on.

Read the pair as a lifespan and four readings fall out of it immediately, none of which require you to recognise a single product name.

The migration pattern is the most valuable of the four because it dates an event to within a month without anyone announcing it. One technology’s last-found month sitting beside another’s first-detected month, in the same category, is a platform change. Line that month up against their funding, their hiring and their leadership changes and you usually have the reason as well as the date.

Every fingerprint-based tool has the same structural blind spot: a signature only fires on something that is still present, so removals are invisible by construction. You cannot detect an absence you were never told to look for. An archive does not have that problem, because it kept the earlier observation and simply stopped adding to it, and the profile marks those rows and offers a filter that isolates them.

The volume involved surprises people. Reading the free detailed profiles of five business software companies on 6 September 2026 returned 234, 373, 330, 440 and 378 rows carrying a date pair, and 113, 80, 69, 192 and 136 of those respectively were flagged as no longer detected. That is 590 removals out of 1,755 rows, so roughly a third of everything the archive held about those companies was a record of something they had stopped running. Anyone can repeat the count on their own competitive set in about fifteen minutes.

Three removal patterns pay for the time. A paid category emptying with nothing replacing it is a budget decision, and it clusters with other cost signals. A vendor disappearing from several rivals’ profiles within the same two quarters is a category losing, which is worth knowing whether you sell into it or buy from it. And a vendor disappearing from exactly one rival while everyone else keeps it is the interesting case: either they built it themselves, which their engineering job adverts will confirm, or they had a bad experience that your sales team can ask about.

BuiltWith states on its own plans page that individual site lookups are free forever, and the free tier is more generous than the paywall makes it look, because of what it chooses to withhold. It withholds names. It does not withhold the rest of the row.

On each of the five domains checked on 6 September 2026 the profile named exactly twenty-one technologies and replaced every subsequent name with an upgrade prompt. On the largest of the five that left 419 rows unnamed. Every one of those rows still displayed its full category tags, its first-detected month and its last-found month, and on a mature company the categories are specific enough to do most of the identification for you.

The practical consequence is a different reading order from the one the page invites. Sort or scan by date rather than by name, work the categories on the unnamed rows, and pay for a plan only when you need the names across a whole list of companies rather than one. For a single competitor the free profile carries the entire chronology; what a plan buys is breadth and the ability to turn the archive sideways and ask which companies match a pattern.

The detailed profile: the only tab that carries the history

There are two views of a domain and the short one is a trap, because it prints what is currently detected and looks like every other technology checker. The detailed view is a separate page and it is the one holding the date columns, the removal markers and the filters for hiding removed, free or established technologies. If a workflow starts anywhere else it throws away the only thing this source has that the alternatives do not.

The relationship profile: which other websites belong to the same operator

This tab lists other sites sharing one of the domain’s technology identifiers, such as an analytics or advertising account number, and other sites sharing its host. BuiltWith states that it tracks hundreds of such identifiers back to 2010. The competitive value is that account numbers are administrative rather than public-facing, so nobody thinks to change them: a second brand, a regional storefront, an acquired company that was never fully migrated and occasionally the agency that built all of them share one number and surface in one list.

The subdomain roster and the redirect record

Underneath the technology tables sits a roster of every hostname the indexers have encountered under the domain, which on a large company runs to hundreds and includes staging, development, administrative and internal names. Read as a whole it maps how the engineering organisation is arranged. Read for names nobody recognises it occasionally carries a product months before its announcement. The redirect record beside it catches the other structural event worth knowing about, which is a company quietly moving its primary domain.

Trends: the same question asked about a market instead of a company

Each technology has its own page carrying live, expired and combined site counts, split by country. The pairing of live against expired is the useful part and it is rarely quoted: a product with a large live count and a larger expired one is being shed, and a product with a small live count and almost no expired history is either new or sticky. Neither number is a market share, since the denominator is the set of sites BuiltWith indexes rather than the set of buyers, but the direction is real and it is free.

Meta and spend: the modelled columns, and how far to trust them

The meta side of a paid report adds the company name, its location, verified telephone numbers, social profiles, traffic ranks from four independent providers, a technology spend figure and, for retail sites, an estimated sales revenue. The two money columns are models and BuiltWith describes them as such: spend is the summed average cost of the paid technologies it detected, and revenue is inferred from the store’s age, traffic, commerce dependence, tool mix and market. Both work as a sorting key across a list. Neither is quotable as a figure about one company.

Very few competitive sources hand the underlying record over, and this one does, which changes the shape of the work. BuiltWith says plainly that no data is locked into the tool: a single domain has a feed returning the profile as JSON, XML, CSV or XLSX, and any report built on a plan exports to CSV or Excel. So the sensible artefact is not a screenshot of a profile but a dated file you keep.

The columns, and why two of them are the file

Company, technology, category, first detected, last found, whether the row is marked as gone, whether it is a paid technology, and the date you pulled the file. First detected and last found are the two doing the work and everything else is context for them. Add a column for the unnamed rows recording their category string verbatim, because that string is what you will reason from later and it is not recoverable once you have moved on.

How it gets filled

By the vendor’s own feed for one domain, or by a report export for a list of them, and both are ordinary product features rather than anything clever. Where the set of competitors is large enough that a quarterly pass quietly stops happening, what breaks is remembering the previous file rather than fetching the new one. A competitive intelligence platform keeps that baseline and reports the difference, which is the step nobody does by hand once the set passes about a dozen companies.

What the file is for once you have two of them

One file describes a company. Two files a quarter apart describe a company changing, and only the second thing is briefable. Diff them and three questions answer themselves: what appeared, what went, and which categories moved for more than one competitor at once. The third of those is the only one describing the market rather than a company, and it is what lets a competitor teardown argue from evidence rather than from impressions.

What a researcher gets without paying anything

The detailed profile with every date, the removal markers and their filter, the relationship tab, the subdomain roster, the redirect record, the trends page for any technology and the single-domain feed in four formats. No account is required to read a profile. For competitor work done one company at a time, that is close to the whole product.

What the free tier actually withholds

Names beyond roughly the first twenty on each profile, unlimited detailed reports, and the entire list-building side: asking which companies use a technology, filtering that list by size, country, vertical or spend, and exporting it. The plans differ mainly on how many technologies you may build reports around, with the entry tier limited to two and the higher ones unlimited, and on how many people can log in.

The one-off report route, published by the vendor

BuiltWith answers this in its own frequently asked questions rather than making you work it out: take the entry plan, build the report you need, export it and cancel, subject to a one-month minimum term. Cancelling leaves the account active to the end of the period and reports are frozen rather than deleted if you drop back to free. For a piece of research with a deadline that is a genuinely reasonable arrangement, and it is worth knowing before somebody budgets for a year.

Where the record itself stops

The resolution is monthly, so nothing here dates an event more precisely than that. Coverage depends on the indexers being allowed in, and a blocked domain is tagged rather than absent. And a company can ask to be removed through a published process, which means an empty profile is not evidence of a simple stack. Check for the block tag before drawing any conclusion from a short list.

Reading a technology profile is unremarkable: it describes publicly served pages and the company doing the indexing carries that burden, not you. Two specific things on this platform are a different activity from research, and both are easy to reach by accident because they sit one tab away from the part that is fine.

• The meta export carries named individuals. Alongside the technology columns it offers people: names, titles and email addresses found on company websites, which BuiltWith says it supplies within data protection restrictions and states it has not held personal information about people in the EU without consent since May 2018. The moment you export that column you are processing personal data for a purpose your own privacy notice has to cover, and a competitive research file is not usually the basis anybody registered.
• Uploading your customer list is a disclosure. Feeding your own accounts in to see what they run is a real and legitimate technique, and it also hands a third party a list of who your customers are. BuiltWith publishes what happens to it: additional columns are discarded, root domains are extracted, the list is held for thirty days and then deleted, and it is encrypted on audited infrastructure. That is a reasonable set of commitments and it is still a decision that belongs with whoever signed your customer contracts.
• A discovered hostname is a list to read, not an address to try. The subdomain roster is published information and reading it is ordinary research. Connecting to the internal names on it to see what responds is a security exercise, and one that needs written authorisation from the company that owns them. The line is easy to see from a distance and easy to drift across when a name looks interesting.

• The product itself. Anything requiring an account, from the admin console to the logged-in application, is never indexed, so the whole record describes a marketing site. Proxy: a trial account read in your own browser, where a local fingerprint sees what you were actually served.
• What is running today. Monthly resolution and weekly refreshes mean the newest row can be several weeks behind reality. Proxy: open the page and read the response headers and network panel, which cost two minutes and are current by definition.
• Why anything changed. The archive dates a migration and is silent on the reason for it. Proxy: their engineering job adverts from the two quarters before the switch, which usually name the destination.
• What they pay. The spend column is built from average list prices, and enterprise software is not bought at list. Proxy: public contract awards and marketplace listings, where real negotiated prices are published.
• Anything about a company that refuses the indexers. A blocked domain is tagged and stays thin no matter how long you wait. Proxy: read the page yourself, and treat the block itself as a small finding about how they run security.

Quarterly is the right cadence and it is set by the source rather than by preference. The record has monthly resolution and refreshes weekly, so checking fortnightly produces the same file with a different date on it. Pull the profile for each competitor, save it with the day you pulled it, and diff against the previous file rather than reading the newest one on its own.

Three things are worth a note in the log each time: technologies that appeared, technologies whose last-found month has stopped advancing, and any category that moved for more than one competitor at once. The third is the only one that describes the market rather than a company, and it is the one nobody records because it is invisible unless you are holding several profiles side by side.

Go back off-cycle on four triggers: a competitor raises money, a competitor announces a product in a category their profile has never carried, a vendor you both use has an incident, or your own win rate against one rival moves without an obvious explanation. That last one is the one teams never think to check, because a finished migration is a common and completely invisible reason for a competitor to start winning differently.

The archive is excellent at the past and structurally late about the present. A competitor adds a consent platform in the first week of March; the indexers pass at some point that month; the row appears with a March date; you open the profile in July during your quarterly pass and learn about a change that was four months old when you found it. Nothing here is broken. It is simply a record built to be complete rather than fast, and the gap between those two goals is measured in the weeks where a decision would still have been useful.

The cost lands unevenly. Knowing a rival changed analytics providers four months late costs nothing. Knowing four months late that they added a payments vendor for a currency they had never supported, or a compliance tool for a market they had never sold into, means the market entry you could have contested happened while you were waiting for a crawl. Closing that gap across pricing, product, documentation, messaging and hiring is the standing job of competitive intelligence software , and Flares reports those changes carrying the date they happened rather than the date somebody eventually noticed. No platform decides which of them matters. A new vendor in a rival’s stack is a fact; whether it threatens your next quarter is a judgement that needs somebody who knows what you sell.