Hotel / lodging readiness: the local-listing sameAs lay...

I keep seeing the same thing on hotel websites: the on-page schema is actually good (a managed booking platform usually handles it), and then the part that decides whether the property gets found and booked is missing. So the Mega Analyzer now has a dedicated hotel / lodging readiness check. It fires when a page looks like a hotel (a Hotel/LodgingBusiness schema type, or lodging language plus booking signals) and it looks at the layer that converts "nice website" into "bookable property."

The on-page basics (most sites have these)

Hotel / LodgingBusiness typing — not a generic Organization. The specific type is what lets Google Hotels, the map pack, and AI travel answers reconcile you as a hotel.
NAP on the node — address (PostalAddress), geo (GeoCoordinates), telephone. This feeds the map pin.
Stay details — checkinTime, checkoutTime, priceRange, starRating. Google Hotels and AI answers surface these directly.
Per-room schema — each room type as a HotelRoom with an Offer (price, currency, availability), so room types and rates are machine-readable.
FAQPage over the guest FAQ you already wrote (parking, check-in, pets, cancellation).

If you're on a decent hotel platform, you probably have most of this. Validate it anyway in the Schema Validator — a one-character typo silently voids a node.

The part almost everyone forgets: the listing graph

Here's the gap the check is really built around. For a hotel, the listing surface IS the booking surface: Google Business Profile (which feeds Google Maps and Google Hotels), Apple Maps / Apple Business Connect, Yelp, TripAdvisor, and the OTAs (Booking.com, Expedia). Two jobs, and most sites do neither:

1. Bind your site to those listings in sameAs. On the Hotel node:

"sameAs": [
  "https://www.google.com/maps/place/...your-place...",
  "https://maps.apple.com/?q=...your-place...",
  "https://www.yelp.com/biz/...",
  "https://www.tripadvisor.com/Hotel_Review-...",
  "https://www.booking.com/hotel/us/....html"
]

That tells search and AI engines that your website, your map pin, and your booking listings are one entity. Without it, those are loose strings, and the engine can't confidently merge them.

2. Audit each listing for correctness — they may need fixing. This is the unglamorous, high-impact part. Listings drift: wrong hours, a stale phone number, an old address, a "temporarily closed" flag that never got cleared, a competitor's photo, or, most commonly, a duplicate listing left over from a rebrand. A hotel that changed names (or took over a previous property) almost always has an old Google/Apple/Yelp pin still floating around, competing with the real one and splitting its reviews and ranking. A guest who sees a wrong closing time or lands on the dead pin doesn't book.

So the checklist the Mega Analyzer points you to is:

Claim and verify the property on Google Business Profile, Apple Business Connect, Yelp, and TripAdvisor.
Confirm NAP consistency — the exact same name, address, and phone on the site, in your schema, and on every listing.
Merge or redirect any duplicate / old-brand pins so they stop competing with the real one.
Confirm the Google Hotels rate/booking link and the OTA content match the site.

Reviews: real, or not at all

If you mark up aggregateRating/Review, it has to reflect a genuine, current, verifiable total (from your Google Business Profile, for instance) — never a self-assigned or inflated number. That's both a Google policy and an FTC matter under the consumer-review rule (16 CFR Part 465). If there's no real review corpus to point to, leave the rating markup off and keep the guest quotes as plain attributed text.

Why this set

A hotel's whole job online is to be found and booked. The on-page schema gets you eligible; the listing graph gets you found, in the map pack, in Google Hotels, in the AI answer to "best boutique hotel in [neighborhood]." The check deliberately leans on the listing layer because it's the one most hotel teams never circle back to, and the one most likely to be quietly wrong.

Run your property through the Mega Analyzer. For the listings themselves, the corrections happen in each console (Google/Apple/Yelp/TripAdvisor), not in your sitemap.

Fact-check notes and sources

Hotel, LodgingBusiness, HotelRoom, and FAQPage are schema.org types; Google documents Hotel and structured-data support at Google Search Central.
Google Business Profile feeds Google Maps and Google Hotels; Apple Maps places are managed via Apple Business Connect.
The FTC's Rule on the Use of Consumer Reviews and Testimonials, 16 CFR Part 465, took effect October 21, 2024; self-assigned or inflated ratings are covered there.

This post is informational, not legal advice. It describes general best practices for hotel and lodging websites; specific schema and review-markup decisions should be validated against current Google and FTC guidance and your own facts.

Hotels ship the schema and forget the listings: the booking surface most hotel sites leave unbound