Cloudflare et WordPress : gérer plusieurs sites (multi-domaines) comme un pro (2025)

1. Pourquoi utiliser Cloudflare sur plusieurs sites WordPress ?

Cloudflare est souvent présenté comme un simple CDN gratuit, mais en réalité, c’est une plateforme de sécurité et de performance pour vos sites :

• Il sert vos assets (CSS, JS, images) depuis un réseau mondial.
• Il fournit un WAF puissant pour bloquer de nombreuses attaques.
• Il permet d’activer HTTP/2 / HTTP/3, Brotli, Early Hints, etc.
• Il protège contre certains DDoS et bots agressifs.
• Il peut filtrer, rediriger, transformer les requêtes en bordure de réseau.

Sur un seul site, c’est déjà un plus. Sur un parc de sites, Cloudflare devient une manière de standardiser la couche réseau pour tous vos projets, tout en réduisant la charge sur vos serveurs.

2. Organisation des comptes et des zones Cloudflare

Cloudflare fonctionne par zones : une zone = un nom de domaine (ex. example.com). Chaque sous-domaine (www, blog, etc.) est ensuite géré à l’intérieur de cette zone.

2.1. Un compte Cloudflare par agence ou par client ?

Deux approches sont possibles :

• Un compte Cloudflare pour l’agence / freelance : vous ajoutez les zones clients dans votre compte, et vous gérez tout depuis un seul tableau de bord. Avantage : centralisation. Inconvénient : le client dépend de votre compte.
• Un compte Cloudflare par client : chaque client possède son compte, vous êtes ajouté comme “membre” avec des droits de gestion. Avantage : séparation claire. Inconvénient : plus de comptes à jongler.

Pour des raisons de transparence et de gouvernance, de nombreuses agences préfèrent créer un compte par client et s’y connecter, mais pour un parc de sites personnels, un seul compte centralisé est souvent plus pratique.

2.2. Une zone par domaine

Chaque nom de domaine complet (ex. lemagweb.fr, bailly-developpement-web.fr) devient une zone Cloudflare. Si vous utilisez des sous-domaines (ex. blog.example.com), ils sont gérés dans la même zone que le domaine principal.

Il est important de :

• bien séparer vos zones (un domaine ≠ un sous-domaine),
• documenter pour chaque client où pointe la zone (vers quel serveur, quelle IP),
• ajouter des notes ou tags pour identifier rapidement les sites WordPress (par exemple dans une doc externe).

3. Règles de base pour WordPress (SSL, cache, WAF)

Une fois les zones créées, il est important d’avoir un “template” de configuration de base à appliquer à chaque site WordPress. Cela vous évite de repartir de zéro à chaque fois.

3.1. SSL et protocole HTTPS

Pour chaque site :

• Activez le mode SSL Full (strict) si possible (certificat valide sur le serveur).
• Forcez HTTPS (Page Rule ou paramètres de redirection).
• Activez HSTS côté serveur (avec prudence).

Le but est d’avoir une terminaison TLS propre, sans mélange de contenus HTTP/HTTPS.

3.2. Cache de base pour WordPress

Pour les pages publiques, vous pouvez laisser Cloudflare gérer un cache agressif, à condition :

• d’exclure /wp-admin/ et /wp-login.php du cache,
• de prévoir des mécanismes de purge (plugin Cloudflare, API, etc.),
• de vérifier que votre plugin de cache WordPress n’entre pas en conflit.

Une règle classique :

• Ne pas mettre en cache : *.php par défaut.
• Utiliser un plugin WordPress pour gérer le cache HTML et laisser Cloudflare gérer surtout les assets.

3.3. WAF et règles gérées

Activez le WAF Cloudflare et les règles gérées (Managed Ruleset). Pour WordPress, certaines règles spécifiques existent ou peuvent être adaptées :

• Protection contre les injections SQL/XSS,
• Blocage de certains user-agents malveillants,
• Restriction d’accès à certains chemins sensibles.

Sur un parc de sites, l’idée est de vous créer un profil “type WordPress” que vous appliquez à toutes les zones, en ajustant éventuellement quelques exceptions selon les besoins de chaque projet.

4. Protéger wp-login et wp-admin sur plusieurs sites

Les pages de connexion WordPress sont une cible privilégiée des robots et des attaques par force brute. Cloudflare permet de filtrer beaucoup de ce trafic en amont, ce qui soulage votre serveur.

4.1. Règles de niveau Firewall (Firewall Rules)

Vous pouvez créer des règles de pare-feu Cloudflare qui :

• ajoutent une protection de type “Managed Challenge” pour les URL /wp-login.php,
• restreignent l’accès à /wp-admin/ à certains pays ou à certaines IP (si vos équipes sont fixes),
• ralentissent ou bloquent les IP qui font trop de requêtes sur ces chemins.

Sur un parc, vous pouvez créer un jeu de règles standard puis le dupliquer d’une zone à l’autre, en adaptant si besoin.

4.2. Rate limiting

Cloudflare propose aussi des fonctionnalités de rate limiting (limitation de requêtes). Vous pouvez par exemple :

• Autoriser un certain nombre de tentatives de login par minute,
• Bloquer/cartonner les IP qui dépassent ce seuil.

En combinant rate limiting et un plugin de sécurité côté WordPress, vos pages de login seront beaucoup moins exposées.

5. Optimisations de performance à activer

Cloudflare apporte aussi de nombreuses optimisations de performance, souvent activables en un clic.

5.1. Paramètres “Speed”

