Comment configurer et optimiser le fichier .htaccess de WordPress ?

Le fichier .htaccess est un fichier de configuration important sur les hébergements WordPress reposant sur Apache ou une technologie compatible. Il intervient notamment dans les permaliens, les redirections et certaines règles de sécurité. Une modification incorrecte peut toutefois rendre le site inaccessible : ces interventions font partie des opérations qui méritent une maintenance WordPress rigoureuse.

Dans ce guide, vous découvrirez comment utiliser ce fichier pour renforcer certaines protections, gérer le comportement du serveur Apache et maîtriser vos redirections. Le rôle de .htaccess dépend directement de votre hébergement WordPress et de la technologie serveur employée.

Note d’actualisation — août 2026 : cet article a été revu afin d’actualiser les règles WordPress et Apache, les pratiques de sécurité, les redirections et les recommandations liées aux performances et aux hébergements Nginx.

À savoir : les exemples .htaccess de ce guide concernent Apache et les environnements compatibles. Un serveur Nginx n’interprète pas ce fichier. C’est notamment le cas de Kinsta : les redirections, blocages et autres règles serveur y sont gérés via MyKinsta ou la configuration Nginx, et non via .htaccess.

Points clés à retenir

• Sur Apache, .htaccess participe notamment à la réécriture des permaliens WordPress et peut ajouter certaines règles de protection côté serveur. Sur Nginx, ces réglages sont gérés autrement.
• Une simple faute de syntaxe dans .htaccess peut provoquer une erreur 500 sur l’ensemble de votre site internet : sauvegardez systématiquement avant toute modification.
• Ce guide présente des exemples pour une installation simple, le multisite, les redirections et plusieurs réglages Apache. Chaque snippet doit être adapté à l’environnement réel avant déploiement.
• Les modifications s’effectuent via SFTP, le gestionnaire de fichiers de l’hébergeur ou, dans certains cas, un outil WordPress dédié. Conservez toujours un accès serveur indépendant du back-office avant d’intervenir.
• Maîtriser htaccess dans WordPress est tout à fait accessible si vous procédez par étapes et testez chaque changement avant de passer au suivant.

Qu’est-ce que le fichier .htaccess dans WordPress ?

Le fichier .htaccess (abréviation de Hypertext Access) est un fichier texte de configuration utilisé par les serveurs web Apache. Il est lu à chaque requête HTTP et permet de contrôler le comportement du serveur pour le répertoire courant ainsi que tous ses sous répertoires.

Dans le contexte de WordPress, ce fichier joue un rôle central dans la gestion des permaliens. Lorsque vous configurez des URLs « propres » depuis Réglages > Permaliens dans le tableau de bord WordPress (par exemple /2025/10/mon-article/ au lieu de ?p=123), WordPress génère automatiquement les règles de réécriture nécessaires dans .htaccess.

Un fichier .htaccess par défaut est généralement créé lors de l’activation des permaliens sur une installation WordPress standard. Ce mécanisme existe depuis les versions 2.x de WordPress et reste identique dans les versions récentes.

Il est important de savoir que plusieurs fichiers htaccess peuvent coexister sur votre site :

Emplacement	Fonction
Racine du site (/public_html/ ou /www/)	Règles principales : permaliens, redirections globales, sécurité
/wp-admin/	Restrictions d’accès au back-office
/wp-content/	Protection des thèmes et plugins
/wp-content/uploads/	Contrôle des fichiers téléversés

Ce fichier n’est interprété que sur les hébergements Apache ou compatibles (LiteSpeed, Apache modifié). Sur un serveur Nginx, les règles doivent être traduites dans la configuration du serveur (nginx.conf).

À quoi ressemble le .htaccess WordPress par défaut ?

Voici la structure classique d’un fichier htaccess de WordPress pour une installation simple :

# 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

Voici ce que fait chaque directive :

