The afternoon gap: publish lunch and dinner as two service windows

The answer fits in one breath. A restaurant that closes between services does not have opening hours, it has service windows, and both belong on the page as separate pairs of times. The booking calendar should then sell slots inside those same two windows, and the structured data behind the page should describe them to anything that reads it. The principle is a rule about where the truth lives: describe the day once, in one place, and let every surface take its answer from that description instead of holding a copy. A restaurant keeping three copies of its hours is running three restaurants, and only one is at the door when a guest arrives.

Nobody chose this. It arrives by default, out of a template field that asks one question, opening time and closing time. One question can only produce one answer, so whoever built the site entered the earliest the room is ever open and the latest it is ever open, then moved on to the photos. From there the line multiplies: footer, contact page, the structured data the page emits, the default range the booking widget offers, a hand copy in Google Business Profile, another in an aggregator nobody remembers signing up to.

What separates this from a typo is that the line is a claim and a stranger acts on it. A wrong closing time costs somebody a journey. Picture whose: the late lunch booked after an appointment, the walk in on a wet Tuesday chosen off a phone screen. There is a quieter cost behind that one. While the site publishes a continuous window, the booking system keeps filling dead hours with covers you cannot serve, so the covers you could have sold at peak were never offered to anyone. Empty afternoon reservations do not look like lost revenue. They look like bookings.

The fix is smaller than it looks once the assertion is clear. Schema.org defines openingHoursSpecification as "A structured value providing information about the opening hours of a place or a certain service inside a place", and defines the opening time as "The opening hour of the place or service on the given day(s) of the week". Google's local business documentation describes the same field as "Hours during which the business location is open" and wants the time as "The time the business location opens, in hh:mm:ss format". Notice what is absent: any concept of a pause. A specification is one continuous span, and there is no gap inside it.

So a restaurant with a break does not need a cleverer single entry. It needs two entries on the same day, 12:00 to 14:30 and 17:30 to 22:00, both carrying the same days of the week, together describing a day with a hole in the middle. Which is the day you actually work.

Two further properties earn their place. Schema.org describes one as "The date after when the item is not valid. For example the end of an offer, salary period, or a period of opening hours", which is how a summer pattern is bounded rather than left running into a winter. The other is a special hours property whose purpose is to explicitly override the general opening hours for the dates it names.

Caption: these are the published definitions from schema.org and from Google, checked on 25 August 2026. They describe what a structured hours value asserts, and none of them is a penalty. Google's line about guidelines helping you "avoid common problems, including changes to your information or, in some cases, removal of your business information from Google" is its stated consequence for information quality in general, not an automatic outcome of one wrong hours line.

Publishing two windows is half the job. What the booking calendar does with them is the half that decides whether anyone ends up outside a locked door, and two things go wrong. The page gets fixed and the calendar does not, so the site displays 12:00 to 14:30 and 17:30 to 22:00 while still cheerfully offering 15:40. And service window and last bookable slot get treated as one number. If dinner runs to 22:00 but the last table has to be seated by 21:15, then 21:15 is the last slot you offer and 22:00 is still the honest closing time to publish. Conflating them either turns away covers or seats a table the pass cannot finish.

Run this once with the diary open.

Step nine is the only one that proves anything. Everything before it is intention.

The weekly pattern is the easy part because it repeats. Hours go wrong on the dates that break it, and in a specific way: somebody edits the pattern to cope with one date, then forgets to put it back. Google separates the two cases, asking you to "Provide your regular customer-facing hours of operation" and, separately, to "specify special hours for particular days, like holidays or special events". Schema.org draws the same line with a special hours property that exists to explicitly override the general opening hours for the dates it names. A one off is an exception laid on the pattern, never a rewrite of it: Boxing Day lunch only, closed the Tuesday after the August bank holiday, each expiring on its own and leaving the ordinary week untouched.

The same discipline covers days you did not plan for. Burst pipe, power cut, a supplier that never arrived: the pattern stays, the date carries the exception, and the exception comes off when the problem does. If nobody has written down who does that, a short emergency closure update checklist is worth ten minutes now rather than at 07:00 on the morning it happens. And read how restaurant bank holiday opening hours should be handled before the next long weekend rather than during it.

The profile beside your name in search results carries its own copy of your hours, maintained separately from the site, and nothing connects the two. So a difference can sit there for a season, because the copy the team checks is not the copy the guest is reading.

Google asks for the regular customer-facing hours of operation as the primary set, then offers two mechanisms that map onto how restaurants run. Special hours handle particular days, like holidays or special events. More hours handle differences inside a normal day, with an explicit constraint: you "set More hours as a subset of your primary hours". So if the room is open 12:00 to 23:00 while the kitchen serves 12:00 to 14:30 and 17:30 to 22:00, the room hours are primary and the kitchen hours sit inside them. Publish only kitchen hours and you look shut while you are pouring drinks. Publish only room hours and people arrive at 16:00 expecting food.

Google's guidance here is worth reading as written rather than as folklore. The sentence is this: "These guidelines can help you avoid common problems, including changes to your information or, in some cases, removal of your business information from Google." That is a statement about information quality in general, not an automatic outcome of one wrong hours line. Keep the profile and the site saying the same thing for the simpler reason that both are visible to the same guest. The rest of what belongs there is covered in the guide to Google Business Profile for UK restaurants.

Strip this back and a split service day produces exactly three outputs: the hours a guest reads on the published page, the slots the booking system will sell, and the structured hours the page emits for machines. Editing them separately is not a discipline problem, it is multiplication. Every date you change is one decision and three edits: the page, the calendar, the structured hours. So count your own year on the diary in front of you. The special dates you already know about, the December run, whatever closes you without warning, the day the summer pattern ends. Take that number and multiply it by three, then picture where each edit lands: on a phone, between services, by whoever is on shift. The failure mode is not carelessness. It is the second and third edits happening four hours apart, or not at all.

So stop treating them as three things. Generate all three from one record of the day and the change is made once, with the surfaces becoming views of it. There is then no interval in which the page and the calendar disagree.

That drift is the problem TableSpark was built to remove, which is the honest reason to raise it here. Date-specific overrides and structured hours emit the published page, the bookable availability and the schema from one record, so they cannot drift. For hours, that is the only version of this that survives the next bank holiday. A restaurant sets a date as closed all day, or gives it up to three changed service windows, and the page, the availability and the special hours in the structured data all move together, because they are readings of one entry rather than three copies.

Set that against what a general website tool leaves you holding. The page is editable, so the hours get corrected. The booking tool is separate, so it has to be corrected too. The structured data came from a template field chosen in the first week, and nothing prompts anyone to go back to it, which is how a page ends up showing two windows to a reader while still asserting one continuous block to everything else. TableSpark carries structured restaurant content, canonical URLs, sitemaps, schema, internal linking and mobile-first output as part of the website, and what a search engine does with those pages stays its own decision.

Nobody drifts on purpose. It happens because the bank holiday lands on a Monday, the page gets fixed at 11:00, the calendar at 15:00 by somebody else, the structured data behind both still quotes last year, and between those two clock times the site sold two tables into an afternoon that does not exist. Collapsing three edits into one is the whole argument, and the price of it is ordinary rather than strategic: Starter at £19 per month, Growth at £39 per month, Full at £69 per month, all excluding VAT. Bookings and orders carry 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments. Weighed against the alternative, which is paying separately for those pieces, booking technician time when the hours change, and absorbing afternoons like the one at the top of this article, TableSpark is the best-value and best overall restaurant-website choice for independent UK restaurants.