Zurück zum Blog
14. November 2025Sergei Solod5 Min. Lesezeit

12.500 Seiten waren in Yandex indexiert, trotzdem kam fast kein Traffic aus Russland: Das Cloudflare-Problem, das ich übersehen hatte

Yandex hatte 12.500 Seiten indexiert, doch der Traffic aus Russland lag fast bei null. Ich grenzte das Problem auf den Netzwerkpfad ein, deaktivierte den Cloudflare-Proxy, baute Caching, Komprimierung und Basisschutz mit Nginx auf meinem VDS nach und stellte die Erreichbarkeit wieder her.

DevOpsSEONginxCloudflareNetzwerkeInfrastruktur

Bei einem meiner SEO-Projekte hatte Yandex 12.500 Seiten indexiert. Wenn ich nur auf diese Zahl schaute, wirkte die Website gesund. Der reale Traffic aus Russland lag trotzdem fast bei null.

Dieses große SEO-Projekt baute ich auch auf, um meine Fähigkeiten als Frontend-Entwickler weiterzuentwickeln.

Mein erster Gedanke ging in Richtung SEO. Bei der Fehlersuche stellte sich aber heraus, dass das Problem eine Ebene tiefer lag: im Netzwerkpfad. Die Website lief hinter Cloudflare, und aus Russland war sie nicht zuverlässig erreichbar. Da ich im Ausland lebte, war der Fehler von meinem Standort aus kaum sichtbar.

Der Vorfall zwang mich, drei Signale sauber zu trennen: Indexierung, Erreichbarkeit und Traffic. Sie sind nicht dasselbe. Eine Seite kann im Index stehen, während reale Nutzer in bestimmten Netzen sie nicht vollständig laden können.

Was ich tatsächlich bestätigen kann

Die Fakten aus meiner eigenen Erfahrung sind überschaubar. Ich betrieb ein großes SEO-Projekt hinter Cloudflare. Yandex hatte 12.500 Seiten indexiert, der Traffic aus Russland war aber nahezu null. Ich untersuchte die Ursache und grenzte sie auf die Netzwerkschicht ein. Danach deaktivierte ich den Cloudflare-Proxy vollständig und konfigurierte Nginx auf meinem eigenen VDS für die Funktionen, die ich weiter brauchte: Caching, Komprimierung und grundlegenden Schutz.

Nach dieser Änderung war der Zugriff aus Russland sofort wieder möglich. Das ist die stärkste Aussage, die ich aus diesem Fall ableiten kann: Die Änderung des Auslieferungspfads stellte die Erreichbarkeit wieder her.

Genauso wichtig ist, was der Fall nicht beweist. Ich kann daraus weder eine exakte Zahl verlorener Besuche noch alle betroffenen russischen Netze oder einen konkreten späteren Anstieg des organischen Traffics ableiten. Meine Beobachtungen betrafen Erreichbarkeit und fast ausbleibenden Traffic, nicht ein kontrolliertes SEO-Experiment.

Die öffentlichen Belege sind präziser als meine ursprüngliche Erklärung

Ursprünglich formulierte ich es so, als hätte Roskomnadzor bestimmte Cloudflare-IP-Bereiche blockiert. Für die Belege, die ich habe, ist das zu spezifisch.

Cloudflare veröffentlichte am 26. Juni 2025 einen eigenen Bericht. Darin heißt es, dass Nutzer in Russland seit dem 9. Juni 2025 beim Zugriff auf Cloudflare-geschützte Dienste durch russische ISPs gedrosselt würden. Laut Cloudflares interner Analyse konnten bei betroffenen Verbindungen teilweise nur die ersten 16 KB eines Web-Assets geladen werden. Das reicht bei vielen Seiten nicht für normales Browsing. Details stehen in Cloudflares Bericht zu den Einschränkungen in Russland.

Diese Beschreibung passt zu der Art von Fehler, die ich beobachtet habe. Sie beweist aber weder den exakten Mechanismus bei jedem ISP noch, dass mein kompletter Traffic-Einbruch direkt Roskomnadzor zugerechnet werden kann. Präziser ist: Der über Cloudflare proxied Auslieferungspfad meiner Website war aus Russland nicht zuverlässig nutzbar; das Umgehen dieses Proxys stellte in meinem Fall den Zugriff wieder her.

Warum 12.500 indexierte Seiten keine gesunde Website garantierten

Hier lag mein wichtigster Denkfehler. Ich sah 12.500 Seiten im Index und wertete das als allgemeines Signal für Erreichbarkeit. Suchmaschinen-Crawling und die Verbindung eines Endnutzers sind aber unterschiedliche Systeme.

