Using Wappalyzer for Competitive Intelligence

Wappalyzer matches public signals in what a website sends: the HTML, the scripts it loads, the response headers, the cookies it sets and a set of other fingerprints. That covers the content system, the front-end framework, the analytics and advertising layer, the consent platform, the chat widget, the payment vendor, the CDN and whatever else the page is obliged to disclose in order to work. It is quick, it is usually right about presence, and for a first pass over a competitor it takes about ten seconds.

What it never sees is anything the page did not send. Databases, queues, message brokers, internal services, the language running on the server and any vendor a company has taken the trouble to serve from its own domain leave no marker to match. That is not a shortcoming of this product specifically; it is the boundary of the whole category, and identifying what a website is built with runs into it whichever tool you reach for.

The part worth understanding before anything else is that two different instruments share the name. One runs inside your browser on the page you have open. The other is a shared index you query, assembled elsewhere and filtered before it reaches you. They will disagree, they are supposed to disagree, and knowing which one produced a given answer is most of the skill in using this source for competitive work.

1. 1Install the extension and settle the sharing switch before you browse. Detection runs locally and needs no account. Sharing is separate: with it on, the extension periodically sends the hostname, the protocol, the technologies found and detection metadata to Wappalyzer, and the privacy policy states that data may be shared or sold as part of its commercial products. Decide that once, in settings, rather than discovering it after a quarter of research inside your own admin tools.
2. 2Read the competitor's public pages, then the ones an index never reaches. Open the marketing site, then the pricing page, the help centre, the status page, the careers site and the trial or free tier if you have legitimate access to one. Because the fingerprint runs on what your browser received, each of those is a separate reading, and they routinely differ. The support subdomain frequently runs vendors the home page does not.
3. 3Run the lookup and treat the gap against the extension as the finding. The lookup returns the indexed answer, which is assembled across several pages of the site and filtered before it reaches you. Compare it against what your extension just showed. Something in the index and not in your browser is usually a technology on a page you did not open, or one that has gone since it was last verified. Something in your browser and not in the index is usually recent.
4. 4Widen the filters on purpose before concluding anything is absent. The documented defaults exclude low-confidence detections and anything not verified in the last couple of months, which is right for building a prospect list and wrong for proving a negative. Turning the confidence filter off returns more and admits more false positives, and reaching further back returns technologies the site may have dropped. Both are useful once you know which one you asked for.
5. 5Put alerts on the rivals you know and a directory check on the ones you do not. Alerts monitor a set you nominated, so they are only as complete as your competitive set was on the day you typed it in. Balance that with a monthly pass over the directory page for the technologies your category sells against, where the ranked alternatives list and the live counts surface products nobody put on your list.

The privacy policy is the clearest statement of how the extension works, and it is worth reading for that reason rather than for the legal content: it says the extension analyses websites locally in your browser to identify technologies, and that no account is needed for basic detection. So the extension is not a thin client asking a server what it thinks about a domain. It is a matcher running against bytes your machine already received.

That one design choice gives it a capability nothing indexed can have. An index reads pages that are publicly reachable. Your browser reads the trial account you legitimately signed up for, the documentation portal that wants a login, the checkout you got three screens into, the regional variant that appeared because of your language settings, and the version of the page that loaded after you accepted cookies. Vendors that only appear in those states are invisible to every external dataset and perfectly visible to you.

Run both on the same competitor and treat the difference as information rather than as a fault. Something in the index and not in your browser is usually a technology living on a page you did not open, or one that has been removed since it was last verified. Something in your browser and not in the index is usually recent, or sits behind a login. Neither result is the tool being wrong.

The published API documentation is where the shared index becomes legible, because it names the filters and states what each one does when you do not set it. Those defaults are documented for the API rather than for the web interface, so read them as the product’s own definition of a good answer rather than as settings you can see. Four of them change what a result means.

The fourth is the counter-intuitive one and it deserves saying out loud: the vendor says its cache is more complete than scanning the site in real time. That is consistent with the rest of the design, since a stored record accumulates across many visits to many pages while a live scan is one pass under a time limit. It also means the instinct to force a fresh read when a result looks wrong will often make the result worse.

There is one thing no combination of these settings will do, which is tell you when a competitor stopped using something. Reaching further back returns technologies that may have gone without saying when, and the vendor documents that trade honestly. A dated first-detected and last-found record is a different product design, and BuiltWith is where that half of the work belongs.

The company describes its method as looking for public signals on websites, and its privacy policy adds the part that matters to a researcher. With sharing enabled, the extension periodically sends limited website-level data about the sites you visit: the hostname, whether the site used HTTP or HTTPS, the technologies detected, and detection metadata such as language, version, root path and hit counts. It states that full page content and full visited URLs are not included, that the data may be used to improve the dataset and may be shared or sold as part of its commercial products, and that the behaviour can be turned off in the extension settings.

