Hotel AEO Is Not FAQ Schema. It Is Entity, Evidence and Booking Readiness.
Google states no special schema or AI-specific optimization is required for its AI features. What structured data can and cannot do, visible-content accuracy, entity consistency, source authority, crawler access, and the AEO theatre to avoid.
The quote that ends most of the sales pitch
Google's published guidance on its AI features is unusually direct for a document of its kind. There is no special schema.org structured data required for its generative AI features. There is no AI-specific markup. There are no additional requirements to appear in AI Overviews or AI Mode beyond existing search fundamentals. The guidance addresses llms.txt, AI-specific content chunking and AI-oriented rewriting, and treats none of them as necessary.
Trade coverage summarised the position as: AEO and GEO are still SEO.
If you have been quoted for "AI schema implementation," that quotation is for markup. It may be perfectly good markup. It is not the mechanism it is being sold as.
This piece is about what is left once the theatre is removed — which turns out to be a substantial and largely unglamorous list.
What structured data can and cannot do
Structured data is still worth maintaining. It makes pages eligible for rich results in ordinary search, it disambiguates entities, and it is a reasonable discipline for keeping property facts in one machine-readable place.
What it cannot do:
- It cannot make an answer recommend you.
- It cannot contain facts that are not visible on the page. That is not a stylistic preference; it is a violation of the structured-data guidelines, and a hotel that marks up amenities it does not display is risking eligibility rather than gaining it.
- It cannot correct a wrong fact held by a source you do not control.
- It cannot substitute for content that does not exist.
That last one matters most for hotels. A property with no page describing its accessibility provision cannot mark up accessibility provision. Schema describes content. It does not create it.
The distinction that actually matters
Not structured versus unstructured. Reachable, readable and consistent, versus not.
An answer about a hotel is synthesised from whatever the system retrieved. Which means the useful questions are:
- Can the surfaces reach the site at all?
- Once reached, is the fact present as text a machine can read?
- Does that fact agree with what every other source says?
Three questions, and hotels fail them in that order of frequency.
Visible-content accuracy
The commonest real defect is not missing markup. It is a fact that exists on the property but not in crawlable HTML.
The recurring hotel offenders:
- PDFs. Accessibility statements, meeting-room specifications and floor plans live in PDFs constantly. A PDF is a poor citation candidate and a worse source of a specific fact.
- Images. Room dimensions, pool length and amenity lists rendered into a graphic. Beautiful, and invisible.
- Client-rendered widgets. Booking engines, availability calendars and increasingly whole amenity sections that only exist after JavaScript runs.
- Interactive maps substituting for a written description of where the property actually is.
- Video carrying the property story with no transcript.
The corrective is boring and effective: if a fact matters commercially, it should exist as text, on a page, in HTML.
Entity consistency
A hotel exists across dozens of records it does not fully control: its own site, Business Profile, OTA listings, tourism authority pages, review platforms, restaurant guides, meeting-venue directories, old press.
When those records disagree, the answer picks one. Frequently the wrong one, because "wrong" and "most confidently stated" are unrelated properties.
The facts most worth auditing, in the order they cause commercial damage:
| Fact | Why it costs money when wrong | | --- | --- | | Pet, child and accessibility policy | Directly disqualifies a guest who would have booked | | Restaurant and bar count | Undercounts the property's F&B proposition and its total-revenue story | | Room count and room types | Removes the property from group and meeting consideration | | Location and district | Loses walkability and proximity questions, which are among the commonest asked | | Check-in, check-out and fees | Erodes confidence at exactly the wrong moment | | Amenity specifics | Loses amenity-led questions, which are unusually high-intent |
A worked example from our fictional sample audit: a stale pet-policy field on a single OTA record produced a wrong answer on one prompt, and cost the property the entire pet-friendly prompt family on a second surface. One incorrect record, two lost question families. No amount of schema on the hotel's own site would have touched it.
The fix is not technical. It is an afternoon of record maintenance across third-party sources, and it is routinely the highest-return item in an audit.
Source authority
Answers cite. Which means the practical question is not "how do I rank" but "why would anything quote me?"
Hotels are unusually badly served here, because the sources that describe them best are usually not theirs: the OTA listing is more detailed than the hotel's own room page, the review platform holds more about the restaurant than the restaurant's page does, and the destination authority describes the neighbourhood better than the hotel does.
That is not inevitable. It is the consequence of hotel websites being built as brochures with a booking button rather than as the most authoritative description of the property in existence.
The work is genuine content work: pages that answer real guest questions with specifics rather than adjectives, presence in destination and category sources that are themselves cited, and accuracy maintained in the third-party records that carry your facts. It is slower than markup and it is the actual mechanism.
Crawler access, which is binary
The least glamorous section and the one that most often produces an immediate result.
Google's guidance explicitly names CDN and hosting infrastructure alongside robots.txt. That phrasing is doing work. The realistic hotel failure is not a deliberate block in robots.txt — it is a firewall rule, a bot-protection setting or a rate limit returning 403 to a declared crawler, while the robots.txt file cheerfully says Allow.
And the crawlers are not interchangeable. OpenAI operates three, with different jobs:
| Agent | Purpose | Consequence of blocking |
| --- | --- | --- |
| OAI-SearchBot | Indexes for ChatGPT's search and citation behaviour | You cannot be retrieved or cited in ChatGPT search |
| GPTBot | Training data collection | Content is excluded from training |
| ChatGPT-User | User-triggered page fetches | A user asking about your page cannot fetch it |
Allowing one does not allow the others. Hotels that blocked "AI bots" in 2023 to keep their content out of training frequently removed themselves from ChatGPT's search retrieval at the same time, without ever deciding to.
Verification is a two-step check — the user-agent token must match and the source IP must fall inside the published range. OpenAI publishes machine-readable IP ranges for exactly this. A user-agent string alone is trivially spoofable, so any WAF rule that allowlists on user-agent alone is not doing what its author thinks.
Practical actions:
- Address each agent explicitly in
robots.txtrather than relying on a wildcard. - Ask your CDN or hosting provider for logs showing declared crawler requests and their response codes. A 403 is your answer.
- Verify by IP range, not by user-agent string.
- Decide the training question separately and deliberately. It is a legitimate business decision — it is just not the same decision as search retrieval.
Guest-question coverage
Answers are assembled around questions. Hotel content is organised around inventory.
Hotel websites have room pages, a dining page, a spa page and an offers page. Guests ask about walkability to a specific landmark, whether the pool is worth using, whether the restaurant takes non-residents, whether the property suits a toddler, whether there is anywhere to take a call, whether the meeting room fits forty people.
The gap between those two lists is the content opportunity, and it is discoverable without a keyword tool: run a prompt panel, note which question families never produce a mention, and write for those.
The discipline that matters: write for the guest, not for the machine. Answer-ready content and human-first content are the same content when it is done properly — specific, accurate, organised, and written by someone who knows the property. Content written to be parsed reads as though it was, and it will be competing with an OTA listing that at least has real photographs.
AEO theatre to avoid
Recognisable by the promise attached:
- "AI schema." Does not exist. Google says so.
llms.txt. Addressed in Google's guidance and not treated as a requirement. It costs almost nothing to add, which is precisely why it is sold — but it should not be presented as a mechanism.- FAQ schema added for visibility. If the FAQ is genuine and visible, mark it up if you like. Adding questions nobody asks, so the markup exists, is content pollution with extra steps.
- "AI-ready certification." No external authority issues one. A badge from a vendor certifies that you paid the vendor.
- Guaranteed AI rankings. There is no rank. There is nothing to guarantee.
- Bulk AI-written location pages. Thin pages at scale, which has failed in ordinary search for a decade and has not become a good idea since.
- Citation or review generation. Manufacturing the evidence you are being assessed on. Beyond the ethics, it is fragile.
- An opaque 0–100 score. If the formula is not published, the number is not a measurement. It is a reason to renew.
A practical checklist
Ordered by return, not by effort.
Distribution — often days, and the most likely to move revenue
- [ ] Confirm Hotel Center state and whether free booking links are appearing for the property
- [ ] Confirm rate and availability accuracy in the booking module
- [ ] Confirm every page an answer has cited offers a visible route to the booking engine
- [ ] Publish the direct-booking value proposition as crawlable text, not a banner graphic
Access — hours, and binary
- [ ] Address
OAI-SearchBot,GPTBotandChatGPT-Userexplicitly and separately inrobots.txt - [ ] Obtain CDN/WAF logs and confirm declared crawlers are not receiving 403s or challenges
- [ ] Verify crawler identity by published IP range, not by user-agent string
- [ ] Confirm key content renders in HTML rather than only after JavaScript
Entity — an afternoon, high return
- [ ] Audit pet, child, accessibility and check-in policies across your three largest third-party listings
- [ ] Reconcile room count, room types and F&B outlet count across every source
- [ ] Confirm location and district descriptions agree
- [ ] Correct at source, then allow thirty days before re-testing
Content — weeks to months
- [ ] Move accessibility, amenity and meeting specifications out of PDFs and images into HTML
- [ ] Build pages for the question families a prompt panel shows you missing
- [ ] Make your own pages the most authoritative description of the property that exists
- [ ] Publish in the market's second language where it is commercially relevant
Markup — last, and modest
- [ ] Ensure structured data matches visible content exactly
- [ ] Remove any markup describing facts not shown on the page
- [ ] Do not add FAQ schema for questions no guest asks
- [ ] Do not expect any of this to produce a recommendation
The short version
Google says no special optimization is required for its AI features, and it means it. The work that remains is access, accuracy, authority, coverage and bookability — five things a hotel commercial function is entirely capable of understanding, and none of which fit on an invoice line called "AI schema."
Sources. Google Search Central, AI features and your website and the generative-AI optimization guide (no special schema; no additional requirements; crawling must be permitted by CDN and hosting infrastructure as well as robots.txt); Google's structured data general guidelines (markup must match visible content); OpenAI crawler documentation and published IP ranges (OAI-SearchBot, GPTBot and ChatGPT-User are separate agents requiring separate handling); Google Hotel Center Help on free booking links. Platform documentation changes — re-check dates before relying on any of it commercially. The worked example is drawn from a fictional sample property and is not a Katalyst client result.
Katalyst insights are based on operator-side experience, original commercial analysis and clearly labelled illustrative calculations. External facts are sourced where used. Representative scenarios are not presented as disclosed client results.
The diagnostic is how the pattern becomes clear.
If this pressure sounds familiar, the next step is not more activity. It is a structured view of what is leaking and what deserves attention first.