• RewriteEngine On : Active le moteur de réécriture d’URLs d’Apache (mod_rewrite)
• RewriteBase / : Définit la base de réécriture à la racine du site
• RewriteRule ^index.php$ – [L] : Si la requête cible déjà index.php, ne rien faire
• RewriteCond %{REQUEST_FILENAME} !-f : Vérifie que le fichier demandé n’existe pas physiquement
• RewriteCond %{REQUEST_FILENAME} !-d : Vérifie que le répertoire demandé n’existe pas
• RewriteRule . /index.php [L] : Redirige tout le reste vers index.php pour traitement par WordPress

Règle d’or : ne modifiez jamais le code situé entre # BEGIN WordPress et # END WordPress. WordPress réécrit automatiquement cette zone lors des changements de permaliens ou de l’activation de certains plugins.

Vos redirections personnalisées et règles de sécurité WordPress doivent être placées avant ou après ce bloc, selon vos besoins, pour éviter les conflits.

Précautions indispensables avant de modifier .htaccess

La moindre faute de syntaxe dans votre fichier .htaccess — un espace manquant, une directive inconnue, un module non disponible — peut bloquer l’intégralité de votre site avec une erreur 500 Internal Server Error.

Avant toute modification, suivez ces étapes essentielles :

1. Effectuez une sauvegarde complète de votre site

Avant toute intervention, vérifiez qu’une sauvegarde récente et exploitable existe. Chez Evolyon, cette protection repose notamment sur les sauvegardes de l’hébergement complétées par une couche indépendante via WP Umbrella. Notre guide consacré à la sauvegarde WordPress détaille cette stratégie.

2. Sauvegardez spécifiquement le fichier .htaccess

Téléchargez-le localement avec un nom daté, par exemple .htaccess-backup-AAAA-MM-JJ.txt. Vous conservez ainsi une version immédiatement restaurable en cas d’erreur.

3. Testez chaque bloc de règles séparément

Ajoutez un snippet, sauvegardez, puis rechargez plusieurs pages clés :

• La page d’accueil
• Un article ou une page
• L’administration (/wp-admin/)

Si une erreur 500 apparaît, restaurez immédiatement l’ancienne version.

4. Gardez un accès SFTP ou gestionnaire de fichiers fonctionnel

En cas de blocage complet, renommez temporairement .htaccess en .htaccess_old via SFTP ou le gestionnaire de fichiers de l’hébergeur afin de neutraliser ses règles et poursuivre le diagnostic.

Erreurs 500 et autres problèmes fréquents

Une erreur 500 après modification de .htaccess provient généralement de l’une de ces causes :

Origine du problème	Solution
Directive interdite par l’hébergeur mutualisé	Consulter la documentation de l’hébergeur
Module Apache manquant (mod_expires, mod_headers)	Encadrer les directives avec <IfModule>
Conflit entre deux blocs de réécriture	Vérifier l’ordre des règles
Erreur de syntaxe (espace, caractère spécial)	Relire ligne par ligne

Le journal d’erreurs (error_log accessible dans cPanel ou le panel de votre hébergeur) permet d’identifier précisément la directive en cause.

En cas de doute, commentez les blocs suspects un par un avec le symbole # pour isoler la règle problématique.

Certains hébergeurs français comme OVHcloud ou o2switch interdisent ou limitent certaines directives. Consultez leur documentation technique avant d’ajouter des règles avancées.

Où trouver et comment accéder au fichier .htaccess WordPress ?

Le fichier .htaccess est un « fichier caché » dont le nom commence par un point. Par défaut, il n’est pas visible dans de nombreux gestionnaires de fichiers, mais reste parfaitement accessible une fois les bons réglages activés.

Sur un hébergement standard, vous le trouverez à la racine de votre site WordPress :

• /public_html/
• /www/
• Ou le dossier portant le nom de votre domaine (ex : /monsite.fr/)

