Technographic data is a record of the software and services a company uses. For sales prospecting, it lets you build a lead list from a fact you can check instead of a guess. If you sell a Shopify app, you want a list of stores that run Shopify. If you sell a migration service, you want companies on the platform you migrate people away from. The filter is the tool, and the tool is often visible from the outside.
You build such a list in three steps. Start with a set of company domains that fit your market. Detect which technologies each domain exposes on its public website and in its DNS records. Then keep the domains where the stack matches your offer. You can do this by hand for a few dozen domains, with free open datasets for broad research, or with a detector that checks each domain on demand. The rest of this article explains how detection works, where it fails, and which route fits which job.
What counts as technographic data
The term covers anything that tells you what a company runs. In practice it falls into a few groups:
- The content management system or shop platform behind the website.
- Analytics, tag managers and advertising pixels.
- Chat widgets, booking tools, form builders and consent banners.
- Payment providers that show up in checkout scripts.
- Hosting, content delivery networks and web servers.
- Email providers and marketing senders, visible through DNS.
Each of these is a buying signal for someone. A company with a live chat widget has already decided that chat matters. A company with three ad pixels spends money on paid traffic. A company on an old self-hosted platform may be open to a rebuild.
How detection works
Nothing here is secret. A detector reads the same things your browser receives when you open a page. It then compares them to known fingerprints.
HTML source. Many platforms leave traces in the markup. Script URLs point to a vendor's domain. Class names and file paths follow a platform's conventions. Some systems announce themselves with a generator tag, which the HTML standard defines as a way to identify the software that produced the page.
HTTP response headers. Servers often say what they are. The Server header is described in the HTTP specification as a field that contains information about the software used by the origin server. Other headers reveal a CDN, a caching layer or a hosting platform.
Cookies and script behavior. Analytics and marketing tools set cookies with recognizable names. Some tools only load after a script runs, so a detector that renders the page sees more than one that only reads raw HTML.
DNS records. These sit outside the website and are public by design. MX records show where a domain receives mail. Google documents the MX values for Google Workspace, and Microsoft publishes the DNS records that Microsoft 365 needs. SPF records list the services allowed to send mail for a domain, which often names a marketing or support tool. Verification TXT records can show that a company once connected a specific service.
You can check all of this yourself. Open the page, view the source, and look at the Network panel in your browser's developer tools. Run a DNS lookup for MX and TXT records. For one domain it takes a few minutes.
What a logged-out visitor cannot see
This is the most important limit, and many lists ignore it. Detection only sees what a public visitor sees. Everything behind a login is invisible.
That rules out most internal software. You will not find a company's CRM, its accounting package, its data warehouse, its HR system or its internal chat tool by looking at its homepage. Some of these leak through a side channel, such as a tracking script from a marketing platform or a DNS record for a help desk. Most do not.
There are other gaps:
- Server-side tools. A tag that fires from the server leaves no trace in the browser. Server-side tracking setups hide tools that used to be visible.
- Stripped headers. Many companies remove or fake the Server header for security reasons. A missing header tells you nothing.
- CDNs and proxies. A CDN in front of a site can mask the hosting and server behind it.
- Consent banners. Marketing scripts may only load after a visitor accepts cookies. A detector that does not accept sees fewer tools.
- Pages you did not check. The homepage may be clean while the checkout, the blog or the careers page runs different tools. A subdomain can run a completely different platform.
- Bot protection. Some sites block automated requests. Then you get no data at all for that domain.
- Stale leftovers. A script tag from a cancelled tool can stay in a template for years. A TXT record proves a service was connected once, not that it is paid for today.
So read every result as "this tool is visible on this page right now". It is not proof of a contract, of a budget or of satisfaction. And the absence of a tool in your results is not proof the company does not use it.
Building the lead list step by step
1. Define the trigger technology. Be specific about why a tool matters for your offer. There are three common patterns. Complementary: you sell something that plugs into the tool. Competitive: you replace the tool. Maturity: the tool signals a stage, such as a first analytics setup or an enterprise consent platform.
2. Collect candidate domains. Technographic detection needs domains as input. Take them from your CRM, an industry directory, a trade association member list, event exhibitor pages or a chamber of commerce export. Clean the list first. Remove duplicates, strip paths, and resolve redirects so you check the domain the company really uses.
3. Detect the stack per domain. Check at least the homepage. For shops, add a product page. Record the detection date next to each result, because stacks change.
4. Filter and score. Keep domains that match the trigger. Add a second condition where you can. "Runs platform X and has no chat widget" is a sharper list than "runs platform X".
5. Enrich with other public signals. Job listings are the best complement, because they reveal the internal tools that a website hides. A vacancy that asks for experience with a specific CRM or cloud platform tells you what runs behind the login. Reviews and company filings add context about size and direction.
6. Verify before you write. Open the site of every lead you plan to contact personally. Confirm the tool is still there. An opening line built on a wrong detection costs you more than a generic one.
7. Re-check on a schedule. A change is a stronger signal than a state. A company that just removed a competitor's script, or just added a new platform, is in motion.
Free ways to get the same data
You do not always need a paid tool.
Manual checks. For a short list of high-value accounts, view source, developer tools and a DNS lookup give you the best data there is. You see context that no automated tool reports. If you work fewer than a few dozen accounts, this is the better choice.
Open web datasets. The HTTP Archive crawls a large set of sites on a regular schedule and publishes the results, including detected technologies, as a public dataset you can query. It is a good fit for market research, such as how common a platform is in a segment. Its limits are coverage and freshness. It mostly tests homepages, your niche domains may not be in the crawl, and the data is as old as the last crawl. Querying it also requires SQL skills and may incur query costs on the hosting platform.
Vendor directories. Many platforms publish customer showcases, partner directories or app store listings. These are confirmed users, not detections. The lists are short and curated, but accuracy is high.
Your own script. Fetching a page and matching patterns is not hard to code. Maintaining the fingerprints is the real work, since vendors change their script URLs and markup over time.
A paid, on-demand detector makes sense in the space between these options. You have your own list of hundreds or thousands of domains, you need current results, and you do not want to maintain fingerprints.
Using the data responsibly
A tech stack is company information, not personal information. The contact details you attach to it later are personal data in many jurisdictions. Check the rules that apply to your outreach, such as GDPR in Europe and the local rules on unsolicited email. Respect a site's terms and keep your request rate low, since a single page fetch per domain is enough for detection.
In your message, be honest about what you know. "I noticed your site loads tool X" is accurate. "I know you are unhappy with tool X" is a guess. Prospects can tell the difference.
If you have a list of domains and want the visible stack for each one without building your own detector, the Website Tech Stack Detector checks the public pages you give it and returns the technologies it finds, and you pay per result instead of for a subscription.
Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.