pitchbook-data.com
Evidence collected August 31, 2026 · 10 polite, robots.txt-respecting requests · every claim cites what it saw
No letter grade — withheld, not failed
No letter grade is issued because 3 of 4 categories could not be observed. The categories that were measurable are scored below.
Read this before the numbers
This tool was built in a few days, on a stack of stated assumptions. I didn't have the time — or the inside knowledge of what buyers in this category actually optimize for — to be certain these are the metrics that matter most. The four categories and their weights are editorial judgment, not measurement: nobody has proven that these things cause employees to post, and I don't claim otherwise.
Where the evidence comes from: three of the four categories read only what your company has published on its own public site — the part you can fix on Monday. Half of Employee & Culture comes from somewhere else: aggregate counts of how many of your people posted in the last 90 days, from a licensed third-party index of public professional-network activity. Nothing here was scraped from LinkedIn by this tool. Those counts are records in an index, not a census — they undercount, they undercount small companies most, and you can't check them yourself — so each one says so where it appears, a zero is reported as "none in the index" and never as "nobody posts," and a company with fewer than 25 people in the index gets the number reported but not scored. No individual is named anywhere in this report.
To prioritize speed, this particular report was loaded using cached data; it was generated from evidence originally collected on August 31, 2026 rather than live. Reports are cached for 30 days. Every observation below is dated and cited.
What you can hold me to: every number cites its evidence and says where it came from, nothing unseen is guessed at, robots.txt is respected on every fetch, and when this tool can't read a site it says so instead of issuing a grade.
What was found — most fixable first
Ranked by impact × ease of fixing, not by category. Counts describe the pages actually read, and each finding cites them.
Your Content-Signal grants what your robots.txt forbids
robots.txt declares a Content-Signal that grants a use requiring the site to be read, while disallowing AI user-agents of exactly the kind that grant depends on: Amazonbot. A machine reading your policy gets two opposite answers.
Evidence: robots.txt.
The fix: Decide which statement is the policy and make the other match: either remove the disallow lines for the agent kinds the signal grants, or narrow the Content-Signal to the uses you actually permit.
Your homepage share card is missing og:title, og:description, og:image
The homepage lacks og:title, og:description, og:image. When anyone — including your own employees — shares your homepage link, the preview card renders incomplete (no image means most platforms show a bare grey box).
Evidence: homepage HTML.
The fix: Add the missing tags to the homepage template: og:title, og:description, og:image. Minutes of work, visible on every share afterward.
9 AI user-agents are blocked at your site root
robots.txt disallows 9 of 25 tracked AI user-agents at the root: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, Amazonbot, meta-externalagent, CCBot, Bytespider, CloudflareBrowserRenderingCrawler. The list exactly matches Cloudflare’s one-click "block AI bots" default, which often means a toggle was flipped rather than a policy decided. This is a tradeoff, not a mistake: blocking protects content from training use, and costs visibility in AI search and assistants that cite sources. robots.txt is advisory, so this describes your declared policy, not enforcement.
Evidence: robots.txt.
The fix: Confirm the block is a decision rather than a default. If AI answer engines matter to how buyers and candidates find you, consider allowing search- and user-fetch-kind agents while keeping training bots blocked — the two can be set independently.
No structured data on your homepage
The homepage carries no JSON-LD schema.org markup. Machine readers — search engines and AI assistants alike — get no structured statement of who you are (Organization, name, logo, sameAs profiles).
Evidence: homepage HTML.
The fix: Add an Organization JSON-LD block to the homepage: name, url, logo, and sameAs links to your official social profiles.
Your job listings are invisible without JavaScript
Your careers page (https://pitchbook-data.com/careers) returns HTML, but the job listings are injected client-side — a plain reader sees a page with no roles on it. Machine readers that do not execute JavaScript (many crawlers and AI assistants) cannot see that you are hiring.
Evidence — careers page probes
- https://pitchbook-data.com/careers
- https://pitchbook-data.com/jobs
The fix: Server-render at least the role titles and locations, or publish jobs in structured data (schema.org JobPosting).
Your homepage is nearly invisible without JavaScript
A plain fetch of the homepage yields almost no readable text (72 characters). Crawlers and AI agents that do not execute JavaScript — which is many of them — see an empty page where your company should be.
Evidence: homepage HTML.
The fix: Server-render or pre-render the homepage shell so the core message, navigation and meta tags exist in the initial HTML.
What could not be seen
Anything the reader could not observe is listed here rather than guessed at or silently skipped.
No sitemap returned any URLs
Sitemaps were checked at 5 location(s) (declared in robots.txt or at the conventional paths) and collected zero URLs. Your content inventory is invisible to this tool — and to anything else that discovers content this way. This means "not found where sitemaps usually live", not "no content".
Evidence: sitemap fetches.
The fix: Publish an XML sitemap of your canonical content and declare it with a Sitemap: line in robots.txt.
For the record
No llms.txt
No llms.txt file is served. This costs nothing today — the evidence that llms.txt affects anything is weak — so I do not count it against you.
Evidence: llms.txt fetch.
How the numbers break down
Weights: Content Supply 30% · Shareability 25% · Employee & Culture 25% (half what the site says, half what employees do) · AI Discoverability 20%. The weights are editorial judgment about what an advocacy program draws on — not the result of a study. Every row cites the observation behind it and says whether it was read from your site or from the licensed index.
Content Supply — not scored
No sitemap URLs were retrieved, so content volume could not be measured.
Shareability — not scored
No content pages were sampled.
Employee & Culture — not scored
No sitemap URLs were retrieved.
AI Discoverability — 38.3/100 (reduced confidence)
| Signal | Points | What was observed |
|---|---|---|
| AI crawler access | 35.3/45 | 9 of 25 tracked AI user-agents are disallowed at the site root: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, Amazonbot, meta-externalagent, CCBot, Bytespider, CloudflareBrowserRenderingCrawler |
| Content-Signal coherence | 3/15 | Content-Signal "search=yes,ai-train=no,use=reference" grants a use that requires reading the site, while 1 AI user-agent(s) of exactly the kind that grant depends on are disallowed from reading it: Amazonbot. |
| Structured data | 0/40 | 0 schema.org type(s) on the homepage; article schema not measured |
| llms.txt | 0/0 | Not present. This costs nothing — the evidence that llms.txt affects anything is weak. |
robots.txt compliance is voluntary and advisory. This reports the declared policy; it is not a claim that any crawler was actually blocked.
The blocked-agent list exactly matches Cloudflare’s one-click "block AI bots" default, which often means a toggle was flipped rather than a policy decided.