One property, several businesses: GEO for a hotel restaurant, bar and spa

Different people ask about the same address

The traveler's questions about your property are about rooms, and the overview for hotels covers what your room and policy pages have to state for them. The other questions come from people who will never sleep there. A couple in the next neighborhood wants a table on Saturday. A company wants a dinner for eighty. Someone wants a massage on a Sunday afternoon and has no idea your spa takes people who are not staying.

A restaurant that exists only as a line on the hotel's amenities page has nothing for the local's question to match: no hours of its own, no menu, perhaps no name beyond "our restaurant". We have not measured which of these questions are asked most in any town, so the table is a map of who asks, not a ranking.

Which outlets get a page, which get a listing, and which stay a line

Two questions decide it. Does the outlet face the public, so that someone who is not staying can walk in or book? And does it operate as a business of its own, with its own name and category? (The guidelines add that such a department typically has its own entrance.) The first decides whether it needs a page. The second, under Google's Business Profile guidelines, decides whether it gets a listing.

The guidelines' own example of the hotel case is a restaurant operated inside a hotel: the restaurant takes the restaurant category, and the hotel keeps its hotel category without adding one for the restaurant. Separately, they list a restaurant, cafe or bar inside a hotel or motel among the co-located businesses that should each have their own profile, and ask for a different name for the second business. A department gets a profile of its own only when it faces the public as a distinct entity; a section of the main business, such as a counter inside a shop, does not.

The page comes first either way. A listing points somewhere, and for an outlet that faces the public it should point to a page that states that outlet's facts, not to the hotel's homepage.

Hours: none on the hotel's profile, each outlet's on its own

If your hotel's Business Profile carries hours, take them off. The guidelines put indoor lodging, such as hotels and motels, on their list of businesses that should not provide hours. The times a traveler needs (check-in from, check-out by, the desk's hours at night and what happens after it closes) belong on your own policies page as text, and in the hotel's markup as checkinTime and checkoutTime.

Each outlet with a profile of its own gives its own hours there. A department's hours go on the department's profile and the main business's on the main profile, as the guidelines ask. For the restaurant that means the hours diners can sit down and eat, which is the guidelines' rule for restaurants, with special hours for holidays and special events. Keeping those the same on the restaurant's page, its profile, its reservation platform and every delivery app is the subject of restaurant data across portals.

On your own site, put an hours block on each outlet's page, under the outlet's name, and never one "Hours" box on the homepage that mixes the desk, the kitchen, the bar and the spa. A template, with every bracket yours:

[Restaurant name]
Dinner: Tuesday to Saturday, [time] to [time]; last orders [time]
Open to hotel guests and to the public; reservations: [number or link]
Closed: Sunday and Monday; [dates of holiday closures]

[Bar name]
Daily, [time] to [time the next morning]; food until [time]

[Spa name]
Open to hotel guests and to non-guests: [days], [time] to [time]
Last treatment starts at [time]

[Hotel name]
Check-in from [time]; check-out by [time]; front desk: [hours, or around the clock]

One name per outlet, written the same way everywhere

Each outlet needs one name, and the same string on its page, its profile, its reservation platform, its menus and its markup. The guidelines ask for the real-world name, and they rule out containment information in it. Their examples of what not to do add the host business with a dash, or with "in", "at" or "inside". So the restaurant's profile carries the restaurant's name. That it is in your hotel is a fact for its description, its page and its markup, not for its name.

The same discipline runs the other way. On the hotel's own pages, name each outlet exactly as its page and profile do, and link the name to the outlet's page: "[Restaurant name], our restaurant, serves dinner to guests and non-guests Tuesday to Saturday." A traveler reading the hotel's page learns the restaurant exists, and the restaurant's page gets a link from the hotel's with its exact name as the anchor text.

Phone numbers need the same care. In our audit of 9,483 small business websites (40 trades, 90 metros, late August to early September 2026), 43.1% were inconsistent about who and where they are across their own homepage, contact page and about page, and 36.9% published more than one phone number across those pages. The audit's measure was blunt: any second number counted, so a clearly labeled restaurant line on a hotel homepage would have been counted too. Read the figure as a count of numbers, not of mistakes, and put each number beside the name of the outlet it reaches.

Markup that keeps the hotel and its restaurant apart

In the structured data, each business is its own node. Hotel is a lodging type under LocalBusiness on schema.org; Restaurant and BarOrPub sit under FoodEstablishment, and DaySpa under HealthAndBeautyBusiness, all of them LocalBusiness subtypes too. Give each node its own @id, its own name, its own page as url, its own telephone, and hours on the outlets that have them, so that each business stays a separate entity and no property of one is read as belonging to the other.

Two properties link them, and schema.org defines both. containedInPlace is the basic containment relation between a place and one that contains it: the restaurant sits in the hotel. department relates an organization to a department of that organization, described as an organization in its own right with its own URL, logo and opening hours; schema.org's own examples are a store with a pharmacy and a bakery with a cafe. Use department on the hotel's node when the hotel runs the restaurant. When another operator runs it, leave department out and keep containedInPlace, which says where the restaurant is without saying who runs it.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Hotel",
      "@id": "https://www.[your-domain]/#hotel",
      "name": "[Hotel name]",
      "url": "https://www.[your-domain]/",
      "telephone": "[front desk number]",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "[street]",
        "addressLocality": "[city]",
        "postalCode": "[postal code]",
        "addressCountry": "[country]"
      },
      "checkinTime": "[hh:mm:ss]",
      "checkoutTime": "[hh:mm:ss]",
      "department": { "@id": "https://www.[your-domain]/restaurant/#restaurant" }
    },
    {
      "@type": "Restaurant",
      "@id": "https://www.[your-domain]/restaurant/#restaurant",
      "name": "[Restaurant name]",
      "url": "https://www.[your-domain]/restaurant/",
      "telephone": "[reservations number]",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "[street]",
        "addressLocality": "[city]",
        "postalCode": "[postal code]",
        "addressCountry": "[country]"
      },
      "containedInPlace": { "@id": "https://www.[your-domain]/#hotel" },
      "servesCuisine": "[cuisine]",
      "acceptsReservations": "[the reservations page URL, or true]",
      "hasMenu": "https://www.[your-domain]/restaurant/menu/",
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
          "opens": "[hh:mm:ss]",
          "closes": "[hh:mm:ss]"
        }
      ]
    }
  ]
}

The JSON-LD template shows both nodes in one graph so that the two links can be read side by side. On the site, put the hotel's node on the hotel's pages and the restaurant's node on the restaurant's page, where its facts are shown; Google's introduction to structured data says to mark up what a visitor can see. A bar that closes after midnight can state it as it is: schema.org's OpeningHoursSpecification reads a closing time earlier than the opening time as running into the next day. The event space is different in kind: schema.org's EventVenue is a place, not a business, so department, which expects an organization, does not fit it. Tie it to the hotel with containedInPlace.

How the @id references hold a graph together is set out in building an entity, and the hotel's own node, field by field, in making a hotel website machine-readable. The restaurant's menu, its dietary labels and its reservation facts are covered in the overview for restaurants, which applies to a hotel's restaurant as it does to any other.