Hotel Schema Markup: LodgingBusiness, Offers and Reviews

What is hotel schema markup?

Hotel schema markup is structured data, written in a shared vocabulary from Schema.org, that labels the facts on your website so search engines read them without guessing. It tells Google your property is a LodgingBusiness, gives your address and coordinates, your room rates as Offers, your star rating and your guest review score, all in code that machines parse reliably.

A search engine can read your homepage and infer you are probably a hotel. Schema removes the inference. Instead of working out that the number near a room photo is a price, it is handed a structured Offer with a currency and a value. Instead of scraping a review widget, it receives an AggregateRating with a score and a count.

That precision is the whole point. The cleaner your facts, the more confidently Google can display them as a rich result, and the more readily an AI assistant can quote them when a guest asks where to stay. For hotels this matters more than for most businesses, because you are competing for your own name against OTA listings that are themselves heavily structured.

Why most hotel websites have none of it

Most independent hotel sites run on website builders or off-the-shelf themes that ship with generic LocalBusiness markup at best, or nothing at all. Schema is invisible to the human eye, so it never shows up in a design review and rarely makes it onto a brief. The result is a quiet, widespread gap that a well-marked-up site can exploit.

There is also a knowledge gap. Hotel-specific schema is genuinely fiddly. LodgingBusiness has its own properties (check-in time, amenities, number of rooms, pet policy) that a general web developer will not know off the top of their head. Faced with that, many simply skip it.

This is good news if you act on it. When competitors and even the OTAs publish thin or generic markup for your area, a single property page that fully describes itself in structured data can earn the rich treatment they cannot. It is the kind of behind-the-scenes edge we describe across our hotel marketing guide: unglamorous work that compounds while others ignore it.

LodgingBusiness and Hotel: the core type

LodgingBusiness is the Schema.org type for any place that offers accommodation, and Hotel is its more specific child type. One of these, not the generic LocalBusiness, should describe your property. It carries the identity facts that matter to search: name, address, geo-coordinates, telephone, price range, star rating, check-in and check-out times and amenities.

Use Hotel when your property is unambiguously a hotel. Use LodgingBusiness for mixed or borderline cases such as an aparthotel, guesthouse or inn, where the broader type fits more honestly. Either way you inherit the same useful properties, so the choice rarely changes much in practice.

Think of this block as the single source of truth about who you are. It is the anchor that the rate and review markup attach to, and the record an AI assistant is most likely to lean on when it summarises your property in an answer.

The properties worth filling in

• ›name, address (as a PostalAddress) and geo (latitude and longitude) so your location is unambiguous in maps and local results.
• ›telephone and url, matching the contact details shown elsewhere on the site and in your Google Business Profile.
• ›starRating, expressed as a Rating, so your class is explicit rather than inferred from marketing copy.
• ›checkinTime, checkoutTime, petsAllowed and numberOfRooms: the practical facts guests and assistants ask about most.
• ›amenityFeature, listing real facilities (parking, spa, restaurant, free wifi) as LocationFeatureSpecification entries.
• ›priceRange as a simple indicator (for example two to four pound symbols), separate from the precise rates you express as Offers.

Offer: marking up your rates and booking action

Offer schema describes what a guest can buy and at what price. For a hotel that means room rates and the action of booking. You attach Offers to your LodgingBusiness or to individual room types (HotelRoom), each with a price, a currency and availability, so search engines can display a from-price and route guests towards a direct booking.

Rates change constantly, which is the practical challenge here. A price you hard-code today is wrong next week, and stale price markup is worse than none. The reliable approach is to generate Offer data dynamically from the same source that feeds your booking engine, or to express a representative price range rather than a single fixed figure you will forget to update.

Pair the Offer with a potentialAction of type ReserveAction pointing at your booking page. This is the structured nudge towards a direct reservation, which is the whole commercial point. Every booking you win on your own site is one you do not pay 15 to 25 percent commission on, and clean Offer markup is a small lever on that larger goal we cover in how hotels outrank OTAs in Google.

AggregateRating and Review: showing your reputation

AggregateRating summarises your guest review score as structured data: an average rating, the scale it sits on, and how many reviews it draws from. Add it to your LodgingBusiness and search engines can show review stars in results, which lifts click-through. Individual Review items can mark up specific guest testimonials shown on the page.

There is a firm rule from Google here, and breaking it gets your stars removed: the rating you mark up must reflect reviews that are genuinely displayed on that page, collected by you for your own property. You cannot import a Tripadvisor average into your schema and claim it as your own on-site rating. Mark up the reviews you actually show.

Because of that constraint, AggregateRating works best when you collect and publish first-party reviews on your site, not only on third-party platforms. That is a reason to capture post-stay feedback directly, then surface a selection on your property and room pages where the structured data can legitimately describe it.

FAQPage: earning expandable answers

FAQPage schema marks up a list of genuine questions and answers shown on a page, and can earn an expandable rich result directly in search. For hotels it is a natural fit, because guests ask the same practical questions repeatedly: parking, breakfast times, check-in, accessibility, pet policy, distance to the things they came for.

