Google maps cookie

Thank you, and thanks for the link to your contact page, it made the problem easy to see. Both things you noticed have the same cause: Bricks does not use an iframe for its Map element. It prints an empty box and draws the map from JavaScript once the Google Maps script has loaded. FAZ was already blocking that Google script until consent, which is correct, but it had nothing to show in the empty box, so visitors saw a blank space with no notice and no way to accept.

This is fixed in 1.32.0. The Bricks Map element now gets the same consent notice as any other blocked embed, with an Accept button right where the map goes. Until the visitor accepts, the map settings stay parked and nothing is requested from Google. After the click the Google script loads and Bricks draws the map on the same page, without a reload. Your site uses WP Rocket’s Delay JavaScript, which loads Bricks’ map script later than Google’s, and that case is handled too: FAZ starts the map once both scripts are there. After updating, please clear the WP Rocket cache so visitors get the new version of the page.

About the scan not finding a Google Maps cookie: that is expected. The map sets its cookies on Google’s own domains, not on yours, and a scan of your site can only read the cookies your domain sets. FAZ still recognises Google Maps as a service from its script and blocks it, so the cookie entry is not what makes the blocking work. Keeping the entry you added is fine, and useful, because it is what lists Google Maps in the cookie declaration your visitors read.

Your map is in the Functional category, which is a reasonable choice for a location map. If you turn on “Enable per-service consent” in Settings, the Accept button on the map allows Google Maps alone instead of the whole Functional category.