GDPR for Restaurant Websites: A Practical EU Guide

A restaurant website is not the most complex compliance target in the EU, but it has a few specific moving parts that recur across the sector and produce most of the findings. Reservations, the Google Maps embed, menu photography and delivery widgets account for roughly nine out of ten compliance issues that I see on a typical restaurant site scan.

This guide focuses on these four. It is intentionally short because the rest of the obligations (privacy notice, cookie banner, Article 30 record of processing, retention) apply equally to any commercial website and are covered in our broader GDPR compliance checklist. To see which of these four issues your site already trips, run a free scan before you start.

Issue 1: the Google Maps embed

The single most common Article 5(3) violation on restaurant websites is the contact-page map. The default Google Maps embed at https://www.google.com/maps/embed?pb=... is an iframe that:

• Connects to Google servers on page load
• Sends the visitor's IP, user agent and referrer
• Loads tracking and ad infrastructure (google.com, gstatic.com, sometimes doubleclick.net)
• Sets cookies on the visitor's device

All of this happens before any user action. The legal position is identical to YouTube embeds: prior consent is required.

The pragmatic fix is a static map image with a link:

<a href="https://maps.google.com/?q=Restaurant+Name+Address"
   target="_blank" rel="noopener">
  <img src="/static-map-image.jpg"
       alt="Our location"
       width="640" height="320" />
</a>

The static image can be generated once and saved locally. No connection to Google on page load. The user clicks through to Google Maps only if they want the interactive map (and at that point the click is the affirmative action). This pattern eliminates the Article 5(3) issue entirely.

If the interactive map is critical (e.g. for accessibility users who need turn-by-turn directions inline), use the click-to-load facade pattern documented in the Google Maps embed and GDPR guide and gate it behind the consent banner.

Issue 2: the reservation system

Reservation widgets (OpenTable, TheFork, Resy, Quandoo) are processors under Article 28 GDPR. They handle customer names, contact details, dietary preferences, allergies and visit history on the restaurant's behalf.

Minimum compliance checklist for the reservation widget:

• DPA accepted with the platform. OpenTable, TheFork and major regional platforms publish their DPA in the admin panel. Click-to-accept is standard.
• Privacy notice mentions the widget as a recipient of personal data, with a link to the platform's own privacy notice.
• International transfer mechanism declared if the widget hosts in the US (TheFork, US-based platforms). The EU-US DPF covers certified participants.
• Retention rules aligned. Active reservations cleared after the visit (or no-show period). Customer history retained per the platform's controls.
• Allergy and dietary fields: handle as the limited Article 9 category they are. Avoid free-text fields that invite unnecessary disclosure. Use structured options where possible.
• No automatic newsletter signup when the customer makes a reservation. Marketing consent is separate.

For embeds of the reservation widget on the restaurant's own site, the third-party iframe usually drops cookies on load. The widget should be gated behind the cookie banner the same way as any third-party embed.

Issue 3: menu photo copyright

Restaurants are uniquely exposed to copyright claims on photography. The pattern is well-documented in our Getty Images letter guide (Belgium version) and widely confirmed in cross-EU enforcement. Two failure modes:

Photos copied from Google Images, Instagram or competitor sites

Photos found via Google Images are not licensed for commercial use unless the original source explicitly grants such a licence. Copying them to a menu page is a copyright infringement. Agencies like PicRights, Copytrack and Getty Images monitor the web for unlicensed uses and send demand letters months or years later.

Cost when claimed: typically €300-2,000 per image, depending on jurisdiction and resolution.

Photos taken by a freelance photographer without a written transfer

A freelance photographer commissioned for a one-off menu shoot retains copyright by default. The restaurant has an implied licence to use the photos for the agreed purpose, but later uses (new menu, social media, delivery platform listings) may exceed the licence. Without a written transfer or expansion of the licence, the photographer can claim additional fees.

The fixes:

• Commission original photography with a written contract that transfers copyright or grants a perpetual royalty-free licence for the purposes you actually need
• Use stock photo sites with verified commercial licences (Unsplash, Pexels, Pixabay: verify the specific photo, not just the site policy)
• Take photos yourself with a phone camera. Quality is sufficient for most menu pages and copyright stays with the restaurant
• Do not copy from Google Images or social media even temporarily. Risk-cost is asymmetric

Issue 4: delivery widgets and integrations

Embedded ordering widgets (Deliveroo, Uber Eats, Just Eat, regional platforms) often drop trackers on the restaurant page. The marketing pixel of the delivery platform fires on page load, sending visitor data to the platform regardless of whether the visitor places an order.

Treatment options:

1. Link out instead of embedding. A button labelled "Order on Deliveroo" that links to the platform avoids the tracker entirely. Cleanest pattern.
2. Embed only after consent. If the embedded ordering experience is critical, gate the widget behind the consent banner the same way as a third-party tracking script.
3. Add the platform to the privacy notice as a joint controller (Fashion ID logic applies, see the YouTube embed guide) and the cookie policy as a tracker source.

The standard set: privacy notice, cookie banner, contact form

Beyond the four restaurant-specific issues, the standard GDPR obligations apply:

• Privacy notice: Article 13 information in a clear and accessible layered format. The privacy policy generator guide covers the structure.
• Cookie banner if the site sets any non-essential cookies, which the embeds above typically do. See cookie banner requirements and do I need a cookie banner.
• Contact form with Article 13 information at the form and the right legal basis. See contact form GDPR.
• Article 30 register listing each processing activity (reservations, contact, newsletter, analytics, photo storage). See GDPR records of processing.
• Retention schedule per category of data with implementation, not just policy.

Final restaurant-specific checklist

• No Google Maps embed loading before consent (static image + link is the safe default)
• Reservation widget has a signed/accepted DPA and appears in the privacy notice
• Reservation retention has a defined schedule (active period + reasonable inactivity)
• Allergy and dietary data field structured rather than free-text where possible
• All menu photos either original, properly licensed stock or with documented permissions
• Photographer contracts include written copyright transfer or perpetual licence
• Delivery widget integrations either linked out or gated behind consent banner
• Privacy notice mentions the reservation platform, delivery platform and any analytics
• Cookie banner present if any non-essential cookies load
• No automatic newsletter signup from reservation or contact form

---

This is technical analysis, not legal advice. For sites operating across multiple countries with sector-specific food safety reporting or for active supervisory authority investigations, consult a lawyer who specialises in data protection.