Schema for Hotels and Hospitality: The Full Guide

Structured data is one of the most valuable (and most misunderstood) technical investments a hotel, B&B, or resort can make. It's also a category where a lot of the advice floating around overpromises: guides that show you a "Hotel rich result" without mentioning it's gated behind a Google partnership, or that recommend Vacation Rental markup as if any property can turn it on. That confusion costs hotels real time and sets expectations that don't match reality.

So this guide does it straight: what Hotel and LodgingBusiness schema actually get you without a Google partnership, why Vacation Rental structured data is locked behind Hotel Center access, the self-serving review trap that catches hospitality sites the same way it catches every other local business, what changed with FAQ rich results in 2026, and how all of it feeds the AI systems travelers now ask before they ask a booking site. Let's build it accurately.

The honest reality: what hotel schema does (and doesn't)

Set your expectations here first, because this is where most hotel-schema advice goes wrong.

There's no open "Hotel rich result" available to any property that adds the markup. The visual hotel experience you see in Google Search (rate cards, an availability calendar, a booking widget layered right into the results) comes from Google Hotel Ads and Hotel Center, a partner program you apply and get accepted into, not a rich result that unlocks itself once your JSON-LD validates. Google's own Hotel Price structured data reference and Vacation Rental structured data documentation both say this plainly: these instructions are for sites that have already connected with a Google Technical Account Manager and have Hotel Center access. If you haven't gone through that process, makesOffer and nested HotelRoom pricing on your Hotel schema won't produce a price or availability display in organic search, because that layer of Google Search isn't organic at all.

What Hotel and LodgingBusiness schema do get you, without any partnership, is more foundational and still genuinely valuable:

• Local visibility: feeding Google clean, structured facts (address, geo-coordinates, phone, amenities, star rating) that support your Knowledge Panel and your presence in Maps and the local pack, which is where a large share of "hotels near me" and destination searches actually land.
• Entity clarity: disambiguating your property from similarly-named hotels, chains, and OTA listings, so Google and AI systems connect the right facts to the right place.
• AI travel search: reducing the guesswork an AI assistant has to do when answering "pet-friendly hotel near the Lake District with free parking" or "boutique hotels in Austin under $200 with a pool," which is increasingly how people research where to stay before they touch a booking site.

None of that is the flashy rate-card experience. All of it is worth doing well, and it's what this guide focuses on: the schema every hotel can implement today, plus an honest look at the gated programs so you know exactly where the line sits.

Choosing the right schema type

Getting the type right is the foundation everything else builds on.

LodgingBusiness is the parent type for the entire hospitality category: hotels, motels, B&Bs, hostels, resorts. It's a subtype of LocalBusiness, which is worth remembering because it's what triggers the review-stars rule below.

Hotel is the specific type for hotels; use it instead of generic LodgingBusiness when that's genuinely what you are. More specific is always stronger than generic.

BedAndBreakfast, Motel, Resort, and Hostel are the specific subtypes for those property types. If one of these accurately describes you, use it over the generic Hotel or LodgingBusiness type.

VacationRental describes short-term rental properties (holiday cottages, villas, self-catering apartments) as its own distinct type, confirmed as a stable, production-ready type in schema.org's March 2026 release. But as covered below, the structured data that makes Vacation Rental listings display richly in Google Search is gated the same way Hotel pricing is. Use the type regardless, it's the accurate description of your property, but don't expect a rich result from it alone.

The rule, as always: use the most specific type that's actually true of your property. A boutique hotel typed as generic LodgingBusiness is giving Google and AI systems a weaker signal than the same property typed as Hotel.

A complete example: a boutique hotel

Here's a well-formed Hotel block covering the properties that matter most: identity, location, amenities, and connected rooms.

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "@id": "https://brightbay.example/#hotel",
  "name": "Bright Bay Hotel",
  "description": "A 24-room boutique hotel on Bright Bay harbor, with a rooftop restaurant and on-site spa.",
  "image": "https://brightbay.example/exterior.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Harbor Row",
    "addressLocality": "Portland",
    "addressRegion": "ME",
    "postalCode": "04101",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 43.6591,
    "longitude": -70.2568
  },
  "telephone": "+1-207-555-0110",
  "priceRange": "$$$",
  "starRating": {
    "@type": "Rating",
    "ratingValue": "4"
  },
  "checkinTime": "15:00",
  "checkoutTime": "11:00",
  "petsAllowed": true,
  "numberOfRooms": 24,
  "amenityFeature": [
    {
      "@type": "LocationFeatureSpecification",
      "name": "Free WiFi",
      "value": true
    },
    {
      "@type": "LocationFeatureSpecification",
      "name": "Swimming Pool",
      "value": false
    },
    {
      "@type": "LocationFeatureSpecification",
      "name": "Free Parking",
      "value": true
    }
  ],
  "containsPlace": [
    {
      "@type": "HotelRoom",
      "name": "Harbor View Queen",
      "bed": {
        "@type": "BedDetails",
        "typeOfBed": "Queen",
        "numberOfBeds": 1
      },
      "occupancy": {
        "@type": "QuantitativeValue",
        "maxValue": 2
      }
    }
  ]
}

