Which technology categories are detected reliably from a company website

Technographics collected from a company website are strong in some technology categories and silent in others, and the difference follows from where a tool leaves public evidence. This post sorts the categories into three groups: those detected reliably from a company website or its DNS records, those detected only in part, and those a public website never names. For each group it gives the evidence to expect, how to read a row, and the second source that covers the rest. A worked example and a test to run on sample data follow.

Which technology categories are detected reliably from a company website

The technology categories detected reliably from a company website are those whose code runs in the visitor's browser: analytics, advertising pixels, tag managers, consent tools, chat, and commerce and content platforms. DNS adds the email provider and the vendors a domain has verified itself with. Server software shows in part, and internal systems such as ERP stay hidden.

The split has a mechanical cause. Wappalyzer's article on hiding technologies from its detection draws the line from the scanner's side: client-side code has to be sent to the browser, so it can always be found, while server-side technologies are easier to hide. Technographic data inherits that line, and the table sets it out by category.

Reliable here means that presence on the page is observable, which is the measure behind a fit rule or an installed base estimate. The middle rows are partial for reasons set out below.

In Fokals data the evidence is on the row. Technology Stack, in the marketing stack dataset, recognises 6,298 technologies in 69 categories, and each row records which kinds of evidence showed the technology: page content, scripts, network requests, response headers or DNS records. A reader can separate a tag running on a page from a service declared in DNS. The post on what a Fokals technology row tells you shows how to read one.

How technographic data vendors detect which software a company uses

Technographic data vendors detect which software a company uses along three main public routes. A website read matches known signatures in page source, scripts, network requests, response headers and cookies. A DNS lookup reads the mail and verification records of the domain. Job postings name the tools a role works with. Each route sees different categories.

Vendors document their routes in different depth.

The route decides the category. A website read and a DNS lookup observe what a company runs in public, and they serve the customer-facing stack and the mail and domain layer. A posting is the employer's own statement, and it serves the tools used inside the company.

Website technology detection in Wappalyzer's terms: source, headers and cookies, with DNS beside them

Website technology detection, in Wappalyzer's terms, matches fingerprints in a site's source code, scripts, HTTP headers, cookies and JavaScript variables. The technologies detectable this way are those that mark the page or the response. DNS is a separate public record that adds mail and verification evidence. The limitations lie where the site owner controls the signal.

Each kind of evidence has a standard behind it.

• Source and scripts. The page as served and the scripts it loads. Wappalyzer's guide treats the generator meta tag in the page source as the first place to look when working out a CMS. A browser has to receive this evidence, which is why the first two rows of the table are reliable.
• Headers. RFC 9110 defines the Server header as information about the software an origin server uses. A server may send it, and the standard says it should not carry needlessly fine-grained detail. Wappalyzer says Apache and Nginx can be identified from this header, and that a site can switch off the version number the header carries by default.
• Cookies. Under RFC 6265 a server sets a cookie with a Set-Cookie header in its response. Wappalyzer says PHP can be identified by its default session cookie and by the file extension in URLs, and that renaming the cookie and rewriting the URLs make PHP harder to detect.
• DNS. Under RFC 5321 a mail sender looks first for a domain's MX record, and Microsoft's DNS guide for Microsoft 365 calls the MX record the one that specifies where a domain's email should go. RFC 7208 defines the SPF record, a TXT record that declares which hosts are authorised to use a domain name in the HELO and MAIL FROM identities of the mail they send, and its include mechanism lets a domain designate administratively independent domains. Microsoft's value for that record is v=spf1 include:spf.protection.outlook.com -all. Vendors also verify ownership by TXT record: Google Workspace issues a unique value beginning `google-site-verification=`.

Tech stack detection limitations: what can and cannot be detected from a website

A website read can detect the technology a page delivers to the browser and what the server states in its responses. It cannot detect software that runs only on the company's servers, tags moved to a server, or tools on pages the read never reaches, and can miss tags held back until consent. Each limitation follows from the evidence.

1. Server software is declared, and the declaration is optional. Nothing in the HTTP standard obliges a server to name itself. A stack that lists no web server or framework shows a site that names none the catalogue recognises, and nothing more.
2. Tags can move to a server. Google's introduction to server-side tagging contrasts a container in the page, which sends measurement data from the browser to collection servers, with a server container, which runs on a server the site owner controls and not in the user's browser. The page then calls that server, and the tags fire there.
3. Tags can wait for consent. Google Tag Manager's consent settings let a tag require consent, and such a tag fires only if every specified consent type is granted. A read that grants nothing sees the page as a visitor who has yet to answer the banner.
4. A read covers the pages it reaches. Wappalyzer's lookup documentation has an option that follows internal links to index several pages for more coverage. A tool that loads only at checkout or inside a signed-in product sits beyond the pages a link-following read reaches.

