Structured data for hotel websites: which fields matter and what it will not do

Structured data (schema markup) is a block of labels in a page's code that tells software what each fact is: name, address, check-in time, amenities, certified star class. For a hotel, the fields worth filling are the ones the page already shows. It does not raise rankings, guarantee a rich result, or place rates in search.

The agency report says schema markup implemented, every field green. Then you open the page and the labels say check-in from 14:00 while the front desk has said 15:00 for two years. The labels were never the problem; the brief was. After reading this you will know which hotel schema markup fields are worth filling, how to word star class against the Ministry certificate, how to test the result with free tools, and what markup cannot do no matter how well it is written.

What is structured data on a hotel website?#

Structured data is a short block of labels in a page's code that tells software what each fact is: this string is the hotel's name, this one is the check-in time. Guests never see it, and the page itself does not change.

A page of prose forces software to guess. A line reading 14:00 could be check-in, a tour departure or the hour the pool opens; a label removes the guess. The vocabulary comes from Schema.org (opens in a new tab), a shared public list of types and properties, in version 30.1 as of 16 September 2026. A type names the kind of thing; a property names one fact about it. Hotel is defined there as an establishment that provides lodging paid on a short-term basis, and it is a kind of LodgingBusiness, so the wider LodgingBusiness properties apply to a hotel as well.

The common format is JSON-LD, a block of text in the page's code that a browser does not display. Microdata puts the same labels inside the visible HTML. Both express the same vocabulary, and neither is more true than the other.

Two kinds of reader consume it: search crawlers deciding which display features a page qualifies for, and AI assistants trying to extract facts about a property without parsing marketing prose. This matters more as what changes when travelers ask an AI assistant instead of browsing shifts how people first meet a hotel online.

What does hotel schema markup actually do, and what do agencies overstate?#

It makes facts machine-readable and can make a page eligible for specific display features. It does not raise rankings, guarantee a rich result, or buy a place in an AI answer.

Google's general structured data guidelines (last updated 10 July 2026) require structured data to be a true representation of the page content, and state plainly that correct markup does not guarantee a rich result. The same guidelines say a structured data issue can lead to a manual action that removes rich-result eligibility but does not affect how the page ranks in web search. Markup is a clarity and display tool, not a ranking lever.

The most oversold claim is star ratings from your own guest reviews. Google's review snippet guide (opens in a new tab) (last updated 8 September 2026) makes a local business that controls reviews about itself ineligible for the star review feature, including reviews pulled in through an embedded third-party widget.

The second oversold claim is an AI-ready badge. No search engine or assistant has published a format that guarantees a citation; markup removes ambiguity, and whether an assistant uses it sits outside the hotel's control. The third is treating implementation as the finish line. A block that contradicts the page is worse than no block, because it is exactly the mismatch the guidelines describe.

What it genuinely earns is smaller: fewer wrong facts in listings and knowledge panels, consistent name, address and telephone, and a property a machine can read without inference.

Which fields are worth filling for a hotel?#

Fill the fields a guest would ask at the front desk, and only where the page already answers them: identity, contact, arrival and departure times, policies, amenities, room types and the certified class.

Identity first: name, address, telephone. The address is optional in the vocabulary, but if you give it, its parts (street, city, postal code, country) are mandatory as a set, so a half-filled address is a defect. Times next: check-in time and check-out time. These are the fields most often wrong, because a template carries an old hour while the front desk changed it seasons ago.

Policies follow: whether pets are allowed is a small field with high value for a traveler filtering options before booking. Amenities need care: the amenity property lists features, but it does not say whether a feature is included in the price or costs extra. That distinction has to live in words on the page, because the label cannot carry it. Languages spoken and number of rooms are verifiable, cheap to keep true, and useful to anyone matching a property to a guest.

Room types deserve their own treatment: describe the unit types you actually sell, each with its own facts, rather than one vague block for the whole property. Star class needs the number together with the body that granted it, and only at the level on the certificate; the next section covers the wording. For the wider page these fields sit inside, see the hotel website checklist: content, legal information and the booking path.

How should star class and certificate wording match?#

The same words must appear on the page, in the listing and in the labels, and they must match the Ministry certificate rather than the best description marketing can write.

The Regulation on the Qualifications of Tourism Facilities (opens in a new tab) (Resmî Gazete 01.06.2019, Sayı 30791, consolidated text, Article 16(2) and 16(3)) requires a facility's promotion to match its certificate and to give accurate information. It bans symbols that suggest stars outside the certified class: a four-star certificate does not permit five star glyphs in a hero image, a footer badge or a review widget. It also bans terms in the facility's name for units the facility does not have. If a unit type is not on the certificate, the name and the labels should not imply it.

