What OpenTable gives you
OpenTable provides a reservation widget you can place on your own pages, a hosted booking page for your restaurant, and links that open a booking with the restaurant, date, time and party size already chosen. Restaurants on OpenTable also appear in its own marketplace and app, which is a separate channel with its own cost per cover.
The website question is simple: how do you get the widget onto your site so guests book with you, without the script slowing down the pages that persuaded them to.
The rule: one widget, one page
The reservation widget is third-party JavaScript. It loads its own scripts, styles and often an iframe. Put it everywhere and every page inherits the cost, including the menu page and the home page, which are the two pages guests actually read.
So: the widget lives on a dedicated Book or Reservations page. Nothing else on the site loads OpenTable's script. Everywhere else uses a plain link or a small static control that passes the guest's choices to that page or straight to the hosted booking flow.
The reservations page
Keep it single-purpose. The widget, a line about large parties and how to arrange them, the phone number as a tappable link, the cancellation and deposit policy in one sentence, and nothing else heavy.
Two technical details do most of the work:
- Reserve the height. Give the widget's container a generous minimum height in the stylesheet, so the page does not jump as the embed arrives. Layout shift on a booking page is the difference between a tap on Book and a tap on something else.
- Preconnect. Add a preconnect hint for OpenTable's domain in the page head, so the browser opens the connection while the rest of the page is still parsing.
The party-size control on other pages
The home page and the menu page should still start a booking, without the script. Build a small static control with date, time and party size that submits to your reservations page or directly to the hosted booking URL with those values as parameters. It is a handful of markup and no third-party code, and it means the guest's first two choices are already made when the widget loads.
The Book button
In the header on every page, and again at the end of the menu. It goes to the reservations page. On a phone, a sticky bar at the bottom with Book and Call earns its space in a restaurant site, because those are the only two things most visitors want.
Deep links and multiple venues
If you run more than one restaurant, each venue gets its own page and its own reservations page pointing at that venue's booking flow. Store the OpenTable restaurant identifier as a field on the venue record so the template builds the link, rather than someone pasting a URL that later changes.
The same applies to special experiences, ticketed events and set menus where OpenTable holds them separately: the link is a field, the page renders it.
Where the rest of the page speed comes from
A restaurant page is usually slow for reasons that have nothing to do with the reservation widget:
- A hero slider of the dining room.
- Uncompressed food photography.
- A PDF menu, which is also unreadable on a phone and invisible to search.
- Three tracking scripts and a chat widget.
- A background video.
Fix those first. Publish the menu as text with prices and allergens, compress the photographs, prioritise one hero image, and keep the third-party scripts to the ones somebody actually reads the reports from.
Test where guests are
Safari and Chrome on a phone, then inside the in-app browsers in Instagram and Facebook, where a lot of restaurant traffic arrives. If the embed misbehaves in an in-app browser, point your Instagram links at OpenTable's hosted booking page instead, which does not depend on your page's environment.
Tracking
Events for Book taps by page, and for reservations completed where the flow can signal back. OpenTable's own reporting distinguishes covers booked through your own site from covers booked through its marketplace. That second number is the one to watch, because it is the one with the higher cost per cover.
The monthly check
Book a table on a phone from the home page and from the menu page, then cancel it. Check the confirmation wording, the deposit rule on large parties, and that the widget still loads inside Instagram. Widgets change, and a broken booking page is a restaurant that is closed online without knowing it.
Common mistakes
- The widget on every page.
- A link that opens the OpenTable app or marketplace listing rather than your own booking flow.
- No minimum height on the widget container, so the page jumps.
- The menu as a PDF beside a fast booking widget.
- No party-size control on the pages guests actually read.
- Nobody testing after an update.
Where this sits
One widget on one page, static controls everywhere else, deep links held as fields, and the heavy media dealt with separately is how we embed reservations on a hospitality business website. The same pattern applies to ResDiary, SevenRooms, Tock and Quandoo on a restaurant site, and to the accommodation and experience engines too.