Unser Ahrefs Domain Rating fiel von 23 auf 6. Die Zahl war schwer zu ignorieren. Sie war aber auch keine Erklärung.
Diese Unterscheidung prägte die Untersuchung. Ein Score von einem Drittanbieter kann dir sagen, dass sich in seinem Modell etwas geändert hat. Er kann dir jedoch nicht sagen, welche technische Entscheidung die Änderung verursacht hat, oder ob dieselbe Bewegung auch in der Suchperformance zu sehen ist. Deshalb behandelten wir den Rückgang als Anlass, die Seite zu prüfen - nicht als Urteil.
Bei der Prüfung wurde ein echtes Problem an der Root-URL gefunden. Für Besucher ohne bestehende Sprachauswahl konnte dieselbe URL je nach Anfrage-Standort zu unterschiedlichen Locale-Pfaden einen temporären Redirect zurückgeben. Dieses Verhalten war inkonsistent mit der permanenten Locale-Struktur, die Suchmaschinen verstehen sollen.
Wir haben das behoben. Wir können ehrlich gesagt aber nicht behaupten, dass dieser Redirect den Domain-Rating-Rückgang verursacht hat.
Was der Score tatsächlich aussagt
Ahrefs definiert Domain Rating als relatives Maß für das Backlink-Profil einer Website auf einer Skala von 0 bis 100. Die Berechnung hängt davon ab, welche Seiten auf eine Domain verlinken, und vom breiteren Ahrefs-Index. Ein Score kann sich daher auch dann bewegen, wenn eine Seite nicht denselben Anteil an Backlinks verloren hat.
Ahrefs sagt außerdem, dass Domain Rating kein Google-Ranking-Faktor ist. Es ist nützlich, um Backlink-Profile zu vergleichen und Veränderungen zu erkennen, aber es ist keine direkte Messung dafür, wie Google eine Seite bewertet.
Damit blieben für uns zwei getrennte Fakten:
- Wir beobachteten, wie der Score von 23 auf 6 fiel.
- Unser Root-Redirect-Verhalten musste korrigiert werden.
Die Fakten existierten zur gleichen Zeit. Ihr zeitlicher Zusammenhang beweist nicht, dass das eine das andere verursacht hat.
Was die Root-URL tat
Das alte Middleware-Setup wählte eine Locale anhand des Request-Landes, wenn noch keine Locale-Präferenz vorhanden war. Anschließend hat es einen nicht lokalisierten Pfad wie die Root-URL mit einer 302-Antwort in diese Locale umgeleitet.
Vereinfacht sah das relevante Verhalten so aus:
const country = request.cf?.country
|| request.headers.get('CF-IPCountry')
|| 'US'
const targetLocale = LOCALE_MAP[country] || 'en'
return new Response(null, {
status: 302,
headers: { Location: `/${targetLocale}/` },
})
Der Code wollte hilfreich sein. Ein Besucher in Deutschland sollte zur deutschen Locale geschickt werden, während ein Besucher in den Vereinigten Staaten zu Englisch weitergeleitet werden konnte.
Das Problem traf den Crawler auf Vertragsebene. Eine Quell-URL hatte kein stabiles Ziel. Ihre Antwort hing vom Standort ab, und der Redirect sagte, dass die Änderung vorübergehend sei.
Das ist relevant, weil Google permanente und temporäre Redirects unterschiedlich behandelt. In seiner Redirect-Dokumentation heißt es, dass permanente Weiterleitungen wie 301 und 308 starke Signale sind, dass das Ziel kanonisch werden soll. Bei temporären Redirects wie 302 und 307 bleibt die Quell-URL in den Suchergebnissen in der Regel die kanonische URL.
Temporäre Redirects sind dann richtig, wenn eine Änderung wirklich temporär ist. Sie sind die falsche Standardannahme, wenn die Website eine permanente Locale-Hierarchie hat und einen deterministischen kanonischen Einstiegspunkt benötigt.
Warum standortabhängiges Routing riskant war
Stell dir zwei Crawler vor, die dieselbe Root-URL aus unterschiedlichen Regionen anfragen. Der eine erhält einen Redirect zu /en/. Der andere erhält einen Redirect zu /de/. Beide Antworten sind temporär.
Nichts in einer der Antworten erzählt eine stabile Geschichte darüber, welches Root-Ziel die Seite bevorzugt. Das Verhalten kann auch dazu führen, dass externe Tools je nach Zeitpunkt und Standort unterschiedliche Ketten speichern.
Das zerstört nicht automatisch Autorität, und eine 302 ist keine Strafe. Suchmaschinen können Redirects interpretieren, indem sie mehr als nur den Statuscode heranziehen. Das Problem war, dass unsere Implementierung in eine einzige Antwort drei Anliegen vermischte:
- Die permanente Struktur der Seite
- Die wahrscheinliche Sprache des Besuchers
- Die gespeicherte Präferenz des Besuchers
Diese Anliegen verdienen eine unterschiedliche Behandlung. Der kanonische Pfad sollte stabil sein. Personalisierung sollte nur bei einer expliziten Präferenz passieren oder nachdem die stabile Seite geladen wurde.
Die deterministische Korrektur
Die korrigierte Middleware trennt eine neue Anfrage von einem wiederkehrenden Besucher mit gespeicherter Locale-Auswahl.
Für eine Cookie-lose Anfrage an einen nicht lokalisierten Pfad liefert der Server nun einen permanenten 301-Redirect auf den englischen Pfad. Das Ziel ist unabhängig vom Land:
https://zenovay.com/ -> https://zenovay.com/en/
Für einen Besucher, der bereits ein Locale-Preference-Cookie hat, kann die Middleware diese persönliche Entscheidung weiterhin mit einem temporären Redirect respektieren. Das ist eine wirklich nutzerspezifische Antwort - keine Aussage über die kanonische Struktur der Seite.
Dies ist eine kleine Änderung im Code mit einer nützlichen Eigenschaft: Ein Crawler und ein sauberer Browser sehen jetzt einen vorhersehbaren ersten Hop. Wir haben die Live-Root-Antwort mit gewöhnlichen Requests, Googlebot-Requests und unterschiedlichen Language-Headern verifiziert. Jede Anfrage lieferte einen 301 zu derselben englischen URL.
Die Korrektur erfordert nicht, dass wir lokalisierte Seiten entfernen. Jede Locale hat weiterhin ihre eigene URL. Language-Selector und gespeicherte Präferenzen bedienen weiterhin die Besucher. Die Änderung macht lediglich den Standard-Einstiegspfad deterministisch.
Was wir ableiten können - und was nicht
Wir können ableiten, dass der alte Root-Redirect ein technischer Fehler war. Er nutzte einen temporären Status für eine permanente Seitenstruktur und ließ zu, dass das Ziel je nach Standort der Anfrage variierte. Das aktuelle Verhalten ist für Crawler, externe Audit-Tools und Menschen einfacher zu interpretieren.
Wir können nicht ableiten, dass der Fehler die komplette Änderung im Ahrefs-Score verursacht hat. Wir haben kein kontrolliertes Experiment, das den Redirect von Änderungen im Ahrefs-Index, dem Backlink-Graphen, den referierenden Domains oder anderen Faktoren der Seite isoliert.
Wir können auch nicht behaupten, dass es eine Erholung gab, bevor die Daten das zeigen. Das Ausrollen der Korrektur ist der Start der Beobachtung - nicht das Ende der Geschichte.
Der verantwortungsvolle Ansatz ist, das Änderungsdatum zu dokumentieren und mehrere Signale getrennt zu beobachten:
- Domain Rating und die darunterliegenden referierenden Domains
- Neu entdeckte und verlorene Backlinks
- Search Impressions und Klicks aus First-Party-Search-Daten
- Indexierung und kanonische Auswahl für die Root- und Locale-Seiten
- Die Redirect-Antwort, wie sie aus sauberen Requests über die Zeit sichtbar ist
Wenn sich diese Signale nach der Korrektur gemeinsam verbessern, wird die Evidenz interessanter. Sie erfordert weiterhin eine vorsichtige Interpretation.
Ein praktisches Redirect-Audit
Du brauchst keine große SEO-Plattform, um diese Art von Problem zu erkennen. Starte direkt bei der HTTP-Antwort.
- Fordere die Root-URL ohne Cookies an und protokolliere den Status sowie den
Location-Header. - Wiederhole die Anfrage mit unterschiedlichen Language-Headers und, wenn möglich, aus unterschiedlichen Regionen.
- Stelle sicher, dass permanente öffentliche Routen genau ein deterministisches Ziel haben.
- Verfolge die Kette und prüfe, ob sie ohne zusätzliche Hops oder Loops endet.
- Untersuche die kanonischen und alternativen Language-Links der finalen Seite.
- Teste einen wiederkehrenden Besucher mit expliziter Locale-Präferenz separat.
- Speichere das Ergebnis und das Deployment-Datum, damit spätere Kennzahlenänderungen Kontext haben.
Ein hilfreicher Command-Line-Check ist bewusst langweilig:
curl -I https://example.com/
Dann ändere jeweils nur eine Eingabe nach der anderen. Füge einen Accept-Language-Header hinzu. Verwende ein sauberes Cookie-Jar. Führe den Request aus einer anderen Region aus. Wenn die öffentliche URL ein einzelnes kanonisches Ziel haben soll, darf der erste Hop nicht zur Geografie-Lotterie werden.
Die allgemeine Lehre
Kennzahlenrückgänge erzeugen Druck für eine schnelle Story. Eine schnelle Story ist oft der Ort, an dem eine technische Beobachtung zu einer unbelegten Kausalbehauptung wird.
Die bessere Reihenfolge ist langsamer - und nützlicher:
- Prüfe, was der Metric misst.
- Untersuche das System auf konkrete Defekte.
- Behebe Defekte, weil sie Defekte sind.
- Trenne verifizierbares Verhalten von Hypothesen über Auswirkungen.
- Beobachte nach der Änderung primäre und Signale von Drittanbietern.
Unser Domain-Rating-Rückgang führte uns zu einem echten Redirect-Problem. Das Korrigieren dieses Problems gab der Seite einen stabilen kanonischen Einstiegspfad. Ob es die Bewegung des Scores erklärt, bleibt eine offene Frage - und wir würden diese Frage lieber offen lassen, als Gewissheit zu konstruieren.
Das ist die Art von Debugging-Record, der uns vertrauenswürdig ist: exakt beim Code, vorsichtig bei Kausalität und klar darin, was als Nächstes gemessen werden soll.
