Bij een van mijn SEO-projecten had Yandex 12.500 pagina’s geïndexeerd. Als ik alleen naar dat getal keek, leek de site gezond. Toch was het echte verkeer uit Rusland vrijwel nul.
Ik bouwde dit grootschalige SEO-project ook om mijn vaardigheden als frontend developer verder aan te scherpen.
Mijn eerste gedachte was SEO. Na troubleshooting vond ik echter een fundamenteler probleem: het netwerkpad. De site stond achter Cloudflare en was vanuit Rusland niet betrouwbaar bereikbaar. Omdat ik zelf buiten Rusland woonde, was de storing vanaf mijn werkplek bijna onzichtbaar.
Dit incident dwong me drie signalen uit elkaar te houden die makkelijk door elkaar worden gehaald: indexering, bereikbaarheid en verkeer. Ze zijn niet hetzelfde. Een pagina kan geïndexeerd blijven terwijl echte gebruikers op bepaalde netwerken haar niet kunnen laden.
Wat ik echt kan bevestigen
De feiten uit mijn eigen ervaring zijn eenvoudig. Ik draaide een groot SEO-project achter Cloudflare. Yandex had 12.500 pagina’s geïndexeerd, maar verkeer uit Rusland was bijna afwezig. Ik onderzocht het probleem en herleidde het tot de netwerklaag. Daarna schakelde ik de Cloudflare-proxy volledig uit en configureerde ik Nginx op mijn eigen VDS voor wat ik nog nodig had: caching, compressie en basisbeveiliging.
Na die wijziging kwam de toegang vanuit Rusland direct terug. Dat is de sterkste conclusie die ik uit deze case kan trekken: het wijzigen van het afleverpad herstelde de bereikbaarheid.
Minstens zo belangrijk is wat deze case niet bewijst. Ik kan er niet uit afleiden hoeveel bezoeken exact verloren gingen, welke Russische netwerken allemaal geraakt waren of hoeveel organisch verkeer later precies terugkwam. Mijn waarnemingen gingen over bereikbaarheid en bijna nul verkeer, niet over een gecontroleerd SEO-experiment.
De publieke informatie is preciezer dan mijn oorspronkelijke uitleg
Ik beschreef het aanvankelijk alsof Roskomnadzor specifieke Cloudflare-IP-ranges had geblokkeerd. Dat is specifieker dan de bewijzen die ik kan onderbouwen.
Cloudflare publiceerde op 26 juni 2025 een eigen verslag. Het bedrijf stelde dat gebruikers in Rusland sinds 9 juni 2025 bij toegang tot Cloudflare-beschermde diensten werden gethrottled door Russische ISP’s. Volgens de interne analyse van Cloudflare konden op getroffen verbindingen soms alleen de eerste 16 KB van een webresource worden geladen, waardoor normaal browsen op veel pagina’s onmogelijk wordt. Zie Cloudflares rapport over de Russische connectiviteitsbeperkingen.
Die beschrijving past bij het type storing dat ik zag, maar bewijst niet het exacte mechanisme bij elke ISP en laat mij niet mijn volledige verkeersdaling rechtstreeks aan Roskomnadzor toeschrijven. De zorgvuldige formulering is: het via Cloudflare geproxiede afleverpad van mijn site was vanuit Rusland niet betrouwbaar bruikbaar; het omzeilen van die proxy herstelde in mijn geval de toegang.
Waarom 12.500 geïndexeerde pagina’s niet betekenden dat de site gezond was
Dit was de conceptuele fout die ik onderschatte. Ik zag 12.500 pagina’s in de index en behandelde dat als algemeen bewijs van bereikbaarheid. Maar zoekmachinecrawling en de verbinding van een eindgebruiker zijn verschillende systemen.
Een zoekmachine kan een URL eerder hebben gecrawld, via een ander netwerkpad binnenkomen of de pagina geïndexeerd houden terwijl sommige gebruikers geen volledige response meer krijgen. Een geïndexeerde URL bewijst dus niet dat een gebruiker bij een bepaalde Russische ISP de pagina vandaag kan laden. In mijn geval waren beide feiten tegelijk waar: Yandex had 12.500 pagina’s geïndexeerd en Russisch gebruikersverkeer was bijna nul.
Indexering is geen bereikbaarheid. Bereikbaarheid is geen verkeer.
Wat ik veranderde
- Ik schakelde de Cloudflare-proxy volledig uit. HTTP/HTTPS-verkeer hoefde niet langer via Cloudflare voordat het mijn infrastructuur bereikte.
- Ik verplaatste de functies die ik nog nodig had naar Nginx. Op mijn VDS configureerde ik caching, compressie en basisbeveiliging zelf.
Het punt was niet dat Nginx “beter” is dan Cloudflare. Ik verwijderde een netwerkafhankelijkheid die een probleem was geworden voor een markt die voor mij belangrijk was.
De toegang kwam terug, maar de verantwoordelijkheid ook
Een reverse proxy omzeilen is geen gratis upgrade. De huidige Cloudflare-documentatie legt uit dat DNS-only gebruikers rechtstreeks naar de origin stuurt en HTTP/HTTPS niet meer via Cloudflare routeert. Daarmee verdwijnen proxy-afhankelijke voordelen zoals caching en verschillende beschermingslagen, en kan het origin-IP zichtbaar worden. Zie de officiële documentatie over Proxy status.
Nginx kan een deel van mijn behoeften afdekken: lokale caching, compressie, request handling en eenvoudige filtering. Het reproduceert niet automatisch Cloudflares wereldwijde netwerk, beheerde DDoS-capaciteit of alle securityfuncties. De migratie was dus een ruil: meer directe controle over het afleverpad tegen meer operationele verantwoordelijkheid.
Voor dit project was die ruil logisch omdat bereikbaarheid vanuit Rusland het directe probleem was. Daaruit volgt niet dat VDS + Nginx universeel de veiligste architectuur is.
Hoe ik een vergelijkbaar probleem nu zou diagnosticeren
Als verkeer in één land of netwerkregio instort, zou ik niet beginnen met titels of content herschrijven. Eerst zou ik de lagen scheiden:
- Kan de pagina vanuit het doelland en via meer dan één ISP worden opgehaald?
- Krijgt de client de volledige response body, en niet alleen HTTP 200?
- Verandert het gedrag als CDN of reverse proxy gecontroleerd wordt omzeild?
- Wordt de URL gecrawld en geïndexeerd?
- Pas nadat bereikbaarheid vaststaat: veranderen impressions, clicks en sessies?
De praktische les is meten vanuit de markt die ertoe doet. Een test uit een ander land kan laten zien dat je origin leeft en toch een regionale verbindingsstoring volledig missen.
Wat ik uit dit incident meeneem
Het begon als een SEO-mysterie: 12.500 geïndexeerde pagina’s en bijna geen Russisch verkeer. Het nuttige antwoord zat lager in de stack.
De Cloudflare-proxy verwijderen en de noodzakelijke functies met Nginx op mijn VDS opnieuw opbouwen herstelde de toegang vanuit Rusland onmiddellijk. Dat resultaat kan ik verdedigen. Wat ik niet kan verdedigen is een bewezen ranking-effect bij Google of Yandex, een exact regulatoir blokkademechanisme of de universele regel dat iedereen Cloudflare moet verlaten.
Mijn regel na deze case is eenvoudiger: als een markt belangrijk is, meet bereikbaarheid vanuit die markt. Een indexaantal vertelt niet of een echte gebruiker de pagina kan ontvangen.