Travel and Hospitality Schema Markup Explained

A hotel page that never states its own star rating or nightly rate in a format search engines can read might as well be invisible to half of what shows up in results. Most travel and hospitality schema markup on booking and tour sites is either missing or built wrong.

A study of hotel structured data by Nicolas Sitter scored a large sample of hotel homepages against Google's own criteria. Only 10.6 percent came back as a good implementation.

The rest weren't necessarily empty. Many had tried and got the basics wrong, marking a property up as a generic business listing instead of anything that told a search engine this was a hotel with rooms, rates and a location worth surfacing.

Where travel and hospitality schema markup goes wrong

The single most common mistake in Sitter's study was using the generic Organization type instead of Hotel, the type schema.org actually defines for lodging. It showed up on 34.7 percent of the sites checked.

That one substitution is why so many listings never earn a star rating or a price range in search results, even when the property has both on the page already.

Past the wrong type, most sites that did try left out the details that make the markup worth having. Amenity information, aggregate review scores and geographic coordinates were each absent from the large majority of homepages the study checked.

None of that is exotic information. It's the same detail already sitting on the page for a human visitor, just never written in a form a machine can lift out.

What actually needs to be marked up

Schema.org's vocabulary for lodging starts with two types. Hotel needs a name, an address and at least one offer. HotelRoom carries the per-room pricing.

A resort, inn or bed and breakfast should use its own specific subtype rather than the generic LodgingBusiness parent, since the specific type is what unlocks the richer search result.

Past that core pair, Travel Tractions' guide to hotel schema points to a few more types worth adding once the basics are solid:

• FAQPage, for the questions a property answers over and over
• Review, for guest ratings and testimonials
• Event or Tour Operator, for anything bookable beyond a room, from a spa slot to a guided excursion

None of it replaces the actual booking-flow work behind the page, which is where a lot of travel sites lose visitors regardless of how well the markup reads.

The JSON-LD assumption that doesn't hold for pricing

Photo by Markus Spiske on Pexels

Most structured data advice defaults to one format: JSON-LD, dropped into a script tag without touching the page's HTML. Google's general structured data guidelines list it as one of three supported formats, with no exception carved out for hotels.

Hotel pricing is the exception. Google's hotel price structured data reference now names Microdata as the default and recommended format for validating hotel rates specifically, and calls JSON-LD deprecated for that one purpose, kept only for legacy reference.

Whichever format a property uses, the price in the markup has to match the price a visitor actually sees, taxes and fees included, or Google's own validation flags the mismatch.

Correct markup still doesn't guarantee a rich result

Getting the markup right earns eligibility, not a promise. Google's general guidelines are explicit that a page can pass every technical check and still never display as a rich result.

Structured data blocked by robots.txt or a noindex tag never even gets evaluated.

Start with Hotel and HotelRoom on the pages that carry your rates. Get the displayed price matching the marked-up price before touching anything else.

Reviews, FAQs and tour listings can wait. That core pricing data is what most search visibility work for a hospitality brand now depends on, and it increasingly feeds the AI systems behind the AI answer economy that a growing share of travel searches end in.

Cover photo by Negative Space on Pexels