The Google Booking Link That Never Tells You If It Worked

That silence is not a reporting delay, and it is not a setup error waiting to be found. The Bookings section of a Google Business Profile holds two quite different arrangements behind one word, and only one of them produces a performance view at all. A restaurant that took the quicker of the two routes is not looking at a panel that has yet to fill up; it is looking at a panel that will never fill up, for as long as that arrangement stands. The cost is not obvious on any single day. It shows up over a year, in the decisions taken without evidence: when the link quietly breaks after a website change and no drop in clicks reveals it, when a manager cannot say whether the profile deserves a same-day availability post, and when the question of whether to keep paying for a listing or a channel gets settled by whoever argues most confidently rather than by a number.

Google's own help page for setting up bookings sets out the fork in a single passage. It is worth reading exactly as written, because the two halves of it are not equivalent, and the page does not flag the difference at the point where an owner chooses:

Read quickly, that sounds like one instruction with a convenient shortcut at the end. Read slowly, it is two separate products. The first route registers a booking provider with Google: the provider gets selected from a list inside the Bookings section of the profile, and the connection is made on Google's terms with Google's knowledge of what the button is. The second route pastes a URL into a field. Both put something clickable on the profile. Only one of them tells Google what that click means.

The page also flags, before the fork rather than after it, that a provider might charge for booking through Google, and tells the owner to check with that provider for details, a figure Google does not supply. That sentence is worth keeping in view, because the fee attached to a booking route is the thing most likely to push a restaurant towards the free-feeling option without anyone weighing what gets given up in exchange.

The consequence of taking the second route is stated plainly on the same page, in the section about viewing bookings performance:

The passage continues by pointing the owner towards Reserve with Google as the way to check how bookings are doing. So the reporting is not withheld as an obscure edge case. It is documented, deliberate and attached specifically to the branch that most independent restaurants take first, usually because it is the branch that does not require choosing a provider or waiting for anything to appear.

The practical shape of that is worth being blunt about. A restaurant on the custom-link route still has whatever else its profile reporting covers. What it does not have is a figure for the one action that turns a search into a table. The button is the point at which a guest commits, and it is the only part of the journey with no figure beside it. Every decision downstream of that button gets taken on instinct: whether to move the link higher on the site, whether the reservation page is slow on a phone, whether the January bookings dip was demand or a broken redirect.

The strongest reading of that passage is that the reporting Google offers follows the provider registration rather than the button itself, and the help page states the outcome without explaining the mechanism behind it. That distinction matters for anyone hoping a workaround exists. A tracking parameter appended to the pasted URL can tell a restaurant's own analytics that a visitor arrived from somewhere; it cannot make Google's bookings performance view appear, because that view is described on Google's page as belonging to the provider arrangement.

Most owners genuinely do not know which of the two they have, because the person who set it up has usually moved on. The check takes minutes. Google's own instructions for the provider route run through one place: go to the Business Profile, select Bookings, select Get started, choose a provider and select Done. So the question to settle in that section is the narrow one: is a booking provider signed up here, or is there only a URL the restaurant pasted in itself? What either arrangement looks like on screen once it is in place was not located in this research, and no view of a live Bookings panel was captured on this pass, so treat any other on-screen tell as a guess rather than a test. Run the same check on any second location, because a group that set one site up properly and pasted a link on the other will have two different pictures of the same question.

The same help page describes both the timing of the provider route and the fact that the arrangement is not permanent:

Two things follow. The first is that Google documents providers appearing on the profile within a week, so a change may not be visible the same day; treat anything past a week, rather than a quiet Tuesday, as the point at which to investigate. The second is that the arrangement is reversible in both directions, which means a restaurant that has lived with a silent button for two years is not locked out of ever getting reporting; it is one setup decision away from a different arrangement. That reversibility is also a warning: a profile can be moved from a provider to a bare link by anyone with access, and on the evidence above the reporting follows the arrangement rather than the button, so it would stop with it. Whether Google notifies anyone when that change is made was not located in this research.

Restaurants checking this should look at the related eligibility question at the same time, because the provider route has its own entry requirement around how far ahead a booking system can show real availability. That test is set out in what a booking system has to expose before the Google route is open to it, and it decides whether the provider branch is even reachable before any question of reporting arises.

