W jednym z moich projektów SEO Yandex miał zaindeksowane 12 500 stron. Patrząc tylko na tę liczbę, witryna wyglądała zdrowo. Mimo to realny ruch z Rosji był prawie zerowy.
Budowałem ten duży projekt SEO również po to, by dalej rozwijać swoje umiejętności jako frontend developer.
Pierwsza myśl była oczywiście związana z SEO. Po diagnozie okazało się jednak, że problem leżał niżej: w ścieżce sieciowej. Strona działała za Cloudflare i z Rosji nie była osiągalna w sposób niezawodny. Ponieważ mieszkałem poza Rosją, z mojego miejsca pracy awaria była prawie niewidoczna.
Ten przypadek zmusił mnie do rozdzielenia trzech sygnałów, które łatwo pomylić: indeksowania, dostępności i ruchu. To nie jest to samo. Strona może pozostawać w indeksie, gdy prawdziwi użytkownicy w części sieci nie są w stanie jej załadować.
Co naprawdę mogę potwierdzić
Fakty z mojego doświadczenia są proste. Prowadziłem duży projekt SEO za Cloudflare. Yandex miał 12 500 zaindeksowanych stron, ale ruch z Rosji był niemal zerowy. Zbadałem problem i zawęziłem go do warstwy sieciowej. Następnie całkowicie wyłączyłem proxy Cloudflare i skonfigurowałem Nginx na własnym VDS, aby przejął potrzebne mi funkcje: cache, kompresję i podstawowe zabezpieczenia.
Po tej zmianie dostęp z Rosji wrócił natychmiast. To najmocniejszy wniosek, jaki mogę uczciwie wyciągnąć z tego przypadku: zmiana ścieżki dostarczania przywróciła osiągalność.
Równie ważne jest to, czego ten przypadek nie dowodzi. Nie daje mi dokładnej liczby utraconych wizyt, listy wszystkich dotkniętych rosyjskich sieci ani miary późniejszego wzrostu ruchu organicznego. Moje obserwacje dotyczyły dostępności i prawie zerowego ruchu, a nie kontrolowanego eksperymentu SEO.
Publiczne dane są dokładniejsze niż moje pierwotne wyjaśnienie
Początkowo opisywałem sytuację tak, jakby Roskomnadzor zablokował konkretne zakresy IP Cloudflare. To zbyt precyzyjne stwierdzenie w stosunku do dowodów, które mogę poprzeć.
26 czerwca 2025 roku Cloudflare opublikował własny opis sytuacji. Firma podała, że od 9 czerwca 2025 roku użytkownicy w Rosji próbujący korzystać z usług chronionych przez Cloudflare byli throttlowani przez rosyjskich ISP. Według wewnętrznej analizy Cloudflare na dotkniętych połączeniach mogło ładować się tylko pierwsze 16 KB zasobu webowego, co uniemożliwia normalne przeglądanie wielu stron. Szczegóły są w raporcie Cloudflare o ograniczeniach łączności w Rosji.
Opis pasuje do rodzaju awarii, który obserwowałem, ale nie dowodzi dokładnego mechanizmu u każdego ISP i nie pozwala mi bezpośrednio przypisać całego spadku ruchu Roskomnadzorowi. Ostrożniejsze zdanie brzmi: ścieżka dostarczania mojej strony przez proxy Cloudflare nie działała z Rosji niezawodnie, a jej ominięcie przywróciło dostęp w moim przypadku.
Dlaczego 12 500 zaindeksowanych stron nie oznaczało, że witryna działa poprawnie
To był błąd koncepcyjny, którego znaczenie niedoceniłem. Widząc 12 500 stron w indeksie, traktowałem to jako ogólny sygnał dostępności. Crawling wyszukiwarki i połączenie użytkownika końcowego to jednak różne systemy.
Wyszukiwarka mogła odwiedzić URL wcześniej, korzystać z innej ścieżki sieciowej albo nadal trzymać stronę w indeksie, mimo że część użytkowników nie otrzymuje pełnej odpowiedzi. Zaindeksowany URL nie dowodzi więc, że użytkownik konkretnego rosyjskiego ISP otworzy stronę dzisiaj. W moim przypadku oba fakty były prawdziwe jednocześnie: Yandex miał 12 500 stron w indeksie, a ruch użytkowników z Rosji był niemal zerowy.
Indeksowanie to nie dostępność. Dostępność to nie ruch.
Co zmieniłem
- Całkowicie wyłączyłem proxy Cloudflare. Ruch HTTP/HTTPS nie musiał już przechodzić przez Cloudflare przed dotarciem do mojej infrastruktury.
- Przeniosłem potrzebne funkcje do Nginx. Na własnym VDS skonfigurowałem cache, kompresję i podstawowe mechanizmy ochronne.
Nie chodziło o to, że Nginx jest z definicji „lepszy” od Cloudflare. Usunąłem zależność sieciową, która stała się problemem na ważnym dla mnie rynku.
Dostęp wrócił, ale odpowiedzialność też
Ominięcie reverse proxy nie jest darmowym ulepszeniem. Aktualna dokumentacja Cloudflare wyjaśnia, że rekord DNS-only kieruje użytkownika do originu i ruch HTTP/HTTPS przestaje przechodzić przez Cloudflare. Znika więc część korzyści zależnych od proxy, takich jak cache i różne zabezpieczenia, a adres IP originu może zostać ujawniony. Zobacz oficjalną dokumentację Proxy status.
Nginx może przejąć część moich potrzeb: lokalny cache, kompresję, obsługę żądań i podstawowe filtrowanie. Nie odtwarza automatycznie globalnej sieci Cloudflare, zarządzanej ochrony DDoS ani wszystkich funkcji bezpieczeństwa. Migracja była więc wymianą: więcej bezpośredniej kontroli nad dostarczaniem w zamian za większą odpowiedzialność operacyjną.
W tym projekcie było warto, bo bezpośrednim problemem była dostępność z Rosji. Nie oznacza to, że VDS + Nginx jest zawsze najbezpieczniejszą architekturą.
Jak diagnozowałbym podobny problem dzisiaj
Gdy ruch spada w jednym kraju lub regionie sieciowym, nie zaczynałbym od przepisywania tytułów i treści. Najpierw rozdzieliłbym warstwy:
- Czy stronę da się pobrać z rynku docelowego i przez więcej niż jednego ISP?
- Czy klient dostaje pełne body odpowiedzi, a nie tylko HTTP 200?
- Czy zachowanie zmienia się po kontrolowanym ominięciu CDN lub reverse proxy?
- Czy URL jest crawlowany i indeksowany?
- Dopiero po potwierdzeniu dostępności: czy zmieniają się wyświetlenia, kliknięcia i sesje?
Praktyczna lekcja: mierz z rynku, który ma znaczenie. Test z innego kraju może potwierdzić, że origin działa, a jednocześnie całkowicie przeoczyć regionalną awarię łączności.
Co wyniosłem z tego przypadku
Zaczęło się jak zagadka SEO: 12 500 stron w indeksie i prawie brak rosyjskiego ruchu. Użyteczna odpowiedź była niżej w stosie.
Wyłączenie proxy Cloudflare i odtworzenie potrzebnego minimum w Nginx na moim VDS natychmiast przywróciło dostęp z Rosji. Tego wyniku mogę bronić. Nie mogę natomiast zrobić z niego dowodu na wpływ na ranking Google lub Yandex, dokładny mechanizm blokady regulacyjnej ani uniwersalną regułę, że każdy powinien zrezygnować z Cloudflare.
Moja zasada po tym przypadku jest prostsza: jeśli rynek jest ważny, mierz dostępność właśnie z tego rynku. Liczba stron w indeksie nie odpowiada na pytanie, czy prawdziwy użytkownik może odebrać stronę.