Il se situe au même niveau que wp-config.php et le dossier wp-content.

Vous ne pouvez pas éditer .htaccess depuis l’interface WordPress standard (Réglages, Extensions…) sans installer un plugin spécifique.

Si vous ne trouvez pas de fichier .htaccess malgré des permaliens configurés, WordPress n’a probablement pas eu les droits d’écriture. Vous devrez alors créer un fichier manuellement et y coller le code par défaut.

Accès via le gestionnaire de fichiers (cPanel, Plesk, panel d’hébergeur)

Voici la procédure pour un utilisateur débutant :

1. Connectez-vous à votre panneau d’hébergement (cPanel, Plesk ou panel propriétaire)
2. Cliquez sur « Gestionnaire de fichiers »
3. Naviguez vers le dossier racine de votre site WordPress
4. Activez l’option « Afficher les fichiers cachés (dotfiles) » — souvent accessible via les paramètres ou préférences du gestionnaire
5. Le fichier .htaccess apparaît alors dans la liste

Bonnes pratiques :

• Téléchargez une copie avant toute modification
• Utilisez l’éditeur intégré pour ajuster les directives
• Vérifiez l’encodage : UTF-8 sans BOM

Certains panels comme Plesk proposent un bouton « Éditer » permettant une modification directe sans logiciel supplémentaire.

Accès via SFTP (FileZilla, Cyberduck…)

L’accès SFTP constitue une méthode adaptée pour gérer ce fichier lorsque l’hébergeur le propose : la connexion est chiffrée et reste indépendante du tableau de bord WordPress.

1. Installez un client compatible SFTP comme FileZilla
2. Connectez-vous avec les identifiants fournis par votre hébergeur (hôte, utilisateur, mot de passe, port)
3. Naviguez vers le dossier racine du site
4. Dans FileZilla : menu « Serveur » > « Forcer l’affichage des fichiers cachés »

Pour modifier le fichier :

1. Téléchargez .htaccess sur votre ordinateur
2. Ouvrez-le avec un éditeur de texte brut (Notepad++, VS Code, Sublime Text)
3. Effectuez vos modifications
4. Renvoyez le fichier sur le serveur en écrasant l’ancien

L’extension doit rester exactement .htaccess (sans .txt ajouté), sinon Apache ne le prendra pas en compte.

Éditer .htaccess depuis WordPress

Certains outils permettent d’éditer .htaccess depuis le tableau de bord. Cette solution reste secondaire : en cas d’erreur 500, un accès SFTP ou au gestionnaire de fichiers de l’hébergeur demeure indispensable pour restaurer le fichier.

Exemples de plugins utilisés actuellement :

• Htaccess File Editor : édition directe et simple
• Yoast SEO : outil d’édition de fichiers intégré
• Rank Math SEO : gestion avancée des redirections et accès au .htaccess

Pour installer un plugin d’édition :

1. Extensions > Ajouter
2. Recherchez le plugin souhaité
3. Cliquez sur Installer puis Activer
4. Accédez à la page dédiée (souvent dans Outils ou SEO)

Restez prudent : copiez toujours le contenu actuel dans un fichier local avant d’enregistrer des modifications via un plugin. Une erreur peut aussi bloquer l’accès au back-office.

Créer ou régénérer un .htaccess WordPress propre

Plusieurs situations nécessitent de créer ou régénérer le fichier :

• Absence de .htaccess sur votre installation
• Corruption après une attaque ou une manipulation hasardeuse
• Erreurs 404 sur toutes les pages
• Migration de site ou changement d’hébergeur

Méthode manuelle :

1. Créez un nouveau fichier texte vierge sur votre ordinateur
2. Collez le code .htaccess standard de WordPress (voir section précédente)
3. Enregistrez-le sous le nom .htaccess (sans extension .txt)
4. Téléversez-le à la racine du site via SFTP ou le gestionnaire de fichiers de l’hébergeur

