
Intro
Schema is one of the highest-leverage technical changes a premium hotel can make for AI visibility.
It works on both sides of the answer engine. On the selection side, Google AI Overviews and Gemini lean heavily on structured data to decide which property to name. On the absorption side, schema makes the page machine-scannable for ChatGPT and Perplexity crawlers that prefer clean entity signals over prose parsing.
This page is a hand-off document for marketing and development. It explains the seven hotel schemas that matter, where each one lives, the five mistakes we see most often, and how to validate the result.
Why schema is high-leverage for hotel AI visibility
A hotel page without schema asks the engine to infer the entity from prose. The engine has to guess: is this a hotel, a restaurant inside a hotel, or a tour operator selling a hotel package? Inference is lossy, and inference favours larger brands with stronger contextual signals.
A hotel page with correct schema removes the guess. The JSON-LD declares the entity type, the location, the rating, the rooms, the offers, the reviews, the services. The engine reads that block and treats it as canonical.
The downstream effect shows up in three places. First, eligibility for rich results in Google search. Second, citation rate in AI Overviews — schema-marked pages are reused more often as the answer’s source URL. Third, accuracy of brand description in ChatGPT and Perplexity, because the model has clean key-value pairs to draw from instead of paragraph text.
Schema does not invent visibility. It removes the friction that prevents existing content from being selected and absorbed. That is why we treat it as a baseline, alongside machine scannability and evidence container design.
The seven hotel schemas that matter
Schema.org defines hundreds of types. For a premium hotel, seven of them carry the load.
Hotel
The primary entity type for the property itself. Use Hotel — not LocalBusiness, not Place, not Organization. The Hotel type inherits from LodgingBusiness and adds hospitality-specific properties.
Required properties: name, address (full PostalAddress), geo (GeoCoordinates with latitude and longitude), telephone, url. Strongly recommended: starRating (using Rating with ratingValue), amenityFeature (list of LocationFeatureSpecification), numberOfRooms, petsAllowed, checkinTime, checkoutTime, image (multiple, with explicit dimensions).
LodgingBusiness
The parent type. Use LodgingBusiness only when the property does not fit Hotel, Resort, BedAndBreakfast, Motel, or Hostel. For a five-star urban hotel, use Hotel. For a destination property with multiple buildings, Resort is often more precise. Resort inherits from LodgingBusiness as well.
Offer
The pricing layer. Each bookable room category or package should carry its own Offer, typically nested inside the room as a HotelRoom with an associated Offer. Properties that matter: price or priceRange (a range string when single price is not honest), priceCurrency, availability, validFrom, validThrough, url (deep link to the booking flow).
Review and AggregateRating
The trust layer. Review is for individual reviews displayed on the page. AggregateRating summarises them. Both must reflect real, verifiable reviews — never invented, never copied from third-party platforms without attribution. If the hotel does not display real reviews on the page, do not add AggregateRating. Faked aggregate ratings are the fastest way to a manual action.
FAQPage
The question layer. Add FAQPage schema only on pages that genuinely display a FAQ block, with questions and answers visible to humans. Each Question carries name (the question) and acceptedAnswer (with text). FAQ schema feeds AI Overview “People Also Ask” placements directly.
Service
The amenity layer. Use Service for distinct offerings inside the hotel — spa, restaurant, conference space, private dining, wedding venue, concierge. Each service deserves its own page and its own Service block, with provider pointing back to the hotel entity by @id.
BreadcrumbList
The navigation layer. Every page on the site carries a BreadcrumbList. It is cheap to implement, it improves rich result eligibility, and it gives AI engines a clear sitemap of the hotel’s content hierarchy.
Where to place each schema
Schema placement follows page intent.
Homepage: Hotel (or Resort) as the primary entity, with full address, geo, starRating, amenityFeature, image set, sameAs links to social profiles. BreadcrumbList with a single Home node. No Offer here — offers belong on room pages.
Rooms / suites pages: HotelRoom entities, each nested with an Offer. The room page carries one main room entity and its offer. Avoid stuffing every room into the homepage.
Restaurant page: Restaurant entity (separate from the Hotel), with its own address (same as parent), menu URL, servesCuisine, openingHoursSpecification. Link back to the Hotel via isPartOf or a custom relationship.
Spa / wellness page: Service entity with provider pointing to the Hotel @id, plus a HealthAndBeautyBusiness block if the spa is bookable independently.
FAQ page (or FAQ block on any page): FAQPage schema, but only when a real FAQ is visible to the user.
Every page: BreadcrumbList reflecting the URL hierarchy.
The nesting pattern that works best is a single @graph per page containing all relevant entities, each with a stable @id URI. Cross-references use @id rather than nested objects. This keeps the JSON-LD readable and lets crawlers resolve relationships cleanly.
Five common mistakes
-
LocalBusinessinstead ofHotel. The most frequent error.LocalBusinessworks for restaurants and shops, not for accommodation. Engines treat it as a weaker signal and may drop hotel-specific rich results. -
Missing geo coordinates. Address alone is not enough.
geowith explicit latitude and longitude unlocks map placements and location-based AI answers (“hotels near the Louvre”). -
AggregateRatingwithout a real source. Inventing a 4.8 rating with 247 reviews to chase rich snippets is a manual action waiting to happen. Only mark up ratings that are visible, verifiable, and tied to a real review collection on the page. -
One giant Hotel block on every page. The homepage carries the Hotel entity. Internal pages reference it by
@idand add their own context (room, service, restaurant). Repeating the full Hotel block on every URL creates noise and dilutes the canonical signal. -
No
BreadcrumbList. The cheapest schema to implement, frequently forgotten. Without it, the engine has to rebuild the hierarchy from URLs and internal links, which is lossy.
How to validate
Three tools cover the full validation surface.
Schema.org validator (validator.schema.org) — the strict syntactic check. Catches malformed JSON, invalid types, missing required properties.
Google Rich Results Test — the pragmatic check. Shows which rich results the page is eligible for and which warnings Google flags. Run this before every production push.
Manual SERP check — after deployment and reindexing (usually 48–72 hours), search for the brand and check whether the rich result appears. Then run a small set of hospitality scorecard prompts to see whether AI Overviews surface the hotel correctly.
Document each schema deployment with: which URL, which entity types, validation screenshot, date, and the next retest date.
How this fits into Capston Core
Hotel schema is a foundational layer of Capston Core. It sits underneath how to win Google AI Overviews, feeds the machine scannability baseline, and gets retested on every quarterly retest cadence. Hotels that pass the schema baseline move on to evidence work and prompt-set scoring.
→ Back to Capston Core
FAQ
Should I use Hotel or LodgingBusiness?
Hotel when the property fits the standard hotel category. Resort for destination properties with grounds. LodgingBusiness only as a fallback when no more specific type applies.
Can I add AggregateRating if reviews come from TripAdvisor?
Only if the page displays the reviews itself and the rating is computed from those displayed reviews. Copying a third-party aggregate score without showing the source on-page is a violation.
Where should room pricing schema live?
On each individual room page, as an Offer nested inside HotelRoom. Never on the homepage.
How often should I revalidate schema?
After every site update that touches templates, prices, or content structure. Quarterly at minimum, even if nothing visible changes — schema.org and Google guidelines evolve.
Final CTA block
Get your hotel schema audited and corrected.
Audit your schema
Run the baseline