{"@context":"https://schema.org","@type":"BlogPosting","headline":"The Schema.org Debate (2026): Why It Still Matters for Hotels","description":"AEO oversold schema as an LLM unlock. The pushback that transformers read tokens, not JSON-LD, is right for the general case. For hotels, every major AI still grounds against Places / KG / OTA aggregators — surfaces that sit downstream of schema. The four fields that actually move the needle: Hotel (category gate), sameAs (cross-platform identity), typed starRating (category bucket gate), alternateName (cross-time identity for rebranded hotels).","datePublished":"2026-05-13","dateModified":"2026-05-13","url":"https://nicolassitter.com/research/schema-org-grounding-loop-2026","category":"research","keywords":["Schema.org for AI","Hotel schema markup","sameAs hotel","alternateName hotel","starRating schema","Knowledge Graph hotel","AEO schema","grounding loop"],"articleSection":"Research","wordCount":2400,"readTime":"10 min","articleBody":"Research · Schema.org & AI\n\n# The Schema.org DebateDoesn’t feed the LLM. Feeds what the LLM calls.\n\nThe AEO industry oversold schema as an LLM unlock. The pushback — that transformers don’t read schema as schema, they read tokens — is right for the _general_ case. But it’s wrong by omission for local. Every major AI grounds hotel queries against Google Maps / Places, which sit downstream of schema and the Knowledge Graph. The loop is real. It’s also narrower than the AEO pitch.\n\n## Two claims, only one is true\n\nThe whole AEO/GEO marketing layer rests on conflating two distinct claims:\n\n### Claim 1: Schema is useful in classical search\n\nTrue\n\nRich 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.\n\n### Claim 2: Schema feeds the LLM\n\nFalse\n\nSchema 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.\n\n## But for hotels, schema still reaches the LLM — via a loop\n\nFor local / POI intent, the conclusion “schema doesn’t matter for AI search” is wrong. Look at where the major AIs _actually source_ their hotel answers:\n\n**Gemini** — Google. Maps, Places, Knowledge Graph natively.\n\n**ChatGPT** — per the [anatomy capture](/research/anatomy-chatgpt-hotel-search-2026), the pipeline blends Google Places among 5+ providers.\n\n**Claude** — per the [Claude capture](/research/how-claude-searches-hotels-2026), one direct call to Google Places per hotel query.\n\nThe grounding source the LLM calls is fed by schema (entity reconciliation into the KG, amenity markup, sameAs to Wikidata) and by the Knowledge Graph itself. So: schema doesn’t feed the LLM — but it feeds what the LLM calls. Same effect, different mechanism. Different mental model.\n\n![Claude.ai rendering a map of Marseille with five hotel pins and a side panel listing ALEX Hôtel & Spa (4.5★), Hôtel Carré Vieux Port (4.3★), and Hôtel Maison Montgrand (4.1★). The data comes from a places\\_search tool call to Google Places.](/_next/image?url=%2Fimages%2Fclaude-marseille-hotel-search.png&w=1920&q=75&dpl=dpl_3E9vSPHyuS22fHZatqX6Bmd76b95)\n\n**The loop, visible.** Claude’s answer to “best 3-star hotels in Marseille.” The map and side panel are populated by a single `places_search` call — star rating, photos, address, review count all sourced from Google Places, which in turn is fed by GBP and by the schema/sameAs signals that reconcile this hotel to its KG entity. The transformer never saw the JSON-LD on the hotel’s site. It saw the Places response.\n\n## The careful version\n\nTwo refinements before you re-stamp every page with `@type: Hotel`:\n\n### GBP is the API surface — not the whole entity\n\nLook 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.\n\n### Not the FAQ schema you think you need\n\nGeneric 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:\n\n-   **`@type: Hotel`** — not `LocalBusiness`, not `Organization`. The category gate. KG entity reconciliation hinges on classifying you correctly in the first place.\n-   **`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.\n-   **`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](/research/ai-hotel-rankings-consistency-study-2026) on category gating.\n-   **`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).\n\nFAQ 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.\n\nWhat AEO templates ship\n\n{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"LocalBusiness\",\n  \"name\": \"Hôtel Example\",\n  \"description\": \"A wonderful hotel in Paris...\",\n  \"address\": { \"@type\": \"PostalAddress\", ... },\n  \"telephone\": \"+33...\",\n  \"openingHours\": \"Mo-Su 00:00-24:00\",\n  \"priceRange\": \"$$$\",\n  // FAQPage — fine if relevant, just not the main lever\n  \"mainEntity\": \\[{\n    \"@type\": \"Question\",\n    \"name\": \"Do you have free wifi?\",\n    \"acceptedAnswer\": { \"@type\": \"Answer\", ... }\n  }\\]\n  // no sameAs, no starRating, wrong @type\n}\n\nWrong category, no entity reconciliation, no star bucket. Earns nothing in the grounding loop.\n\nWhat the loop actually consumes\n\n{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"Hotel\",\n  \"name\": \"Alfred Hotel Beaune\",\n  \"alternateName\": \\[\"Hôtel de la Paix\"\\],\n  \"address\": {\n    \"@type\": \"PostalAddress\",\n    \"streetAddress\": \"5 rue de l'Hôtel-Dieu\",\n    \"addressLocality\": \"Beaune\",\n    \"postalCode\": \"21200\",\n    \"addressCountry\": \"FR\"\n  },\n  \"starRating\": {\n    \"@type\": \"Rating\",\n    \"ratingValue\": \"4\"\n  },\n  \"sameAs\": \\[\n    \"https://www.wikidata.org/wiki/Q123456\",\n    \"https://www.booking.com/hotel/fr/example.html\",\n    \"https://www.tripadvisor.com/Hotel\\_Review-g187147-d000000.html\",\n    \"https://maps.google.com/?cid=00000000000000000000\"\n  \\],\n  \"amenityFeature\": \\[\n    { \"@type\": \"LocationFeatureSpecification\", \"name\": \"Free WiFi\", \"value\": true },\n    { \"@type\": \"LocationFeatureSpecification\", \"name\": \"Breakfast\",  \"value\": true }\n  \\]\n}\n\nRight category, OTA profiles reconciled to you, typed star bucket, amenities GBP can’t express.\n\n### Amenities and `HotelRoom` — the part GBP can’t encode\n\nSchema can encode a lot more than GBP exposes. You can ship typed amenities, room subtypes, bed configurations, accessibility flags, room sizes — and you control all of it directly from your CMS:\n\n{\n  \"@type\": \"Hotel\",\n  \"amenityFeature\": \\[\n    { \"@type\": \"LocationFeatureSpecification\", \"name\": \"WiFi\", \"value\": true },\n    { \"@type\": \"LocationFeatureSpecification\", \"name\": \"Pool\", \"value\": true },\n    { \"@type\": \"LocationFeatureSpecification\", \"name\": \"Pet-friendly\", \"value\": false }\n  \\],\n  \"containsPlace\": \\[{\n    \"@type\": \"HotelRoom\",\n    \"name\": \"Deluxe Suite\",\n    \"bed\": { \"@type\": \"BedDetails\", \"numberOfBeds\": 1, \"typeOfBed\": \"King\" },\n    \"occupancy\": { \"@type\": \"QuantitativeValue\", \"maxValue\": 2 },\n    \"floorSize\": { \"@type\": \"QuantitativeValue\", \"value\": 35, \"unitCode\": \"MTK\" },\n    \"amenityFeature\": \\[\n      { \"@type\": \"LocationFeatureSpecification\", \"name\": \"Balcony\", \"value\": true }\n    \\]\n  }\\]\n}\n\nGBP gives you a narrow set of typed amenities (pool, parking, WiFi, breakfast) and no room-level structure at all — no bed types, no floor size, no accessibility per room. Your `Hotel` schema is the natural place to expose all of that. The markup is one-time, it’s entirely under your control, and it feeds the same entity graph the LLMs ground against. It’s the easiest delta over GBP to ship.\n\n### Two surfaces, two strategies\n\nA 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.\n\nThe actual finding\n\nDon’t double down on AEO schema theatre. Don’t throw schema out either. For hotels (and for local intent generally), the right framing is: **schema doesn’t feed the LLM, but it feeds what the LLM calls.** The same playbook that earned you Knowledge Graph hygiene last decade earns you grounding-source hygiene this one. The optimisation game stays similar; only the target downstream of it has changed.\n\n## Frequently Asked Questions\n\n### Summarize with AI\n\n### Related research\n\n[\n\nHotel Schema.org Adoption Study\n\nHow widely hotels actually ship structured data — and which fields.\n\n](/research/hotel-schema-adoption-study-2026)[\n\nHow Claude Searches Hotels\n\nOne direct call to Google Places — the grounding loop in action.\n\n](/research/how-claude-searches-hotels-2026)","author":{"@type":"Person","name":"Nicolas Sitter","url":"https://nicolassitter.com/about","sameAs":["https://www.linkedin.com/in/nicolassitternolleau/","https://github.com/Nicositter88","https://hotelrank.ai"]},"publisher":{"@type":"Person","name":"Nicolas Sitter","url":"https://nicolassitter.com"},"image":"https://nicolassitter.com/api/og/schema-org-grounding-loop-2026","mainEntityOfPage":{"@type":"WebPage","@id":"https://nicolassitter.com/research/schema-org-grounding-loop-2026"},"tags":["Schema.org","AEO","GEO","Knowledge Graph","Hotels"],"sameAs":["https://hotelrank.ai/research/schema-org-grounding-loop-2026"],"alternateFormat":{"html":"https://nicolassitter.com/research/schema-org-grounding-loop-2026","json":"https://nicolassitter.com/api/post/schema-org-grounding-loop-2026","rss":"https://nicolassitter.com/rss.xml"},"datasets":[{"name":"summary","contentUrl":"https://nicolassitter.com/data/schema-org-grounding-loop-2026/summary.csv","encodingFormat":"text/csv"}]}