Most restaurant owners assume their website is harmless from a privacy standpoint because it “only shows the menu and a map”. That is exactly where the trouble sits. The embedded Google map, the Google font, and the reservation form all transmit data before a guest has clicked anything. This is not scaremongering; it has already triggered waves of cease-and-desist letters in Germany, and the same rules apply in Austria: according to its activity report (2024), the Austrian Data Protection Authority resolved 2,397 individual complaints in 2024, around 21 percent more than the year before. The good news: a restaurant website has a manageable number of weak spots. Let’s walk through them one by one.

Google Maps: the directions widget that phones home

Nearly every restaurant website embeds a Google map. Technically, here is what happens: the moment the page loads, the guest’s browser contacts Google’s servers and transmits, among other things, their IP address. Without consent. That transmission is the violation, not the map itself.

There are two clean fixes. The two-click approach: a placeholder image appears first, and the real map only loads after the guest clicks it. Or the pragmatic approach: a static image of your neighbourhood with a link that says “Open route in Google Maps”. The link only contacts Google when clicked, and on a phone it opens the guest’s maps app anyway. For most restaurants the second option is the better one, because guests plan the route on their phone regardless.

Fonts: Google Fonts belong on your own server

Google Fonts is the classic invisible violation. Many site-builder templates and older agency builds load their typefaces directly from Google’s servers, transmitting each visitor’s IP address before any consent is possible. In 2022 the Regional Court of Munich awarded a website visitor €100 in damages for exactly this (case 3 O 17493/20), and a wave of legal letters followed across the German-speaking market.

The fix costs nothing: download the font files once and serve them from your own server. Visually, nothing changes; legally, a great deal does. You can check your own site in two minutes: open the page, right-click, “View page source”, search for “fonts.googleapis”. If it shows up, your fonts load from Google.

Cookies: the banner you may not need at all

The cookie banner has become the symbol of the GDPR, yet it is only required for optional things: analytics tools, marketing pixels, embedded videos. Technically necessary storage, say for a reservation form, needs no consent.

Which leads to an uncomfortable truth for everyone who simply bolted a banner onto their site: a banner does not make a website compliant. If Google Analytics loads before the guest presses “Accept”, the banner is decoration. The reverse is also true: a restaurant website that skips tracking often needs no banner at all. That is legally more relaxed, and frankly it looks better when the first impression of your restaurant is not a grey consent window.

Reservation data: where it gets genuinely personal

Maps and fonts involve IP addresses. Reservations involve names, phone numbers, email addresses, dates, party sizes, and perhaps a note about the nut allergy at table 7. That is real personal data, and health-related notes such as allergies enjoy special protection.

You should be able to answer three questions. First: where does the data live? If you use an external booking platform, the data sits with the platform, and you need a data processing agreement with the provider. Second: how long is it kept? A reservation from two years ago has no business in any system; set a deletion period, a year is a reasonable choice. Third: is all of this described in your privacy policy? Guests must be able to read what happens to their data.

What belongs in your imprint and privacy policy

In Austria, every commercial website needs an imprint with the company name, address, contact details, and further information depending on the legal form. The privacy policy must match the actual website: if it mentions a reservation form you switched off long ago, or omits the Instagram embed you added last month, the document is out of date.

Our advice: do not copy a privacy policy from another restaurant’s website. It describes their tech stack, not yours. Free generators from the Austrian Chamber of Commerce or other reputable providers are a usable starting point, but they do not replace checking against what your page actually loads.

Your checklist for one afternoon

All of this sounds like more work than it is. Go through the following points and you have covered the most common weak spots of a restaurant website:

Replace the Google map with a two-click solution or a static image plus a route link
Search your page source for “fonts.googleapis”; host fonts locally if needed
Test the cookie banner: does anything optional really load before consent?
Reservation data: clarify where it lives, check the processing agreement, set a deletion period
Compare your privacy policy against what the website actually does
Check the imprint for completeness

Or you hand the whole topic off

Honestly: a restaurant owner should not spend evenings searching page source. With GuestMaker, the privacy-aware setup is part of the package: locally hosted fonts, no embeds that load uninvited, and a reservation system where it is clear where guest data lives. You get a website with this checklist ticked from day one, from €99 a month, with no down payment.