How the AI Presence Readiness score works

Agentic search studies show freshness terms such as 2024 and 2025 dominate fan-out queries. Structured, recent dates help agents trust that seasonal advice, pricing, and availability are still valid.

Pass: structured dates updated within 12 months. Partial: dates exist but are stale or inconsistent. Fail: no reliable freshness signal.

What good looks like: A hotel keeps room, package, restaurant, and event pages marked with dateModified from the current season.

Citation research found ChatGPT answers are much more likely to cite pages with actual HTML tables. Tables help agents compare amenities, seasons, tiers, prices, and policies without guessing from prose.

Pass: decision-critical data appears in semantic HTML tables. Partial: structured comparisons exist but are incomplete or image-only in places. Fail: no machine-readable comparison structure.

What good looks like: A destination publishes activity seasons, accessibility, durations, and price bands in a table with clear column headings.

Agents operate inside finite context windows and often truncate long pages. Pages over roughly 30K tokens risk losing the exact facts an assistant needs to recommend or book confidently.

Pass: key pages fit comfortably inside the token budget. Partial: some pages are heavy but still extractable. Fail: important pages are too large or repetitive to read fully.

What good looks like: A restaurant page keeps menu, opening hours, booking, address, and dietary facts concise rather than burying them after repeated layout boilerplate.

Clean Markdown alternatives reduce token overhead and remove navigation chrome. Agents can parse headings, lists, links, and facts faster when a .md route mirrors the canonical page.

Pass: important pages expose clean .md versions. Partial: only some pages or partial content are available. Fail: no Markdown alternative is discoverable.

What good looks like: An attraction page offers /visit.md with summary, opening times, ticket links, accessibility, location, and FAQs.

AI surfaces can promote entities as richer visual cards when schema includes the minimum properties needed for display. Missing one critical field, often image or aggregateRating, can drop the entity to a plain text mention.

Pass: schema includes image, rating or price cues, location, and canonical action URL. Partial: one non-critical card field is weak or missing. Fail: critical card fields are absent.

What good looks like: A hotel has image, address, geo, aggregateRating, priceRange, and ReserveAction on the canonical property page.

Schema doesn't feed the LLM directly — it feeds what the LLM calls (Google Places, Maps, the Knowledge Graph). Properties are graded in three impact tiers, and properties only count when they're filled in the typed form AI engines actually parse — a primitive starRating of 4 fails the category-bucket filter that a typed Rating object passes.

Pass: critical-tier properties (name, description, url, address, primary identifier) are all filled and typed correctly. Partial: critical tier is fine but one or more high-impact properties are missing or malformed. Fail: critical-tier properties are missing or typed wrong.

Hotels get a sameAs reconciliation sub-signal — own the canonical URL on any 2 of {Wikidata, Booking, TripAdvisor, Google Maps} and you earn full credit, rendered as a binary 4-cell checklist rather than a progress bar. alternateName, typed starRating, and containsPlace (room-level structure) also feed this check on the hotel path. A wrong @type (LocalBusiness or Organization on a hotel page) cuts the score with a tiered penalty rather than a flat one.

What good looks like: A hotel publishes name, description, url, address, a typed starRating Rating object, image, aggregateRating, priceRange, sameAs to Wikidata + Booking + Google Maps, alternateName for prior brands, and containsPlace entries for room types.

The check is entity-aware. For destinations it's reframed as "Entity Linking" and grades Wikidata QID resolution (50) + Wikipedia sameAs (25) + schema geo (15) + locality signal (10) — the QID is resolved server-side via SPARQL reverse-lookup from your Google Place ID, so a destination earns the entity-linking points even when the publisher doesn't declare a sameAs. For hotels and other places it splits into three proportional sub-signals: Address Structure (50) + Entity Reconciliation (30, skippable) + Geo Coordinates (20).

Pass: high entity-resolution evidence for the entity type. Partial: present but partial — destination has geo but no QID resolved; hotel has address but no reconciliation. Fail: AI can neither place you nor link you.

Destinations are weighted 0.08 within Machine-Readable Core (down from 0.16) because "is this city locatable?" is trivially yes for any DMO. The freed weight redistributes to schema completeness and server-rendered schema. Hotels keep the full 0.16 — address really matters for a specific property.

What good looks like: A destination resolves to its Wikidata Q-id, publishes a Wikipedia sameAs and geo coordinates, and carries a containedInPlace or addressRegion locality signal. A hotel publishes a typed PostalAddress, sameAs to Wikidata or Booking, and geo coordinates.

Agents need to separate a local entity from a chain, parent organization, or management brand. Clear hierarchy avoids recommendations or booking links being attributed to the wrong property.

Pass: local entity, parent brand, address, and booking URL are distinct. Partial: hierarchy is inferable but incomplete. Fail: brand and local property identity are conflated.

