Yandex had indexed 12,500 pages on one of my SEO projects. From that number alone, the site looked healthy. But real traffic from Russia was almost zero.
I was building this large-scale SEO project to sharpen my skills as a frontend developer.
My first instinct was to think in SEO terms. After troubleshooting, however, I found a more basic problem: the network path. The site was behind Cloudflare, and users in Russia could not reliably reach it. I was living abroad, so the problem was largely invisible from where I was working.
This incident forced me to separate three things I had been treating as if they were the same signal: indexing, reachability, and traffic. They are not the same. A page can be indexed while real users on particular networks still cannot load it.
What I can actually confirm
The first-hand facts are straightforward. I was running a large SEO project behind Cloudflare. Yandex had indexed 12,500 pages, but traffic from Russia was close to zero. I investigated and narrowed the problem to the network layer. I then disabled Cloudflare’s proxy and configured Nginx on my own VDS to handle the parts I still needed: caching, compression, and basic security.
After that change, access from Russia returned immediately. That is the strongest result I can claim from this incident: changing the delivery path restored reachability.
What I should not claim is equally important. This case alone does not tell me exactly how many visits were lost, which Russian networks were affected, or by how much organic traffic later recovered. The original evidence was about accessibility and the near-zero traffic I observed, not a controlled SEO experiment.
The public evidence is more precise than my original explanation
I originally described the incident as Roskomnadzor blocking specific Cloudflare IP ranges. That wording is too specific for the evidence I can support.
Cloudflare published its own account on June 26, 2025, saying that since June 9, 2025, users in Russia connecting to Cloudflare-protected services had been throttled by Russian ISPs. Cloudflare said its internal analysis indicated that in affected connections only the first 16 KB of a web asset could load, which would make normal browsing fail for many pages. You can read Cloudflare’s report on the Russian connectivity restrictions.
That public description is consistent with the kind of failure I saw, but it still does not prove the exact enforcement mechanism for every ISP or let me attribute my individual traffic drop directly to Roskomnadzor. The safer statement is: my site’s Cloudflare-proxied delivery path was not reliably usable from Russia, and bypassing that proxy restored access in my case.
Why 12,500 indexed pages did not mean the site was healthy
This was the conceptual mistake I underestimated. I saw 12,500 indexed pages and treated that as broad evidence that the site was accessible. But search crawling and end-user connectivity are separate systems.
A search engine may have crawled a URL earlier, may reach it through a different network path, and may keep it indexed even while some users cannot fetch the full response. An indexed URL therefore does not prove that a user on a particular Russian ISP can load the page today. In my case, both facts were true at once: Yandex had indexed 12,500 pages, and Russian user traffic was still almost nonexistent.
Indexing is not reachability. Reachability is not traffic.
What I changed
- I disabled Cloudflare’s proxy. HTTP and HTTPS traffic no longer had to pass through Cloudflare before reaching my infrastructure.
- I moved the responsibilities I still needed to Nginx. On my VDS I configured caching, compression, and basic security controls myself.
The important part was not that Nginx is somehow “better” than Cloudflare. It was that I removed a network dependency that had become a problem for a market that mattered to me.
The fix restored access, but it also moved responsibility back to me
Bypassing a reverse proxy is not a free upgrade. Cloudflare’s current documentation explains that a DNS-only record sends users to the origin instead of routing HTTP/HTTPS traffic through Cloudflare. That means proxy-based benefits such as caching and several security protections no longer sit in front of the origin. Cloudflare also warns that bypassing the proxy can expose the origin IP. See the official proxy-status documentation.
Nginx can cover some of the functions I needed, especially local caching, compression, request handling, and basic filtering. It does not magically reproduce Cloudflare’s global network, managed DDoS capacity, or every security feature. My migration therefore traded convenience and some managed protection for direct control over the delivery path.
For this project, that trade was worth making because access from Russia was the immediate problem. That does not make VDS + Nginx the universally safest architecture.
How I would diagnose a similar problem now
If traffic collapses in one country or network region, I would not start by rewriting titles or changing content. I would first separate the failure into layers:
- Can the page be fetched from the target country and from more than one ISP?
- Does the client receive the full response body, not merely an HTTP 200 status?
- Does the behavior change when the CDN or reverse proxy is bypassed in a controlled test?
- Is the URL crawled and indexed?
- Only after reachability is confirmed: are impressions, clicks, and sessions actually changing?
The lesson is practical: monitor from the market you care about. Testing from another country can tell you that your origin is alive while completely missing a regional connectivity failure.
What I take from this incident
I started with what looked like an SEO mystery: 12,500 indexed pages and almost no Russian traffic. The useful answer was lower in the stack.
Removing Cloudflare’s proxy and rebuilding the essentials with Nginx on my VDS restored Russian access immediately. What I can defend is that result. What I cannot defend is a stronger story about a proven Google- or Yandex-ranking effect, a precise regulator-level blocking mechanism, or a universal rule that everyone should abandon Cloudflare.
My rule now is simpler: if a market matters, measure reachability from that market. Search-console numbers and index counts cannot tell you whether a real user can receive the page.