Agentic Readiness

The real current state of AI-agent and crawler readiness. What's blocked, what's missing, what ships next.

Gates open

Google’s Lighthouse now ships an experimental “Agentic Browsing” check. Not a 0-100 score, a pass/warning/fail readiness read across four areas: a clean accessibility tree, stable page layouts, an optional llms.txt, and experimental WebMCP support for forms and actions. The first two matter now. The last two are early-adoption upside, not requirements yet.

The reference case: Bex + Co

Bex + Co is the production template DH audits against. It already has a strong foundation: clear H1, logical heading hierarchy, descriptive nav, crawlable links to every location and professional. Performance is excellent, desktop LCP 1.0s, CLS 0.01, INP 57ms, TTFB 0.1s, Core Web Vitals passing. That near-zero CLS matters specifically for agents: an agent sometimes clicks an element by screen location from a screenshot, so a shifting button causes a wrong click.

Bex’s biggest remaining gap: Person schema for individual professionals. DH’s own live build is behind Bex on every one of these fronts.

What’s blocked right now

robots.txt blocks ClaudeBot, GPTBot, and Google-Extended on new.designhacker.com. Nothing downstream (proof, answers, agent actions) matters if crawlers can’t get through the door.
JSON-LD: not firing at all on the live DH build.
Forms: missing form/name/submit wiring, so an agent’s accessibility tree can’t reliably identify or complete them.

What still needs building

llms.txt

The easiest agent-specific win available. A concise markdown map of the site and its most important links, at the site root. A missing file scores N/A, not a failure, pure upside. Should generate from the same canonical source that feeds the sitemap and JSON-LD, not a hand-written one-off.

Structured data

Organization site-wide, LocalBusiness/HairSalon per location, Person per professional, Service per offering, BreadcrumbList, FAQPage where real FAQs exist. Describes what’s visible and accurate, never a keyword dump.

Form + link legibility

Every control needs a programmatic name: real <button>/<a href>/<label>/<select>, not clickable divs. Links need self-contained names (“View Alaura’s profile at Barton Hills,” not repeated “View profile”).

Canonical location/entity data

One shared source powering the location page, directory, JSON-LD, sitemap, llms.txt, GBP, and any future agent API. Prevents an agent from seeing conflicting hours in two places.

The reusable standard for every future DH build

Semantic HTML by default

Native elements matching the action: header, nav, main, article, button, a, form, label, input, select. No clickable divs.

Every action gets a unique name

Weak: “Learn more,” “Click here,” “Submit,” “View.” Better: “View Alaura’s profile,” “Submit your membership application.”

One clear H1, logical hierarchy

Heading levels chosen for structure, never for font size.

Core content in server-rendered HTML

No hover-only, canvas-only, or third-party-widget-only content for anything load-bearing.

Stable layouts

Set width/height on every image, video, embed. No late-injected banners, no late font swaps.

Fully labeled forms

Visible label, for/id connection, name, correct type, required state, inline errors, a visible submission confirmation.

Structured data planned at architecture time

Pick schemas by business type during site planning, not bolted on after launch. Validate every deployment.

llms.txt as a standard launch step

Generated, not hand-maintained. Treated as free upside on every launch checklist.

Launch baseline (clear this before shipping anything)

Agent-ready: semantic HTML throughout, unique accessible names, labeled inputs, stable layouts, visible confirmations, dedicated entity pages, valid JSON-LD, correct robots.txt, llms.txt, real agent-journey testing (not just a homepage score).

Performance: LCP under 2.5s, INP under 200ms, CLS under 0.1, responsive images with width/height set, minimal third-party scripts.

WebMCP: sequence rule

Read-only first, bounded writes later. First candidate tool for Bex: findBeautyProfessional (inputs: location, service, professional name, availability; outputs: matching pros, location, booking URL). WebMCP is still tied to a Chrome origin trial (Chrome 150+ for the Agentic Browsing category itself). Fix semantics, labels, stability, and structured data first. Experiment with WebMCP next, on one high-value, low-risk flow, never starting with a write action like direct appointment submission.

Where this SOP lives

The plan is to fold this checklist directly into the dh-stack-build and dh-blog-build skills as a mandatory gate, so a build can’t be called “done” without clearing it, plus a lightweight on-demand audit skill for spot-checking any live URL. A scheduled recheck loop (not manual, not Andrew-triggered) is the proposed way to catch regressions, a slow image added later, a JS widget that breaks the accessibility tree, CLS creeping back up.

See also: Five-Layer Brand Visibility System for how this technical floor feeds the strategy above it.