.htaccess WordPress : 15 règles essentielles pour sécuriser et optimiser votre site

Le .htaccess est le fichier le plus puissant - et le plus dangereux - de votre installation WordPress. Une ligne bien placée peut bloquer une attaque. Une erreur de syntaxe peut rendre votre site inaccessible. En tant que développeur WordPress depuis 2011 et après des centaines de sites audités en formation, j’ai vu les deux cas. Plus souvent le deuxième.

Qu’est-ce que le fichier .htaccess ?

.htaccess est l’abréviation de "Hypertext Access". C’est un fichier de configuration pour les serveurs web Apache - le logiciel qui traite les requêtes HTTP et affiche vos pages aux visiteurs.

Chaque fois qu’un internaute demande une page de votre site, Apache consulte le .htaccess pour savoir comment traiter la requête : rediriger ? Bloquer ? Mettre en cache ? Exiger un mot de passe ? Le .htaccess répond à toutes ces questions.

Le fichier .htaccess est situé à la racine de votre installation WordPress, au même niveau que wp-config.php et wp-content/. Le point initial (.) signifie que c’est un fichier caché - dans votre client FTP, activez l’affichage des fichiers cachés pour le voir.

Le .htaccess par défaut de WordPress

Quand vous activez les permaliens personnalisés (Réglages → Permaliens), WordPress génère automatiquement un .htaccess avec ce contenu :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Pour l’essentiel, ce code fait une chose : si le fichier ou dossier demandé n’existe pas physiquement sur le serveur, WordPress le redirige vers index.php qui interroge la base de données pour trouver le contenu correspondant. C’est ce qui permet à vos URLs propres (/mon-article/) de fonctionner au lieu d’afficher ?p=123. La ligne HTTP_AUTHORIZATION, ajoutée par WordPress avec les mots de passe d’application, transmet à PHP l’en-tête d’authentification utilisé par l’API REST.

Règle d’or : ne modifiez jamais le bloc entre # BEGIN WordPress et # END WordPress. WordPress peut le réécrire à tout moment. Ajoutez toujours vos règles personnalisées au-dessus de ce bloc.

15 règles .htaccess essentielles pour WordPress

Chaque règle ci-dessous se copie-colle directement. Ajoutez-les au-dessus du bloc # BEGIN WordPress dans votre .htaccess. Les règles d’accès sont écrites pour Apache 2.4, avec Require. L’ancienne écriture (Order, Allow from, Deny from) est celle d’Apache 2.2, dont la dernière version date de juillet 2017 : si votre fichier en contient déjà, convertissez-la plutôt que de mélanger les deux, ce que la documentation d’Apache déconseille.

1. Protéger wp-config.php

Le fichier wp-config.php contient vos identifiants de base de données et vos clés de sécurité. Si quelqu’un y accède, il a tout.

<Files wp-config.php>
Require all denied
</Files>

2. Protéger le .htaccess lui-même

<Files ~ "^\.ht">
Require all denied
</Files>

3. Interdire le directory browsing

Sans cette règle, un visiteur peut taper votresite.com/wp-content/uploads/ et voir la liste de tous vos fichiers. Une mine d’informations pour un attaquant.

Options -Indexes

4. Désactiver l’exécution PHP dans /uploads/

C’est la règle de sécurité la plus sous-estimée. Si un attaquant uploade un fichier PHP déguisé en image, cette règle empêche son exécution. Créez un fichier .htaccess dans wp-content/uploads/ avec :

<Files "*.php">
Require all denied
</Files>

5. Désactiver l’exécution PHP dans /wp-includes/

Même logique. Les fichiers dans /wp-includes/ ne doivent pas être appelés directement. Sur un multisite, retirez la ligne RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] et remplacez [S=3] par [S=2] sur la ligne qui la précède : cette règle empêche ms-files.php de servir les images (réserve du guide officiel de WordPress).

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

6. Masquer les informations serveur

ServerSignature Off

7. Bloquer les scans d’auteurs

Les attaquants utilisent ?author=1, ?author=2 etc. pour découvrir les identifiants de connexion. Cette règle bloque ces tentatives.

<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F]
</IfModule>

8. Bloquer le spam de commentaires

Cette règle vérifie que les commentaires proviennent bien de votre site (via le referrer) et bloque les soumissions directes par des bots.

<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*votresite\.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F,L]
</IfModule>

9. Bannir des adresses IP

Si vous identifiez des IP malveillantes dans vos logs (tentatives de connexion répétées, scans de vulnérabilités) :

<RequireAll>
# Remplacez ces adresses d'exemple par celles à bannir
Require all granted
Require not ip 203.0.113.10
Require not ip 198.51.100.25
</RequireAll>

10. Désactiver XML-RPC

XML-RPC permet les connexions depuis des applications tierces (app mobile WordPress, Jetpack). Si vous ne l’utilisez pas, désactivez-le - c’est un vecteur d’attaque brute-force courant. Avant de poser la règle, vérifiez que rien ne s’en sert : j’explique comment décider s’il faut fermer xmlrpc.php.

<Files xmlrpc.php>
Require all denied
</Files>

11. Bloquer le hotlinking d’images

Le hotlinking, c’est quand un autre site affiche vos images en pointant vers vos URLs. Votre serveur supporte le trafic, ils profitent du contenu. La règle ci-dessous laisse passer votre site et les moteurs Google, Bing et DuckDuckGo (google.fr comme google.com) : testez l’affichage de vos images depuis Google Images avant de la laisser en place.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?votresite\.com [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^/]+\.)?(google|bing|duckduckgo)\.[a-z.]+/ [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC,L]
</IfModule>

12. Forcer HTTPS

Si votre certificat SSL est en place mais que le site est encore accessible en HTTP :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

