How to get your hotel recommended by ChatGPT

A traveller opens ChatGPT and types: "quiet four star hotel near the beach in Puerto Plata, good breakfast, family rooms". The assistant answers with three or four names and a line of reasoning for each. Your hotel is in that list or it is not, and nobody opened ten blue links to decide. What follows is what decides it, based on the hotel sites Polargate builds and maintains in Spain and the Caribbean.

How an assistant actually picks a hotel

Assistants build these answers from three sources: a web index (ChatGPT and Copilot lean on Bing, Google's AI surfaces use Google's index), their own crawlers fetching your pages, and what the rest of the web says about you on Google Maps, TripAdvisor and Booking.

Two properties of those crawlers decide most of the outcome:

• They fetch raw HTML and do not run JavaScript. GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot and Meta's fetchers read what your server sends, not what React renders afterwards.
• In fast answering modes they read very little: the title, the H1 and roughly the first two hundred characters after it. A hero video and a three word tagline give them nothing to quote.

Your pages have to exist without JavaScript

Most hotel sites built in the last five years are single page applications. The server sends an empty shell, and the rooms, restaurants and rates appear only after the browser runs the bundle. To an AI crawler, that page is blank.

The fix is prerendering: a real HTML file for every route and every language, generated at build time. On one Caribbean resort site we took over, Search Console showed only 4 of about 30 submitted pages indexed before we prerendered it. Afterwards, 38 Spanish and English routes were served as static HTML, checked with JavaScript switched off. On a second hotel site, 22 public routes now ship as real HTML with their own title, description, canonical and hreflang tags.

Prerendering also has to be verified. In our August 2026 audit of one hotel site, which closed 48 confirmed findings, only one of the two room types was present in the prerendered HTML, the hero image stayed hidden behind a 4.5 second curtain until hydration, and the guest counters were served as zeros. To a machine, that is a thin, half empty page.

Three checks worth running today

• Load the page with JavaScript disabled. If a room, a rate or a restaurant disappears, it does not exist.
• Request it the way a bot does, with curl -A "OAI-SearchBot" https://yourhotel.com/rooms, and read the HTML that comes back.
• Confirm nothing at the edge blocks those user agents. Firewall bot protection that serves a challenge to an AI fetcher removes you from the answer, silently.

Structured data for the hotel, the rooms and the restaurants

Schema.org hands a machine an unambiguous fact sheet. Be honest about what it does: a 2026 Ahrefs study of 1,885 pages with added markup against 4,000 controls found no meaningful uplift in AI citations from schema alone, and Google's FAQ rich results ended in May 2026. Structured data does not win the recommendation. It removes ambiguity, and ambiguity is what gets a hotel left out.

A hotel graph worth shipping:

• Hotel with legal name, address, geo coordinates, telephone, star rating, amenities and sameAs pointing at your verified Google Maps, TripAdvisor and Booking listings.
• One HotelRoom per room type, with occupancy, size in square metres and a price range that matches the visible page.
• Restaurant per outlet, EventVenue for meeting and wedding spaces with real capacities, HealthAndBeautyBusiness for the spa.
• ReserveAction pointing at the booking engine URL, so the assistant knows where a booking is made.
• BreadcrumbList, and a WebPage node with a genuine dateModified.

Two rules, both learned the hard way. Never mark up what is not visible on the page: hidden prices and invented opening hours breach Google's policy. And never invent a rating. One site we inherited published an aggregate rating of 4.7 from 2,847 reviews that matched no real source. We removed it and put the hotel's actual TripAdvisor figure in its place, 4.2 out of 5 from 9,239 reviews, as visible text next to the markup.

Languages, reviews and questions in visible text

Travellers ask in their own language, so every language needs its own URL with its own prerendered content: /habitaciones and /en/rooms, not one page that swaps strings at runtime. Add reciprocal hreflang plus x-default, and set the html lang attribute per route. That last one sounds trivial. On one site we audited, every English page was served with lang="es" and the English legal pages carried Spanish text. Never redirect by Accept-Language or IP address without exempting crawlers, or the engines will only ever see one language of your site.

Then give the assistant something worth quoting:

• Real reviews in the page text, attributed, next to the aggregate published by the platform they came from.
• A questions page written the way guests actually ask. One of our hotel sites publishes 27 real questions in six groups, inside native <details> elements so the answers sit in the HTML whether the accordion is open or closed, with matching FAQPage markup.
• Under each question, a direct answer of 40 to 70 words that stands alone: check in from 15:00, airport 20 minutes by car, all inclusive covers these four restaurants.

A booking engine that does not hide the page

Booking engines are the most common self inflicted wound. Three patterns to avoid:

• It takes over the page. If the availability widget opens as a full screen layer on load, or the room detail only exists inside the engine's iframe, none of it is in your HTML. Content in a third party iframe belongs to that third party.
• It blocks the paint. A heavy widget loaded before the hero costs Core Web Vitals and hands a crawler a slow, empty document. Load it lazily, after the content.
• Rates live only inside it. Publish an honest range in your own HTML ("double rooms from X EUR per night, all inclusive") and let the engine handle the live, dated price.

On the sites we run, the engine is a global widget that initialises lazily and hides itself while a dialog is open, with a ReserveAction in the structured data pointing to it. The page still reads correctly with the engine stripped out.

The same hotel, spelled the same way everywhere

An assistant assembles a hotel from many sources. When they disagree, you become several weak entities instead of one clear one.

• Write one fact sheet: legal name, commercial name, address, coordinates, phone, category, one sentence description. Apply it word for word to the site footer, Google Business Profile, Bing Places, TripAdvisor, Booking and your chain listing.
• Check the coordinates. On one hotel site, the published point sat 430 metres from the real entrance.
• Verify the domain in Bing Webmaster Tools and submit the sitemap. ChatGPT search and Copilot draw on Bing's index, and Google Search Console alone will not show you that.
• Ping IndexNow on production deploys, and give the sitemap real lastmod dates taken from the content, never the build date.
• Delete claims you cannot support. We removed "up to 200 attendees" and a "5/5" global rating from a hotel site because no source backed them.

None of this is a trick, and none of it comes with a ranking guarantee: nobody can promise a position inside an answer generated fresh each time. What it produces is a hotel a machine can read, describe correctly and cite. Polargate starts this as a fixed price Discovery Sprint from 4,900 EUR, then builds, then keeps checking under a monthly CARE retainer, because the crawlers, the booking engine and your room list all keep changing.