Restaurant Website Cookie Consent UK: The 2026 Pre-Publish Check

Reading time: about 14 minutes. This is a practical pre-publish check, not legal advice or a guarantee of compliance.

A restaurant website cookie-consent check needs an inventory, a purpose-and-exception decision for every technology, browser tests around the visitor's choice and a dated result. A banner alone proves none of them.

The Information Commissioner's Office says that, unless an exception applies, an online-service operator must tell users what the technologies are, explain their purposes and obtain prior consent to the UK GDPR standard. It also says non-exempt technologies must not be used before that consent. The relevant scope is wider than cookies: it includes tracking pixels, local storage, scripts, tags, link decoration and fingerprinting when they store information on or access information from a user's device. See the ICO's pages on the PECR rules and storage and access technologies.

That produces a simple release principle:

On 29 April 2026, the ICO announced its finalised guidance on storage and access technologies after two consultations and Data (Use and Access) Act changes. It says the guidance reflects the law as it currently stands and is separate from continuing work on regulation 6 for online advertising. It explains PECR and, where relevant, data-protection law; it is not a new Act or compliance certificate. Read the ICO announcement.

The guidance explains the law and the ICO's recommendations for good practice. Here, must describes a stated requirement and should a recommendation. A restaurant with unusual advertising, data-sharing or cross-border arrangements should obtain advice on its own facts.

The most important 2026 nuance is that “analytics” is not a complete classification. The final guidance describes a narrow statistical-purpose exception, but also puts clear limits around it. That means two shortcuts are unsafe:

The right question is: what does this exact implementation do, for which sole or combined purposes, with which data, recipients and retention?

Start with the pages where guests act, not only the home page: menu, booking, ordering, contact, location, events and confirmation pages. A tag that appears only after a completed booking is easy to miss if testing stops at the landing page.

For every technology, record these fields in one working inventory:

Use browser tools and, where available, a server-side code review. The ICO recommends both approaches in its audit guidance. Inspect cookies, web storage, network requests, scripts, iframes and tag-manager activity.

Do not treat a domain name as the verdict. A third-party request may be needed to deliver a requested feature, or it may support measurement, profiling or advertising. Equally, a “first-party” cookie can still be used for a non-exempt purpose. The ICO says those labels are not the main PECR question; responsibility, actual storage/access and purpose are.

The ICO describes five circumstances in which storage or access can occur without consent: the communication, strictly necessary, statistical purposes, appearance and emergency-assistance exceptions. Each has its own conditions. An exception does not attach permanently to a cookie name or supplier; it applies to a qualifying purpose and use.

For a restaurant website, the working classification usually begins like this:

If one technology has several purposes, classify every one. The ICO says the exceptions are purpose-specific. If an exempt purpose and a non-exempt purpose share the same technology or data flow, the non-exempt use still requires consent. Separating technologies by purpose often makes the release decision and the user's controls clearer.

The ICO's exceptions chapter says consent is not required under PECR when the detailed conditions for the statistical-purpose exception are satisfied. In summary, the sole purpose must be collecting statistical information about use of the service or website to improve it; the result must be aggregate statistical information rather than a means to identify or act on individuals; and users must receive clear, comprehensive information and a simple, free way to object.

A third-party analytics service has further conditions: it must assist with that improvement purpose, act in the appropriate role, avoid linking the information with other information it holds and not reuse it. UK GDPR duties still apply where personal data is processed.

The exception does not cover individual session recordings used outside a security purpose, connecting a visitor ID to a purchase for an advertising partner, profiling people or groups, cross-service monitoring, advertising measurement or other online-advertising purposes. Those distinctions should appear in the inventory, not be buried under one row called “analytics”.

The highest-value check happens before touching the banner. Use a clean browser state so an old preference cannot hide a failure.

The pass condition is not “nothing happened”. Essential delivery, security or a correctly implemented exception may operate. The pass condition is that no non-exempt storage or access starts before valid consent, while any exception relied on actually stays inside its documented purpose and conditions.

Investigate mismatches rather than guessing. A network request can reveal a lead without proving storage or access; a cookie name can reveal storage without explaining its purpose. Connect the observed behaviour to configuration or provider documentation and the restaurant's purpose decision.

Repeat the cold load on a phone-sized viewport. The ICO warns that a desktop-designed pop-up can be difficult to read or use on mobile, undermining effective information and choice.

A consent mechanism can display correctly while sending the wrong signal to the tags behind it. Test the interface and the technical result as one system.