• Brotli : compression moderne, plus efficace que Gzip.
• HTTP/2 / HTTP/3 : activés automatiquement sur la plupart des plans.
• Early Hints : permet aux navigateurs de précharger certains assets.
• Image Optimization (selon le plan) : compression et redimensionnement d’images.

Sur un parc de sites, ces optimisations peuvent faire une différence notable sur le temps de chargement, surtout pour les visiteurs géographiquement éloignés du serveur.

5.2. APO et cache HTML

Pour certains projets, vous pouvez utiliser APO (Automatic Platform Optimization) pour WordPress (service payant de Cloudflare), qui met en cache le HTML en bordure de réseau de façon plus intelligente.

Sur un parc de sites, APO peut être intéressant pour les sites à fort trafic mondial, mais il faut vérifier les coûts et la compatibilité avant de l’activer partout.

6. Automatiser la configuration via l’API (ou Terraform)

Si vous gérez une dizaine, voire plusieurs dizaines de sites, configurer Cloudflare à la main pour chaque zone devient vite chronophage et source d’erreurs. L’API Cloudflare permet d’automatiser :

• la création de zones,
• l’ajout d’enregistrements DNS,
• l’application de règles de firewall,
• la configuration de paramètres de performance.

6.1. API Cloudflare

L’API peut être utilisée via :

• des scripts (bash, Python, etc.),
• des outils comme Terraform,
• des intégrations côté panel ou CI/CD.

6.2. Terraform & “infrastructure as code”

Avec Terraform, vous pouvez décrire vos zones Cloudflare et leurs règles sous forme de fichiers texte versionnés. Cela permet :

• d’appliquer la même configuration sur plusieurs zones,
• de garder un historique des modifications,
• de reconstruire une configuration en cas d’incident.

Pour un parc de sites conséquent, cette approche “infrastructure as code” devient rapidement un investissement rentable.

7. Logs, monitoring et gestion des incidents multi-sites

Sur plusieurs sites, il est important de pouvoir repérer rapidement :

• quels domaines sont impactés par un incident,
• si le problème vient de Cloudflare, du DNS, du serveur, ou de WordPress lui-même,
• si une règle de sécurité bloque un trafic légitime.

7.1. Page de statut Cloudflare et logs

En cas de suspicion de problème côté Cloudflare (pannes de région, latence globale) :

• consultez la page de statut de Cloudflare,
• vérifiez si les erreurs 5xx viennent de Cloudflare ou du serveur d’origine (origine down).

7.2. Suivi par site

Pour chaque site WordPress, il est utile de :

• noter l’IP d’origine (serveur),
• conserver un historique des règles spécifiques appliquées (exceptions WAF, bypass cache),
• mettre en place un monitoring externe (uptime checks) qui contourne ou non Cloudflare selon le besoin.

Sur un parc, ces informations peuvent être centralisées dans un document ou un outil interne (tableur, wiki, etc.) pour faciliter le diagnostic.

FAQ – Cloudflare & parc de sites WordPress

Cloudflare est-il obligatoire pour WordPress ?

Non, mais il apporte une couche de protection et de performance très intéressante, surtout si votre site est exposé au public, reçoit du trafic et doit être accessible rapidement depuis différents pays. Pour un parc de sites, Cloudflare devient un standard pratique pour unifier la couche réseau.

Dois-je activer le cache HTML de Cloudflare ou seulement les assets ?

Sur un simple site vitrine, il est possible de mettre le HTML en cache, mais cela demande de bien gérer la purge (en cas de mise à jour). Beaucoup de setups préfèrent laisser le cache HTML au niveau de WordPress (plugin de cache) et laisser Cloudflare gérer les assets statiques + la sécurité.

Cloudflare peut-il remplacer un plugin de sécurité WordPress ?

Cloudflare protège surtout la couche réseau (avant que la requête n’atteigne WordPress). Un plugin de sécurité complète cette protection côté application (détection de fichiers modifiés, durcissement du wp-admin, etc.). Les deux jouent à des niveaux différents et sont complémentaires.

Comment savoir si un problème vient de Cloudflare ou du serveur ?

Les codes d’erreur peuvent vous aider : certaines erreurs 5xx indiquent un souci côté Cloudflare, d’autres indiquent un serveur d’origine inaccessible. Vous pouvez aussi désactiver temporairement le proxy (nuage gris) pour voir si le site répond directement. Un monitoring externe configuré hors Cloudflare est également très utile.

Faut-il mettre tous les sites d’un serveur derrière Cloudflare ?

Ce n’est pas obligatoire, mais c’est souvent recommandé : cela permet d’unifier la gestion SSL, de bénéficier du CDN, de limiter certains DDoS et d’ajouter une couche WAF. Si vous n’activez Cloudflare que pour certains domaines, le serveur reste plus exposé pour les autres.

Conclusion : une couche réseau propre pour tout votre parc

Cloudflare est bien plus qu’un CDN gratuit : c’est une brique réseau stratégique pour sécuriser et accélérer un parc de sites WordPress. En structurant vos zones, en appliquant un template de règles de base, en protégeant les pages d’admin, en activant les bonnes optimisations de performance et en automatisant ce qui peut l’être, vous gagnez du temps et de la sérénité sur la gestion quotidienne de vos projets.

Intégré à une architecture serveur bien pensée (comme décrite dans le guide pilier Serveur WordPress Haute Performance) et à une configuration solide de PHP-FPM, MySQL/MariaDB et Redis, Cloudflare devient un allié puissant pour maintenir des sites rapides, stables et protégés, même lorsque le nombre de projets gérés augmente.