Websites 27 July 2026, 6 min read
Why your restaurant website is losing reservations
Restaurant sites lose bookings in the same six places, in roughly the same order. None of them are the reservation system, which is the thing everyone blames.
A table booking is a small decision made quickly, usually on a phone, often by someone who is mildly hungry and definitely impatient. They are not evaluating you. They are trying to finish a task, and any moment where they have to think is a moment where they might go somewhere else instead. Here is where those moments usually are.
One: the menu is a PDF
This is still the single most common fault and it is the most costly. A PDF on a phone opens in a viewer, arrives at 200 per cent zoom showing the top left corner of a page designed for A4, and requires pinching to read. A meaningful proportion of people simply close it.
It is also invisible everywhere else. Search engines struggle with it, assistants cannot quote from it, and nobody can search for the one dish they remembered. And it is slow to change, so the menu on the site is the one from spring, which means the guest who arrives having decided on the lamb is now a small disappointment you have to manage at the table.
Menus should be pages. Then they load instantly, read properly on a phone, can be updated by whoever is in the office in about a minute, and can be found by someone searching for what you actually serve.
Two: opening hours that need interpreting
"Lunch: Wednesday to Sunday. Dinner: Tuesday to Saturday. Closed Mondays. Kitchen closes 9pm, 9.30pm at weekends." That is four sentences the guest has to hold in their head to answer one question, which is whether they can eat with you at half past seven on Thursday.
Show the week as a simple list of days and times, put it where it can be seen without scrolling, and say what happens on bank holidays before anyone has to ring and ask. If the hours change seasonally, say the date the current pattern runs until, so nobody has to wonder whether the page is old.
Three: the booking button is somewhere else
The single most common structural mistake is treating "book a table" as a page rather than an action. It should be present and visible on every page, particularly the menu, because the menu is where people decide. Someone who has just read the tasting menu and wants to book should not have to navigate anywhere to do it.
The second version of this fault is a button that scrolls to a widget further down the same page, so the guest presses it, the page moves, and they are not sure whether anything happened.
Four: the reservation widget is a different world
Most reservation systems allow some styling and most restaurants never use it. So the guest goes from your carefully considered site to a grey box in a different typeface asking them to pick a date from a calendar that opens on the wrong month.
Worse, many open in a new tab or, on a phone, take over the screen entirely with no obvious way back. If they change their mind about the time and want to check the menu again, they have lost their place. Some proportion of those people do not come back.
You usually cannot change which system the restaurant uses, and often should not. You can nearly always make it inherit your colours and typeface, open in place rather than elsewhere, and be pre-filled with the party size and date the guest already indicated.
Five: the questions nobody answered
Every restaurant has a list of things guests ring up to ask. It is usually the same eight or nine questions, and your team can recite them. Parking. Whether there are steps. Whether children are welcome and whether there is a menu for them. Dogs in the bar. Gluten free. Whether the tasting menu is the only option on a Saturday. Whether you can do a table of ten. Dress code, asked more often than anyone admits.
Every unanswered one is a booking that either does not happen or costs you a phone call. Write the answers down, put them on the site in plain words, and the calls reduce and the bookings do not.
Six: it is slow
Restaurant sites are frequently the slowest thing a person will load all day, because they are built around large photographs of food and nobody compressed them. A hero image that takes four seconds on a phone in a car park is a booking someone else takes.
The fix is unglamorous: compress the photographs properly, serve them in a modern format, tell the browser how big they are so the page does not jump while it loads, and do not load twelve of them before the first one is visible. It is an afternoon of work and it is usually the single largest measurable improvement available.
The ones that are not on the website at all
Two losses happen before anyone reaches your site, and they are worth more than several of the six above.
The first is the Google Business Profile. For a restaurant it is frequently more visited than the website, and it is usually neglected: hours that were right in 2023, no menu link, photographs uploaded by guests rather than by you, and the "book a table" button either missing or pointing somewhere unhelpful. Half an hour of attention there regularly does more for covers than a fortnight of work on the site.
The second is consistency. If your hours say one thing on the website, another on Google and a third on the reservation platform, some proportion of people will arrive at a closed door or, more often, decide not to risk it. Machines reading all three do the same. It is dull, unglamorous work and it is nearly free.
What a good booking page actually contains
Not much, which is the point. The party size and the date, taken first because those are the two things the guest already knows. Availability shown without a page reload, so trying half past eight instead of seven is instant rather than a fresh start.
Then the smallest possible form. Name, phone, email. Dietary requirements as an optional note, not a compulsory dropdown of eighteen allergens. A card only if you genuinely take deposits, and if you do, say why in one line, because an unexplained card request at a neighbourhood restaurant reads as a trick.
And a confirmation that arrives immediately, contains the date, time and party size in the first line, and includes a link to change it. A confirmation that requires the guest to ring you to alter anything is how a booking becomes a no-show.
The order to fix them in
Menus off PDF first, because it fixes the reservation journey and the search problem at once. Then speed, because it is quick and it lifts everything else. Then the booking button on every page. Then the questions. Then the styling of the widget, which matters but matters less than the four things before it.
Do those and the reservation system you were about to replace will probably turn out to have been fine.