Tech & Trust
What it tells you
Some of the ground you compete on isn’t the copy or the price — it’s the plumbing. How locked-down a rival’s site is, the compliance badges and reviews they show a nervous buyer, the tools they’ve wired in, and whether their pages are reachable by the AI assistants buyers now ask for a shortlist. Tech & Trust reads all of that off the live site, the same way for every competitor and for you.
It comes down to a handful of plain readings:
| What you see | What it means |
|---|---|
| Security grade | An A-to-F grade for how well each rival’s site is hardened, from the protections its pages send. |
| Trust signals | The compliance badges, reviews, social proof, and privacy disclosures a rival shows buyers — 26 signals across five categories, counted and compared. |
| AI assistant reach | Which named AI assistants can obtain a rival’s pages at all — and which crawler decided it. |
| Tech stack | The tools each rival’s site is built on, sorted into what they’re for. |
The one that’s easy to overlook is AI assistant reach. It reads like a technical footnote, but it’s really an AI-visibility signal wearing a robots.txt costume: a page an assistant can’t fetch is a page it can’t quote.
What a check looks like
A check reads each competitor’s site for its security protections and its robots.txt rules, then sets the result beside yours. One run reads something like this:
Because every site is read the same way, the comparison lines up cleanly — you can see at a glance who’s hardened and who’s exposed, and who’s quietly slammed the door on the assistants buyers ask for a shortlist.
The security grade, and the headers behind it
Every rival gets a plain A-to-F security grade, worked out from the protective headers their site sends a browser. It’s not a penetration test — it’s the front-door check a careful buyer’s security team would run first, and it’s the same check for every competitor and for you.
The grade comes down to a handful of headers, each one a specific protection either present or missing:
You don’t need to read them as a security engineer — the grade rolls them into one letter — but the breakdown is there when you want to see exactly what a rival is missing:
| Rival | Grade | HSTS | CSP | X-Frame | X-Content-Type |
|---|---|---|---|---|---|
| Rival A | A | ✓ | ✓ | ✓ | ✓ |
| Rival B | C | ✓ | — | ✓ | — |
| You | B | ✓ | ✓ | — | ✓ |
CompetLab also names the top-graded competitor and the point gap between them and you, so the read is never a bare number — it’s where you stand against the best-hardened site in your set.
Trust signals — and an honest read of them
A check counts the credibility a rival puts in front of buyers: the compliance badges, review-site ratings, social proof, and privacy disclosures scattered across their site. There are 26 signals in all, across five categories, and each rival gets a tally by category and a coverage read — so you can see who’s leaning hard on trust and who’s quiet.
Compliance is the security and privacy attestations a buyer’s procurement team asks for. Reviews are the third-party rating badges from the platforms buyers check. Social proof is the customer logos, counts, and case studies a site uses to say others already trust us. Certifications are the standards marks a site displays. Disclosures is the newest and smallest — today a linked privacy policy, the one signal non-English sites publish more often than English ones, because it needs no vendor relationship to obtain. Together they’re a read on how much a rival invests in reassuring a cautious buyer before a single sales conversation.
Most of the named programmes in this list are US or EU ones — the review platforms are the anglophone B2B ecosystem, and the privacy regimes are GDPR, CCPA and LGPD. The list isn’t uniformly so: ISO 27001 and PCI DSS are held worldwide, and the social-proof and disclosure signals describe a practice rather than a programme, so they’re market-neutral.
That’s what bounds a count. A vendor selling outside the US and EU commonly scores on the market-neutral signals and near-zero on the named ones — so when a total is low, say which part is low rather than reading the total as a level of trust, and compare counts within a market rather than across them.
Trust signals are read visually, and some badges are baked into images the scanner can’t parse — so a low or zero count can be a false negative, not a real absence. CompetLab flags that possibility rather than presenting a raw zero as fact. Treat a surprisingly thin count as worth a look, not a verdict, and confirm it against the live site.
Can AI even reach them?
This is the read to watch. A check doesn’t score a site’s robots.txt out of 100 — it names which AI assistants can actually obtain the pages, which crawler decided that, and the line in the site’s own file that settled it.
Six assistants each get their own verdict:
And the verdict is one of four:
Open and Blocked read as they sound. Partial means the assistant reaches some of the site but not all of it — and partial reach is still reach, so it counts as reachable rather than shut out. On paper is the honest one: a rule is written, but the crawler it names isn’t reliably bound by it — either its operator publishes a carve-out, or it’s been measured ignoring robots.txt outright. That’s a request the site has made, not protection it has. In practice you’ll meet it on the training side rather than on reach, because every assistant we track is decided by at least one crawler whose operator documents that it does obey.
Why a list of blocked bots was never enough
The map from assistant to crawler is neither one-to-one nor symmetric. Microsoft Copilot has no
crawler of its own — it grounds on the Bing index, so bingbot decides it. Gemini Apps is decided
by Google-Extended, a token that fetches nothing at all yet governs both training and that
assistant.
So a site can block every OpenAI token by name and still be reachable by an assistant nobody thought about. Each verdict therefore ships with the crawlers that decided it and — where a rule decided it — that directive verbatim and its line number, so it’s a finding you can check against the file rather than a claim you take on trust. An Open verdict carries no directive, because nothing restricted the crawler; there’s no rule to point at.
Training access is a separate question
Alongside reach, a check reports whether each of nine model operators may use the content for training:
Training access is an operator-level fact, not an assistant-level one — one training crawler
feeds many products, so “may OpenAI train on you” is answerable where “may ChatGPT train on you”
isn’t. Common Crawl is on the list although it trains nothing itself: it publishes the open corpus
much model training is built on, and a site blocking CCBot is making exactly this decision.
Keep the two questions apart: blocking a training crawler costs no visibility and is a legitimate
content decision — don’t read it as a gap. The exception worth checking for is a token that
governs both at once, Google-Extended being the documented case; there a training block does
carry a visibility consequence.
”We couldn’t read it” is an answer, not a blank
Three situations used to collapse into one. They’re kept apart deliberately:
| What happened | How it reads | Is it a finding? |
|---|---|---|
| The file blocks AI crawlers | Verdicts render, some closed | Yes — measured |
| The site publishes no robots.txt | Verdicts render, all open | Yes — a real 404 means the standard allows everyone |
| We couldn’t read the file | No verdicts at all | The failed read is the finding |
That last row is the one to internalise. When a fetch fails — a 503, a timeout, a bot-protection page — the verdicts are absent entirely, not empty and not zero. An unreadable file is not an open site, and nothing is derived from a read that failed.
Reading this across your set tells you two things at once: whether your own door is open, and whether a rival’s is closed in a way you could out-manoeuvre.
A verdict says an assistant is permitted to obtain the content. It never says the assistant mentions or cites the site — that’s AI Visibility. Reach is a precondition for being named, not a measure of it.
The tech stack, sorted
A check detects the tools each rival’s site is built on and sorts them by what they’re for, so you’re reading a profile of how a competitor operates rather than a raw dump of script tags.
Core tech is the frameworks, languages, and infrastructure the site runs on. Growth is the analytics, ads, and marketing tooling — a tell for how heavily a rival invests in acquisition. Engagement is the chat, support, and CRM tools they’ve wired in for talking to customers. Each rival gets a count in each bucket and a total.
| Rival | Core tech | Growth | Engagement | Total |
|---|---|---|---|---|
| Rival A | React · Next.js · TypeScript | Analytics · marketing automation | Live chat · support desk | 12 |
| Rival B | Vue · Nuxt | Analytics | Support desk | 7 |
| You | React · Next.js | Analytics · marketing automation | Live chat | 9 |
Read across a row and you get a rival’s whole operational posture — a lean stack versus a heavily tooled growth machine tells you something about how they compete that no headline metric will.
The grades, the trust-signal coverage read, the per-assistant reach verdicts, and the sorted tech stack are rendered in the CompetLab app. The REST API and MCP tools return the pieces underneath — each rival’s security grade and the individual header results, the trust-signal counts by category, the per-assistant reach verdicts with the crawler and directive behind each one, the categorized tech stack, and the DNS and email infrastructure each site runs on — so you can rebuild the same comparison in your own tools.
A trend, not a snapshot
A single check tells you how each rival is set up today; the value builds when you watch it move. Because CompetLab runs on a schedule and keeps every result, Tech & Trust becomes a record of how the field’s technical and trust posture shifts — the month a rival finally shipped a proper security header set, the week a competitor added a SOC 2 badge, the day one of them quietly closed their pages to an assistant. Run History keeps each check with your security grade and the gaps to the field, so a change in a rival’s setup shows up as a trend rather than a thing you stumble on later.
That same check-over-check diff is what powers alerts: when an assistant stops being able to reach a competitor’s pages, or their security grade moves, you hear about it between checks.
Tech & Trust runs on its own cadence, set independently of the other dimensions. Turning it on and choosing how often it checks are both covered in How monitoring works.
Work with it in code
Every quantitative piece here is available programmatically — the same data the dashboard renders.
FAQ
What is Tech & Trust?
Tech & Trust is one of CompetLab's five continuously monitored dimensions. It reads the technical and credibility signals off each competitor's live site and lines them up against yours: a security grade from the protections their pages send, a count of the trust signals they display (26 signals across five categories — compliance badges, review ratings, social proof, certifications, and privacy disclosures), the tools their site is built on sorted by purpose, and — the read worth watching closely — which of the six named AI assistants can obtain their pages at all. Because it's monitored, every check is stored as history, so you watch a rival's setup shift over weeks and get an alert when something moves between checks — a security grade slipping, or a competitor quietly closing their pages to an assistant.
What goes into the security grade?
The grade is an A-to-F read of how well a site is hardened, worked out from the protective headers its pages send a browser — things like HSTS, a content security policy, and clickjacking and content-type protections. Each is a specific defence that's either present or missing, and the grade rolls them into one letter so you don't have to read them as a security engineer, while the breakdown stays available when you want to see exactly what a rival is missing. It's a front-door check, not a penetration test — the same quick read a careful buyer's security team runs first. CompetLab grades every competitor and you the same way, and names the best-hardened site in your set plus the point gap to it, so the number always has something to stand against.
What does "AI assistant reach" tell me, and why does it matter?
It reads each rival's robots.txt and reports, for each of six named assistants — ChatGPT, Claude, Perplexity, Microsoft Copilot, Google AI Overviews, and Gemini Apps — whether it can obtain their pages. Each verdict is Open, Partial, Blocked, or "On paper", and each ships with the crawlers that decided it and — where a rule decided it — that directive verbatim and its line number, so it is checkable against the site's own file. An Open verdict carries no directive, because nothing restricted the crawler. Per-assistant matters because the map from assistant to crawler is neither one-to-one nor symmetric: Microsoft Copilot has no crawler of its own and grounds on the Bing index, so bingbot decides it, while Gemini Apps is decided by Google-Extended, a token that fetches nothing yet governs both training and that assistant. A site can therefore block every OpenAI token by name and still be reachable by an assistant nobody considered. Partial reach counts as reach. And when the file cannot be read at all — a 503, a timeout, a bot-protection page — there are no verdicts rather than open ones, because an unreadable file is not an open site. It's the same contest as AI Visibility seen from the plumbing side: reach is a precondition for being named, never a measure of whether you are.
My trust-signal count looks low — is that real?
Maybe not. Trust signals are read visually from the live site, and a lot of badges — SOC 2 seals, review-platform ratings, certification marks — are baked into images the scanner can't parse. When that happens, a genuine badge reads as absent, so a low or zero count can be a false negative rather than a real gap in your credibility. CompetLab flags that possibility rather than presenting a raw zero as fact, which is the honest way to handle a limit of visual scanning. The practical rule: treat a surprisingly thin count as worth a look, not a verdict. Open the live site, confirm what's actually displayed, and if the badges are there as images, the count is understating you — not catching a real absence.
What's in the tech stack it detects?
The tools a competitor's site is built on, sorted into three buckets so you read a profile rather than a raw list. Core tech is the frameworks, languages, and infrastructure the site runs on. Growth is the analytics, advertising, and marketing tooling — a tell for how heavily a rival invests in acquisition. Engagement is the chat, support, and CRM tools they've wired in for talking to customers. Each rival gets a count per bucket and a total, and reading across a row gives you their operational posture at a glance: a lean stack versus a heavily tooled growth machine says something about how a competitor works that no headline metric will. The API also surfaces the DNS and email infrastructure each site runs on, for a fuller picture of how a rival is set up.
How often does it check, and does it keep history?
Tech & Trust runs on a schedule you set, on its own cadence, independently of the other dimensions — you can watch it closely or let it tick along, and changing the frequency never costs you past data. Every check is stored, so the dimension is really a running record of the field's technical and trust posture over time: Run History keeps each check with your security grade and the gaps to the field, so a rival hardening their site, adding a compliance badge, or closing their pages to an assistant shows up as a change against what the last check saw. That history is also what powers alerts — when a competitor's security grade moves or an assistant's reach verdict flips between checks, you hear about it. Frequency is set in the project's settings; see How monitoring works for the walkthrough.