Two consequences follow, and they point in opposite directions.

The upside is real coverage nobody else has, particularly of tools that only exist behind a login. The downside is a coverage bias that follows attention: technologies used by people who install browser extensions are over-represented, and a competitor whose customers are not that sort of person is thinly seen. Neither of these is a criticism, but both change how you read a site count.

The part that concerns your own organisation is simpler. An analyst who installs the extension and leaves sharing on spends their week inside your admin tools, your billing system, your staging environments and your internal dashboards, and the hostnames of all of them are website-level data. That is a decision worth making deliberately, once, in the settings, rather than discovering it in a security review.

For most of its life the detection ruleset was public. The fingerprints that decided whether a page was running one content system or another were openly licensed files anybody could read, argue with and contribute to, which meant a detection was auditable: you could go and look at the exact marker that produced it.

That ended in August 2023, and the record of it is checkable rather than anecdotal. The original repository no longer resolves. The package on the public registry has a final published version dated 23 August 2023 and now carries a notice saying it is no longer supported. A copy preserved by a third party, described in its own words as the last commit before the project went private, was created the same day and still carries the original licence. A separate fork maintained by a web-measurement project has been kept current since, which is how a public version of the ruleset survives at all.

It is worth being fair about why this happened rather than treating it as a betrayal. A fingerprint database is expensive to maintain and was funding a commercial product, and every vendor in this category keeps its rules private. Wappalyzer is simply the one where a researcher can remember what having them open felt like.

The browser extension: what is on this page, right now

Free, no account, and the only surface that reads what you personally were served. Use it on the marketing site, then on the pricing page, the help centre, the status page, the careers site and any trial you have legitimate access to. Each one is a separate reading and they differ more often than people expect, because support and documentation subdomains are frequently run by a different team with a different budget.

The technology lookup: what the index holds about a domain

The indexed answer, assembled across several pages of a site rather than from the home page, and filtered by confidence and recency before it reaches you. It is the right surface for comparing several competitors on the same basis, since every one of them was measured the same way. It is the wrong surface for establishing that something is absent.

Website alerts: the only part that watches instead of answering

Nominate sites and get told when the stack on one of them changes, with a handful included free and a slightly larger allowance on the entry tier. A new consent platform, a new payment provider or a new support tool usually appears before the announcement that explains it, so this is a genuine early-warning channel. Its ceiling is that it only ever watches names you typed in.

The public technologies directory: the market view, free

Every tracked technology has a page carrying the number of live sites detected running it, a country and language breakdown as percentages, and a ranked list of the competing technologies in the same category. The vendor gives the directory as several thousand technologies across just over a hundred categories. No account is needed for any of it.

The top-sites list: named companies, in bands rather than figures

Each technology page samples the highest-traffic sites detected running it, with traffic and technology spend expressed as bands rather than numbers. Bands are the honest presentation for a modelled figure, and they are enough for the only question worth asking here, which is whether the reference customers a competitor claims match the ones observably running the product.

Lead lists: the paid inversion of the same index

Instead of asking what one site runs, ask which sites run a given combination, filtered by company attributes and exported with firmographic and contact columns. This is the commercial heart of the product and it is built for prospecting rather than research. The entry paid tier caps you at two technology targets, which is the constraint to check before assuming a subscription will answer a broad competitive question.

The API: the filters, exposed as your decisions

The same data with confidence, verification age, crawl depth and cached-or-live turned into parameters, charged per site looked up, on the higher plan. Its real value to a researcher is not automation but honesty: reading the parameter documentation is the fastest way to understand what the interface has been deciding on your behalf.

The output worth building here is a grid rather than a profile: competitors down the side, the technology categories you care about across the top, and a cell recording what each one runs. A grid makes the interesting thing visible immediately, which is not what any single company uses but which category the whole field has moved on.

The columns, and the one people leave out

Competitor, page checked, category, technology, and then the column that decides whether the sheet is worth anything: how you established it. Extension on the pricing page, indexed lookup at default settings, indexed lookup with the filters widened, and confirmed in the network panel are four different evidence levels. Without that column a row you cannot reproduce in three months looks exactly like one you can.

How it gets filled

Manually for a competitive set of five, which describes most teams, and through a list export or the API once the set runs to hundreds. Where the requirement is continuous rather than periodic, the work worth handing to software is remembering last quarter, which a competitive intelligence platform does and a spreadsheet you have to reopen does not.

What to read once the grid exists

Two readings justify the afternoon. Read down a column to find the category where every rival has converged on one vendor and you have not, which is either a gap or a deliberate refusal you should be able to explain. Then read the row for the competitor you lose to most and check it against a competitive product comparison you already maintain, because a technology they run and you do not is frequently the mechanism behind a claim in their pitch.

Free, and enough for competitor-by-competitor work

