Hotel website design: direct bookings vs the OTAs

There’s an idea doing the rounds that you can’t beat Booking. It has more budget, more domain authority and more people, so the only sensible move is to accept the commission as a fixed cost of doing business and carry on.

Partly true. No independent hotel is going to outrank an OTA for a generic search like ‘hotels in Valencia’, and chasing that is setting money on fire.

But that isn’t the fight.

The fight is over the guest who already knows your hotel’s name, searched for it, landed on your website and still ended up booking through the portal. Nobody stole that guest. You lost them.

Paying commission on someone who was already walking up to your door is like tipping the neighbour for opening it.

Hotel website design that works doesn’t try to replace the OTA. It makes sure the guest who has already found you has no reason whatsoever to leave your site.

What you’re really buying when you pay commission

Two things always get lumped together, and they need separating.

The OTA brings you new guests, people who’d never heard of you and found you in a list. That’s acquisition, and it has a reasonable price.

The OTA also charges you for guests who were already yours: the one who comes back every year, the one who was recommended, the one who saw your sign and the one who searched for your name. That isn’t acquisition. It’s a toll you pay because your website didn’t close the booking.

The ratio between those two groups decides whether your website is working or just playing the part of an expensive brochure. And that ratio can be moved.

Base Aparthotels: what changed and what was measured

In the Base Aparthotels redesign the brief was exactly that: don’t fight for the generic search, stop losing the people who had already arrived.

The figures are published on the project page. 48% more direct bookings. 35% fewer drop-offs inside the booking process. 62% more interaction on the landing pages. And the site loading in 1.4 seconds on mobile.

None of those numbers came from a campaign. They came from removing friction where the guest already was.

The six mistakes that keep your website below the portal

Almost everything that goes wrong in hotel website design fits on this list. It’s the same for a three-star hotel as for a holiday apartment.

1. The booking engine lives on another domain

The most serious one, and the most common. The guest picks dates on your site, taps ‘Book’ and lands on an address that looks nothing like yours, with a different design, a different font and sometimes a different language.

That’s where people drop off. Some because they don’t trust it, some because the jump takes too long, and some because that change of page is the perfect moment to check the price on the portal.

What you should demand from your booking engine provider: that it sits inside your domain, inherits your design and shows availability and price before the jump. If the contract doesn’t allow that, at the very least the subdomain should carry your full identity rather than the factory template.

2. There’s no advantage to booking direct

If the price is the same, the conditions are the same and the process is clunkier, booking on your website is the worst option on the table. Guests aren’t daft.

A direct booking needs an explicit, visible reason right on the room page. More flexible cancellation, breakfast included, late check-out subject to availability, the best room in the category booked, a discount at the restaurant. Whatever fits the way you run things.

And it has to be written where the decision gets made, not on a page called ‘Benefits’ that nobody ever opens.

3. The price can’t be compared

For years, contracts with the big portals included parity clauses that stopped hotels advertising a better price on their own website. That framework has changed in the European Economic Area since Booking was designated a gatekeeper under the Digital Markets Act.

In plain English: you probably have more room to differentiate your direct offer than you used to, so check your contract instead of assuming you’re still tied.

If that room exists, an explicit comparison on the room page is the most effective argument there is. If it doesn’t, the argument becomes the conditions rather than the price.

4. The website is half translated

A hotel sells abroad. That’s the fundamental difference with almost any other local business.

What usually happens: the homepage and rooms get translated, and the blog, the legal notices, the booking process and the confirmation emails stay in the original language. Or worse, someone installs an automatic translator that produces versions no search engine will index properly and sentences that scare people off.

Multilingual that holds up needs three things. Its own URL per language. Human translation at least for rooms, rates and the booking process. And the tags that tell search engines which version belongs to which country.

When those tags are wrong, Google shows the German version to someone searching in English. You spot it by reviewing what the search engine is seeing and what it’s ignoring.

5. The website is slow exactly when it matters

The booking engine is usually the heaviest part of the site, and it nearly always loads on every page even though it’s only used on one.

Guests check from their phone, often at the airport or out on the street. Every second the calendar takes to appear is a chance to open the portal’s app, which is optimised down to the last pixel.

The rule is simple: the engine loads when someone touches it, not before. The exact thresholds and how to tell which one you’re failing are in the three metrics Google measures and how to fix each one.

6. Nobody knows where the booking falls over

If the engine sits on another domain and your analytics don’t connect the two, your website measures nothing. You know how many come in and how many finish, and you have no idea at which step people leave.

Without that data, every improvement is a bet. With it, the conversation changes: you can see whether people drop off at the dates, the room selection, the details form or the payment gateway, and you fix what needs fixing.

It’s the same problem an online shop has when it stops selling and nobody knows why, applied to a basket that holds a single night.

The content an OTA can’t publish

This is the part almost no hotel works on, and the cheapest one to get right.

A portal describes the room, the square metres, the bed and the amenities. It has to do it the same way for the four hundred hotels in town, because its listing is a template.

What it can’t tell, and you can:

• How to actually get there from the airport or the station, with the real journey time, the rough cost and which line suits which time of day.
• What’s open in the low season, which is exactly what someone travelling in November asks and can’t find anywhere.
• Where to park, with the specific answer for your street, not a generic link.
• What you see from each room type and which one suits what you’re coming to do.
• Neighbourhood guides written by someone who lives there, with the places you genuinely recommend.

That content brings in searches the OTA doesn’t chase. It reaches guests while they’re still choosing a city, in other words before anyone has compared prices.

It also holds the site’s structure together, because every guide has its own query behind it. It’s the logic behind how pages are split so none of them gets in another’s way.

Zero pages written to fill up the menu.

If your website is inherited

Plenty of hotels drag along a website built by the previous chain, the PMS provider or an agency that no longer answers the phone. Before rebuilding anything, you need to know what’s there.

Two questions settle the decision: can the current engine be integrated or does the contract forbid it? And is the content you have worth anything, or does it all need writing from scratch?

With those two answers you know whether this is a repair or a rebuild, the same dilemma I go through when choosing between a custom build and a template. The diagnosis that comes first is described in what a full site review covers.

What I do on a hotel project

I don’t start with the design. I start by asking for the booking engine contract and the portal contract, because that’s where it’s written what I can and can’t do.

I’ve seen gorgeous proposals crash into a clause on page four.

Then I measure where the current booking falls over, before touching anything. Without that snapshot, there’s no honest way to say in six months whether the work paid off.

And I don’t sign off a booking process until I’ve completed it myself on a phone, on mobile data and out on the street, in every language you sell in. If anything is a struggle in that test, it changes, even if it had already been approved.

It’s the order I follow in everything I plan before writing a line of code, and hotels are where it shows most.