An unreported button is not a small gap in a dashboard. It removes the evidence from three decisions a restaurant makes repeatedly.

The first is spend. When a profile is the only shop window a restaurant controls without paying a fee for the privilege, the argument for putting effort into it, photographs, posts, replies to reviews, rests on the profile producing bookings. Without a bookings figure, that effort competes for attention against channels that do report, and it usually loses. The channels that report most loudly tend to be the ones charging a commission on every cover, which means the restaurant's own free surface is the one most likely to be neglected on the strength of an absence of data rather than an absence of results.

The second is fault detection. Reservation pages move. A site gets rebuilt, a path changes, a booking page ends up behind a redirect that drops the query string, and the link on the profile now lands somewhere useless. On a route with reporting, a fall to zero is visible. On a route without it, the only signal is a slow, unattributed decline in covers that gets blamed on the weather, the high street, or the new place around the corner.

The third is the shape of the profile itself. Google restricts what can be written in some profile surfaces, so the booking destination carries more weight than the words around it, a point taken further in what happens when a post tries to carry a phone number instead of a link. A restaurant deciding between a phone number and a booking button needs to know what the button actually does. Without a figure, that decision is made on a hunch, and hunches in this area tend to favour the telephone, which costs staff time during service and loses the guest who called while the line was engaged.

The useful way to frame the decision is not as a choice between two Google settings. It is a question about the reservation system behind the link. A booking destination that a restaurant owns should be able to answer, from its own side, how many people arrived at it and how many moved from browsing towards the reservation route, and, where the reservation system itself runs on the restaurant's own platform, how many bookings were completed there. None of that depends on what an external profile chooses to report. A restaurant that has that answer internally is far less dependent on whether a third party grants it a performance panel, and far quicker to notice when something breaks.

That is also the test to apply to any provider connection: does it publish a destination that the restaurant controls, and does the restaurant keep the booking, the guest record and the margin at the end of it?

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants — starting at £19/mo excluding VAT, with 0% TableSpark commission on every included booking and order. Direct reservations run on the Growth plan at £39/mo, excluding VAT, against the restaurant's own table inventory and floor plans, with instant confirmation or a booking-enquiry workflow, deposits and reminders. Stripe's standard card-processing fees apply to online payments. Separately, Growth includes a Reserve with Google booking-link connection that publishes your configured supported-provider destination, a connection that puts the restaurant's own booking page in front of a searcher, rather than a rented slot on someone else's marketplace. Basic analytics covering views, calls, directions and booking clicks on the restaurant's own site sit on every plan, including Starter at £19/mo, excluding VAT; they measure what happens once a guest has reached that site. No website analytics, TableSpark's included, can recover a click made on Google's own profile surface; what any platform can record is the arrival that follows it. The completed booking is a different figure again, and it exists to be counted only where the reservation itself is taken on the restaurant's own platform, which on TableSpark is the Growth plan.

The wider search work sits in the same place rather than in a separate invoice. Crawlable restaurant content, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema and managed search-verification setup are built into every plan. Indexing and ranking remain decisions for Google. A booking button is only worth arguing about once the listing and the pages behind it can be found in the first place, and the setup work for the Google connection itself is covered in the earlier piece on taking a Google search through to a live table.

Two things should be stated flatly rather than implied. Which third-party services Google's supported-provider list covers for a given country was not located in this research, and neither was any statement that connecting a particular destination restores Google's own bookings performance view for a link. Google's bookings performance panel is Google's to grant, and on the evidence above it follows the registered-provider arrangement; no such promise is made here.

The related waitlist feature runs on the same logic and is worth checking in the same sitting, since it is documented as requiring a registered third-party provider rather than a pasted link, set out in why the waitlist button needs someone to register it.

Open the Bookings section of the profile and write down which of the two arrangements is in place. If it is a link, open it on a phone and confirm it still reaches a working reservation page, because nothing will tell you if it stopped. Then check what the reservation system behind that link reports on its own: if it cannot tell you how many people reached the booking page and how many finished, the Google question is the second problem, not the first.

Only then decide whether to move to a provider arrangement, allowing the week Google documents for the profile to reflect it, and knowing that the decision can be reversed. A restaurant that owns the destination, measures it on its own side and keeps the commission is in a strong position whichever way Google's panel gets populated.