Connecter WordPress à Cloudflare peut accélérer un site et filtrer une partie du trafic malveillant, à condition de coordonner correctement le DNS, le chiffrement et le cache. Les difficultés apparaissent surtout lorsque deux systèmes tentent de forcer HTTPS en même temps, qu’une page personnalisée est mise en cache ou que le serveur ne reconnaît plus l’adresse réelle du visiteur.
Pour illustrer les réglages, suivons la boutique fictive de Léa, qui utilise WooCommerce. Son objectif n’est pas de multiplier les optimisations, mais de faire fonctionner chaque couche avec les autres : Cloudflare reçoit les requêtes, WordPress génère les pages nécessaires et le serveur conserve un accès sécurisé.
En bref
- Faites pointer les enregistrements DNS du site vers le bon serveur et activez le proxy Cloudflare sur les noms d’hôte concernés.
- Choisissez le mode SSL/TLS Full (strict) avec un certificat SSL valide sur le serveur d’origine.
- Excluez l’administration, les comptes et les étapes de commande du cache public.
- Après chaque changement, vérifiez les redirections HTTPS, les en-têtes de cache et le parcours d’achat.
- Utilisez le plugin Cloudflare pour WordPress si vous activez APO et souhaitez automatiser la purge du cache.
Préparer la configuration DNS de WordPress avant d’activer le proxy
Cloudflare fonctionne comme un intermédiaire entre le navigateur et l’hébergement. Avant toute modification, vérifiez que le domaine est ajouté au tableau de bord Cloudflare et que les serveurs de noms fournis par le service sont configurés chez le registrar. La propagation peut prendre un certain temps ; évitez de modifier simultanément les DNS, les réglages du serveur et les URL WordPress, car il devient alors difficile d’identifier l’origine d’un incident.
Dans la zone DNS, contrôlez les enregistrements A ou AAAA correspondant au domaine principal et à « www ». Ils doivent viser l’adresse de l’hébergement, et le nuage orange indique que les requêtes web passent par le proxy Cloudflare. Ne proxifiez pas automatiquement les services qui ne sont pas compatibles avec ce fonctionnement, comme certains serveurs de messagerie. En cas de doute, conservez ces enregistrements en DNS uniquement.
Léa vérifie aussi que son site s’ouvre déjà correctement directement sur son hébergeur, avec une adresse canonique clairement définie. Si la boutique répond parfois avec et parfois sans « www », elle règle d’abord cette incohérence. Une fois le DNS stabilisé, elle peut tester la nouvelle route sans confondre une panne d’hébergement et un problème de proxy.
Pour distinguer cache WordPress et distribution des ressources par CDN, un guide sur la configuration d’un CDN pour accélérer les fichiers statiques apporte un complément utile. La règle pratique est simple : valider d’abord la résolution du domaine, puis activer les fonctions d’accélération.
Choisir le mode SSL/TLS et éviter les boucles de redirection HTTPS
Le réglage le plus sûr est généralement Full (strict), à condition que le serveur d’origine présente un certificat SSL valide, par exemple Let’s Encrypt ou un certificat d’origine Cloudflare. Le chiffrement doit ainsi rester actif entre le navigateur et Cloudflare, mais aussi entre Cloudflare et l’hébergement. Le mode Flexible est à éviter lorsque WordPress redirige déjà les visiteurs vers HTTPS : le serveur peut recevoir une requête en HTTP et la renvoyer vers HTTPS en boucle.
Vérifiez ensuite que les adresses du site dans WordPress, sous Réglages puis Général, utilisent bien HTTPS. Les redirections doivent être cohérentes et ne pas être imposées indépendamment par plusieurs extensions, le serveur et Cloudflare. Activez « Always Use HTTPS » seulement après avoir confirmé que le certificat et l’accès sécurisé fonctionnent de bout en bout. HSTS, qui indique aux navigateurs de toujours utiliser HTTPS, vient plus tard : une configuration prématurée peut rendre un site difficile d’accès pendant la correction.
Si une boucle apparaît, désactivez temporairement la règle récemment ajoutée et comparez le mode SSL/TLS, l’URL WordPress et les directives de redirection du serveur. Le guide pour corriger l’erreur de redirections trop nombreuses aide à isoler les causes sans empiler de nouvelles règles. Une seule couche doit décider de la redirection canonique, ou les différentes couches doivent être réglées pour se reconnaître.
Enfin, si le serveur journalise uniquement les adresses IP de Cloudflare, configurez la prise en compte de l’en-tête d’IP réelle avec les plages officielles des proxys. Cette opération est importante pour l’analyse des visites et les règles de sécurité, mais elle doit faire confiance uniquement aux plages Cloudflare, jamais à une valeur d’en-tête provenant arbitrairement d’un visiteur.
Régler le cache Cloudflare sans exposer l’administration ni WooCommerce
Le cache améliore les temps de réponse en conservant des ressources à proximité des visiteurs, mais toutes les pages WordPress ne sont pas équivalentes. Les images, feuilles de style et fichiers JavaScript se prêtent généralement bien à une durée de cache longue, ajustée à la fréquence de mise à jour. À l’inverse, une page contenant un compte connecté, un panier ou une commande doit rester personnalisée.
Créez des règles de contournement pour /wp-admin/, /wp-login.php, les prévisualisations et les pages WooCommerce telles que le panier, la commande et le compte client. Les cookies de connexion et de panier sont également des signaux à respecter. Une boutique peut mettre en cache sa page d’accueil ou ses catégories publiques, mais doit vérifier que les extensions de tarification par rôle, de langue ou de géolocalisation ne personnalisent pas ces pages au moyen de cookies ignorés par la règle.
APO, l’option Automatic Platform Optimization, peut distribuer le HTML public de WordPress sur le réseau périphérique de Cloudflare. Le plugin WordPress officiel est utile pour déclencher une purge du cache lors de la publication ou de la modification d’un article. Les gains dépendent du thème, de l’hébergement, de la localisation des visiteurs et du taux de pages réellement cachables : un TTFB très faible n’est pas garanti sur toutes les requêtes.
| Élément | Réglage à privilégier | Vérification |
|---|---|---|
| Fichiers statiques | Cache adapté à leur cycle de mise à jour | Tester une image ou une feuille CSS |
| Administration et connexion | Contournement du cache | Ouvrir l’admin après connexion |
| Panier et commande | Contournement et respect des cookies | Ajouter un produit et finaliser un test |
| HTML public avec APO | Activation accompagnée du plugin officiel | Contrôler la purge après modification |
Après un changement de contenu, préférez la purge ciblée quand elle est disponible. Une purge globale peut être nécessaire lors d’une refonte ou d’une erreur généralisée, mais répétée trop souvent, elle oblige le serveur d’origine à régénérer de nombreuses pages. Pour diagnostiquer un contenu ancien ou un cache qui semble inactif, consultez ces conseils pour vider les différents caches après une modification.
Renforcer la sécurité et tester les performances après activation
Le proxy Cloudflare peut absorber une partie du trafic indésirable avant qu’il atteigne WordPress. Il ne remplace toutefois ni les mises à jour, ni les sauvegardes, ni une politique d’accès solide. Selon le plan choisi, activez les règles WAF disponibles et configurez prudemment les protections contre les tentatives répétées sur la page de connexion. Une règle qui bloque un pays entier ou un outil automatisé peut aussi empêcher un client, un prestataire ou un service légitime d’accéder au site.
Pour les visiteurs ordinaires, testez le site dans une fenêtre privée et depuis un appareil mobile. Vérifiez la page d’accueil, une page de contenu, le formulaire de contact et, pour WooCommerce, le parcours complet jusqu’à l’étape de paiement sans réaliser de transaction réelle. Si l’administration ou des scripts cessent de fonctionner, désactivez d’abord les optimisations susceptibles de modifier l’ordre d’exécution, comme Rocket Loader, puis réactivez-les une à une.
Les en-têtes HTTP fournissent des indices précieux. Avec un outil de requête, examinez notamment CF-Cache-Status et Cache-Control : HIT indique qu’une réponse a été servie depuis le cache, tandis que BYPASS peut être normal pour une page personnalisée. Un MISS isolé ne signifie pas forcément une erreur ; répétez la requête et vérifiez les cookies et les en-têtes renvoyés par l’origine.
Mesurez avant et après avec les mêmes URL et dans des conditions comparables. Le TTFB peut diminuer si une page publique est servie depuis un point de présence proche, mais le cache ne corrige pas une image trop lourde, un décalage de mise en page ou un script bloquant. Une configuration réussie combine donc un cache cohérent, des ressources optimisées et un HTTPS sans redirection contradictoire.
Pour une vérification globale, examinez aussi les réponses en navigation connectée et déconnectée : elles ne doivent pas être identiques lorsque le contenu dépend du compte ou du panier.
Diagnostiquer les problèmes de cache et de HTTPS sur WordPress
Quand un visiteur voit une ancienne version d’une page, commencez par identifier les couches de cache actives : plugin WordPress, hébergeur, Cloudflare et navigateur. Purgez uniquement la couche concernée lorsque c’est possible, puis rechargez la page dans une fenêtre privée. Si le problème revient après chaque publication, contrôlez la connexion API du plugin Cloudflare et ses permissions de purge plutôt que de vider systématiquement tout le domaine.
Si le cache ne prend jamais, cherchez un en-tête Set-Cookie inattendu ou un Cache-Control: no-store sur une page publique. Certaines extensions ajoutent des cookies même aux visiteurs non connectés, ce qui peut empêcher la mise en cache. Le diagnostic décrit dans cet article sur la vérification d’un cache WordPress qui ne fonctionne pas permet de remonter à la règle responsable.
Pour les problèmes HTTPS, comparez la réponse obtenue avec et sans redirection, puis contrôlez le certificat à l’origine et le mode SSL/TLS choisi dans Cloudflare. Une seule redirection vers la version canonique du domaine suffit généralement. Si une règle de cache vient d’être modifiée, le mode développement de Cloudflare peut faciliter les tests temporaires ; désactivez-le après intervention pour ne pas laisser le site sans ses optimisations habituelles.
Le fil conducteur reste celui de la boutique de Léa : une modification à la fois, un test précis, puis une vérification depuis un visiteur non connecté. Cette méthode réduit le risque qu’une optimisation destinée à accélérer le site perturbe la connexion, le panier ou la commande.
Quel mode SSL/TLS choisir pour connecter Cloudflare à WordPress ?
Choisissez généralement Full (strict), avec un certificat SSL valide sur le serveur d’origine. Vérifiez que WordPress utilise HTTPS et évitez les règles de redirection contradictoires.
Comment empêcher Cloudflare de mettre en cache l’administration WordPress ?
Configurez un contournement du cache pour /wp-admin/, /wp-login.php, les prévisualisations et les pages personnalisées. Vérifiez également les cookies de connexion et de session.
APO est-il indispensable pour accélérer WordPress ?
Non. APO peut améliorer la distribution du HTML public depuis le réseau Cloudflare, mais son intérêt dépend du trafic, de l’hébergement et de la part de pages pouvant être mises en cache.
Que faire si une ancienne version de page reste affichée ?
Vérifiez les caches du plugin, de l’hébergeur et de Cloudflare, puis déclenchez une purge ciblée. Si le souci persiste après une publication, contrôlez les permissions API du plugin Cloudflare officiel.