Méthode automatique (recommandée) :

1. Connectez-vous au tableau de bord WordPress
2. Allez dans Réglages > Permaliens
3. Vérifiez la structure souhaitée (par exemple /%postname%/)
4. Cliquez sur « Enregistrer les modifications »

WordPress réécrit automatiquement le fichier .htaccess avec les règles appropriées.

Si WordPress indique qu’il ne peut pas écrire dans le fichier, vérifiez les droits d’écriture et la propriété du fichier selon les recommandations de votre hébergeur. Évitez de modifier les permissions au hasard.

.htaccess pour installation simple vs multisite

Un réseau WordPress multisite utilise des règles de réécriture spécifiques. La constante WP_ALLOW_MULTISITE autorise l’accès à la configuration du réseau ; elle ne transforme pas, à elle seule, une installation standard en multisite.

Type d’installation	Caractéristiques du .htaccess
Installation simple	Règles standards avec RewriteRule vers index.php
Multisite en sous-dossiers	Règles supplémentaires pour gérer les chemins /site2/, /site3/
Multisite en sous-domaines	Configuration DNS + règles spécifiques

Pour un multisite en sous-dossiers (ex : monsite.fr/site2/), WordPress fournit le code exact dans Outils > Réseau après activation de la fonctionnalité. Ce code doit remplacer celui du .htaccess classique à la racine.

Ne mélangez pas des snippets trouvés au hasard avec les règles de base d’un multisite. Testez d’abord sur un environnement de préproduction si possible.

Renforcer la sécurité de WordPress avec .htaccess

Le fichier .htaccess permet d’ajouter une couche de sécurité côté serveur avant même que WordPress ne se charge. Cette protection au niveau Apache bloque de nombreuses attaques automatisées avant qu’elles n’atteignent votre application.

Ces règles ne constituent qu’une couche de durcissement Apache. Une stratégie WordPress complète associe notamment les protections de l’hébergement, les mises à jour, le contrôle des accès et la surveillance des vulnérabilités. Chez Evolyon, Patchstack complète cette protection ; un pare-feu applicatif WordPress traite par ailleurs les requêtes malveillantes à un niveau plus adapté qu’une longue collection de règles statiques.

