If you run an independent or boutique hotel, you have probably been told to “add schema” by some agency that then never explained a single field of it. They dropped a blob of JSON-LD on your homepage, called it done, and moved on. I see this constantly. The markup is there, it technically validates, and it does almost nothing because nobody thought about what each field is actually telling a machine.
So this is the post I wish someone had handed me years ago. I am going to walk through Hotel and LocalBusiness schema field by field, specifically for your location landing pages, and explain what each field signals, how to fill it out, and where people get it wrong. No copy-paste-and-pray. By the end you should be able to look at your own markup and know whether it is pulling its weight.
Why schema matters for a hotel (and why it is not magic)
Let me set expectations first, because I am allergic to overpromising. Schema markup does not “rank” you. It is structured data that describes your business in a vocabulary search engines and AI tools already understand. It helps them build a confident, machine-readable picture of who you are, where you are, and what you offer.
That picture, the entity, is what gets matched against queries like “boutique hotel near downtown with free parking” or “pet friendly inn walkable to the beach.” When ChatGPT or Google’s AI surfaces hotels, it is reasoning over entities, not raw HTML. Clean schema makes you legible. Messy or missing schema makes you a guess.
Schema does not move you up the list by itself. It makes you easier to understand, easier to trust, and easier to cite. Those are the conditions under which good content and real reviews get rewarded.
This connects directly to the bigger fight every independent hotel is in: the OTAs already mark up their pages obsessively. Booking and Expedia feed search engines pristine structured data about your property. If your own landing pages are vague while their listing of your property is crisp, you are handing them the entity advantage on your own name. I wrote about that dynamic in how OTAs steal search, and tightening your schema is one of the cheapest ways to claw some of it back.
Hotel vs LocalBusiness: pick the most specific type
Schema.org is a hierarchy. LocalBusiness is a broad type. LodgingBusiness is a subtype of it. Hotel is a subtype of LodgingBusiness. The rule is simple: use the most specific type that fits.
For a hotel, that is Hotel. You inherit every LocalBusiness field (address, telephone, geo, hours, price range) and gain hotel-specific ones (amenityFeature, starRating, checkinTime, checkoutTime, numberOfRooms, petsAllowed). If you run a B&B, BedAndBreakfast exists. A hostel? Hostel. Resort? Resort. Use them.
I see hotels using plain LocalBusiness all the time, usually because it was a default in a plugin. It is not wrong, exactly, but it is leaving specificity on the table. More specific equals less ambiguity equals better entity matching.
The field-by-field walkthrough
Here is the spine of a Hotel JSON-LD block and what each piece is doing. I will describe these in plain language rather than dumping raw code, because the point is understanding, not copying.
name
Your exact, consistent property name. The single most important consistency check in your whole local presence. The name in your schema must match your Google Business Profile, your website header, your citations, everything. If your schema says “The Magnolia Hotel” and your GBP says “Magnolia Hotel and Spa,” you are introducing doubt. Pick one canonical name and use it everywhere. This is foundational to the Google Business Profile playbook too.
address (PostalAddress)
Break it into its real components: street address, locality (city), region (state), postal code, country. Do not jam it all into one string. Search engines want the parts. Match your GBP address to the character.
geo (GeoCoordinates)
This is the one people skip, and it is one of the most useful for a location page. geo carries your latitude and longitude. Get the precise coordinates of your front door, not the rough center of your city, by dropping a pin on a map and copying the values.
Why it matters: near-me and neighborhood queries are about proximity. Coordinates let a machine confirm exactly where you sit relative to the airport, the beach, the convention center, the historic district. For a boutique hotel whose whole pitch is “walkable to everything,” precise geo is the difference between being confidently placed in the right neighborhood and being approximately somewhere in the metro.
telephone and url
Your real, local phone number (the one on your GBP, again, consistency) and the canonical URL of the page the schema lives on. For a location landing page, url should point to that landing page, not blindly to the homepage.
areaServed
Underused and genuinely powerful for hotels. areaServed lets you name the places, neighborhoods, and regions you serve. For a hotel, that means the districts your guests come for: the downtown arts district, the waterfront, the university area, the wine country an hour north. This reinforces local relevance for queries tied to those areas without keyword-stuffing your visible copy.
A word of caution: keep it honest and relevant. Listing fifty surrounding towns you have no real connection to is noise. Name the areas a guest would genuinely associate with a stay at your property.
amenityFeature (LocationFeatureSpecification)
This is the hotel-specific gold. Each amenity is its own entry with a name and a true/false value. Free WiFi, free parking, pool, pet friendly, free breakfast, fitness center, airport shuttle, EV charging, accessible rooms.
Two things matter here. First, accuracy. Mark true only what you actually offer. If you flag a pool you do not have, you create a guest expectation you will fail, and you teach the machine your data is unreliable. Second, relevance. Lead with the amenities people actually filter and search on. “Free parking” and “pet friendly” are decision-makers; “ice machine on every floor” is not.
starRating, priceRange, numberOfRooms
starRating should reflect a legitimate rating, not aspiration. priceRange is typically expressed as a symbol band (a count of dollar signs) rather than exact dollar amounts; it signals tier, not a quote. numberOfRooms is straightforward and, for boutique properties, your small room count is often a selling point worth stating.
checkinTime and checkoutTime
Specific hotel fields, expressed as times. Small detail, but it is exactly the kind of fact AI tools love to pull into a direct answer. “What time is check-in at [property name]?” is a real query, and if your schema answers it cleanly, you are a better citation candidate.
openingHoursSpecification
For a hotel front desk that is staffed 24/7, you express that as round-the-clock availability. If you have a restaurant, spa, or bar with their own hours, those are better expressed on their own entities rather than crammed into the hotel block. Keep hours truthful; stale hours are worse than no hours.
image, sameAs, and aggregateRating
image should point to real, high-quality photos of the property. sameAs is your list of authoritative profiles, your verified social accounts, your TripAdvisor page, your Wikipedia entry if you are lucky enough to have one. These are entity-reinforcement links that help machines connect the dots between your mentions across the web, which ties into the work we do on brand mentions in LLMs.
aggregateRating should only be present if you genuinely surface reviews and the rating reflects real, verifiable data. Do not fabricate a rating. Search engines have gotten aggressive about penalizing self-serving review markup that does not correspond to visible reviews on the page.
A quick reference table
Here is the cheat sheet I keep handy when auditing a hotel’s markup.
| Field | Type | What it signals | Common mistake |
|---|---|---|---|
| name | Text | Canonical entity identity | Mismatch with GBP |
| address | PostalAddress | Physical location parts | Single jammed string |
| geo | GeoCoordinates | Precise proximity | City center, not the property |
| areaServed | Place / Text | Neighborhood relevance | Padding with unrelated towns |
| amenityFeature | LocationFeatureSpecification | Filterable guest needs | Listing amenities you lack |
| checkinTime | Time | Direct-answer fact | Left blank |
| starRating | Rating | Tier and quality | Aspirational, not real |
| sameAs | URL | Cross-web entity links | Missing entirely |
| aggregateRating | AggregateRating | Social proof | Fabricated or page-mismatched |
Where to put it, and how to verify it
A few practical rules that save a lot of pain.
One Hotel entity per property, on the page that represents it. Your main location landing page is the natural home for the full Hotel block. If you operate multiple properties, each gets its own page and its own entity with its own geo, address, and amenities. Do not merge two hotels into one schema block.
Match what is visible on the page. Schema is supposed to describe content a human can also see. If your markup claims a pool and a spa, those should be present in the actual page content. Mismatches between markup and visible content are a known quality problem.
Validate, then test in context. Run your markup through Google’s Rich Results Test and the Schema.org validator. Validation only proves your syntax is legal, not that your facts are right, so eyeball the values too. A clean validator pass with the wrong coordinates is still wrong.
The fastest way to ruin good schema is to set it and forget it. Phone numbers change, amenities get added, the spa closes for renovation. Stale structured data quietly teaches machines that your data is unreliable, and that reputation is hard to rebuild.
How this ties into the bigger picture
I want to be honest about scale here. Schema is a multiplier on good fundamentals, not a substitute for them. If your content is thin and you have no reviews and your name is fragmented across the web, perfect JSON-LD will not save you. But if you have done the real work, schema is what makes that work legible to the systems deciding who to show and who to cite.
The demand context is worth keeping in view. Search around AI visibility is large and growing, with terms like “aeo” pulling roughly 27,100 US searches a month and “generative engine optimization” around 5,400, while “hotel seo” sits at a much more modest ~590. The point is that the broader shift toward machine-mediated discovery is real, and structured data is one of the few levers you fully control on your own site. That is why I treat it as table stakes in our AI visibility work and our local SEO and GBP engagements.
And it ladders up to the thing that actually pays your bills: more direct bookings and a healthier OTA mix. Every percentage point of demand you can capture on your own site instead of through a channel charging ~15 to 25 percent commission goes straight to your margin. Clean schema helps the right guests find and trust your property directly. It will not let you escape the OTAs, and anyone who tells you it will is selling something, but it is a real, controllable input into reducing your dependence on them. If you want to run those numbers, I broke them down in the book-direct math post.
Do this much this week
If you only do three things after reading this: confirm your name, address, and telephone are byte-for-byte consistent with your Google Business Profile; add or fix your geo coordinates to the actual front door of your property; and audit your amenityFeature list so every entry is true and the decision-driving ones are present. That alone puts you ahead of most independent hotels I audit.
If you would rather not hand-edit JSON-LD and run validators yourself, that is exactly the kind of unglamorous, high-leverage groundwork we handle. Bring me your location pages and I will tell you, field by field, what is helping, what is missing, and what is quietly lying to the machines. Book a call or take a look at how we approach local SEO and Google Business Profile for hotels, and let’s get your property described as precisely as it deserves to be.