IP-Geolokalisierung versus geräteeigener Browser-Standort
Die geräteeigene Geolocation-API des Browsers (navigator.geolocation) fragt die Nutzerin oder den Nutzer um Erlaubnis und kann eine präzise, vom Gerät gemessene Position liefern; IP-Geolokalisierung braucht keine Erlaubnis und läuft bei jeder Anfrage, schätzt den Standort aber nur aus der Netzwerkadresse der Verbindung. Beide lösen unterschiedliche Probleme und sind nicht austauschbar.
Erlaubnis und Quelle
navigator.geolocation.getCurrentPosition() (die W3C-Geolocation-API, von jedem großen Browser implementiert) erfordert eine ausdrückliche, pro Origin gestellte Berechtigungsabfrage und, in modernen Browsern, einen sicheren (HTTPS-)Kontext. Bei erteilter Berechtigung kann sie je nach Geräteausstattung GPS, WLAN-Positionierung, Mobilfunkmast-Triangulation oder IP als Fallback nutzen. IP-Geolokalisierung braucht keine Berechtigungsabfrage und keine Mitwirkung des Geräts — eine API wie GET /v1/geo liest sie direkt aus der eingehenden Anfrage —, hat aber immer nur die Netzwerkadresse zur Verfügung.
Genauigkeit
Eine erteilte Geräteposition enthält üblicherweise einen ausdrücklichen Genauigkeitsradius in Metern und kann auf einem Telefon mit GPS und freier Sicht zum Himmel auf wenige Meter genau sein. IP-Geolokalisierung löst zu einem Netzwerkbereich auf, nicht zu einem Gerät — Ergebnisse auf Länderebene sind meist verlässlich, Ergebnisse auf Stadtebene sind eine echte Schätzung, und weder Watch-IP noch irgendein anderer Anbieter liefert eine Genauigkeitsangabe im Meterbereich, weil die zugrunde liegenden Daten dafür nicht präzise genug sind. Eine ausführlichere Aufschlüsselung der Unsicherheit auf Stadtebene finden Sie unter Genauigkeit.
Fehlerzustände
Die Geräte-Geolokalisierung kann fehlschlagen oder abgelehnt werden: Die Nutzerin oder der Nutzer kann die Berechtigungsabfrage ablehnen, der Browser kann so konfiguriert sein, dass er sie blockiert, ein Desktop-Rechner hat möglicherweise keine brauchbare Standort-Hardware, oder die Anfrage läuft in ein Timeout. Behandeln Sie PERMISSION_DENIED, POSITION_UNAVAILABLE und TIMEOUT (die eigenen Fehlercodes der API) als eigenständige, erwartbare Ergebnisse, nicht als Ausnahmefälle. IP-Geolokalisierung schlägt anders fehl — ein auflösbares Feld kann einfach null sein oder, bei einer Abfrage einer angegebenen IP, found: false — und zeigt der Nutzerin oder dem Nutzer überhaupt keine Berechtigungsabfrage.
Die Wahl zwischen beiden
Verwenden Sie die Geräte-Geolokalisierung, wenn Sie die tatsächliche Position der Nutzerin oder des Nutzers benötigen und die Berechtigungsabfrage dafür rechtfertigen können — eine Karte, eine Filialsuche oder eine Schritt-für-Schritt-Navigation. Verwenden Sie IP-Geolokalisierung für einen reibungsarmen Standardwert: das Vorausfüllen eines Landes oder einer Währung, Analytics-Routing oder das Vorschlagen (nie Erzwingen) eines Locale, bevor oder anstatt um Erlaubnis zu fragen. Ein gängiges Muster ist, IP-Geolokalisierung als Null-Berechtigungs-Standard zu verwenden und die Geräte-Geolokalisierung als ausdrückliches, von der Nutzerin oder dem Nutzer ausgelöstes Upgrade für Aufgaben anzubieten, die tatsächlich Präzision benötigen.
Was dieser Artikel nicht behauptet
Dies ist ein allgemeiner Vergleich zweier unterschiedlicher Browser-Mechanismen, keine Behauptung, dass Watch-IP die geräteeigene Geolocation-API implementiert oder umschließt — das tut es nicht. GET /v1/geo basiert ausschließlich auf IP; wenn Ihre Anwendung auch Geräte-Geolokalisierung benötigt, rufen Sie die Browser-API direkt auf und behandeln Sie die beiden Ergebnisse unabhängig voneinander, statt zu versuchen, sie in Einklang zu bringen.
Quellen
Verfasst vom Watch-IP-Redaktionsteam, 6. September 2026. Geprüft gegenüber apps/web/lib/cf.ts und apps/api/src/routes/geo.ts.