Sur l’un de mes projets SEO, Yandex avait indexé 12 500 pages. Si je regardais uniquement ce chiffre, le site semblait en bonne santé. Pourtant, le trafic réel venant de Russie était presque nul.
Je construisais aussi ce projet SEO d’envergure pour continuer à développer mes compétences de développeur frontend.
Mon premier réflexe a été de chercher du côté du SEO. Après investigation, j’ai trouvé un problème plus fondamental : le chemin réseau. Le site se trouvait derrière Cloudflare et n’était pas accessible de manière fiable depuis la Russie. Comme je vivais à l’étranger, la panne était presque invisible depuis mon propre environnement.
Cet incident m’a obligé à distinguer trois signaux que l’on confond facilement : indexation, accessibilité et trafic. Ce ne sont pas les mêmes choses. Une page peut rester dans l’index alors que des utilisateurs réels sur certains réseaux ne peuvent plus la charger correctement.
Ce que je peux réellement confirmer
Les faits observés de mon côté sont simples. J’exploitais un gros projet SEO derrière Cloudflare. Yandex avait indexé 12 500 pages, mais le trafic russe était presque nul. J’ai enquêté et ramené le problème à la couche réseau. J’ai ensuite désactivé complètement le proxy Cloudflare et configuré Nginx sur mon propre VDS pour assurer ce dont j’avais encore besoin : cache, compression et sécurité de base.
Après ce changement, l’accès depuis la Russie est revenu immédiatement. C’est la conclusion la plus forte que je puisse soutenir : modifier le chemin de livraison a rétabli l’accessibilité.
Il est tout aussi important de dire ce que ce cas ne prouve pas. Il ne me permet pas de donner le nombre exact de visites perdues, de dresser la liste de tous les réseaux russes touchés ni de mesurer une reprise précise du trafic organique. Mes observations portaient sur l’accessibilité et un trafic presque nul, pas sur une expérience SEO contrôlée.
Les éléments publics sont plus précis que mon explication initiale
Au départ, j’avais décrit le problème comme un blocage de certaines plages IP Cloudflare par Roskomnadzor. Cette formulation est trop précise par rapport aux preuves que je peux réellement étayer.
Le 26 juin 2025, Cloudflare a publié son propre compte rendu. L’entreprise indiquait que depuis le 9 juin 2025, les utilisateurs en Russie accédant à des services protégés par Cloudflare subissaient du throttling de la part de FAI russes. Selon son analyse interne, sur certaines connexions affectées seuls les premiers 16 KB d’une ressource web pouvaient être chargés, ce qui suffit à casser la navigation normale sur de nombreuses pages. Voir le rapport de Cloudflare sur les restrictions de connectivité en Russie.
Cette description correspond bien au type de panne que j’ai constaté. Elle ne prouve toutefois ni le mécanisme exact chez chaque FAI ni que la totalité de ma chute de trafic puisse être attribuée directement à Roskomnadzor. La formulation la plus rigoureuse est donc : le chemin de livraison de mon site via le proxy Cloudflare n’était pas fiable depuis la Russie, et contourner ce proxy a rétabli l’accès dans mon cas.
Pourquoi 12 500 pages indexées ne signifiaient pas que le site fonctionnait correctement
C’est la distinction conceptuelle que j’avais sous-estimée. Je voyais 12 500 pages dans l’index et je prenais cela pour un signal général d’accessibilité. Mais le crawl d’un moteur de recherche et la connexion d’un utilisateur final sont deux systèmes différents.
Un moteur peut avoir crawlé une URL plus tôt, l’atteindre par un autre chemin réseau ou la conserver dans son index alors que certains utilisateurs ne reçoivent plus la réponse complète. Une URL indexée ne prouve donc pas qu’un utilisateur chez un FAI russe donné puisse l’ouvrir aujourd’hui. Dans mon cas, les deux réalités coexistaient : 12 500 pages étaient indexées dans Yandex et le trafic utilisateur russe restait presque inexistant.
Indexation n’est pas accessibilité. Accessibilité n’est pas trafic.
Ce que j’ai changé
- J’ai désactivé complètement le proxy Cloudflare. Le trafic HTTP/HTTPS n’avait plus à passer par Cloudflare avant d’atteindre mon infrastructure.
- J’ai déplacé les fonctions nécessaires vers Nginx. Sur mon VDS, j’ai configuré moi-même le cache, la compression et des contrôles de sécurité de base.
L’idée n’était pas que Nginx soit intrinsèquement « meilleur » que Cloudflare. J’ai supprimé une dépendance réseau devenue problématique pour un marché important pour moi.
L’accès est revenu, mais la responsabilité aussi
Contourner un reverse proxy n’est pas une amélioration gratuite. La documentation actuelle de Cloudflare précise qu’un enregistrement DNS-only dirige l’utilisateur vers l’origine et que le trafic HTTP/HTTPS ne passe plus par Cloudflare. Les avantages dépendants du proxy, comme le cache et plusieurs protections, disparaissent alors, et l’adresse IP d’origine peut être exposée. Voir la documentation officielle sur le Proxy status.
Nginx peut assurer une partie de ce dont j’avais besoin : cache local, compression, traitement des requêtes et filtrage simple. Il ne reproduit pas automatiquement le réseau mondial de Cloudflare, sa capacité DDoS gérée ni toutes ses fonctions de sécurité. La migration était donc un compromis : davantage de contrôle direct sur le chemin de livraison, mais davantage de responsabilité opérationnelle.
Pour ce projet, le compromis était acceptable parce que l’accès depuis la Russie était le problème immédiat. Cela ne signifie pas que VDS + Nginx soit universellement l’architecture la plus sûre.
Comment je diagnostiquerais aujourd’hui un problème similaire
Si le trafic s’effondre dans un pays ou une région réseau, je ne commencerais pas par réécrire les titres ou le contenu. Je séparerais d’abord les couches :
- La page est-elle accessible depuis le pays cible et via plusieurs FAI ?
- Le client reçoit-il le corps complet de la réponse, pas seulement un HTTP 200 ?
- Le comportement change-t-il lorsqu’on contourne temporairement le CDN ou le reverse proxy dans un test contrôlé ?
- L’URL est-elle crawlée et indexée ?
- Seulement après confirmation de l’accessibilité : les impressions, clics et sessions évoluent-ils ?
La leçon pratique est simple : il faut mesurer depuis le marché qui compte. Un test effectué depuis un autre pays peut confirmer que l’origine fonctionne tout en manquant complètement une panne régionale.
Ce que je retiens de cet incident
Au départ, cela ressemblait à une énigme SEO : 12 500 pages indexées et presque aucun trafic russe. La réponse utile se trouvait plus bas dans la pile.
Désactiver le proxy Cloudflare et reconstruire l’essentiel avec Nginx sur mon VDS a immédiatement rétabli l’accès depuis la Russie. Ce résultat, je peux le défendre. En revanche, je ne peux pas en déduire un effet prouvé sur le ranking Google ou Yandex, un mécanisme réglementaire précis ou une règle universelle selon laquelle tout le monde devrait quitter Cloudflare.
Ma règle après ce cas est plus simple : si un marché est important, mesurez l’accessibilité depuis ce marché. Le nombre de pages indexées ne répond pas à la question de savoir si un vrai utilisateur peut recevoir la page.