13. Activer le cache navigateur

Les fichiers statiques (images, CSS, JS) ne changent pas à chaque visite. Le cache navigateur dit au navigateur de les stocker localement pendant une durée définie.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/html "access plus 0 seconds"
</IfModule>

14. Activer la compression GZIP

La compression réduit la taille des fichiers envoyés au navigateur. Sur un site WordPress typique, ça peut réduire le poids des pages de 60 à 70 %.

<IfModule mod_deflate.c>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>
</IfModule>

15. Ajouter les en-têtes de sécurité

Les en-têtes de sécurité HTTP ajoutent une couche de protection côté navigateur.

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Redirections 301 dans le .htaccess

Les redirections 301 (permanentes) sont indispensables pour le SEO lors d’un changement de structure d’URLs ou de migration.

# Redirection simple
<IfModule mod_alias.c>
Redirect 301 /ancienne-page/ https://votresite.com/nouvelle-page/
</IfModule>
# Redirection avec regex (supprimer /category/ des URLs)
<IfModule mod_rewrite.c>
RewriteRule ^category/(.+)$ https://votresite.com/$1 [R=301,L]
</IfModule>
# Forcer www ou non-www
# Sans www (recommandé) :
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^www\.votresite\.com [NC]
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
</IfModule>

N’utilisez la règle qui retire /category/ que si WordPress affiche déjà vos catégories sans ce préfixe (option dédiée de votre extension SEO ou extension spécialisée) : sinon, toutes vos archives de catégories deviendront introuvables. Et si c’est l’option de Yoast SEO ou de Rank Math qui retire le préfixe, l’extension redirige déjà les anciennes adresses : la règle est alors inutile.

Page de maintenance via .htaccess

Besoin de mettre le site en maintenance pour une mise à jour majeure ? Ces règles affichent une page statique à tous les visiteurs, sauf à votre IP, avec le code 503 :

ErrorDocument 503 /maintenance.html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteRule ^ - [R=503,L]
</IfModule>

Remplacez l’IP par la vôtre (trouvable sur whatismyipaddress.com). Le code 503 (service temporairement indisponible) signale à Google une interruption passagère, d’un ou deux jours au plus ; n’utilisez jamais de redirection 301, sinon Google indexera votre page de maintenance. La troisième condition laisse passer le fichier robots.txt : un code 503 sur ce fichier bloquerait toute l’exploration du site.

Augmenter les limites serveur

Si votre hébergeur le permet, vous pouvez augmenter les limites PHP via le .htaccess :

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Erreurs courantes et dépannage

• Erreur 500 après modification - restaurez immédiatement votre backup. L’erreur vient d’une faute de syntaxe, d’un module Apache désactivé ou d’une directive non supportée par votre hébergeur.
• Les règles ne s’appliquent pas - vérifiez que mod_rewrite est activé (la plupart des hébergeurs l’activent par défaut). Vérifiez aussi que AllowOverride All est configuré dans la configuration Apache du serveur.
• Conflit avec un plugin de cache - LiteSpeed Cache, W3 Total Cache et WP Super Cache écrivent leurs propres règles dans le .htaccess. Si vous ajoutez des règles de cache manuelles qui entrent en conflit, désactivez d’abord les règles du plugin.
• Boucle de redirections - vérifiez que vous n’avez pas une redirection HTTP→HTTPS dans le .htaccess ET dans un plugin (Yoast, Really Simple SSL). Une seule suffit.

Questions fréquentes

Où se trouve le fichier .htaccess dans WordPress ?

Le fichier .htaccess se situe à la racine de votre installation WordPress, au même niveau que wp-config.php et le dossier wp-content. C’est un fichier caché - activez l’affichage des fichiers cachés dans votre client FTP pour le voir.

Peut-on créer un fichier .htaccess s’il n’existe pas ?

Oui. Allez dans Réglages → Permaliens et cliquez sur "Enregistrer les modifications". WordPress génère automatiquement le .htaccess. Vous pouvez aussi créer le fichier manuellement via FTP avec un éditeur de texte.

Le .htaccess fonctionne-t-il avec Nginx ?

Non. Le .htaccess est spécifique aux serveurs Apache. Si votre hébergeur utilise Nginx (Kinsta, Flywheel, certaines offres premium), les règles équivalentes se configurent dans le fichier nginx.conf ou via le panneau d’administration de l’hébergeur.

Comment restaurer un .htaccess corrompu ?

Connectez-vous en FTP, supprimez le .htaccess corrompu et remplacez-le par votre sauvegarde. Si vous n’avez pas de sauvegarde, créez un fichier vide et allez dans Réglages → Permaliens pour que WordPress régénère le .htaccess par défaut.

Faut-il ajouter les règles avant ou après le bloc WordPress ?

Toujours avant le bloc "# BEGIN WordPress". WordPress peut réécrire le contenu entre ses balises BEGIN et END à tout moment. Vos règles personnalisées placées à l’intérieur seraient supprimées.

Le .htaccess peut-il améliorer le SEO ?

Indirectement, oui. Les redirections 301 préservent le jus de lien, le cache navigateur améliore les Core Web Vitals, la compression GZIP accélère le chargement, et le forçage HTTPS est un facteur de classement Google. Ces optimisations se configurent dans le .htaccess.

Mon hébergeur utilise LiteSpeed, le .htaccess fonctionne-t-il ?

Oui. LiteSpeed est compatible avec les fichiers .htaccess Apache. C’est l’un de ses avantages par rapport à Nginx. La plupart des hébergements mutualisés (O2switch, OVH, PlanetHoster) utilisent LiteSpeed ou Apache - le .htaccess fonctionne dans les deux cas.