The content has to be real and visible. The questions and answers in your schema must appear on the page for a user, not be invented purely for markup. Used honestly, FAQPage is one of the easier ways to occupy more vertical space in a result and to hand AI assistants ready-made answers in question-and-answer form, which is the shape they prefer to quote.

Keep answers concise and self-contained, ideally 40 to 90 words, so each one stands alone. This is the same answer-first habit that helps with getting cited in AI search: a clear question and a complete, factual answer are easy for a machine to lift with confidence.

How the types fit together on a page

These types are not separate experiments, they nest. Your LodgingBusiness is the parent record. Room types sit inside it as HotelRoom entries, each with its own Offer. AggregateRating attaches to the property. FAQPage covers the common questions. BreadcrumbList describes where the page sits in your site. Together they paint one coherent, structured picture.

• ›Homepage and property page: LodgingBusiness or Hotel with address, geo, star rating, amenities, AggregateRating and a price range.
• ›Room pages: HotelRoom with an Offer (price, currency, availability) and a ReserveAction towards the booking engine.
• ›Any page with a Q&A block: FAQPage listing the visible questions and answers.
• ›Every page: BreadcrumbList for navigation context, and Organization or WebSite markup at the site level for publisher identity.

JSON-LD, not microdata: the format to use

Google recommends JSON-LD, a block of structured data placed in a script tag, usually in the page head. It is kept separate from your visible HTML, which makes it far easier to maintain than the older microdata approach that tangles schema attributes through your markup. For a hotel changing rates and offers, that separation is the practical difference between markup you keep current and markup you abandon.

Because JSON-LD lives apart from the content, you can generate it programmatically from the data you already hold (your rates, room list, address, review score) and inject it per page. That is how modern, performance-focused sites keep dozens of pages accurately marked up without hand-editing each one.

A word of caution if your site renders content with JavaScript: make sure the schema is present when Google fetches the page, not added only after a script runs in the browser. Server-rendered or statically generated JSON-LD is the safe choice, and it is one reason the technical foundation matters as much as the markup itself.

Does schema markup improve rankings?

Not directly. Google has been clear that structured data is not a ranking factor in its own right. What it does is make your page eligible for rich results (review stars, FAQ accordions, the hotel pack) and give search and AI systems reliable facts to display and cite. The ranking benefit is indirect: better visibility and higher click-through, not a position boost.

That distinction matters because it sets expectations honestly. Adding LodgingBusiness schema will not move you from page three to page one on its own. It will make the listing you already have more prominent and more quotable, and it will help an AI assistant describe you accurately rather than vaguely.

Treated that way, schema is a multiplier on the rest of your SEO rather than a shortcut. It pairs naturally with strong content, a complete Google Business Profile and the local signals we cover in hotel local SEO and Google Business Profile, each reinforcing the others.

How schema feeds AI search

AI search engines such as Google's AI Overviews, ChatGPT, Perplexity and Gemini favour content they can parse cleanly and trust. Structured data is purpose-built for exactly that. A property described in LodgingBusiness, Offer and FAQPage schema is offering machine-readable facts in the precise form these systems prefer to read and cite.

Today AI answers about hotels tend to quote OTAs, review sites and SaaS platforms, and rarely the hotels themselves. That gap is the opportunity. The properties that publish clean structured data now, alongside answer-first content, are the ones best placed to be named when a traveller asks an assistant for a recommendation near a landmark or for a particular kind of stay.

Schema is not the only ingredient (clear writing and genuine authority matter too), but it is the part most hotels skip, and the part most directly suited to how machines consume information. Done well, it turns your own site into a reliable source the models can lean on.

Common mistakes to avoid

Most schema problems on hotel sites come down to a handful of repeat errors: using the wrong type, marking up content that is not visible, letting prices go stale, or claiming review scores that belong to a third party. Each one either wastes the effort or risks a structured-data manual action that removes your rich results entirely.

• ›Using LocalBusiness instead of LodgingBusiness or Hotel, so the accommodation-specific fields are lost.
• ›Marking up content a guest cannot see on the page, which breaches Google's structured-data policy.
• ›Hard-coding room rates that drift out of date; generate them dynamically or use a price range instead.
• ›Importing a third-party review average and presenting it as your own on-site AggregateRating.
• ›Inconsistent name, address and phone details between your schema, your site and your Google Business Profile.
• ›Adding schema only via client-side JavaScript, so it is missing when search engines first fetch the page.

How to validate and monitor your markup

Before publishing, run every template through Google's Rich Results Test to confirm it is eligible for rich results, and through the Schema.org validator to catch syntax errors. After publishing, watch the Enhancements and rich-result reports in Google Search Console, which flag errors and warnings on live pages as Google recrawls them.

Treat validation as a routine step, not a one-off. Every time you change a page template, add a room type or adjust how rates are pulled in, re-test before it goes live. Schema breaks quietly: a single malformed value can disqualify a whole block, and you will only notice the lost stars weeks later if you are not checking.

If managing all of this in-house feels like more than your team should carry, it is the kind of technical groundwork our hotel SEO service handles end to end, from choosing the right types to wiring rates into Offers and keeping the markup valid as the site evolves.