A few details worth pointing out. amenityFeature includes a false value on "Swimming Pool": declaring you don't have something is as useful to an AI system as declaring you do, because it lets it answer "does this hotel have a pool?" with a confident no instead of no answer at all. Most hotel schema on the web only lists positive amenities, which leaves every unstated feature ambiguous. There's no aggregateRating on this block, deliberately; we'll get to why in the review-stars section below. And each room is nested as a HotelRoom via containsPlace, which is how you connect specific room types to the property without duplicating your address, geo, and identity on every room's own markup.

Amenities: what AI travel search actually reads

amenityFeature deserves its own moment, because it's one of the most under-implemented properties in hotel schema and one of the most directly useful for AI-driven travel queries.

When someone asks an AI assistant for a hotel with a specific feature (a pool, free parking, EV charging, an on-site gym, pet-friendliness), the system is trying to match attribute-specific intent to properties that structurally declare that attribute. A page of marketing prose describing your "resort-style amenities" doesn't give a model anything concrete to match against. A LocationFeatureSpecification with "name": "Swimming Pool", "value": true does.

The practical guidance: build out your amenity list comprehensively, covering both what you have and, where it's a common enough traveler question, what you don't. A complete amenity picture, positive and negative, is what lets an AI system answer confidently rather than hedging or guessing. A property with ten accurately-declared amenities is more useful to a matching system than one with fifty vague adjectives in its "About" copy.

The local layer: getting found by nearby and destination travelers

For most independent hotels, local and destination search still drives the majority of direct bookings, so the business layer of your schema is doing real work underneath the AI conversation.

Your address, geo coordinates, telephone, and check-in/check-out times feed what Google uses for Maps and the local pack: the results that show for "hotels in Portland Maine" or "hotel near [landmark]." Fill these in completely, and make sure they match your Google Business Profile exactly. Mismatches here (a slightly different address format, an old phone number still live somewhere) undermine confidence in both sources, the same way they do for any local business. If you operate more than one property, the patterns in our multi-location schema guide apply directly: each property as its own complete entity, not a shared block stretched across locations.

The self-serving trap: hotels and star ratings

This is the single most common mistake in hotel schema, and it catches properties the same way it catches dental practices, restaurants, and every other local business, because Hotel and LodgingBusiness are subtypes of LocalBusiness, and Google's self-serving review rule applies to them exactly the same way.

