SEO WordPress : auditer Cloudflare et robots.txt après l’alerte

Audit prioritaire : vérifications rapides et indicateurs à analyser

1. Vérifier l’accès Googlebot et les autres bots légitimes

Commencez par simuler des requêtes avec l’User‑Agent Googlebot et observez les codes HTTP. Pour des pages publiques, un code 200 est attendu ; les redirections 3xx sont acceptables si elles conservent le signal canonique. Notez toute URL qui renvoie 4xx ou des challenges inattendus. Contrôlez ensuite dans Cloudflare les éléments de Bot Management et les règles de Firewall susceptibles d’appliquer une action block ou challenge en fonction du user‑agent, du score ou d’une signature.

2. Contrôler robots.txt et règles spécifiques AMP

Ouvrez /robots.txt et vérifiez l’absence d’un Disallow générique qui bloquerait la racine ou les variantes AMP comme /amp, /?amp ou /amp/. Assurez‑vous que les ressources nécessaires au rendu (CSS, JS, images) ne sont pas empêchées par des règles trop larges. Si vous servez encore des pages AMP ou des redirections vers AMP, robots.txt doit autoriser ces chemins et les ressources associées pour que le rendu côté moteur soit complet.

3. Passer en revue les règles de pare‑feu et les Workers

Listez les règles actives dans Cloudflare et identifiez celles qui ciblent user‑agent, pays, rate‑limit ou chemins spécifiques. Priorisez l’audit des règles appliquées au nom de domaine et des Workers qui interceptent des requêtes vers /wp‑ ou /amp. Recherchez des conditions combinées, par exemple IP range + UA, qui peuvent provoquer des faux positifs contre Googlebot selon l’IP publique ou la forme de l’UA.

4. Collecter les signes côté moteur et côté site

Consultez Google Search Console pour recenser les erreurs d’exploration, d’indexation et les messages de crawl. Dans Cloudflare Analytics et les logs WordPress ou plugin de logs, identifiez les blocages, challenges CAPTCHA ou timeouts. Croisez les timestamps et les URLs pour relier un blocage Cloudflare à une erreur remontée par Search Console.

5. Tests complémentaires à lancer

Utilisez l’inspection d’URL dans Search Console pour vérifier le rendu et l’accès réels. Lancez des tests curl simulant Googlebot et, si possible, testez depuis plusieurs régions IP pour détecter un filtrage géographique. Priorisez les corrections sur les règles les plus restrictives et documentez chaque modification afin de pouvoir revenir en arrière rapidement.

Agrandir

Démarrage rapide : actions immédiates à exécuter

En 10 minutes, réalisez les vérifications critiques suivantes : sauvegardez votre robots.txt, vérifiez l’absence de "Disallow: /" et d’interdiction sur /amp ou /?amp, affichez les règles de pare‑feu dans Cloudflare et désactivez temporairement toute règle récente suspecte, basculez les règles Bot ou Challenge en mode observation si disponible, lancez une inspection d’URL pour quelques pages clés dans Google Search Console, exécutez une requête curl avec l’User‑Agent Googlebot pour noter le code HTTP retourné, contrôlez les redirections 301/302 et l’en‑tête rel=canonical, vérifiez la configuration de votre plugin AMP pour qu’il n’impose pas de blocage dans robots.txt, activez une journalisation détaillée côté WordPress pour capturer 403/401 et documentez chaque action en planifiant une surveillance sur 48 à 72 heures pour observer l’impact.

Procédure complète : étapes pour corriger et sécuriser sans risque

Étape A - Préparer un environnement sûr

Avant toute modification, exportez la configuration Cloudflare, y compris les règles et Workers, et réalisez une sauvegarde complète du site WordPress (fichiers et base). Notez les valeurs initiales et créez des points de restauration pour Cloudflare et pour votre hébergement afin de pouvoir revenir en arrière rapidement en cas d’effet indésirable.

Étape B - Collecte d’éléments et diagnostic

Exportez les logs Cloudflare et filtrez les sessions qui montrent des blocages pendant les périodes concernées. Sur le serveur, recherchez les réponses 4xx/5xx et identifiez les origines par user‑agent et IP. Dans Search Console, listez les URLs non indexées et les erreurs d’exploration, puis classez-les par gravité et par trafic pour prioriser les corrections.

Étape C - Ajuster robots.txt et en‑têtes

Éditez robots.txt en privilégiant l’autorisation explicite des chemins nécessaires au rendu et à l’indexation, par exemple en autorisant les répertoires de ressources utiles. Évitez les règles génériques. Vérifiez aussi les en‑têtes HTTP pour s’assurer qu’aucune page clé n’envoie "X‑Robots‑Tag: noindex" ou une instruction équivalente de blocage involontaire.

Étape D - Corriger les règles Cloudflare de façon progressive

Mettez d’abord chaque règle problématique en mode observation ou warning avant toute suppression. Pour les règles ciblant des user‑agents, évitez les correspondances strictes d’UA et préférez des contrôles basés sur Bot Management ou des vérifications d’IP connues. Pour les Workers, identifiez les routes interceptées et ajoutez, si nécessaire, une liste blanche pour les user‑agents ou les adresses IP reconnues des crawlers.

Étape E - Valider les corrections et surveiller

Après modification, re‑testez avec curl et l’inspection d’URL et attendez la propagation des changements sur Cloudflare. Surveillez Search Console et Cloudflare Analytics pendant plusieurs jours pour détecter toute rechute. Si l’arrêt du cache AMP affecte des pages, documentez les URLs impactées et planifiez des mises à jour des balises canoniques et des redirections pour limiter la perte de trafic organique.

Étape F - Gouvernance et prévention

Standardisez une procédure d’audit à exécuter après tout changement de configuration Cloudflare. Restreignez les droits de modification aux personnes identifiées et conservez un historique des modifications. Programmez des revues trimestrielles de robots.txt et des règles de sécurité pour anticiper les effets des évolutions des crawlers et des politiques d’indexation.

Conclusion : priorités opérationnelles et suivi

Après l’alerte Cloudflare et la fin du cache AMP, priorisez l’accès des moteurs : vérifiez robots.txt, testez l’accès Googlebot et placez les règles suspectes en mode observation avant de les supprimer. Agissez par étapes : sauvegarde, collecte de logs, correctifs ciblés, validation et surveillance. Documentez chaque changement et mettez en place une gouvernance stricte des modifications Cloudflare et des revues régulières des chemins AMP et des balises canoniques. Ces démarches rétablissent l’accès des crawlers sans compromettre la sécurité ni la performance de votre site WordPress.