WordPress and hotel
One launcher across a property that books in three different places
A hotel website is one site and the property behind it is three or four businesses, each with its own supplier and its own idea of what notice means. Rooms book in a rate and availability engine, the restaurant books on a reservation platform, and the treatment rooms book in a scheduler. Every one of those holds a notice period and a charge that appears nowhere on the site the guest is reading. The hook that prints the tag covers the site. It covers none of them.
Why this pairing is its own job
The WordPress install guide covers the tag, and the hotel guide covers what the assistant has to know. What follows is the part that belongs to neither.
- There is no single booking system to describe. Rooms, tables and treatments run on three separate suppliers at three separate addresses, and each carries its own notice period, its own deposit and its own charge for not arriving. The site holds one page called something like Terms, describing at most one of the three.
- The hook prints on every front end page, so one assistant with one body of material stands beside all three parts of the property, and a guest asking whether they can cancel does not say which one they mean and has no reason to think it matters.
- The room answer then splits again by rate. A flexible rate, an advance purchase rate and a booking made through a third party site are three different positions, and the last of those is usually not the hotel's to change at all.
- The restaurant often has a site of its own, sometimes on its own domain, built at a different time by different people. That is a second origin to list, a second crawl to run and, on a surprising number of properties, a second set of opening hours that disagrees with the first.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the WordPress guide. Everything below is about where it goes on a hotel site specifically.
List the addresses first, including the ones you cannot install on
Start with what the property answers on: the apex and the www, the restaurant's own domain if it has one, a spa or weddings microsite, and the domain from before the last rebrand that still resolves. Every one a guest can reach is an origin, and an origin that is not listed renders nothing and names itself in the console.
Then write the second list, the addresses where the tag cannot go at all. The booking engine, the table platform and the scheduler are somebody else's pages, and no allowlist entry changes that.
That second list is the coverage statement for this install. The assistant is on the property's website and on none of its booking screens, which is the right shape, and it is much better said out loud at the start than discovered when somebody asks why it is missing from the payment step.
One assistant, three sets of terms, so the terms have to name themselves
It cannot tell which system a guest used, and nothing in the question will tell it either. The separation has to exist in the material, which means each set of terms carries the name of the thing it governs inside its own sentences: the rate name for a room, the restaurant's name for a table, the treatment name for the spa.
A single page called cancellation policy is the worst document this site can hold, because it is a strong match for every version of the question and a correct answer to at most one of them.
Where a guest booked through a third party, say plainly in the same document that the booking belongs to that route and the hotel cannot change it, rather than leaving it as an exception somebody is supposed to remember.
Point the handover at somebody who can open all three
The questions that survive the material are reservation questions, and they arrive about rooms, tables and treatments in roughly equal numbers. A handover address that reaches reception alone gets a guest forwarded twice before anybody can open the right system.
Pick a mailbox the duty manager reads, or say in the material which route each kind of enquiry takes. It is a small decision at install time and it is the difference between an assistant that shortens a conversation and one that adds a step to it.
Where the answerable material lives
| Cancellation and deposit terms, one section per system | The notice period, the charge and what a guest is asked for at the time of booking, written separately for rooms by rate, for the restaurant and for the spa. Merged into one policy they become a single confident answer that is right about a third of the time. |
|---|---|
| Rate inclusions, per rate name | Breakfast, parking, any facility fee, and the city or tourist tax where it applies along with how it is collected. A guest quoted only the room figure has been given the wrong number, and this is the material that stops the front desk explaining it at half past three in the afternoon. |
| A room type matrix with the access detail as it really is | Bed configuration, floor, whether the lift reaches it, bath or walk in shower, door widths where you know them, whether connecting rooms exist. Written to include what is not accessible, because a guest who books on an encouraging description arrives to a room they cannot use. |
| Real hours for every outlet, including the days each one is shut | The restaurant, the bar, the pool, the spa, room service and reception overnight. A facility listed without hours reads as always available, and on this platform those hours are usually spread across three pages and a post written during a refurbishment. |
The first thing to get right
Write one page per booking system stating its notice period, its charge and the name a guest would recognise it by, then index those three ahead of anything else.
Cancellation is the highest volume question the property gets in writing and it currently has three answers and one page. Until the three exist separately, every version of the question receives whichever policy the site happens to hold, in the hotel's voice, with a citation underneath it.
The failure that belongs to this combination
The room policy, given to somebody who booked a table
A guest asks what happens if they cancel. The material holds one cancellation page, written when the site was built, about rooms. The assistant answers with the room notice period and cites that page, and the guest was asking about a table for twelve on Saturday with a deposit per head attached to it.
Both halves of that are correct in isolation. The page is real, the policy is the hotel's, and the answer is the wrong one for the booking the guest actually holds, which they discover at the point where the restaurant keeps the deposit. Nothing in the exchange gave either party a reason to check.
Ask the assistant the cancellation question three times, once about a room, once about a table and once about a treatment, and read what it cites. If all three cite the same page, the material has not been split yet, and no wording of the refusal will make up for that.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a hotel visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Can it see whether we have a room free next weekend?
- No. It reads pages and documents and the rate and availability system is neither, so anything it said about a date would be a guess with a booking attached to it. Have it state the room types, the rate inclusions and the arrival times, then point at the booking page or take the dates as an enquiry.
- The restaurant has its own website. One assistant or two?
- One, if the restaurant is yours and the material names each outlet clearly, because a guest booking a room and asking about dinner is one person on one trip. Two, if it is run by a separate operator with its own terms and its own inbox, since a shared assistant would answer their guests from your material and route their enquiries to you.
- Should it appear on the page holding the booking engine?
- It renders around that panel rather than inside it, because the panel is served by your supplier and is a separate document. That is usually what you want. What matters more is that everything a guest might open the panel to check, the inclusions, the deposit and the notice period, is on the page above it in words.
Keep reading
- Installing on WordPressHook the tag into wp_footer with a snippet plugin, keep it out of the theme, and stop optimisation plugins from deferring it away.
- Everything for a hotelRate inclusions, check in times, parking and room accessibility answer well. Live availability and a named reservation do not.
- A veterinary practice on WordPress, and the pages the snippet should skipA vet site on WordPress hangs half its material off other origins: the practice management form, the out of hours provider, and a fee list nothing links to.
- A gym on WordPress, where the timetable is a container and the terms are a fileThe timetable block is filled in the browser, so a crawl of it reads an empty box. The notice period is in a PDF. Both decide what a gym assistant can say.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.