The short version
A technology checker reads a page's HTML and response headers and matches them against known fingerprints: asset hostnames, framework markers, and script sources. It reliably identifies what it finds, but cannot see anything a tag manager injects after the page loads, so an absence is never proof.
How fingerprinting actually works
Every platform leaves traces it cannot help leaving. WordPress serves assets from wp-content and wp-includes. Shopify loads from cdn.shopify.com. Wix uses static.parastorage.com. Next.js embeds a __NEXT_DATA__ script block. None of these are hidden, because they are how the page functions.
So a checker fetches one page, reads the HTML and the response headers, and tests them against a list of patterns. A match on an asset hostname is close to conclusive. That is why good detection leans on hostnames and structural markers rather than loose words: matching the word react in body text would light up on any blog post about React.
This is a passive read. Nothing is probed, nothing is logged into, and no credentials are involved anywhere. It sees exactly what any visitor's browser sees on the first request, and nothing more.
The limitation that matters most
Here is the honest caveat, and we would rather lead with it than let you draw a wrong conclusion.
A great deal of what loads on a modern site is not in the initial HTML. Tag managers inject scripts after the page loads. Consent tools hold analytics back until someone clicks accept. Frameworks assemble content in the browser. None of that is visible to a passive read.
We tested this on Tidio's own website. Tidio sells a chat widget, their widget is unquestionably on their site, and our checker does not see it, because they load it through a tag manager. Shopify's homepage similarly showed no analytics.
So read the results in one direction only. If we found something, it is there. If we did not, it may still be there. Any tool in this category that tells you flatly that you have no analytics or no chat widget is overstating what it can know.
| What we can see | What we cannot |
|---|---|
| Scripts hardcoded in the HTML | Scripts injected by a tag manager |
| Platform asset hostnames | Anything gated behind a consent banner |
| Response headers (CDN, host) | Content assembled in the browser |
| WordPress theme and plugin paths | Server-side code and databases |
| Payment and chat SDK sources | Tools loaded only on other pages |
What the chat widget tells you
Of everything a checker reports, the chat and support row is the most commercially revealing, and for two opposite reasons.
If a widget is there, someone at that business already concluded visitors need a way to ask questions, and is paying monthly for it. The decision has been made. The only remaining questions are whether the tool is any good and whether it handles voice.
If no widget is there and the site genuinely has none, then every question a visitor cannot answer from the page becomes an email, a phone call, or a lost sale. That gap is invisible in analytics, because a visitor who leaves without asking looks identical to one who was not interested.
Two or more widgets loading at once is its own finding. It usually means an old tool was never removed after a switch. It costs load time and occasionally shows visitors two chat bubbles.
Script bloat is a real cost
Counting scripts is more useful than it sounds. Every third-party tag is a separate connection, a separate download, and usually a separate piece of JavaScript executing on the main thread.
Most sites accumulate these rather than choose them. A pixel from an agency that no longer works there, a heatmap tool from a trial that ended, two analytics platforms because nobody was sure which one to standardise on. None of it is ever removed, because removing things feels riskier than leaving them.
If the checker reports five or more analytics and marketing tags, that is worth an afternoon. Work out which ones anybody actually looks at, and delete the rest. It is the cheapest page-speed improvement available and it needs no developer.
Questions about this tool
Is this accurate?+
In one direction. What it reports as present is genuinely present, because detection relies on asset hostnames and structural markers. What it does not report may still be there, since anything a tag manager injects after load is invisible to this method.
Why does it say my site has no chat widget when it does?+
Almost certainly because the widget is loaded through a tag manager rather than hardcoded in the page. We verified this against Tidio's own site, where their widget does not appear for exactly that reason.
Does it read more than one page?+
No, just the address you give it. Tools that only load on a checkout or contact page will not appear if you point it at the homepage.
How does it find WordPress plugins?+
From the asset paths the page itself exposes. WordPress serves plugin files from wp-content/plugins/<name>, so any plugin loading CSS or JavaScript on that page reveals its folder name.
Is scanning someone else's site allowed?+
This makes one ordinary request for one public page, the same as visiting it in a browser, and identifies itself honestly in the user agent. Nothing is probed and nothing is logged into.