Commentez chaque bloc avec une ligne explicative (ex : # Protéger wp-config.php) pour vous y retrouver lors de futures modifications.

Protéger les fichiers sensibles (wp-config.php, .htaccess, fichiers système)

Le fichier wp-config.php contient vos identifiants de base de données et vos clés secrètes. Bloquer son accès au niveau Apache empêche toute consultation directe via HTTP.

Ajoutez ce code dans votre .htaccess, en dehors du bloc # BEGIN WordPress :

# Protéger wp-config.php
<Files wp-config.php>
Require all denied
</Files>

# Protéger .htaccess
<Files .htaccess>
Require all denied
</Files>

# Protéger les fichiers système
<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
Require all denied
</FilesMatch>

Ces règles retournent une erreur 403 Forbidden si quelqu’un tente d’accéder directement à ces fichiers.

Si aucune intégration de votre site n’utilise XML-RPC, vous pouvez bloquer l’accès direct à xmlrpc.php. Vérifiez ce point avant d’appliquer la règle : certaines applications et intégrations WordPress s’appuient encore sur ce mécanisme.

# Bloquer xmlrpc.php si non utilisé
<Files xmlrpc.php>
Require all denied
</Files>

Placez ces règles au-dessus du bloc WordPress pour qu’elles soient traitées en priorité.

Désactiver l’indexation des répertoires

Sans directive particulière, certains serveurs affichent la liste des fichiers d’un dossier qui ne contient pas d’index.php. Cela peut dévoiler vos thèmes, plugins ou fichiers de sauvegarde à des visiteurs malveillants.

Ajoutez cette directive simple en haut de votre .htaccess principal :

# Désactiver l'affichage du contenu des répertoires
Options -Indexes

Cette règle couvre l’ensemble de votre site WordPress, y compris les dossiers wp-content, wp-includes et leurs sous répertoires.

Cette règle réduit l’exposition accidentelle du contenu d’un répertoire lorsque le listing est activé par le serveur. Vérifiez simplement que votre hébergeur autorise la directive Options dans .htaccess.

Limiter l’accès au back-office et à wp-login.php

La page de connexion wp-login.php et le répertoire /wp-admin/ figurent parmi les cibles habituelles des attaques automatisées. Les protections de l’hébergement, le WAF et une authentification renforcée constituent généralement une réponse plus robuste qu’une accumulation de règles statiques.

Restriction par adresse IP (pour IP fixe) :

# Restreindre wp-login.php à certaines IP
<Files wp-login.php>
Require ip 123.45.67.89 98.76.54.32
</Files>

Remplacez les adresses IP par celles de votre bureau ou domicile.

Protection par mot de passe HTTP (pour IP dynamiques) :

Une authentification HTTP supplémentaire sur /wp-admin/ reste envisageable dans certains environnements maîtrisés. Elle doit être testée soigneusement : une protection trop large peut perturber des appels utilisés par WordPress ou certaines extensions, notamment via admin-ajax.php.

1. Créez un fichier .htpasswd en dehors de public_html avec l’utilitaire htpasswd
2. Ajoutez dans /wp-admin/.htaccess :

AuthType Basic
AuthName "Zone Admin"
AuthUserFile /chemin/vers/.htpasswd
Require valid-user

Testez d’abord ces règles depuis une IP alternative (smartphone en 4G par exemple) pour vous assurer de ne pas vous bloquer vous-même.

Bloquer des IP et limiter certaines attaques courantes

Pour quelques sources clairement identifiées et répétitives, .htaccess peut bloquer des adresses IP précises. Pour un filtrage dynamique ou à grande échelle, privilégiez le pare-feu de l’hébergement ou un WAF.

# Bloquer des IP spécifiques
<RequireAll>
Require all granted
Require not ip 192.0.2.1
Require not ip 203.0.113.0/24
</RequireAll>

La syntaxe Apache 2.2 fondée sur Order, Allow et Deny est désormais dépréciée. Sur Apache 2.4, privilégiez les directives Require comme dans l’exemple précédent.

Vous pouvez également bloquer certains user-agents malveillants :

# Bloquer des bots agressifs
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^(BadBot|EvilScraper) [NC]
RewriteRule .* - [F,L]

Les adresses IP changent régulièrement (VPN, proxies). Ce blocage est surtout efficace contre des attaques répétées venant de la même source. Pour un blocage géographique fin, préférez le pare-feu de votre hébergeur ou un CDN comme Cloudflare.

Tenez une liste documentée des IP bloquées pour nettoyer régulièrement votre fichier .htaccess.

Créer des redirections et gérer les URLs avec .htaccess

Sur Apache, .htaccess constitue un emplacement courant pour gérer des redirections côté serveur lors d’une refonte, d’un changement de structure d’URL ou d’une migration HTTP vers HTTPS. Sur Nginx, ces règles se configurent ailleurs ; chez Kinsta, elles sont notamment gérées au niveau de MyKinsta.

Types de redirections :

Code	Type	Usage
301	Permanente	Changements définitifs (SEO-friendly)
302	Temporaire	Modifications provisoires

Pour un changement d’URL permanent, la redirection 301 reste le choix le plus courant sur WordPress. L’essentiel est surtout d’éviter les chaînes de redirections et de faire pointer directement l’ancienne URL vers la destination finale.

Pour un site WordPress classique, placez vos règles de redirection avant le bloc # BEGIN WordPress pour éviter les conflits avec la réécriture des permaliens.

Les sites avec des centaines de redirections préféreront un plugin dédié comme « Redirection » pour une gestion plus visuelle et des fonctionnalités d’import/export.

Redirections 301 classiques (pages, catégories, anciens articles)

Voici les cas concrets les plus fréquents :

• Changement de slug d’article après optimisation SEO
• Fusion de deux pages similaires
• Suppression d’une catégorie
• Restructuration des URLs lors d’une refonte

Syntaxe de base :

# Redirection simple d'une page
Redirect 301 /ancienne-page/ https://monsite.fr/nouvelle-page/

# Redirection avec RewriteRule
RewriteEngine On
RewriteRule ^ancien-article/?$ /nouvel-article/ [R=301,L]

Pour les patterns complexes :

# Rediriger une ancienne structure de catégorie
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]