What good looks like: A restaurant page distinguishes the venue, parent hospitality group, local address, and reservation URL.

Review signals are a trust baseline for agents deciding whether to recommend a place. Scores grade depth and freshness rather than treating any rating snippet as enough.

Pass: structured aggregateRating has at least 20 reviews and recent activity. Partial: review data exists but is thin, stale, or not fully structured. Fail: no reliable review signal.

What good looks like: A destination or hotel links trusted review platforms and exposes aggregateRating with reviewCount and current rating data.

Almost every other check reads your own website, so a determined publisher can pass them by editing their markup. This one asks Wikipedia. We resolve your destination to its Wikidata entity — from your schema when you declare it, by name when you don't — then read the external links of its article, in the local language and in English, and check whether your domain is among them. Wikipedia editors decide the answer, self-added links are routinely reverted, and Wikipedia is a primary source for both AI training data and live citation.

100 if the article links to your domain, 0 if it does not. Existing in Wikidata is a prerequisite, not points — almost every destination does, so scoring it would separate nobody. The entity's official-website property and how many languages its article exists in are shown in your report and are worth nothing.

If we cannot resolve your entity, or Wikipedia is unreachable when we audit you, this check is skipped rather than scored zero — a question we could not ask must not read as an answer against you.

What good looks like: The Wikipedia article for the destination lists the DMO's site among its external links or references.

llms.txt is most useful when it gives agents task-organized routes, descriptions, and token expectations. Quality is graded rather than simple existence.

Pass: entries include descriptions, token counts, and task sections. Partial: file exists but is shallow or disorganized. Fail: no useful llms.txt signal.

Google does not use llms.txt for Google Search; we grade it because other engines and AI crawlers may. We weight it as a supplementary signal, not a primary one.

What good looks like: A destination groups Markdown URLs by plan a trip, book a hotel, find events, and practical information, with short descriptions for each entry.

Machine-readable manifests like llms.txt and JSON specs let agents discover which entities, tasks, and routes they can safely use. Broader coverage means agents need less guesswork to act.

Pass: manifests describe entities, tasks, and canonical routes with structured detail. Partial: coverage exists but is shallow or missing key task surfaces. Fail: no usable agent spec is exposed.

What good looks like: A hotel exposes llms.txt plus JSON manifests pointing to canonical entity data, booking endpoints, and task-specific Markdown pages.

Agents need a structured path to transact on behalf of a user. The pillar runs a universal programmatic-endpoint sub-check on every entity, plus two lodging-only sub-checks (structured ReserveAction and a cancellation policy URL) that fire on hotels and campsites.

Pass: all applicable sub-checks pass for the entity type. Partial: some action surfaces exist but are incomplete. Fail: no agent-readable action path is present.

What good looks like: A hotel exposes a programmatic booking endpoint (well-known mcp.json / a2a.json or schema.org potentialAction), a structured ReserveAction, and a cancellation policy URL on the canonical property page.

Drives answer-engine visibility — when ChatGPT, Claude, Gemini, or Perplexity fetch your site live to cite it in user answers, this is the bot set that matters. Blocking Googlebot also hurts classic SEO. We test robots.txt policy and a simulated fetch for OAI-SearchBot, ChatGPT-User, Claude-User, Googlebot, and PerplexityBot.

Pass: ≥80% of retrieval UAs allowed by robots.txt AND reach the site successfully. Partial: 50–80% on either axis. Fail: <50% on either axis.

What good looks like: robots.txt explicitly allows OAI-SearchBot, ChatGPT-User, Claude-User, Googlebot, and PerplexityBot, and the CDN's bot-protection rules don't challenge them.

Training crawlers build the long-term model knowledge of your brand. This is a longer-horizon brand-control decision: it's legitimate to opt out, but vendors increasingly use retrieval-only bots that respect this signal — so blocking training no longer breaks live citations. We test GPTBot, ClaudeBot, Google-Extended, and PerplexityBot.

Pass: ≥80% of training UAs allowed by robots.txt AND reach the site successfully. Partial: 50–80% on either axis. Fail: <50% on either axis.

What good looks like: robots.txt explicitly allows GPTBot, ClaudeBot, Google-Extended, and PerplexityBot — or you've made a deliberate, documented opt-out for training while still allowing retrieval bots.

Beyond raw HTML, agents rely on the accessibility tree, form-label association, semantic interactive elements, and stable layout. A booking widget that's invisible to the a11y tree is invisible to the agents that book on behalf of guests.

Composite of four sub-scores (A11y Tree 40 / Form Labels 25 / Interactive Semantics 20 / Layout Stability 15). Pass ≥80, Partial 40–79, Fail <40.

What good looks like: Booking CTAs are <button> with proper ARIA, every input has a label, ARIA roles are valid, and CLS is below 0.1.