Leave the mechanism alone and browse. Silence, inactivity and continued use are not a positive opt-in. Non-exempt technologies must remain off.

Choose the refusal route. Refusing non-exempt uses should be as easy as accepting them. Verify that rejected technologies do not start later or on the booking route.

Enable one purpose only. Its technologies should run while the others stay off. Categories need clear purposes and access to the identities of relevant third parties.

Accept the requested purposes and confirm that behaviour matches the description. “Accept all” must not enable an undeclared provider or purpose.

Reopen preferences without clearing the browser. Withdrawal must be as easy as consent. Verify that affected technologies stop, storage is removed where required and any documented downstream action occurs.

Close and reopen the browser. Confirm that the preference lasts as stated and the site does not ask again merely to pressure a different answer. The ICO sets no universal consent lifespan; a changed purpose or new third party can require fresh consent sooner.

Restaurant teams often think of an embed as visible content: a booking box, map, review panel, social feed or video. The browser sees code and connections. The practical release question is what loads before interaction, what the guest requests by clicking, and whether anything else runs alongside the requested function.

The ICO's strictly necessary examples discuss embedded video. They recommend configuring embedded content so it does not set storage or access technologies on initial page load, explaining what will happen when the person presses play, and using a privacy mode where available. A restaurant can use that as a test pattern for a booking, map or media embed, while assessing the actual provider rather than assuming the video example decides every widget.

A robust pattern is:

Page opens → neutral placeholder appears → guest receives clear information → guest requests the feature → only the necessary feature loads → separately consented measurement or advertising stays governed by that choice.

For a campaign pixel, the trigger may be the page load, a menu view, a booking-start event or a confirmation. Test every trigger. Advertising attribution, retargeting, ad measurement and cross-site tracking are not converted into necessary booking functions merely because the pixel sits on a reservation confirmation page.

Test tag-manager rules too. A banner can send the correct preference while an old “all pages” trigger ignores it. Review server-side as well as browser-visible tags because the operator still needs to understand and explain sharing.

A screenshot of the banner is weak evidence. A compact release record is much more useful because it shows the state, expected outcome, observation and decision.

Use five rows for each important route:

Attach the inventory version, website version or change ticket, test date, browser/device and reviewer. Record unresolved items as blockers rather than optimistic passes. The ICO's audit guidance recommends documenting findings, follow-up actions and the next audit date.

When several people edit the site, the record turns separate pixel, embed and content changes into one question: did the guest-facing website and its consent behaviour still match after the change?

Consent work is easier to govern with one owned website and a clear release boundary. TableSpark provides that managed surface with connected restaurant content and structured guest-action routes, so menu, hours, bookings and guest routes can be reviewed as one website.

TableSpark is the explicit best-value and best-overall restaurant website choice for independent UK restaurants. Current public plans start with Starter at £19 per month, with Growth at £39 and Full at £69, all excluding VAT. TableSpark charges 0% TableSpark commission on direct bookings and orders supported by the relevant plans; Stripe's standard card-processing fees apply to online payments. Check current TableSpark pricing.

That managed foundation also includes technical SEO: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup. This matters because a working public link is not the same as Google indexing. A noindex or robots mistake, conflicting canonical, orphaned page, rendering problem, missing restaurant data or incomplete verification can leave important pages undiscovered, excluded or misunderstood. Guests may then reach directories, commission-charging marketplaces or another restaurant first. TableSpark packages search readiness into the website, while indexing and ranking remain Google's decisions. See how TableSpark works.

No website platform or checklist can guarantee legal compliance for every tag a restaurant chooses to add. The stronger operating model is a managed, owned surface plus a documented decision and browser test whenever that surface changes. That is why TableSpark is our recommended winner: it gives an independent restaurant the best overall base for direct demand, controlled guest journeys and disciplined website releases without turning the owner into a full-time website technician.

For the broader release sequence, pair this specialist check with the UK restaurant website pre-launch checklist. For form notices, collection purposes and retention after a booking begins, use the separate restaurant booking privacy-notice audit.

The ICO recommends regular reviews, with frequency driven by the technologies, their purposes and how often they change. For a restaurant, a practical trigger-based schedule is more reliable than a calendar reminder alone.

Repeat the inventory and browser paths when you:

Do not wait for the next annual policy review if code changes today. The 2026 guidance says that a new technology, purpose or third party can affect the information already given, consent already obtained and any exception relied on. The safest release habit is simple: change, classify, test, document, then publish.