The browser extension needs no account at all for basic detection. The public technologies directory, its per-technology site counts, the country and language splits, the ranked alternatives and the top-sites samples are all open. A free account adds a small monthly allowance of technology lookups and a handful of website alerts, which is enough to keep an eye on a short competitive set.

What a paid plan is actually for

Scale and enrichment rather than better detection. The entry tier raises the lookup allowance and the alert count and adds company and contact information to an individual lookup and to the extension. The higher plans open list building, CRM enrichment and the API, and the first of those caps the number of technologies you may target unless you move up again. None of it improves what the fingerprint can see.

The credit rules worth knowing before you budget

API usage is charged in prepaid credits, normally one per website, rising when you ask for a live deep scan rather than a cached answer. Credits included with a plan expire after sixty days and credits bought as a bundle after a year, so an allowance is a monthly rhythm rather than a balance you accumulate. Requests are rate limited, several sites can go in one call, and a deep scan of a site not already indexed can take minutes rather than seconds.

Where access stops mattering

No tier changes the boundary of the category. Paying more returns more rows, more companies and more contact columns, and it will not reveal a database, an internal service or a vendor served from the competitor’s own domain. If that is the question, the money is better spent somewhere else entirely.

Reading what a public page sent to your own browser is ordinary use of a website, and running a local matcher over bytes you already received adds nothing to that. The care needed here is not about the competitor at all. It is about the two directions in which this tool collects from you.

• Your own hostnames go into a commercial dataset. With sharing on, website-level data about everything you visit is sent periodically and may, per the published policy, be shared or sold. A competitive analyst spends their week inside internal tooling, so this is a question for whoever owns security rather than a personal preference, and the setting takes ten seconds to change.
• A trial account comes with terms you accepted. Reading a rival’s public site is unrestricted. Signing up for their product to inspect it is governed by whatever you agreed to at signup, and competitive research and benchmarking are among the uses those agreements most often exclude. Read that clause before the trial, not after somebody quotes what you found.
• Component versions are a finding you handle carefully. Where a version number is exposed, a detection can imply an unpatched component. Noting it is fine. Testing it is unauthorised access, and passing it around a sales team as a talking point is a different kind of mistake that tends to end up in writing.
• A detection is not a claim you can repeat. Telling a buyer that a competitor uses a particular vendor, on the strength of a signature match you cannot inspect, is repeating somebody else’s inference as fact. Confirm it on the page first, and say where it came from.

• When something was removed. The index is tuned to what is current, and reaching backwards returns more results without telling you when any of them ended. Proxy: an archive that stamps every observation with a month, which is a different product design entirely.
• Anything server-side. Languages, databases, queues and internal services never reach a browser, so no fingerprint can reach them. Proxy: their engineering job adverts, their public repositories and their conference talks, which state it directly.
• Vendors served from the competitor’s own domain. Proxying a script through a first-party path removes the marker, and it is exactly the vendors a company cares most about that get this treatment. Proxy: their subprocessor list, which names the vendors handling customer data because contracts require it.
• A rival nobody added. Alerts watch a nominated set, so the whole system inherits your competitive set’s blind spots. Proxy: the ranked alternatives list on a technology page, which is built from detected sites rather than from your assumptions.
• Why they chose any of it. The tool names vendors and never reasons. Proxy: the job adverts posted in the two quarters before a change, which describe the destination and often the motivation.

Monthly for the extension pass and quarterly for the grid. The extension reading costs about five minutes per competitor and is worth doing often because it is the only current answer available anywhere; the indexed comparison moves slowly enough that redoing it monthly produces the same file. Alerts sit underneath both and cover the gap between passes on the rivals you have already named.

Vary which page you check rather than always opening the home page. Marketing sites change vendors slowly and support portals, status pages, careers sites and checkout flows change faster, so rotating through them catches things a home-page habit never will. Record which page each reading came from, because a technology present on one surface and absent on another is a finding rather than a contradiction.

Go back off-cycle when a competitor announces a market you had not seen them in, when your own team reports a capability in a rival’s pitch that you did not think they had, or when an alert fires on any vendor connected to payments, consent or identity. Those three categories change least often and mean most when they do.

Every monitoring surface here starts from a list you wrote. Alerts watch the sites you added, the grid holds the competitors you chose, and the monthly pass covers whoever was on the list when you built it. That works precisely as long as your competitive set is right, and the failure it produces is the quiet kind: not a wrong answer, but a run of clean months while a company nobody had heard of takes deals in a segment you no longer check.

What that costs is not a missed technology. It is the six months of clean reports that made everybody confident, ending in a deal review where a name comes up that nobody in the room can place. Watching a category rather than a list is the specific job competitive intelligence software exists for, and Flares reads the field rather than a set of nominated domains, so an unfamiliar company arrives as a dated observation months before it arrives as a question nobody can answer. The judgement it cannot make for you is which of those names deserves a response, and that still belongs to somebody who knows the market.