A hotel cannot show star ratings for reviews about itself, on its own site, using Hotel or LodgingBusiness schema. If your property controls the reviews being marked up (reviews you collected yourself, or a review widget you've embedded), your Hotel-typed page is ineligible for the star review feature. This is why the Hotel block above doesn't include aggregateRating: adding it there wouldn't earn stars, and it risks flagging the page.

The legitimate path for hotels runs through independent third-party sources: TripAdvisor, Booking.com, Google's own reviews, and industry-specific platforms. These are eligible to mark up reviews about your property because they're an independent party collecting them, not you reviewing yourself. So the actual strategy isn't to engineer stars onto your own homepage; it's to build a genuinely strong presence and rating on the third-party platforms travelers already trust, which does double duty, because those same platforms are exactly what AI travel assistants cross-reference for consistency. We cover the full mechanics, including the eligible content types that can self-mark-up reviews (which hotels generally aren't), in our guide to getting star ratings.

Vacation rentals and the Hotel Center gate

If you manage vacation rentals, holiday cottages, or short-term rental inventory, here's the honest picture, because a lot of vacation-rental schema advice glosses over it.

Google's own Vacation Rental structured data documentation states directly that these instructions are intended for sites that have already connected with a Google Technical Account Manager and have Hotel Center access. Getting there means filling out a vacation rental interest form (an expression of interest, not an application with a guaranteed outcome) and going through an Early Adopters Program with its own eligibility criteria. In other words, VacationRental schema producing a rich listing in Google Search isn't a self-serve technical implementation the way most structured data is. It's a partnership you're invited into.

That doesn't mean the VacationRental type itself is pointless without the partnership. Use it: it's the accurate schema.org type for the property, confirmed stable in the March 2026 schema.org release, and it still does the same entity-clarity and AI-legibility work that Hotel does for a hotel, telling search engines and AI systems precisely what kind of property this is, where it is, and what it offers. What it won't do outside the Hotel Center program is produce Google's rich vacation-rental listing experience. Be clear with clients or stakeholders about that distinction before anyone budgets for it as a rich-result play.

The Hotel Ads pricing layer, briefly

Worth a short, honest mention because it's the piece most guides conflate with everyday hotel schema: Google's Hotel Price structured data (Hotel with required name, address, and makesOffer, plus HotelRoom entries each requiring their own offers) exists to help Hotel Ads and Hotel Center partners validate price accuracy on their landing and booking pages. It's a real, documented format, and Google recommends JSON-LD for it. But it's built for partners already in that program, feeding price-accuracy checks rather than producing a standalone consumer rich result for arbitrary hotel sites.

If you're not enrolled in Hotel Ads or Hotel Center, don't spend implementation time chasing the pricing schema expecting a visible payoff in organic search. Spend it on the Hotel/LodgingBusiness identity and amenity schema covered above: that's the layer that helps every hotel, partnership or not.

What changed in 2026: FAQ rich results are gone

A currency point worth knowing if you're following older hospitality-SEO advice: Google fully retired the FAQ rich result on May 7, 2026, including the exception that had previously kept it available to authoritative government and health sites. That exception never covered hotels specifically, but a lot of hospitality-SEO content still tells properties to add FAQPage schema expecting an expandable rich result in search. That advice is now describing a feature that no longer exists for anyone.

FAQ content is still worth writing on your site: real guest questions, answered clearly, genuinely help both human readers and AI extraction. Just don't implement FAQPage schema expecting the visual rich result, and be skeptical of any hospitality-SEO guide still promising it.

Connecting your property: rooms, restaurant, spa, and events

A hotel is rarely just one entity: it's a property with rooms, often a restaurant, sometimes a spa or an event venue, and this is exactly where connected schema pays off.

Your rooms connect via containsPlace as HotelRoom entities, as shown in the example above. An on-site restaurant is its own entity (typed Restaurant or the more general FoodEstablishment) connected back to the hotel, so Google and AI systems understand it as part of your property rather than a disconnected business. This matters for a genuinely practical reason: someone searching "best brunch near the harbor" is a different intent than "hotels near the harbor," and a properly connected Restaurant entity lets your hotel surface for both, rather than only the query that matches your primary type.

A spa, a conference or event space, and one-off happenings hosted at the property can each carry their own appropriate type, connected back to the hotel the same way. If you run recurring or dated events (weddings, conferences, seasonal happenings), our Event schema guide covers the specifics, including a detail hospitality sites commonly get wrong: leaving old Event markup live long after the event has passed, which Search Console flags and which erodes confidence in the rest of your structured data.

Every one of these connected entities is also populating the same underlying idea as your brand's broader entity profile: not a pile of disconnected schema blocks, but one coherent, cross-referenced picture of what your property is and what it offers.

Hotel schema and AI travel search

This is the fastest-growing reason to get hospitality schema right, and it's worth understanding on its own terms.

Travelers are increasingly asking AI assistants directly, "boutique hotels in Austin with a rooftop bar," "pet-friendly hotels near Yellowstone under $200 a night," rather than starting with a list of blue links. Some of these systems now go further than recommending: ChatGPT and other assistants have begun shipping in-conversation booking flows with major platforms and hotel groups, meaning the distance between "traveler asks a question" and "reservation confirmed" is shrinking. Whether or not booking happens directly in the conversation, the underlying mechanics are the same ones this guide covers: clean identity schema, complete and accurate amenity data, and consistency across your own site and the third-party platforms (TripAdvisor, Booking.com, Google) an AI system cross-references for confidence.

That consistency point matters more for hospitality than for most local business categories, because travelers and AI systems alike are comparing your property against near-identical competitors down the street. Two hotels with the same view and the same star rating don't get treated the same way by an AI assistant if one has complete, structured, consistent data and the other has generic markup or none at all: the system simply has more to work with on one side. Google's own position is that no special schema is required to appear in AI Overviews or AI Mode beyond standard indexability and good content; schema doesn't buy a citation on its own. What it does is remove the ambiguity that causes a system to describe your amenities accurately or to reach for a better-documented competitor instead. For a deeper look at the mechanics of AI citation generally, our guide to getting cited by ChatGPT covers the crawler-access and entity-clarity fundamentals that apply here too.

Common mistakes to avoid

Expecting a rich result from Hotel or VacationRental schema alone. The visible rate-card and listing experiences are Hotel Ads / Hotel Center partnerships, not something JSON-LD unlocks on its own.

Adding aggregateRating to your own Hotel schema. Self-serving reviews on a LocalBusiness/LodgingBusiness subtype are ineligible for star ratings and can flag your site. Route review markup through independent third-party platforms instead.

Only listing positive amenities. Skipping explicit false values leaves common traveler questions ("does it have a pool?") unanswered to an AI system rather than confidently answered no.

Generic LodgingBusiness when a specific type fits. Hotel, Resort, BedAndBreakfast, and Motel all send a stronger, more precise signal than the generic parent type.

Stale Event markup. Weddings, conferences, and seasonal happenings that have already occurred but are still marked up as upcoming create warnings in Search Console and erode trust in your other structured data.

Relying on FAQPage for a rich result. It was fully retired in May 2026. Write FAQ content for guests and AI extraction, not for a snippet that no longer exists.

Inconsistent NAP across your site, Google Business Profile, and OTA listings. For a category travelers actively cross-reference, mismatches don't just fail to help; they undermine confidence in every source.

Duplicate LodgingBusiness entities on different pages. Multiple, slightly different descriptions of the same property across your site send conflicting signals rather than one coherent entity.

Implementing it on WordPress

Most independent hotels and B&Bs run on WordPress, often paired with a booking or PMS plugin, and the right implementation approach depends on how much of this you're maintaining by hand.

Check what your booking plugin or theme already outputs: many hospitality themes ship with generic LocalBusiness markup at best, missing the specific Hotel type, room-level detail, and amenity completeness that actually matter here.

The real challenge is depth plus staying current: the specific accurate type, connected room and restaurant entities, a comprehensive true/false amenity list, and details that change as rooms, amenities, and offerings evolve. Hand-maintaining that across a growing property (or a portfolio of them) is exactly where most hospitality sites fall behind, and where a stale amenity list or an old Event block quietly sits for months.

This is where generating markup from your live content helps. AI Schema Gen reads your property, room, and amenity pages and generates the accurate specific schema (Hotel or your correct subtype, connected HotelRoom entities, a complete amenity picture), and because it generates from your actual content rather than a static template, your markup stays in sync as rooms, amenities, and offerings change, rather than drifting the way hand-written JSON-LD does after the next site refresh. It also keeps you clear of the self-serving review trap by generating markup that matches what's genuinely eligible on your pages, rather than defaulting to a rating claim that won't work. Whatever route you take, the tests are the same: the accurate specific type; a complete, honest amenity list; connected room and dining entities; and no rating claim on a page where it's ineligible.

Validating your hotel schema

Google's Rich Results Test validates your markup and flags errors, useful for confirming syntax, though remember that Hotel/LodgingBusiness won't show a rich-result preview the way Product or Recipe do outside the Hotel Ads program.

The Schema Markup Validator at validator.schema.org checks broader schema.org validity for the connected entities (rooms, restaurant, amenities) that don't map to a specific consumer rich result.

Cross-check consistency between your schema, your Google Business Profile, and your listings on TripAdvisor and OTA platforms: name, address, phone, and amenities should tell the same story everywhere.

Search your own property name and a few destination queries to see how you're currently represented, and periodically ask an AI assistant about hotels in your area to check whether your amenities and details come through accurately.

Running a hotel, B&B, or resort on WordPress? AI Schema Gen generates the accurate specific schema from your property, room, and amenity pages, a complete, honest amenity picture, connected rooms and dining entities, and no rating claims where they won't work, and keeps it in sync as your property changes. Start free at aischemagen.com.