Domains, hours, closures and the day-to-day of a site that is already live.
A printed table code will never be edited again, yet the address behind it can lapse, move or drift out of date, and the failure lands on a guest mid-service.
A published security fix reaches a restaurant's live site only when somebody applies it, and by default that is nobody's job. The exposure lands on the restaurant either way.
A discount code at the foot of a table confirmation makes the whole message direct marketing. The exposure behind that mistake is far higher than older guidance suggests.
Nominet suspends .uk domains whose registrant name or address it cannot validate. A paid-up domain stops resolving, and the trade behind it is lost until it is fixed.
Gmail can now reject a booking confirmation outright, with no bounce and nothing red on the screen. Six spam complaints in two thousand is the whole margin.
The week beginning 8 December took 34% of festive bookings last year. Groups commit long before that, so a menu published in December misses most of them.
One hours line claims continuous service from noon to close. The kitchen stops at 14:30, so the site keeps taking afternoon bookings for the wrong hour.
The only copy of the menu, the guest records and the page content sits in one account nobody has ever tested restoring from, and nobody finds out until it is lost.
A fake restaurant site can copy a venue’s identity, divert guests from the genuine route and leave the owner preserving evidence under pressure.
A time-sensitive restaurant update can be stale before an external publishing queue clears, and a page can be live without being ready for guests or search systems.
A new restaurant address can look ready in the editor while a guest reaches a warning page or a different version of the site. Prove the connection before announcing it.
A guest can see a success message after sending a restaurant enquiry while nothing reaches the owner, so private-dining and group business quietly disappears.
