Setup checklist
- Open the verified profile for the restaurant location you want guests to join.
- If you use an eligible Reserve with Google provider, follow its setup for the native Join waitlist action. A pasted website link does not enable that integration.
- Otherwise, use the Website destination to give guests a clear route to the live queue. Keep booking and ordering fields for the actions their labels promise.
- Use a full HTTPS URL for that location. Check that it loads signed out, displays the restaurant name and explains whether the queue is open or closed.
- Save, then open the public profile in both Search and Maps on a phone. Confirm the destination before a busy service; the edit screen alone does not prove what guests see.
For a standalone location, copy the published public waitlist URL from StoveOps and test it while signed out. A grouped public site may route other slugs to its default location, so do not assume that each slug has a separate queue.
Native button or website link?
A Google Business Profile can be the moment a hungry guest decides whether to come in or join the line. The words on Google, the destination page and the host’s workflow need to describe the same action.
The first distinction matters. Google’s native Join waitlist feature is not a general custom button. Its own provider setup guidance says restaurants must sign up with an eligible third-party Reserve with Google provider to use it. If you have that provider, set it up with the provider and let Google display the native action. If you do not, do not promise a native Google waitlist button that is not there.
You can still build a useful, owned path from Google to a live waitlist. It is a link in your profile, pasted into a field whose label stays true—not an integration, and not a button Google adds for you. This guide is about that operational path. For the broader guest journey, start with an online waitlist for your restaurant website.
Choose the Google profile field that stays true
Google’s local business links help lists the transaction fields a profile can carry: Menu (1 link), Services list (1), Booking (up to 10), Reservations (up to 10), Food ordering (up to 10) and Pickup and delivery (up to 10). Those counts are the ones that help article states; the links policy names a different ceiling — a maximum of 20 links per transaction type — so let the live editor settle the cap that binds you. Two more surfaces sit outside that list and matter just as much: the Website link every profile has, and the button on a post, one per post. The same help page notes that local business links are not available through the Business Profile API or a spreadsheet upload, so this is manual editing, one profile at a time.
If you run StoveOps, the address you are placing is page.stoveops.com/<store-slug>/waitlist—the public join page of a standalone store, built from that store’s slug. Stores grouped under one public site do not each get one — they share the default location’s join page, which is why the multi-location question below has an answer of its own. The published menu of the same store lives at page.stoveops.com/<store-slug>/menu.
| Profile field | When the label stays true | Where to point it |
|---|---|---|
| Menu (1) | there is a published menu | page.stoveops.com/<store-slug>/menu |
| Reservations (up to 10) | the restaurant really confirms a time | the reservation system the restaurant uses — never today’s queue |
| Booking (up to 10) | same test as Reservations | same destination as Reservations |
| Food ordering, Pickup and delivery (10 each) | the guest can order or pay there | the ordering page — never the queue |
| Website (1) | always | the restaurant’s own site, or page.stoveops.com/<store-slug> when there is no other site — or that store’s join page, when the queue is what the profile should drive |
| Button on a post (1 per post) | an Event post dated to today’s service | page.stoveops.com/<store-slug>/waitlist?utm_source=gbp&utm_medium=referral&utm_campaign=post-YYYYMMDD |
A post button is the honest home for a same-day queue only when the post expires with the claim. Google archives posts older than six months unless a date range is set, and only Events and Offers carry one — an Update that says “no wait right now” can stay published for months, which is the false promise this guide exists to prevent. Publish the push as an Event whose date range is today’s service, so it stops showing when the window closes, or delete the Update the moment service ends. Give the button the label that promises least — Learn more or Sign up where the editor offers them, never Book or Order online — and read the live editor for the labels your profile actually has.
A permanent transaction field cannot carry today’s queue at all: the fields that exist are named for reservations, orders and deliveries, and Google’s link policy adds that eligibility varies by business, country and region. Treat the live options in the verified profile as the source of truth, and let the field name limit the promise.
That leaves one permanent field that names no action at all: Website. Point it at the restaurant’s own site when there is one, and make the join path obvious on the page it opens. When there is no other site, point it at page.stoveops.com/<store-slug> — or straight at page.stoveops.com/<store-slug>/waitlist?utm_source=gbp&utm_medium=referral&utm_campaign=profile when the queue is the action the profile should drive. The join page keeps the mini-site header, so the menu and the other pages stay one tap away.
If no transaction field describes a live queue honestly, do not force one — the Website link and a dated Event post already carry it. A restaurant that needs confirmed bookings should keep its booking system and its same-day queue in their honest roles.
Build a destination that deserves the click
The link should lead directly to a page that a guest can use now—not to a social profile, a generic corporate home page, or a message thread where the host must reconstruct party size during a rush.
Google requires a local business action link to lead to a dedicated landing page for that business and, for multi-location operators, to the specific location. It also says the customer must be able to complete the named action there. Before you add anything to the profile, test this destination checklist:
- One location, one destination. The restaurant name, address context and joining flow should match the Google profile the guest just opened. Do not send a Toronto searcher to a brand-wide page that leaves them choosing a city.
- One promise, one completed action. A guest should be able to understand that the page is a same-day waitlist, enter the details the restaurant needs for the queue and reach a clear confirmation state. Do not call a queue a reservation merely because “Booking” is visible in the edit interface.
- One page that loads for anyone. Google’s verification crawlers need unrestricted access, a successful response such as
200 OK, and the ability to load the page’s essential resources. Nothing may stand between arrival and the visible action: no login, no app download, no employee-only code, no challenge screen. Two things on a StoveOps join page are not that barrier. A check the page runs when the guest submits the form happens after arrival, and the join page puts no challenge in front of the form. The privacy notice a first-time visitor sees is a choice, not a verification: the page has already arrived in full, which is what the crawler needs. Load the production URL signed out and confirm the form is there. Clearing Google’s verifier through the domain’s bot protection belongs to whoever hosts the page, not to the profile owner. - One stable, full URL. Use the restaurant’s own HTTPS page, not a URL shortener, social profile or messaging link. Google explicitly excludes those types from local business links.
One risk belongs to the restaurant rather than to Google. If you hide the waitlist section of your public page while its URL is published on the profile, that address starts answering 404 and the link can be removed. Take the link out of the profile first, then hide the section. Check the production URL before the shift, not after guests report that it failed.
If you are building the waitlist itself, an owned restaurant waitlist workflow keeps the action centered on the host team rather than on a marketplace. Guests can join from their phone, wait away from the entrance and receive table-ready updates by SMS, WhatsApp or email; reservations are a separate module, carried by the Business plan. Those are useful operational reasons to send the right guest to the right page, not reasons to overstate what Google has enabled.
Add the link only where the label remains true
Once the destination passes the preflight, open the restaurant’s verified Business Profile. Google’s current instructions say local links can be managed from Google Search by selecting the relevant transaction type, or in Google Maps through Edit profile and that transaction type. The exact choices a restaurant sees can differ, so follow the live profile instead of a screenshot from another market.
Use this decision sequence:
- Look for the native Waitlists flow first. If the restaurant has an eligible provider, this is the route for a native Join waitlist action.
- If there is no eligible-provider route, inspect the available local-business-link fields. Add the restaurant-owned URL only when the field name and the completed guest experience agree.
- If no transaction field describes the live queue honestly, do not force it. Put the standing link on Website and add a visible Join the waitlist path to that location’s page, then use an Event post button, dated to that service, when the queue is the thing you want to promote today.
- Save, then inspect the public profile rather than assuming the edit screen is the guest experience.
This can feel less flashy than attaching every link to Google. It protects something more valuable: a guest who taps a button should know whether they are joining today’s queue, ordering food, or requesting a confirmed booking before they hand over their details.
Rehearse the Google-to-host handoff
The link is only useful if the guest’s arrival looks normal to the team. Before publishing it broadly, run a short rehearsal during a quiet period: open the profile from a signed-out mobile search and from Google Maps, follow the exact action, join a test party with approved test data, confirm the host sees the expected state, then remove the test entry. Repeat it after any change to the destination or to the profile link.
| Guest step | What to check | Host-side decision |
|---|---|---|
| Finds the profile in Search or Maps | The wording and visible action match the real service. | Do not offer a promise the room cannot keep. |
| Opens the destination on a phone | The correct location and waitlist purpose are clear before the form. | Route confusing cases to a named lead, not to ad hoc promises. |
| Joins the queue | The confirmation says what happens next and does not read like a reservation confirmation. | Confirm the party enters the normal operating view. |
| Receives a table-ready update | The message and response path match the shift’s standard. | Handle late replies and no-shows through the existing policy. |
Pair the Google path with a QR-code waitlist at the entrance. The two routes should reach the same location-specific flow, so a host is not managing one paper list, one Google list and one tablet list. Keep guest communication in a single, deliberate process; the restaurant guest messaging guide can help frame the handoff without treating a marketing channel as a live-service shortcut.
Measure the journey without corrupting it
Do not add campaign parameters to an internal waitlist CTA just to identify the click. That can overwrite the source of the session. The link you paste into Google is the opposite case: it is an external entry point, which is exactly what campaign parameters are for. Tag it once and keep the pattern stable—utm_source=gbp&utm_medium=referral&utm_campaign=profile for the standing Website link, and utm_campaign=post-YYYYMMDD for an Event post button, so a dated push never blends into the standing link.
Read those numbers as a floor rather than a total. A guest who declines analytics still joins the queue and still gets a table; they simply are not counted. Look for operational evidence, not vanity numbers:
- Are guests arriving with the right expectation: a current wait, not a guaranteed reservation?
- Is the location on the page always the location shown in Google?
- Can the host identify and serve Google-originated parties without asking them to repeat the basics?
- Does the link still return a successful, public page after the website, consent flow or rate limits change?
The best version of this setup feels unremarkable to the guest. They find the restaurant, understand the next action, join the correct queue and receive a clear update when the table is ready. That is a far better outcome than a prominent button attached to a promise the restaurant cannot actually keep.