// stack · schnittstelle
Die Google-Maps-Plattform liefert Karten, Adressdaten und Routen für die eigene Website — und sie ist damit zugleich der Baustein, der am häufigsten am Datenschutz hängen bleibt. siteway setzt in der Regel auf diese API, weil sie das dichteste Adress- und Routing-Material mitbringt, und baut sie so ein, dass die Karte erst nach Einwilligung lädt. Diese Seite beschreibt die Technik dahinter: Dienste, Schlüssel, Geocoding und den Platzhalter davor.
// definition
Die Google Maps Platform ist die Sammlung der Kartendienste, die Google für eigene Websites und Anwendungen bereitstellt. Wer von „der Google-Maps-API“ spricht, meint dabei meist die Maps JavaScript API — die interaktive Karte im Browser. Sie ist aber nur einer von mehreren Diensten, und für eine Website sind die anderen oft genauso wichtig.
Daneben stehen die Maps Static API, die ein fertiges Kartenbild als Antwort auf einen gewöhnlichen HTTP-Aufruf zurückgibt und dafür kein JavaScript braucht, die Geocoding API, die Adressen in Koordinaten übersetzt und umgekehrt, die Places API für Ortsdaten, Suche und Autocomplete sowie die Routes API für Routen und Fahrzeiten. Der Zugriff auf alle diese Dienste läuft über einen API-Schlüssel.
Diese Aufteilung ist der Grund, warum eine Standortkarte mehr ist als ein eingefügter Kartenausschnitt. Eine Filialübersicht mit Umkreissuche berührt drei Dienste gleichzeitig — Geocoding für die Adressen, die Karte für die Darstellung, Routen für die Anfahrt. Wie der Baustein daraus auf einer Website aussieht und was er kann, beschreibt die Komponente Karten & Standorte. Hier geht es um die Schnittstelle darunter.
// praxis
laden auf zuruf
Die erste Entscheidung fällt vor der Karte: Die Seite lädt kein Kartenskript, solange niemand es angefordert hat. An der Stelle, an der später die Karte steht, steht zunächst ein Platzhalter — ein statisches Kartenbild vom eigenen Server oder ein Adressblock mit Anschrift, Öffnungszeiten und Routenlink, dazu ein Schalter zum Laden. Wird er betätigt, kommt das Skript nach und die Karte erscheint an derselben Stelle, im selben Container, ohne dass etwas verspringt.
Die zweite Entscheidung betrifft die Datenhaltung. Standorte sind Inhalte, keine Konfiguration — sie gehören ins CMS, als eigene Inhaltsart mit Feldern für Name, Adresse, Öffnungszeiten, Telefon, Kategorie und Koordinaten. Die Redaktion legt eine neue Filiale an, und sie erscheint auf der Karte und in der Liste. Niemand fasst dafür Code an, und niemand pflegt Koordinaten von Hand.
Denn die Koordinaten kommen aus dem Geocoding — und das läuft serverseitig. Beim Speichern eines Standorts oder in einem geplanten Lauf wird die Adresse einmal in Länge und Breite übersetzt und das Ergebnis in den Datensatz geschrieben. Danach arbeitet die Website mit diesen Werten weiter. So geht nicht bei jedem Seitenaufruf eine Anfrage raus, und die Standorte stehen auch dann auf der Seite, wenn der Dienst gerade nicht antwortet.
Der API-Schlüssel wird dabei getrennt behandelt. Der Schlüssel für die Karte im Browser ist naturgemäß sichtbar, deshalb wird er auf die eigene Domain als HTTP-Referrer und auf die tatsächlich genutzten Dienste beschränkt. Der Schlüssel fürs Geocoding bleibt auf dem Server, beschränkt auf dessen IP-Adresse, und taucht im Quelltext der Seite gar nicht erst auf. Google empfiehlt beides ausdrücklich und weist darauf hin, dass der Betreiber für Kosten haftet, die durch Missbrauch unbeschränkter Schlüssel entstehen.
Und schließlich das, was oft fehlt: der zweite Zugang. Neben der Karte steht eine Liste der Standorte als echter Text — Adresse, Zeiten, Telefon, Routenlink, per Tastatur erreichbar. Sie kommt aus denselben CMS-Feldern wie die Marker, ist also kein Nebenprodukt, sondern dieselben Daten in anderer Darstellung. Mehr dazu unter Barrierefreiheit im Stack.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation der Google Maps Platform — Dienstnamen und Funktionsumfang im Original. Konditionen und Kontingente ändern sich und stehen deshalb nicht auf dieser Seite; sie gehören in die Kalkulation eines konkreten Projekts, nicht in eine Technikbeschreibung.
// d-01karte
Die interaktive Karte im Browser. Geladen wird sie über ein Skript von Google, bei Bedarf per dynamischem Import einzelner Bibliotheken. Marker lassen sich gestalten, das Kartenbild über Map-Styling anpassen — Farben, Beschriftung, Dichte der Points of Interest.
zweck: darstellung
// d-02bild
Der Dienst erzeugt die Karte laut Dokumentation aus URL-Parametern eines gewöhnlichen HTTP-Aufrufs und gibt sie als Bild zurück — Mittelpunkt, Zoom, Größe, Kartentyp, Marker. Kein JavaScript nötig. Für uns der Stoff, aus dem der Platzhalter vor der Einwilligung besteht.
zweck: platzhalter
// d-03adressen
Übersetzt Adressen in Koordinaten oder Place-IDs und umgekehrt Koordinaten zurück in lesbare Adressen. Google führt den Dienst unter den Web Services, er wird also per HTTP vom Server angesprochen — genau dort setzen wir ihn an, einmalig je Standort statt bei jedem Aufruf.
zweck: koordinaten
// d-04orte
Ortsdaten, Ortssuche und Autocomplete. Auf einer Website ist das vor allem das Eingabefeld, das bei „Ham…“ schon Hamburg vorschlägt — praktisch für Umkreissuche und Adressfelder. Weil dabei Eingaben an Google gehen, hängt auch dieses Feld an der Einwilligung.
zweck: ortssuche
// d-05routen
Routen und Fahrzeiten für verschiedene Verkehrsmittel, laut Dokumentation mit Verkehrslage. Für viele Websites reicht darunter die einfachere Variante: ein Link, der die Route in der Kartenanwendung des Besuchers öffnet — ohne dass die Website selbst rechnen muss.
zweck: anfahrt
// d-06schlüssel
Google nennt in seinen Sicherheitsempfehlungen drei Hebel: Anwendungsbeschränkung auf HTTP-Referrer für Browser-Schlüssel oder auf IP-Adressen für Server-Schlüssel, Beschränkung auf die genutzten Dienste und getrennte Schlüssel je Anwendung. Wir setzen alle drei.
zweck: missbrauch begrenzen
Aus diesen Diensten wird kein Kartenausschnitt, sondern ein Bereich der Website. Die Karte zeigt die Standorte als Marker und bündelt viele Punkte zu Clustern, die sich beim Hineinzoomen auflösen. Die Liste daneben zeigt dieselben Standorte als Text, sortierbar und filterbar, und bleibt bedienbar, ohne dass jemand die Karte berührt. Klick auf einen Marker und Klick auf einen Listeneintrag führen zum selben Ergebnis.
Dazu kommt die Umkreissuche: Postleitzahl oder Ort eingeben, die nächsten Standorte nach Entfernung sortiert bekommen. Weil die Koordinaten aller Standorte bereits im CMS liegen, rechnet die Website die Entfernungen selbst — an Google geht dabei höchstens die eine eingegebene Adresse, nicht der gesamte Bestand. Für Suchmaschinen ergänzen wir je Standort strukturierte Daten aus denselben Feldern, damit Adresse und Öffnungszeiten auch ohne Karte maschinenlesbar sind.
Und der Container, in dem all das steckt, hat von Anfang an eine feste Höhe. Der Platzhalter belegt sie, die Karte übernimmt sie — kein Nachrutschen des Textes darunter, kein Layout-Sprung. Warum das mehr als Kosmetik ist, steht unter Performance im Stack.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er beginnt mit einer Regel: Die Karte lädt erst nach Einwilligung. Bis dahin steht an ihrer Stelle ein Platzhalter — ein statisches Kartenbild oder ein Adressblock mit Anschrift, Zeiten und Routenlink — und dazu ein Schalter zum Laden. Erst wenn er betätigt wird, holt die Seite das Kartenskript nach und baut die Karte im selben Container auf. Der Zustand der Einwilligung wird an einer Stelle verwaltet, nicht in jedem Template neu entschieden; das Kartentemplate fragt ihn nur ab.
Die Datenseite ist ebenso systemunabhängig. Adressdaten und Marker liegen im CMS, als eigene Inhaltsart mit Feldern für Name, Adresse, Öffnungszeiten, Kontakt, Kategorie und Koordinaten — dieselbe Quelle für Karte, Liste und strukturierte Daten. Der API-Schlüssel liegt serverseitig beziehungsweise ist als Browser-Schlüssel auf die eigene Domain und die genutzten Dienste beschränkt, nie fest im Template. Und das Geocoding läuft serverseitig: Beim Speichern eines Standorts oder in einem geplanten Lauf wird die Adresse einmal aufgelöst und in die Koordinatenfelder geschrieben, damit nicht bei jedem Seitenaufruf eine Anfrage rausgeht. Was sich zwischen den Systemen unterscheidet, sind nur die Bordmittel, mit denen wir das bauen.
// cms-01typo3
Wir bauen die Einbindung als eigene Extension. Die Standorte werden Records mit eigenem TCA — Adressfelder plus zwei Koordinatenfelder für Länge und Breite —, abgelegt in einem Systemordner und im Backend pflegbar wie jeder andere Inhalt. Das Geocoding läuft als Scheduler-Task: Er greift sich Standorte ohne oder mit veralteten Koordinaten, löst die Adresse auf und schreibt das Ergebnis zurück. Der API-Schlüssel steht in der Extension-Konfiguration statt im Template. Im Frontend rendert ein Fluid-Template zuerst den Consent-Platzhalter mit Kartenbild oder Adressblock; erst nach dem Schalter kommt die Karte. Ein Content-Element setzt die Redaktion auf jede Seite, die eine Karte braucht.
// cms-02wordpress
In WordPress entsteht die Einbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie den Theme-Wechsel. Die Standorte werden ein Custom Post Type mit Meta-Feldern für Adresse, Zeiten, Kontakt und Koordinaten, dazu Taxonomien für Region oder Standorttyp als Filter. Das Geocoding hängt am Speichern: Wird ein Standort gesichert und hat sich die Adresse geändert, löst das Plugin sie serverseitig auf und legt die Koordinaten ab. Der Schlüssel steht in der wp-config.php oder in einer Umgebungsvariablen. Fürs Frontend kommen ein Block für den Editor und Template-Teile dazu, die den Platzhalter ausgeben und die Karte erst auf Anforderung nachladen.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil angenehm gerade. Ein Blueprint beschreibt den Standort mit Adressfeldern und Koordinatenfeldern, die Standorte sind Entries in einer eigenen Collection. Fürs Geocoding schreiben wir einen Artisan-Command, den der Laravel-Scheduler regelmäßig aufruft und der auch von Hand nachlaufen kann; er löst offene Adressen auf und schreibt die Koordinaten in die Entries. Der Schlüssel steht in der .env und wird über die Konfiguration gelesen. Antlers oder Blade rendern zuerst den Platzhalter, danach die Karte — und weil Static Caching die Seiten ausliefert, kostet der Platzhalter beim Aufruf praktisch nichts.
// datenschutz
technik, nicht rechtsberatung
Der technische Sachverhalt ist schnell beschrieben: Eine eingebettete Google-Karte lädt Code, Kacheln und Schriften von Google-Servern. Damit diese Auslieferung überhaupt funktionieren kann, geht die IP-Adresse des Besuchers an den Server, der die Daten schickt — das ist keine Eigenheit von Google, sondern gilt für jede Ressource, die von fremder Stelle geladen wird. Der Unterschied liegt darin, ob das ungefragt beim Seitenaufruf passiert oder erst, wenn jemand die Karte tatsächlich sehen will.
Bei einer Website, die wir trackingfrei bauen, wäre eine automatisch mitladende Karte der einzige Fremdaufruf im Dokument — und damit die Ausnahme von der eigenen Regel. Deshalb ist die Zwei-Klick-Lösung bei siteway der Standardweg: Der erste Klick gilt dem Schalter, der die Karte anfordert, der zweite dem Marker. Bis dahin steht an der Stelle ein statisches Kartenbild vom eigenen Server oder ein Adressblock mit Anschrift, Öffnungszeiten und Routenlink. Wer nur die Adresse sucht, hat sie damit vor dem ersten Klick.
Dazu gehört, dass die Entscheidung nachvollziehbar bleibt: Der Schalter ist beschriftet, nicht als Bildfläche getarnt, und benennt, was beim Laden passiert. Die Einwilligung wird an einer zentralen Stelle verwaltet und lässt sich zurücknehmen — dann steht beim nächsten Aufruf wieder der Platzhalter. Was die Karte verarbeitet und was davon in die Datenschutzerklärung gehört, halten wir als Dokumentation fest, damit sie nicht bei der ersten Rückfrage rekonstruiert werden muss.
Wir beschreiben hier die Technik und ihre Umsetzung — die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen. Was wir liefern, ist die Grundlage dafür: eine Umsetzung, die zeigt, wann welche Daten fließen. Wie das im Zusammenhang der ganzen Website aussieht, steht unter Sicherheit & Datenschutz; wer den Bestand einer vorhandenen Seite geprüft haben will, findet das im Datenschutz-Audit.
// faq
Die Google Maps Platform ist die Sammlung der Kartendienste, die Google für eigene Websites und Anwendungen bereitstellt. Für eine Website sind fünf davon relevant: die Maps JavaScript API für die interaktive Karte im Browser, die Maps Static API, die ein Kartenbild als Antwort auf einen normalen HTTP-Aufruf liefert und dafür kein JavaScript braucht, die Geocoding API, die Adressen in Koordinaten übersetzt und umgekehrt, die Places API für Ortsdaten, Suche und Autocomplete sowie die Routes API für Routen und Fahrzeiten. Der Zugriff läuft immer über einen API-Schlüssel. Was davon ein Projekt wirklich braucht, entscheidet sich am Anwendungsfall — eine Anfahrtskarte kommt mit weniger aus als eine Händlersuche.
Indem die Karte nicht automatisch mitlädt. Eine eingebettete Google-Karte holt Code und Kacheln von Google-Servern; damit die Auslieferung überhaupt funktionieren kann, wird die IP-Adresse des Besuchers übertragen. Bei einer trackingfrei gebauten Website heißt das: An der Stelle der Karte steht zunächst ein Platzhalter — ein statisches Kartenbild vom eigenen Server oder ein Adressblock mit Anschrift, Öffnungszeiten und einem Link zur Route. Erst wenn jemand den Schalter aktiv betätigt, wird das Kartenskript nachgeladen und die Karte erscheint an derselben Stelle. Diese Zwei-Klick-Lösung ist bei siteway der Standardweg. Welche Datenverarbeitung im konkreten Fall wie zu bewerten und in der Datenschutzerklärung zu beschreiben ist, gehört in die Hand der Rechtsberatung — wir liefern die technische Umsetzung und die Dokumentation dazu.
Weil eine Adresse sich selten ändert, ein Seitenaufruf aber oft passiert. Die Geocoding API ist ein Webdienst, den Google unter den Web Services führt und der per HTTP angesprochen wird — er passt damit genau dorthin, wo er hingehört: auf den Server. Wir übersetzen die Adresse einmal in Länge und Breite, schreiben das Ergebnis als Koordinatenfelder in den Datensatz im CMS und arbeiten danach mit diesen Werten. Die Karte bekommt fertige Koordinaten statt einer Adresse, die sie erst auflösen muss. Das ist schneller, sparsamer im Verbrauch und unabhängiger: Fällt der Dienst kurz aus, stehen die Standorte trotzdem auf der Seite.
Über drei Beschränkungen, die Google in seinen Sicherheitsempfehlungen selbst benennt. Erstens die Anwendungsbeschränkung: Ein Schlüssel, der im Browser sichtbar ist, wird auf die eigene Domain als HTTP-Referrer festgelegt, ein Schlüssel für Serveraufrufe auf die IP-Adresse des Servers. Zweitens die Dienstbeschränkung: Der Schlüssel wird nur für die Dienste freigeschaltet, die tatsächlich benutzt werden. Drittens getrennte Schlüssel je Anwendung, damit ein kompromittierter Schlüssel nicht alles betrifft. Google weist ausdrücklich darauf hin, dass der Betreiber für Kosten haftet, die durch Missbrauch unbeschränkter Schlüssel entstehen — der Schlüssel fürs Geocoding liegt deshalb serverseitig und taucht im Quelltext der Seite gar nicht erst auf.
Eine Karte allein ist für Tastatur und Screenreader schwer zu bedienen — Zoomen, Schwenken und Marker anklicken sind visuelle Handlungen, und ein Pin auf einer Kachel hat für sich genommen keinen lesbaren Inhalt. Deshalb gehört neben die Karte eine bedienbare Liste der Standorte als gleichwertiger Zugang: Adresse, Öffnungszeiten, Telefonnummer und Routenlink als echter Text, per Tab erreichbar, ohne dass jemand die Karte anfassen muss. Wer die Karte nutzen kann, nutzt sie; wer nicht, kommt über die Liste an dieselben Informationen. Die Liste ist dabei kein Ersatzangebot am Rand, sondern derselbe Datenbestand in anderer Darstellung — sie kommt aus denselben CMS-Feldern wie die Marker.
Eine Karte ist einer der schwersten Bausteine, die eine Seite haben kann: Skript, Kacheln, Schriften und Symbole kommen zusammen. Genau deshalb passt der Consent-Platzhalter so gut zur Technik — solange niemand die Karte anfordert, wird nichts davon geladen. Der Platzhalter selbst ist ein Bild mit festen Maßen oder ein Textblock und kostet fast nichts. Wird die Karte geladen, geschieht das nach dem ersten Seitenaufbau und in einem Container, dessen Höhe vorher feststeht, damit nichts nachträglich verspringt. Das hilft den Core Web Vitals an drei Stellen gleichzeitig: weniger zu übertragende Daten, weniger Arbeit im Hauptthread, kein Layout-Sprung.
In der Regel setzt siteway auf die Google-Maps-API, weil sie das dichteste Adress- und Routing-Material liefert. Für Anfahrt, Filialübersicht, Umkreis- und Händlersuche ist das die pragmatische Wahl: Adressen werden zuverlässig gefunden, Routen und Fahrzeiten stimmen, und Besucher kennen die Bedienung. Mapbox kommt in Frage, wenn eine eigene Kartensprache gefragt ist — wenn die Karte selbst Gestaltungsfläche ist, eigene Datenebenen tragen soll oder sich gestalterisch vollständig ins Design einfügen muss. Das ist eine Zuordnung nach Anwendungsfall, keine Rangliste. Welche Technik ein Projekt bekommt, klären wir vorher im Konzept.
Ja, in allen drei Systemen — und wir bauen die Einbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension: Standorte als Records mit Koordinatenfeldern, das Geocoding als Scheduler-Task, der Schlüssel in der Extension-Konfiguration, im Frontend ein Fluid-Template mit Consent-Platzhalter. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type für Standorte, das Geocoding beim Speichern eines Standorts, der Schlüssel in der wp-config.php oder in einer Umgebungsvariablen. In Statamic liegt Laravel darunter: ein Blueprint mit Koordinatenfeldern, ein Artisan-Command fürs Geocoding, der Schlüssel in der .env, gerendert über Antlers oder Blade. Die Mechanik ist überall dieselbe, nur die Bordmittel heißen anders.
// womit das zusammenhängt
baustein, technik & grundlagen
// komponente · buchen
Die Technik hier, der Baustein dort: Marker, Cluster, Umkreis- und Händlersuche, Route und Karten-Design als buchbare Komponente.
zur komponente →
// stack · schnittstelle
Der Weg für eine eigene Kartensprache: Karte als Gestaltungsfläche, eigene Datenebenen, Stil bis ins Detail.
zur technik →
// stack · grundlage
Wo Fremdcode ins Spiel kommt, wird es konkret: Einwilligung, Schlüssel serverseitig, Datensparsamkeit, Dokumentation.
zur technik →
// stack · grundlage
Warum neben jede Karte eine bedienbare Standortliste gehört — und was das für Tastatur und Screenreader bedeutet.
zur technik →
// stack · grundlage
Karten sind schwer. Verzögertes Laden, feste Containerhöhen und weniger Fremdcode wirken direkt auf die Core Web Vitals.
zur technik →
// leistung · buchen
Analyse, Mapping, Umsetzung, Monitoring und Betrieb einer Anbindung — als buchbare Leistung beschrieben.
zur leistung →
// Standortkarte, die erst nach Einwilligung lädt?
Projekt anfragen