We wrote recently about why a golf resort's course can win almost every AI recommendation prompt while its attached hotel loses on the same platforms. Part of that gap comes down to a detail most sites get wrong: accommodation needs its own, more specific schema type. A general LocalBusiness or GolfCourse block, the kind covered in our earlier golf club schema walkthrough, doesn't carry the fields a model needs to answer "is there a hotel here, what are the rooms like, and what's included."
Why a golf club's course schema doesn't cover its hotel
If your site has one schema block describing the golf course, and the accommodation is mentioned only as a paragraph of amenity text, an AI model has no structured way to separate "this is a golf course" from "this also has 42 hotel rooms with a spa." The two need to be described as genuinely different entities, even when they sit on the same property and the same website, because a prospect asking about a place to stay is asking a fundamentally different question to one asking about a place to play.
The schema type to use
Schema.org's Hotel type, a subtype of LodgingBusiness, is built specifically for this. It supports room level detail, amenity lists, and check in and check out timing that a general business schema doesn't carry. For a golf resort with an attached hotel, the practical approach is two linked schema blocks: one for the golf facility, one for the hotel, referencing each other so a model understands they're part of the same property without conflating what each one actually offers.
| Field | What goes in it | Why it matters |
|---|---|---|
| @type | Hotel, nested under LodgingBusiness | Signals room and stay specific detail that a generic business type doesn't support |
| name | The hotel's actual trading name, distinct from the golf club name if they differ | Avoids a model conflating the golf brand with the accommodation brand when they're marketed separately |
| starRating | An honest, verifiable rating if one applies | A concrete trust signal a model can cite directly in an answer |
| numberOfRooms | The actual room count | A specific fact that helps distinguish a boutique property from a larger resort in a comparison style prompt |
| amenityFeature | Spa, restaurant open to non-residents, parking, pool, accessible rooms, and so on | Lets AI match the property to specific buyer questions like "hotel with a spa near a golf course" |
| checkinTime / checkoutTime | Actual times, not "flexible" | Answers a genuinely common direct question without needing a phone call |
| petsAllowed | true or false, stated plainly | One of the most frequently asked practical questions in accommodation prompts, and one of the least answered in text anywhere on site |
| priceRange | An honest rate indication, even a banded range | Gives a model something concrete instead of guessing or omitting price entirely |
A minimal working example
The block below is deliberately short. Accuracy across fewer fields outperforms a long block with several left blank or wrong, the same principle that applies to golf club schema generally.
| Structure | Content |
|---|---|
| @type | Hotel |
| name | The property's hotel trading name |
| address | Full street address, matching the golf club's address exactly if it's the same site |
| telephone | The accommodation booking line, if distinct from the golf club's general number |
| starRating.ratingValue | The verified star rating, as a number |
| numberOfRooms | The room count, as a number |
| amenityFeature | A list of named amenities, each as its own entry |
| checkinTime / checkoutTime | Actual times in 24 hour format |
| priceRange | An honest rate banding, such as "£110 to £220 per night" |
Where to check it
Google's Rich Results Test and Schema.org's own validator will parse whatever markup already exists and confirm which fields are populated and which are missing or malformed. Run the accommodation page specifically, not just the homepage, since many resort sites only carry structured data on the top level page and leave the dedicated hotel or stay page with none at all.
The wider point
None of this replaces the plain text content a model actually reads first. Schema confirms and structures facts that should already exist somewhere in readable form on the page. Get the room detail, amenities, and policies written in plain English first, then structure them, in that order, and the accommodation side of a resort stops being the weaker half of the same AI recommendation answer.