We Failed Our Own AI-Readiness Check

We've spent the last few months building seellm.com — server-side observation for AI bot traffic, plus a free AI Search Visibility Score that audits fetchability and structural signals on a URL.

On May 6, 2026, we ran it on ourselves.

This article preserves that historical test as it appeared at publication. The scores, page HTML, and scanner result below are point-in-time evidence, not a claim about the current deployment.

The result

Overall score: 100 / A.

• All 20 major AI bots allowed in robots.txt (GPTBot, ClaudeBot, Bytespider, PerplexityBot, Google-Extended, Applebot-Extended, Meta-ExternalAgent, Amazonbot, DuckAssistBot, Mistral-User, xAI, CCBot, YouBot, and the rest) ✅
• robots.txt served, sitemap declared, sitemap valid ✅
• Canonical host resolves, no restrictive X-Robots-Tag header ✅
• Spec-conformant llms.txt and llms-full.txt published ✅

So far so good. Then agentReadiness came back needs_fixes (67 / 100):

The failing check, verbatim from our own scanner: "Primary heading starts after 8,388 HTML characters."

In the server-rendered response we tested, the H1 that explains what we do appeared after 8 KB of nav and decorative HTML. That is what the diagnostic flagged; it is not evidence of how a particular answer system used the page.

The cobbler's children, etc. We're a startup whose entire pitch is "make sure AI search can actually read your site," and our own homepage fails on the most basic agent-readability check.

Why this happens (and probably to you too)

This isn't a SeeLLM-specific problem. We see it across most modern landing pages we audit. The pattern:

• Hero section optimized for human eyeballs. A big animated background, a logo, a top nav, sometimes a banner, sometimes social proof — all rendered before the H1.
• Marketing-design defaults push the H1 down. A typical SaaS landing page hierarchy is: nav → hero visual → headline. The headline is visually first, but in the HTML source it's often the third or fourth major block.
• JavaScript-heavy frameworks compound the problem. React/Next.js apps ship a lot of script tags before the readable content. Agents that don't execute JS — and many still don't, especially during training — see scaffolding, not content.

The result is a readability risk worth investigating when a system processes only part of a response. The HTML check alone cannot establish whether an assistant reached the H1, summarized the navigation, or cited the page; those outcomes require separate sampled answer evidence.

What "agent readiness" actually checks

Our /agent-readiness diagnostic looks at a page from an agent's perspective, not a browser's. The six checks we run on the initial server-rendered HTML:

1. HTML is fetchable — does the URL return readable HTML at all?
2. Machine-readable summary available — is there a llms.txt pointing to a structured summary?
3. Token budget — is the initial response within an agent-friendly token count (~5,000 tokens or less for the part agents read)?
4. Answer depth — does the H1 + a short answer paragraph appear early in the HTML, or is it buried after long navigation and decoration?
5. Extractable structure — are there lists, tables, and clear headings that make the answer easy to lift?
6. JavaScript rendering risk — does the readable text exist server-side, or is it injected after hydration?

A page that passes all six satisfies this diagnostic's fetchability and structural heuristics. A warning or failure identifies a condition to inspect; it does not deterministically predict parsing, quotation, citation, or omission in an AI answer.

The full classification rules are on our methodology page.

The fix (shipped)

The fix was mundane: move the H1 + a short answer paragraph above the hero animation in the server-rendered HTML. The hero stays for human visitors; the H1 just shifts up in the source.

We shipped that source-order change after the historical test. It was intended to move the answer closer to the start of the server-rendered HTML while leaving the visual experience intact. Deployed HTML and diagnostic results can change, so use the linked scanner for the current measurement rather than treating this publication-time case study as a live status page.

The harder lesson: agent readiness is a distinct design constraint from human readability, and many landing pages prioritize the visual experience over source order. If you care about AI search as a distribution channel, a deep H1 is a testable risk—not proof that a hero kept the page out of ChatGPT or Claude answers.

See your own score

It's a free single-URL audit, no signup, ~30 seconds:

• Run it on our homepage and see the current result: /agent-readiness/?d=seellm.com
• Run it on your own page: /agent-readiness — paste any URL
• Site-wide audit (bot access + discoverability + AI-readable content): AI Search Visibility Score

Try it on your own homepage. The current diagnostic passes an H1 at or before 2,500 HTML characters, warns from 2,501 through 6,000, and fails beyond 6,000. Treat any warning or failure as a structural risk worth reviewing. Measure sampled citations, quoted-text matches, and detectable ChatGPT or Claude referrals separately before drawing a visibility conclusion.

Related reading:

• Crawl volume and AI traffic are decoupling
• What is "crawled but not cited"?
• Why Google Analytics can't see AI traffic