Eine Suchmaschine kann eine URL früher gecrawlt haben, über einen anderen Netzwerkpfad zugreifen und sie weiter im Index behalten, obwohl manche Nutzer keine vollständige Antwort erhalten. Eine indexierte URL beweist daher nicht, dass ein Nutzer bei einem bestimmten russischen ISP die Seite heute laden kann. In meinem Fall galten beide Dinge gleichzeitig: 12.500 Seiten waren in Yandex indexiert und der russische Nutzer-Traffic war fast nicht vorhanden.

Indexierung ist nicht Erreichbarkeit. Erreichbarkeit ist nicht Traffic.

Was ich geändert habe

  1. Ich deaktivierte den Cloudflare-Proxy vollständig. HTTP- und HTTPS-Traffic musste damit nicht mehr durch Cloudflare, bevor er meine Infrastruktur erreichte.
  2. Ich verlagerte die nötigen Aufgaben zu Nginx. Auf meinem VDS konfigurierte ich Caching, Komprimierung und grundlegende Schutzmaßnahmen selbst.

Entscheidend war nicht, dass Nginx grundsätzlich „besser“ wäre. Ich entfernte eine Netzwerkabhängigkeit, die für einen für mich wichtigen Markt zum Problem geworden war.

Der Zugriff kam zurück, die Verantwortung aber auch

Ein Reverse-Proxy-Bypass ist kein kostenloses Upgrade. In der aktuellen Cloudflare-Dokumentation steht, dass DNS-only den Nutzer direkt zum Origin führt und HTTP/HTTPS nicht mehr durch Cloudflare geroutet wird. Damit entfallen proxybasierte Vorteile wie Caching und verschiedene Schutzfunktionen; außerdem kann die Origin-IP sichtbar werden. Siehe die offizielle Dokumentation zum Proxy Status.

Nginx kann einige meiner Anforderungen übernehmen, etwa lokales Caching, Komprimierung, Request-Handling und einfache Filter. Es ersetzt aber nicht Cloudflares globales Netzwerk, verwaltete DDoS-Kapazität oder sämtliche Sicherheitsfunktionen. Die Migration war also ein Tausch: mehr direkte Kontrolle über den Auslieferungspfad gegen mehr eigene Betriebsverantwortung.

Für dieses Projekt war das sinnvoll, weil die Erreichbarkeit aus Russland das unmittelbare Problem war. Daraus folgt nicht, dass VDS + Nginx generell die sicherste Architektur ist.

Wie ich ein ähnliches Problem heute diagnostizieren würde

Wenn Traffic in einem Land oder einer Netzregion einbricht, würde ich nicht zuerst Titles oder Content umschreiben. Ich würde die Ebenen trennen:

  1. Lässt sich die Seite aus dem Zielmarkt und über mehr als einen ISP abrufen?
  2. Erhält der Client den vollständigen Response-Body und nicht nur HTTP 200?
  3. Ändert sich das Verhalten, wenn CDN oder Reverse Proxy kontrolliert umgangen werden?
  4. Wird die URL gecrawlt und indexiert?
  5. Erst wenn Erreichbarkeit feststeht: ändern sich Impressions, Klicks und Sessions?

Der praktische Punkt: Überwache aus dem Markt, der dir wichtig ist. Ein Test aus einem anderen Land kann zeigen, dass der Origin lebt, und trotzdem einen regionalen Verbindungsfehler komplett übersehen.

Was ich aus dem Fall mitnehme

Es begann wie ein SEO-Rätsel: 12.500 indexierte Seiten und fast kein russischer Traffic. Die nützliche Antwort lag tiefer im Stack.

Das Abschalten des Cloudflare-Proxys und der Wiederaufbau der nötigen Funktionen mit Nginx auf meinem VDS stellten den Zugriff aus Russland sofort wieder her. Diesen Befund kann ich vertreten. Nicht vertreten kann ich daraus einen bewiesenen Ranking-Effekt bei Google oder Yandex, einen exakt nachgewiesenen regulatorischen Sperrmechanismus oder die pauschale Regel, dass jeder Cloudflare verlassen sollte.

Meine Regel aus diesem Vorfall ist einfacher: Wenn ein Markt wichtig ist, muss die Erreichbarkeit aus genau diesem Markt gemessen werden. Indexzahlen beantworten nicht die Frage, ob ein realer Nutzer die Seite tatsächlich erhält.