Site Audit

What this is for, in one sentence: Site Audit checks whether AI systems can actually read, parse, and trust your website — the technical layer underneath every citation, topic, and visibility number in the rest of the product.

When to come here:

When your content is strong but your citations or topic presence don’t reflect it — the gap is often technical, and this is where it shows up
Before commissioning content into gaps: publishing onto a site AI can’t fully read wastes the work
After your web team ships fixes, to verify AI-readiness actually changed

Nadia Rahman doesn’t manage servers — she manages a newsroom. But if a crawler can’t reach GreenGrid’s guides, every editorial investment downstream underperforms and nobody in the newsroom knows why. This screen translates the technical layer into findings she can read, route to the right person, and verify — without becoming a developer.

Reading your results

audit results The header tells you two things before any score: when the audit ran, and — critically — how much of the site it actually read. GreenGrid’s latest run is a full crawl: 118 of 118 pages, which means every number below it is trustworthy. (What it looks like when that’s not true is covered at the end of this article — it matters.)

The Health Score — 76/100, Good — is the summary, with the tier scale right beside it (Excellent 90+, Good 70–89, Needs work below 70). Treat it as a trend line between audits, not a grade to fixate on: the real content is the four checks below, each written in plain English with three things per card — what the check is, why it matters (the Impact line), and who usually fixes it. That last line is the difference between an audit you act on and an audit you archive: HTTPS problems go to your hosting provider, robots.txt and speed issues to your web developer, llms.txt to your developer or straight to the Action Center generator.

GreenGrid’s picture: HTTPS passes clean; robots.txt carries one warning; llms.txt is missing entirely; page speed carries three issues (mobile 62, desktop 88). Five issues total — and the footer shows exactly where they went: five technical fixes, already waiting in Visibility Gaps, one click away. The audit’s output is a populated to-do list, not a dead end. And if the to-do list belongs to someone outside the product, “Email this list to my web person” sends the findings — plain descriptions, owners, and all — without you translating anything.

Honest guidance — read the checks, not the score. The score is a composite; a 76 with a robots.txt problem blocking your best content is worse than a 71 with three cosmetic speed issues. Prioritize by what each finding touches, and let the score track your progress between audits.

The finding that explains a mystery

robots detail Open the robots.txt warning and you get the actual rule the crawler found:

User-agent: PerplexityBot
Disallow: /guides/

One line of configuration, probably years old, and here’s what it’s been costing: GreenGrid’s /guides/ section is its most-cited content — but only to the engines allowed to read it. The detail view says it directly: in Citation Analysis this period, ChatGPT and Gemini cite your guides; Perplexity cites only your news pages. That asymmetry looked like an engine preference. It was a door, closed, to exactly one crawler.

This is the audit doing its real job — connecting a technical artifact to a visibility pattern you could see but not explain. The fix is one edit for your web developer (the email button sends it with instructions), the item is already tracked in Visibility Gaps, and the verification loop is: fix ships → re-run the audit to confirm the rule is gone → watch Perplexity’s citation behavior over the following periods in Citation Analysis.

Honest guidance — opening the door isn’t the same as traffic walking through it. Fixing a robots rule lets a crawler in immediately; citations and presence follow on the engine’s own re-crawl schedule — weeks, not days. Verify the fix with a re-run now; judge the effect across future periods.

The missing llms.txt is the other structural finding. It’s a small file that gives AI crawlers a guide to your site — what you publish, what matters, where your canonical content lives. Your developer can create it, or the Action Center generates one from your profile in minutes; either way it ends with a file at greengrid.media/llms.txt and one less reason for AI to guess about you.

When the audit can’t see your site

partial crawl GreenGrid’s July 5 audit looked alarming for about a minute: almost nothing readable. But the screen says exactly what happened — “We couldn’t fully audit this site — greengrid.media blocked our crawler during this run. Results below reflect access, not site quality.” The coverage badge reads 1 of 118 pages, the Health Score is withheld rather than rendered, and every check shows “couldn’t read” in neutral grey instead of a failing grade.

Read that banner carefully, because it’s the difference between two completely different problems:

“Couldn’t read” is an access problem — a firewall, a bot-protection service, or a hosting setting blocked the auditor. The fix is whitelisting the crawler (your hosting provider or web developer), then re-running. GreenGrid’s was resolved in six days; the July 11 full crawl confirms it.
“Failing” is a site problem — the crawler got in and found real issues. That’s the July 11 result, and the fix list above.

A partial-crawl banner is also a signal worth taking seriously on its own: if the audit crawler is being blocked, there’s a fair chance AI platform crawlers hit the same wall — meaning the access problem may itself be a visibility problem. Whitelist, re-run, and then trust the numbers.

Honest guidance — never report a partial-crawl result as a site assessment. If you’re preparing anything for leadership or a partner and the coverage badge shows a partial crawl, the only honest statement is “we couldn’t fully measure this yet.” Resolve access first; conclusions second.

Common questions

Is 76 good? The scale on screen answers the tier (70–89 is Good); the checks answer what matters. GreenGrid’s 76 with one structural block on its best content is a “fix two things this week” situation, not a redesign.

I’m not technical — what do I actually do with these findings? Three moves, all on-screen: the fixes are already in Visibility Gaps as a tracked list; each finding names who usually fixes it; and “Email this list to my web person” sends the whole thing in plain English. Your job is routing and follow-up, not implementation.

Does page speed really affect AI visibility? Indirectly but genuinely: slow or heavy pages get crawled less completely and parsed less reliably, and some engines fold page-experience signals into what they trust. Mobile 62 won’t zero you out, but it’s friction on every crawl. It’s usually the cheapest of the fix categories, too.

Can deleting an old audit lose my history? Audit results can be deleted, and deletion asks for explicit confirmation — but the history is your before/after evidence, so keep runs around bracketing any fix you want to prove.

How often should we run this? After any site change (redesign, migration, new hosting or bot-protection service — the classic silent breaker), after your web team ships fixes from the list, and quarterly as a floor even when nothing changed.

What to do next

Visibility Gaps — the five fixes from this audit live there, prioritized alongside your content opportunities.
Action Center — generate the missing llms.txt now; it’s the fastest item on the list.
Citation Analysis — where you’ll verify the robots fix paying off, engine by engine.
Key Topics Analysis — once AI can read everything, this is the map for what to publish next.