The limits of technographic data collected from public websites

Technographic data collected from public websites records presence: a signature seen on the pages that were read, at the times they were read. Its limits follow from that. A row is silent on licence size, spend and depth of use, an absence can be a refused or partial read, and a record can outlast the tool it names.

Four rules keep a reading inside those limits.

• Absence has several causes. BuiltWith's knowledge base notes that some websites refuse requests from cloud networks and from self-declared indexing bots, and says it tags a site that does. Before you read a missing technology as a gap in adoption, check that the site was read.
• A match has a strength and an age. BuiltWith describes a confidence score from 0 to 1 on each detection, lower when a technology was seen once or has not been seen recently and something newer sits in its place. Wappalyzer's lookup excludes low-confidence results by default, and its documentation says results verified longer ago are likelier to come from websites that have since dropped the technology. Ask any vendor for the equivalent fields.
• A DNS record has a life of its own. Google's help says its verification record can be removed once the domain is verified. Microsoft's guide tells an administrator moving to Microsoft 365 to keep a single SPF record that includes the values of both the previous email provider and Microsoft 365. A verification can be gone while the product is in use, and one record can name two providers.
• Dates are observation dates. In Fokals data every technology carries its first-seen and last-seen dates, a first observation sets a baseline and is never counted as a change, and a removal is confirmed before it is written. The methodology states the rules.

We found no detection rate by category in the vendor documentation read for this post, which is why the last section is a test you run yourself.

Where job postings are the second source

For the categories a website never names, the public second source is the job posting, where a role names the tools it works with. TheirStack's documentation is explicit about the reading: a technology that no posting mentions has not been shown to be absent, and a company that is not hiring will not appear under it.

So the two sources fail differently. A website read misses what the page does not load, and postings miss what no open role mentions. Held on one company key, each covers part of what the other leaves out.

Fokals delivers both views on one company ID. Technology Stack holds what each website shows, and Job Postings, in the hiring dataset, carries the tools named in each role, with labels for tool families that include SAP, Workday, Snowflake and Databricks. The post on reading job postings from the company's own board covers that source.

Example: Acme Robotics, category by category

Acme Robotics is an invented company and this example is illustrative: its figures show the arithmetic and are not findings.

Assumptions:

• Acme Robotics runs 14 tools, listed below in three groups.
• Its public pages load six of them in the browser, and its responses name its content delivery network.
• Its advertising pixel is set to fire after consent, and the read grants none.
• Its MX records point to its email provider, and its SPF record includes its email-sending service.
• Its server sends no Server header.
• Its open job postings name the advertising platform, the server framework, the ERP system and the data warehouse.

The working:

• Website alone: 7 of 14 tools, or 50%.
• Website and DNS: 7 + 2 = 9 of 14, or 64%.
• Website, DNS and postings: 9 + 4 = 13 of 14, or 93%.
• By group, from website and DNS: customer-facing 7 of 8, or 87.5%; mail and domain 2 of 2; behind the website 0 of 4. Postings lift the last group to 3 of 4.

The single figure of 64% hides the split that matters. A team selling a consent tool can work from the website alone. A team selling into the data warehouse needs the postings, and should expect a company with no open roles to stay silent.

A test to run on sample data

The example becomes a test once the 14 tools are replaced by stacks you know.

1. List 20 to 30 companies whose stack you know at first hand: customers, partners, your own employer. Write each tool under one of the example's three groups: customer-facing, mail and domain, behind the website.
2. Ask each vendor for sample data on those companies, with its data dictionary.
3. For each group, divide the tools on your list that the sample shows by all the tools on your list. That is recall by group, the figure the example computes.
4. Take 20 sample rows that are missing from your list and open the evidence for each: the script, the header, the record or the posting. That is the check on false matches.
5. Compare the first-seen and last-seen dates with what you know of each adoption and removal.
6. Repeat step 3 with the tools named in job postings added, and note which group moved.

On a Fokals sample two queries produce the inputs. The first counts a website's technologies by category and by the evidence that showed each one, leaving out any technology whose removal is awaiting confirmation.

select technology_category, seen_via, count(*) as technologies
from company_technologies
where domain = 'acme-robotics.example'
  and missing_since is null
group by technology_category, seen_via
order by technology_category;

The second lists the tools named in the same company's open postings.

select p.title, p.technologies, p.first_seen_at
from job_postings p
join (
  select distinct company_id
  from company_technologies
  where domain = 'acme-robotics.example'
) c on c.company_id = p.company_id
where p.closed_at is null
order by p.first_seen_at;

The data dictionary defines every field in both queries, and ten questions for a company data vendor gives further tests for the same sample.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.