Testez chaque redirection immédiatement après l’ajout : vérifiez dans le navigateur et avec les DevTools de Chrome/Firefox (onglet Réseau).

Pour les gros sites, maintenez une « carte de redirection » sous forme de tableur afin de garder une vision claire des changements d’URL impactant votre référencement naturel.

Forcer HTTPS et choisir la version avec ou sans www

La navigation HTTPS repose aujourd’hui sur des certificats TLS/HTTPS largement automatisés par les hébergeurs. Sur Apache, .htaccess peut assurer la redirection vers la version sécurisée ; sur un hébergement managé comme Kinsta, privilégiez la fonction HTTPS fournie par l’infrastructure.

Forcer HTTPS (sans www) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Forcer sans www
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Forcer HTTPS avec www :

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.monsite.fr/$1 [R=301,L]

Choisissez une seule version canonique et forcez toutes les autres à y rediriger.

Si vous gérez HTTPS dans .htaccess, placez la redirection avant les règles WordPress et vérifiez qu’elle ne duplique pas une redirection déjà appliquée par le CDN, le proxy ou l’hébergeur.

Les outils SEO (Google Search Console, Ahrefs, SEMrush) considèrent la version canonique choisie ; restez cohérent dans toutes vos configurations.

Supprimer /category/ des URLs de catégories

Par défaut, WordPress peut intégrer /category/ dans les URLs des archives de catégories. Le retirer relève surtout d’un choix d’architecture et de lisibilité des URL, pas d’un bénéfice SEO automatique.

Avantages d’une URL plus courte (/actualites/) :

• URL plus concise lorsque cette convention correspond à l’architecture éditoriale du site
• Structure plus homogène si les autres taxonomies suivent une logique similaire
• Navigation plus simple à lire lorsque la suppression est prévue dès la conception

Deux approches possibles :

1. Via un plugin (plus convivial) : Yoast SEO Premium, Rank Math ou des plugins dédiés comme « Remove Category URL »
2. Après le changement : redirigez chaque ancienne URL /category/… vers sa nouvelle destination et vérifiez les liens internes, les canonicals et le sitemap.

Vérifiez absolument que toutes les anciennes URLs /category/ renvoient bien un code 301 vers la nouvelle URL, afin de ne pas perdre de trafic ni accumuler d’erreurs 404.

Améliorer les performances avec cache et compression dans .htaccess

Sur Apache, .htaccess peut définir certains en-têtes de cache et activer la compression lorsque ces fonctions ne sont pas déjà gérées par l’infrastructure. Avant d’ajouter des règles, vérifiez ce que fournit déjà l’hébergement, le CDN ou votre solution de cache. Notre guide sur la performance WordPress détaille cette démarche.

Ces optimisations sont souvent recommandées par les outils de performance comme PageSpeed Insights, GTmetrix ou WebPageTest.

Prérequis :

• Vérifiez que les modules Apache nécessaires sont disponibles : mod_expires, mod_deflate, mod_headers
• Si un plugin comme WP Rocket, W3 Total Cache ou LiteSpeed Cache est installé, il injecte probablement déjà ses propres directives — évitez les doublons

Configurer la mise en cache du navigateur