In the vocabulary, the star rating property expects the rating body to be named. A bare number with no body behind it is an unverifiable claim, and it is the first thing a careful reader checks.

The practical method: pull the certificate, write the class as one sentence, and use that sentence in three places, the page, the business listing and the labels. One wording, three places. The same discipline applies to Google Business Profile for hotels: facts, photos and the booking link. This is a legal duty, not a marketing preference; confirm your own certificate scope, dates and penalties with a legal adviser before you change any wording.

Which markup mistakes cause the most trouble?#

The recurring ones are labels for facts the page does not show, review scores a hotel writes about itself, and markup left stale after a renovation or a policy change.

Marking up content that is not visible to readers of the page is the easiest defect for anyone to spot in a minute, and Google's general guidelines (10 July 2026) forbid it. Marking up irrelevant or misleading content, such as fake reviews, breaks the same rule: structured data must be a true representation of the page.

Self-serving review scores are the most common version. An aggregate rating about your own business on your own site, typed into the markup or pulled in through an embedded widget, makes the page ineligible for the star review feature. Aggregating reviews or ratings from other websites is also banned, and ratings must be sourced directly from users; incentivized reviews without clear disclosure are not allowed either.

Two quieter mistakes follow. Amenity labels that imply inclusion: the vocabulary has no field for included in the price, so a spa label beside a paid spa is a mismatch waiting to be reported. And stale markup: a renovation, a rebrand, a recertification or a changed check-in time leaves the labels describing a property that no longer exists. Template copy-paste rounds it off, with address, telephone and star class inherited from another property on sites built from a shared theme.

How do you test structured data, and what should you send your agency?#

Test with free public checkers, compare the result field by field with the page a guest sees, and put the field list, the source of truth and a re-test rule into the agency brief.

Google's free Rich Results Test, a page checker that reports which display features a page is eligible for, and the Schema.org validator, which checks the vocabulary itself, both accept a web address or a pasted block. Read the output as eligibility, not success: correct markup does not guarantee a rich result, and a green report is not a ranking report.

Compare each field with the page as a guest sees it, on a phone, in every language version you publish. The mobile page is where mismatches usually appear. Booking engine pages are usually a third party's: check whether you control their markup at all, and do not accept a promise about a page you cannot change.

The brief itself is short. Include the field list, who owns each fact, the source of truth (the certificate, the front desk's actual times), a rule that nothing goes live unless the page shows it, and a re-test after every template or policy change. Put no guarantee of rich results in the contract. A supplier who guarantees them is selling something the search engine's own documentation says cannot be guaranteed. For the wider selection process, see hiring an agency for AI search: a checklist for hotels before signing, and for the surrounding technical work, hotel website SEO: pages, local search and the technical basics.

Can structured data put your rates into Google's hotel results?#

No. Rates in Google's hotel surfaces come from a separate connection, and the hotel price markup is only an additional way to check price accuracy for partners already in that program.

Google's hotel price structured data reference (opens in a new tab) (last updated 28 August 2026) exists for price accuracy validation: it lets crawlers extract prices from a partner's pages more reliably, covering base prices, rates, room details, itemized fees and taxes, and booking policies. It is an additional check and does not replace the price feed. Google uses it only for partners whose structured data matches what users see on the website, and stops using it while mismatches persist, until accuracy has held for several days. It is validated only on the landing page, so a rate shown deeper in the booking path is not covered.

The format rules differ from general search: Microdata is the recommended default for these price checks, and JSON-LD is deprecated for that purpose and kept for legacy reference only. Other uses of structured data are unaffected. The required identity fields, the hotel name and a partner hotel identifier that matches the price feed exactly, only exist if you are already a partner.

For a hotel outside that program the honest answer is simple: markup cannot place a rate in a result. The connection is the route, and it is a separate piece of work covered in Google hotel prices: Hotel Center, free booking links and hotel ads.

What to do next#

Take the certificate, the front desk's real check-in and check-out times, and the amenities list with its paid or included wording, and fill the field table above from those three sources only. Then send the agency the field list, the source of truth and the re-test rule. Markup done this way keeps listings and machine readers aligned with the property; it will not lift rankings, win a rich result or put a rate in front of a traveler, and a brief that says so is the one that survives the next renovation.