私の SEO プロジェクトのひとつでは、Yandex に 12,500 ページがインデックスされていました。この数字だけを見れば、サイトは順調に見えます。ところが、ロシアからの実トラフィックはほぼゼロでした。
この大規模な SEO プロジェクトは、フロントエンド開発者として自分のスキルを磨く目的でも作っていました。
最初は SEO 側の問題を疑いました。しかし切り分けを進めると、もっと手前の問題に行き着きました。ネットワーク経路です。サイトは Cloudflare の背後にあり、ロシアから安定して到達できない状態になっていました。私は国外に住んでいたため、自分の作業環境からはその障害がほとんど見えませんでした。
この経験で、私はそれまで同じような指標として見ていた三つを明確に分けるようになりました。インデックス、到達性、トラフィックです。これらは別物です。検索結果に残っているページでも、特定のネットワーク上の実ユーザーが正常に読み込めないことはあります。
このケースで実際に確認できること
自分の経験として確認できる事実はシンプルです。私は Cloudflare の背後で大規模な SEO プロジェクトを運用していました。Yandex には 12,500 ページがインデックスされていましたが、ロシアからのトラフィックはほぼありませんでした。調査した結果、問題をネットワーク層まで絞り込みました。その後 Cloudflare のプロキシを完全に無効化し、必要だった機能、つまりキャッシュ、圧縮、基本的なセキュリティを 自分の VDS 上の Nginx に移しました。
この変更後、ロシアからのアクセスはすぐに戻りました。この事例から強く言えるのはここまでです。配信経路を変えたことで到達性が回復した、ということです。
逆に、このケースだけでは言えないこともあります。失われた訪問数の正確な値、影響を受けたロシアの全ネットワーク、移行後にオーガニックトラフィックが何％回復したか、といった数値はこの事例からは導けません。私が観測したのはアクセス不能に近い状態と、ほぼゼロのトラフィックであり、管理された SEO 実験ではありません。
公開情報は、私の最初の説明よりも正確だった
当初私は「Roskomnadzor が Cloudflare の特定 IP レンジをブロックした」と説明していました。しかし、現在確認できる証拠に対しては、この言い方は具体的すぎます。
Cloudflare は 2025 年 6 月 26 日に自社の調査結果を公開し、2025 年 6 月 9 日以降、ロシア国内から Cloudflare で保護されたサービスへ接続するユーザーが、ロシアの ISP による throttling の影響を受けていると説明しました。Cloudflare の内部分析では、影響を受けた接続で Web リソースの最初の 16 KB しか読み込めないケースがあり、多くのページで通常の閲覧が成立しない状態だったとしています。詳細は Cloudflare のロシア向け接続制限に関する報告で確認できます。
この説明は、私が見た障害の種類とはよく一致します。ただし、すべての ISP で同じ仕組みが使われたことや、私のトラフィック減少全体を Roskomnadzor に直接帰属できることまでは証明しません。より正確には、私のサイトでは Cloudflare プロキシ経由の配信経路がロシアから安定して利用できず、そのプロキシを迂回したところアクセスが回復した、というのが確認できる事実です。
12,500 ページのインデックスが「正常」を意味しなかった理由
ここが、私が最も過小評価していた考え方の違いです。12,500 ページがインデックスされているのを見て、サイト全体の到達性も問題ないと考えていました。しかし、検索エンジンのクロールとエンドユーザーの通信経路は別のものです。
検索エンジンは以前に URL をクロールしているかもしれません。ユーザーとは異なるネットワーク経路からアクセスしているかもしれません。また、一部のユーザーが完全なレスポンスを受け取れなくなっていても、URL がしばらくインデックスに残ることはあり得ます。したがって、インデックス済みであることは、特定のロシア ISP のユーザーが今日そのページを開けることの証明にはなりません。私のケースでは、Yandex に 12,500 ページが存在することと、ロシアの実トラフィックがほぼゼロであることが同時に成立していました。
インデックスは到達性ではありません。到達性はトラフィックではありません。
私が変更したこと
- Cloudflare のプロキシを完全に無効化しました。 HTTP/HTTPS トラフィックが私のインフラに届く前に Cloudflare を経由しない構成にしました。
- 必要な機能を Nginx に移しました。 自分の VDS 上で、キャッシュ、圧縮、基本的なセキュリティ制御を設定しました。
ここで重要なのは、Nginx が Cloudflare より「優れている」という話ではありません。私にとって重要な市場で問題になっていたネットワーク依存を一つ外した、ということです。
アクセスは戻ったが、運用責任も戻ってきた
reverse proxy を外せば無条件に得をするわけではありません。Cloudflare の現在のドキュメントでは、DNS-only にすると HTTP/HTTPS は Cloudflare のプロキシを通らず origin に直接向かうと説明されています。その結果、プロキシに依存するキャッシュや各種保護が前段から外れ、origin IP が見える可能性もあります。詳細は 公式の Proxy status ドキュメントにあります。
Nginx で、ローカルキャッシュ、圧縮、リクエスト処理、基本的なフィルタリングなど、私が必要としていた機能の一部は置き換えられます。しかし Cloudflare のグローバルネットワーク、マネージドな DDoS 対応能力、すべてのセキュリティ機能まで再現できるわけではありません。つまりこの移行は、配信経路を自分で直接コントロールできる代わりに、運用上の責任をより多く引き受ける選択でした。
このプロジェクトではロシアからのアクセスが目の前の問題だったため、そのトレードオフには価値がありました。ただし、VDS + Nginx が誰にとっても最も安全な構成だという意味ではありません。
同じ問題を今ならどう切り分けるか
特定の国やネットワーク地域だけでトラフィックが急落したなら、私は最初に title や本文を書き換えることはしません。まず層を分けて確認します。
- 対象国から、できれば複数の ISP 経由でページを取得できるか。
- HTTP 200 が返るだけでなく、クライアントが レスポンス本文全体を受信できているか。
- CDN や reverse proxy を制御されたテストで迂回したときに挙動が変わるか。
- URL はクロールされ、インデックスされているか。
- 到達性を確認した後で初めて、impression、click、session がどう変化しているかを見る。
実務上の教訓は単純です。重要な市場があるなら、その市場から計測する必要があります。他国からの監視で origin が生きていることを確認できても、地域限定の接続障害は見逃せます。
この経験から得た結論
最初は SEO の謎に見えました。12,500 ページがインデックスされているのに、ロシアからのトラフィックがほぼない。実際に役立った答えは、SEO より下のレイヤーにありました。
Cloudflare のプロキシを外し、VDS 上の Nginx に必要な機能を再構築すると、ロシアからのアクセスはすぐに戻りました。ここまでは事実として言えます。一方で、このケースを Google や Yandex のランキング影響の証明、規制当局による正確なブロック方式の証明、「全員 Cloudflare をやめるべきだ」という普遍的な結論にすることはできません。
私がこの件から得たルールはもっと単純です。重要な市場があるなら、その市場から到達性を測る。インデックス件数だけでは、実ユーザーがページを最後まで受け取れるかは分かりません。