Le principe : le navigateur conserve en local les fichiers statiques (images, CSS, JS, polices) pendant une durée définie, rendant les visites suivantes beaucoup plus rapides.

<IfModule mod_expires.c>
ExpiresActive On

# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"

# CSS et JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"

# Polices
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"

# HTML
ExpiresByType text/html "access plus 0 seconds"
</IfModule>

Exemples de repères à adapter au versionnement des fichiers et à votre couche de cache :

Type de ressource	Durée suggérée
Images rarement modifiées	1 an
CSS/JS	1 mois
Polices	1 an
HTML	Selon la stratégie de cache applicatif, serveur ou CDN

Après ajout des règles, testez en navigation privée et relancez un audit de performance pour vérifier que les en-têtes HTTP sont correctement envoyés.

Activer la compression GZIP/DEFLATE

La compression GZIP/DEFLATE réduit la taille du HTML, CSS, JS et autres ressources textuelles avant leur envoi au navigateur, diminuant ainsi le temps de chargement.

<IfModule mod_deflate.c>
# Compresser les ressources textuelles
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/json
</IfModule>

La compression réduit sensiblement le poids des ressources textuelles, mais le gain varie selon leur contenu. Les infrastructures modernes peuvent également utiliser Brotli, généralement signalé par l’en-tête Content-Encoding: br.

Tous les navigateurs modernes (Chrome, Firefox, Safari, Edge) gèrent la compression depuis des années, ce qui en fait une optimisation sans risque.

Utilisez les DevTools (onglet Réseau) pour vérifier que la compression est active : recherchez l’en-tête Content-Encoding: gzip ou br dans les réponses.

Cas avancés et bonnes pratiques autour de .htaccess WordPress

Au-delà des configurations standards, .htaccess permet diverses optimisations supplémentaires : forcer le téléchargement de fichiers, contrôler les types MIME, désactiver certaines méthodes HTTP considérées comme risquées.

Ces réglages avancés sont optionnels et doivent toujours être testés sur un environnement de préproduction avant déploiement en production.

Principes de maintenance :

• Plus vous ajoutez de règles, plus la documentation devient importante
• Regroupez les règles par thème (sécurité, redirections, performance)
• Séparez les sections par des commentaires clairs
• Révisez périodiquement pour supprimer les règles obsolètes

Forcer le téléchargement de certains types de fichiers

Par défaut, les navigateurs affichent certains fichiers (PDF, images) au lieu de proposer un téléchargement direct. Vous pouvez modifier ce comportement avec .htaccess.

# Forcer le téléchargement des PDF
<FilesMatch "\.pdf$">
Header set Content-Disposition attachment
</FilesMatch>

Évitez de modifier artificiellement le type MIME des documents avec application/octet-stream. Si un téléchargement forcé est réellement nécessaire, préférez un en-tête Content-Disposition: attachment ciblé sur les fichiers concernés.

Exemple concret : forcer le téléchargement des PDF hébergés dans /docs/ pour proposer un « vrai » téléchargement de brochure commerciale ou de livre blanc.

Limitez ces règles aux dossiers ou extensions nécessaires pour ne pas perturber l’expérience utilisateur sur le reste du site (lecture en ligne, visionnage d’images).

Désactiver des méthodes HTTP jugées dangereuses

WordPress moderne et sa REST API utilisent plusieurs méthodes HTTP au-delà de GET et POST, notamment PUT, DELETE et OPTIONS selon les routes et les intégrations. Un blocage global limité à GET, POST et HEAD peut donc casser l’éditeur, WooCommerce ou des services connectés.

Ne restreignez une méthode HTTP qu’après avoir identifié un besoin de sécurité précis et vérifié les usages réels du site. Pour un filtrage avancé, privilégiez les protections du serveur, du CDN ou du WAF plutôt qu’une règle générale ajoutée à .htaccess.

FAQ – htaccess et WordPress