The Schema.org DebateDoesn’t feed the LLM. Feeds what the LLM calls.

Rich results (prices, ratings, event times, FAQs) on Google SERPs. Knowledge Graph entity disambiguation. Voice assistants pulling structured fields. None of that goes away. If you’re responsible for technical SEO, keep implementing schema where it earns its keep.

Schema cannot reach into a transformer and improve its comprehension of your prose. The model isn’t architected to read schema as schema — it receives whatever text the search or retrieval layer fetched and chose to include, and processes that text as language tokens. The JSON-LD block on your hotel page doesn’t make the model “understand” you better. That part of the AEO pitch is just wrong.

Look at a Places API response in an LLM tool call and most of what you see — rating, review_count, hours, photos, address — comes from Google Business Profile. That’s what is visible to the model at call time, and it makes schema look redundant. But GBP is a narrow surface: no amenities field, no room categories, limited typed attributes. The fuller hotel entity sitting behind the Knowledge Graph has more on it — and that’s where your Hotel schema does work: amenity / starRating / category markup feeds KG enrichment that GBP can’t express, and sameAs reconciles your hotel to its OTA profiles (Booking, TripAdvisor, niche aggregators) so those profiles route grounding traffic to you, not to a near-duplicate listing. The clean way to say it: schema → entity graph → grounding source → LLM. Not the linear “schema → LLM” the AEO pitch implies — but also not the dismissive “GBP is all that matters” that the API view encourages.

Generic AEO advice for any business is “add FAQ schema, add HowTo schema, add Article schema.” For hotels that’s not where the leverage is. The three types that actually move the needle in the grounding loop are unsexy and specific:

• @type: Hotel — not LocalBusiness, not Organization. The category gate. KG entity reconciliation hinges on classifying you correctly in the first place.
• sameAs — an array of canonical URLs (Wikidata, your Booking listing, your TripAdvisor profile, your Google Maps URL). This is how your hotel page on your own site gets fused with the OTA profiles LLMs cite. Without it, aggregators get the grounding traffic; with it, you do.
• starRating — specifically the typed Rating object with ratingValue, not a number in your prose. AI hotel queries are sliced by category bucket (“best 4-star”, “luxury”, “budget”) and if your category is wrong or missing, you don’t appear in the relevant bucket — see the rankings consistency study on category gating.
• alternateName — the most underused field in hotel schema, and the one that solves a real and growing problem: hotels rebrand all the time. AIs trained on pre-rebrand data still recommend the old name. A specific case: Hôtel de la Paix in Beaune is now Alfred Hotel Beaune. With alternateName: ["Hôtel de la Paix"] on the live page’s schema, the entity reconciliation can route the old query to the new identity. Without it, you’re fighting your own training data forever. sameAs handles cross-platform identity (you = your Booking listing); alternateName handles cross-time identity (you now = you then).

FAQ blocks may earn a rich result on a SERP, but they don’t change how a hotel surfaces in an AI answer. The boring four above do.

A hotelier’s own schema mostly affects how their own site surfaces — rich results, KG card, voice. What affects how they appear inside an LLM answer is whether the grounding sources (Maps/Places, OTAs, niche aggregators) carry them correctly. So the practical takeaway splits: keep schema on your site for classical SEO + KG hygiene; for AI visibility, also audit how you’re represented in the upstream sources LLMs actually call.