Die Website zeigt einem englischsprachigen Nutzer aus den USA eine Seite, während Googlebot, der physisch im Rechenzentrum in Mountain View sitzt, eine ganz andere sieht. Formal ist das bereits Cloaking, auch wenn Sie nur den Inhalt für die Region anpassen wollten. Wir analysieren 6 typische Fehler bei Geo-Redirects, aufgrund derer Websites ihre Positionen verlieren, manuelle Sanktionen erhalten und ganze Domains in Partnernetzwerken gesperrt werden.
Was ist ein Geo-Redirect und warum ist er für Unternehmen wichtig?
Ein Geo-Redirect ist ein Mechanismus, der den Nutzer automatisch auf die Version der Website umleitet, die für sein Land angepasst ist: eine andere Sprache, Währung, Preise, Angebote. Online-Shops verwenden ihn, damit ein Käufer aus Deutschland sofort auf die deutsche Version mit Preisen in Euro gelangt, anstatt durch einen Katalog in Dollar zu blättern. Arbitrageure verwenden Geo-Redirects in Kombinationen, um je nach Geo-Traffic unterschiedliche Angebote anzuzeigen – zum Beispiel eine Landing Page für Nutzer aus Tier-1-Ländern und eine andere für alle anderen.
Das Problem ist, dass dieselbe Logik, die das Land des Nutzers anhand der IP bestimmt, auch auf Googlebot angewendet wird. Die IP-Adressen der Google-Bots befinden sich physisch in den USA, unabhängig davon, ob sie eine Seite für die russische, kasachische oder deutsche Ausgabe indizieren. Wenn das Geo-Redirect-System den Crawler nicht von einem echten Menschen unterscheidet, ist das Ergebnis dasselbe – Google sieht nicht die Seite, die echte Besucher sehen. Dies ist die formale Definition von Cloaking gemäß den Empfehlungen von Google Search Central, und die Strafe dafür reicht von einer Herabstufung in den Suchergebnissen bis zur vollständigen Ausschluss der Domain aus dem Index.
Warum sieht Googlebot andere Seiten als Menschen?
Die Diskrepanz entsteht aus drei Gründen gleichzeitig, die sich normalerweise gegenseitig beeinflussen. Erstens crawlt Googlebot die Website von IP-Adressen, die Google gehören, und diese Adressen werden von Geo-Diensten (MaxMind, IP2Location und ähnlichen) in fast 100 % der Fälle als amerikanisch identifiziert. Zweitens sendet Googlebot seinen eigenen User-Agent, der oft von einem separaten Code-Zweig verarbeitet wird – manchmal absichtlich, um die Indizierung nicht zu stören, und manchmal einfach aus einem Fehler des Entwicklers. Drittens unterscheidet sich das Verhalten von Googlebot beim JS-Rendering vom Verhalten des Browsers: Der Crawler kann einen Redirect, der auf clientseitigem JavaScript basiert, nicht ausführen, und indexiert dann eine ganz andere Version der Seite, die der Mensch mit aktiviertem JS sieht.
Fügen Sie hier das CDN-Caching hinzu, das auf der Version für ein bestimmtes Land „stecken bleiben“ kann und diese an alle ausliefert, und Sie haben eine Situation, in der selbst ohne böse Absicht des Website-Besitzers die Suchmaschine Inhalte indiziert, die nicht dem entsprechen, was das Publikum sieht. Im Folgenden finden Sie sechs konkrete Szenarien, in denen dies am häufigsten vorkommt.
Fehler 1: Redirect nach IP ohne Überprüfung des User-Agent des Bots
Der häufigste Fehler besteht darin, dass die Logik des Redirects ausschließlich auf der Bestimmung des Landes anhand der IP basiert, ohne auch nur einmal zu überprüfen, wer genau die Anfrage stellt: ein Mensch oder ein Crawler. Infolgedessen gelangt Googlebot, der von einem amerikanischen IP-Bereich aus zugreift, automatisch auf die US-Version der Website, selbst wenn die Seite ursprünglich für Anfragen aus Russland oder Kasachstan beworben wurde. Nach einigen Wochen des Crawlens ist der Google-Index mit der „falschen“ Version des Inhalts überfüllt, und die Positionen in den Zielregionen beginnen ohne ersichtlichen Grund zu sinken.
Die Lösung besteht darin, immer bekannte User-Agents und IP-Bereiche von Suchmaschinen-Bots (Googlebot, Bingbot, YandexBot) aus dem Geo-Redirect auszuschließen und ihnen die kanonische Version der Seite unabhängig vom bestimmten Land zu liefern. Die Überprüfung des User-Agent ist eine notwendige, aber nicht ausreichende Barriere, da sie leicht gefälscht werden kann. Daher verifizieren ernsthafte Projekte zusätzlich die IP über eine Reverse-DNS-Abfrage, wie es die Google-Dokumentation selbst für die Verifizierung von Googlebot empfiehlt.
Fehler 2: Testen mit Rechenzentrums-IP anstelle von realen Nutzer-IP
Der zweite Fehler tritt bereits in der Testphase auf. Der Entwickler oder Marketer testet den Geo-Redirect über einen normalen Rechenzentrumsproxy oder VPN, und die Logik funktioniert so, als ob es sich um einen echten Nutzer aus dem gewünschten Land handelt. Aber Rechenzentrums-IP sind leicht von Haushaltsverkehr zu unterscheiden – viele CDNs und Anti-Fraud-Systeme kennzeichnen sie mit einem eigenen Flag, und ein Teil der Geo-Targeting-Logik kann sich für solche Adressen anders verhalten als für normale Heim-ISP-IP.
Infolgedessen „besteht“ der Test, der Redirect auf dem Entwicklungsserver funktioniert perfekt, und in der Produktion erhalten echte Nutzer aus dem Zielgebiet nicht die richtige Version, weil die ISP-Geolokalisierungsdatenbank oder die CDN-Regel ihre IP anders interpretiert als die Test-Rechenzentrumsadresse. Für eine korrekte Überprüfung sollten residential Proxys verwendet werden – sie haben IPs von echten Heim-ISPs im gewünschten Land, und Geo-Dienste identifizieren sie genauso, wie sie einen echten Nutzer identifizieren würden. Dies gibt ein ehrliches Bild davon, was ein echter Besucher der Website sehen wird, und nicht eine vereinfachte Version für eine „typische“ Rechenzentrums-IP.
Fehler 3: Cache und fehlende Vary-Header
Wenn die Website hinter einem CDN (Cloudflare, Fastly, Akamai) steht und der Geo-Redirect auf der Ebene des Origin-Servers und nicht des CDN selbst implementiert ist, kann es leicht zu einer Situation kommen, in der das CDN die erste ausgelieferte Version der Seite zwischenspeichert und diese an alle ausliefert – unabhängig vom Land des nächsten Besuchers. Dies geschieht, wenn im Serverantwort kein korrekter Header Vary: Accept-Language oder ein ähnlicher Cache-Schlüssel nach Geo-Kriterium angegeben ist.
Googlebot kann in diesem Fall die „richtige“ Version beim ersten Besuch erfassen, sie in seinen eigenen Indizierungssystemen zwischenspeichern und dann wochenlang dieselbe Version bei wiederholten Besuchen erhalten, selbst wenn der Inhalt für andere Länder längst geändert wurde. Die Nutzer sehen in der Zwischenzeit eine aktuelle, aber andere Version – die Asynchronität wächst allmählich und ist schwer zu diagnostizieren, ohne direkte Vergleiche der Serverantworten für verschiedene Geos über Tools wie curl mit Header-Manipulation oder über Proxys mit der gewünschten Geolokalisierung.
Fehler 4: JS-Redirect, den der Bot anders interpretiert
Googlebot kann JavaScript ausführen, tut dies jedoch mit erheblicher Verzögerung (die zweite Rendering-Welle kann Tage dauern) und nicht immer identisch zum Browser des Nutzers. Wenn der Geo-Redirect über clientseitiges JS implementiert ist – zum Beispiel über window.location nach einem Fetch-Request an die Geo-API – besteht das Risiko, dass der Crawler die Seite beim ersten Durchgang indexiert, bevor der Redirect ausgelöst wird, also die „falsche“ Version des Inhalts für die spezifische Region.
Dies ist besonders kritisch für Single-Page-Landing-Pages (SPA), bei denen die gesamte Personalisierungslogik auf der Client-Seite basiert. Der richtige Ansatz besteht darin, die Geo-Bestimmung und den Redirect auf der Serverseite (Edge-Funktion des CDN, Middleware auf Node.js, Regel in Nginx) auszuführen, sodass Googlebot und der Nutzer den HTTP-Redirect 302 erhalten, noch bevor die Seite im Browser gerendert wird. Dies beseitigt die Abhängigkeit davon, wie genau der Crawler JS zu einem bestimmten Zeitpunkt verarbeitet.
Fehler 5: Eine URL ohne hreflang für verschiedene Sprachversionen
Der fünfte Fehler besteht darin, zu versuchen, mehrere Sprachversionen unter derselben URL ohne hreflang-Markup bereitzustellen. Google empfiehlt ausdrücklich: Wenn der Inhalt unter einer URL je nach Benutzerlokalität unterschiedlich ist, sollten entweder unterschiedliche URLs für jede Version (Subdomains, Unterverzeichnisse oder separate Domains) mit gegenseitigem hreflang-Markup bereitgestellt werden, oder dieselbe Version sollte allen, einschließlich Bots, ehrlich angezeigt werden, wobei die Möglichkeit hinzugefügt wird, die Sprache manuell umzuschalten.
Ohne hreflang kann Google physisch nicht verstehen, dass /product auf Russisch und /product auf Englisch absichtlich unterschiedliche Inhalte für verschiedene Zielgruppen sind und nicht der Versuch, eine Version vor dem Index zu verbergen. Das Ergebnis ist, dass eine zufällige Version (gewöhnlich die, die beim letzten Crawlen für den Bot verfügbar war) in den Index gelangt, und genau diese beginnt, in allen Regionen gleichzeitig zu ranken, was sich negativ auf die Relevanz der Ausgabe und die Konversion auswirkt.
Fehler 6: Kein Fallback für Nutzer mit VPN und mobilen Proxys
Der sechste Fehler betrifft weniger Googlebot als echte Nutzer – aber er steht in direktem Zusammenhang mit dem Thema Geo-Redirects, da oft gerade der Versuch, das Verhalten für Bots zu „reparieren“, es für echte Menschen mit VPN oder mobilem Internet kaputt macht. Nutzer von Mobilfunkanbietern gehen oft über CGNAT (Carrier-Grade NAT) ins Internet, wenn zehntausende von Abonnenten dieselbe externe IP verwenden, und die Geo-Datenbank kann eine solche IP fälschlicherweise als zu einem benachbarten Land gehörend identifizieren.
Wenn auf der Website kein manueller Länder-/Sprachumschalter als Fallback vorhanden ist, bleibt ein Nutzer mit einer „falsch“ identifizierten IP auf einer irrelevanten Version ohne Möglichkeit, diese zu wechseln – und verlässt einfach die Seite. Um genau dieses Szenario zu testen, sollte das Verhalten der Website über mobile Proxys überprüft werden, die IPs von echten Mobilfunkanbietern mit typischem CGNAT-Verhalten in Bezug auf Geolokalisierung emulieren – dies hilft, das Problem im Voraus zu erkennen, bevor es echte Nutzer entdecken und den Support kontaktieren.
Wie man Geo-Redirects aus der Sicht von Google aus verschiedenen Ländern überprüft
Das Hauptwerkzeug für die erste Diagnose ist die Funktion „Als Googlebot ansehen“ in der Google Search Console (URL-Prüftool), die zeigt, welchen HTML-Code der Google-Crawler tatsächlich erhält. Wenn dort nicht die Version angezeigt wird, die Sie in Ihrem Browser aus Ihrem Land sehen, ist das Problem bestätigt. Aber die Search Console crawlt immer von amerikanischen IPs, daher ist für den Vergleich des Verhaltens der Website in verschiedenen Regionen eine separate Testschicht erforderlich.
In der Praxis erstellen Marketer und SEO-Spezialisten mehrere Profile in einem Anti-Detect-Browser – Dolphin Anty, AdsPower, Multilogin oder GoLogin – und verknüpfen mit jedem Profil Proxys aus dem gewünschten Land, um den Nutzerweg manuell zu durchlaufen: die Website zu öffnen, zu sehen, welche Version geladen wurde, welchen Accept-Language-Header gesendet wurde, ob der Redirect funktioniert hat und auf welche URL. Für solche Überprüfungen sind residential Proxys mit gezielter Auswahl von Stadt oder Anbieter praktisch – sie bieten die ehrlichste Nachahmung eines echten Besuchers, im Gegensatz zu Rechenzentrumsadressen, die von einigen Diensten möglicherweise bereits vor der Geo-Bewertung als verdächtig gekennzeichnet werden.
| Proxy-Typ | Für welche Prüfung geeignet | Risiko eines falschen Ergebnisses |
|---|---|---|
| Residential Proxys | Nachahmung eines normalen Haushaltsnutzers im gewünschten Land/Stadt | Niedrig |
| Mobile Proxys | Überprüfung des Verhaltens bei CGNAT und mobiler Geolokalisierung | Niedrig |
| Rechenzentrums-Proxys | Schnelle Überprüfung des Vorhandenseins eines Redirects nach Land | Höher: Ein Teil der Geo-Datenbanken kennzeichnet IPs anders als Haushalts-IP |
Um das Verhalten der Serverlogik (nicht die visuelle Darstellung) zu überprüfen, ist es nützlich, zusätzlich die rohe Serverantwort über curl mit einer Änderung des User-Agent auf Googlebot und des X-Forwarded-For-Headers auf die IP des gewünschten Landes zu betrachten – dies zeigt, welchen HTTP-Status und Location der Server vor jeglichem JS-Rendering zurückgibt und ermöglicht es, Fehler 4 und Fehler 1 aus der obigen Liste mit nur einem Befehl zu erfassen.
Checkliste für die sichere Einrichtung von Geo-Redirects
- Googlebot, Bingbot und YandexBot sind aus der Logik des Geo-Redirects nach User-Agent ausgeschlossen und über Reverse-DNS bestätigt
- Der Redirect ist auf der Serverseite (302/307) implementiert und nicht nur über clientseitiges JavaScript
- Der Header
Varyist für korrektes CDN-Caching nach Geo/Sprache konfiguriert - Für jede Sprachversion gibt es eine separate URL mit gegenseitigem hreflang-Markup
- Es gibt einen sichtbaren manuellen Länder-/Sprachumschalter als Fallback für falsch identifizierte IPs
- Tests werden über residential und mobile Proxys aus den gewünschten Ländern durchgeführt, nicht nur über Rechenzentrumsadressen
- Einmal im Quartal wird überprüft, was die Google Search Console anzeigt – die Version stimmt mit dem überein, was echte Nutzer sehen
Fazit
Die Diskrepanz zwischen dem, was Googlebot sieht, und dem, was der Nutzer sieht, ist selten ein absichtlicher Betrug der Suchmaschine – oft ist es ein angesammelter technischer Schuldenstand: Redirect nach IP ohne Überprüfung des Bots, Cache ohne Vary-Header, JS-Redirect, den der Crawler nicht rechtzeitig ausführen kann, und das Fehlen von hreflang für Sprachversionen. Jeder dieser Fehler scheint für sich genommen geringfügig zu sein, aber zusammen ergeben sie ein klassisches Bild des Cloakings in den Augen von Google – mit entsprechenden Sanktionen.
Der einzige zuverlässige Weg, um sicherzustellen, dass die Website sowohl für Bots als auch für Menschen gleich ehrlich funktioniert, besteht darin, sie regelmäßig von echten IPs aus den gewünschten Ländern zu überprüfen. Für eine solche Diagnose empfehlen wir die Verwendung von residential Proxys zur Nachahmung eines typischen Haushaltsnutzers und mobilen Proxys zur Überprüfung von CGNAT-Szenarien – dies gibt das ehrlichste Bild davon, was Ihr Publikum in jeder Region tatsächlich sieht, und hilft, Probleme zu erkennen, bevor sie vom Google-Algorithmus entdeckt werden.