WordPress : faut-il optimiser le fichier .htaccess pour les permaliens ?

Le fichier .htaccess de WordPress a longtemps été vu comme une petite boîte magique. On y ajoutait des règles pour les permaliens, la compression, le cache, les redirections, la sécurité, parfois même un peu de superstition Apache.

En 2011, j’avais publié une version “optimisée” du bloc WordPress pour les permaliens. L’idée était simple : éviter que certaines requêtes passent inutilement par WordPress, notamment les images, les fichiers CSS et les fichiers JavaScript.

Avec le recul, cette optimisation n’est plus un bon conseil générique. Le bloc standard de WordPress fait déjà le nécessaire pour laisser passer les vrais fichiers et les vrais dossiers. Mieux vaut donc garder une configuration simple, lisible et compatible avec WordPress.

À quoi sert le fichier .htaccess dans WordPress ?

Sur Apache, .htaccess permet d’appliquer des règles de configuration au niveau d’un dossier. WordPress l’utilise surtout pour les permaliens : les URL jolies comme /mon-article/ sont réécrites vers index.php, qui se charge ensuite de trouver le bon contenu.

Sans ces règles de réécriture, les permaliens personnalisés peuvent produire des erreurs 404. C’est pourquoi WordPress régénère ce bloc lorsque vous enregistrez la structure des permaliens dans Réglages > Permaliens.

Point important : WordPress peut réécrire cette section. Il ne faut donc pas placer vos règles personnalisées entre les marqueurs # BEGIN WordPress et # END WordPress.

Le bloc .htaccess standard de WordPress

Sur une installation WordPress classique à la racine du domaine, le bloc ressemble généralement à ceci :

# BEGIN WordPress
# Les directives entre “BEGIN WordPress” et “END WordPress”
# sont générées dynamiquement et doivent être modifiées uniquement via les filtres 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 WordPressLangage du code : PHP (php)

Ce bloc dit essentiellement :

• active le moteur de réécriture Apache ;
• préserve l’en-tête Authorization, utile pour certaines API et authentifications ;
• ne réécris pas directement index.php ;
• si la requête cible un fichier existant, laisse Apache le servir ;
• si la requête cible un dossier existant, laisse Apache le servir ;
• sinon, envoie la requête vers /index.php.

C’est cette partie qui rend l’ancienne “optimisation” beaucoup moins intéressante aujourd’hui :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Ces deux conditions excluent déjà les vrais fichiers et les vrais dossiers. Une image existante, un fichier CSS existant ou un fichier JavaScript existant ne passe donc pas par WordPress.

Pourquoi l’ancienne optimisation n’est plus recommandée

L’ancien code ajoutait une logique de ce type : si l’URL cible une image, un fichier CSS ou un fichier JavaScript, alors Apache saute la réécriture vers WordPress.

Le problème, c’est que cette logique repose sur une liste d’extensions. Or le Web moderne ne se limite plus à gif, jpg, png, ico, css et js.

Il faut aussi penser à :

• webp et avif pour les images modernes ;
• svg pour les icônes ;
• woff et woff2 pour les polices ;
• json pour des fichiers de données ;
• map pour les source maps ;
• pdf, xml, txt, webmanifest, et d’autres.

En ajoutant une liste partielle, on donne une impression de contrôle, mais on crée surtout une règle à maintenir. Et une règle à maintenir finit souvent par devenir une règle oubliée.

Autre souci : la directive [S=1] rend le comportement moins lisible. Elle saute la règle suivante si les conditions correspondent. C’est astucieux, mais pas nécessaire ici. Le bloc WordPress natif est plus clair, plus robuste, et mieux compris par les hébergeurs, les plugins et les outils de diagnostic.

La recommandation actuelle

Pour les permaliens WordPress sur Apache, gardez le bloc généré par WordPress. Ne cherchez pas à “optimiser” cette partie sans profilage réel.

La version recommandée est donc simplement :

# BEGIN WordPress
# Les directives entre “BEGIN WordPress” et “END WordPress”
# sont générées dynamiquement et doivent être modifiées uniquement via les filtres 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 WordPressLangage du code : PHP (php)

Si votre installation WordPress est dans un sous-dossier, le bloc peut varier. Dans ce cas, laissez WordPress le régénérer via l’écran des permaliens.

Comment régénérer proprement le .htaccess WordPress

La méthode la plus simple passe par l’administration WordPress :

1. allez dans Réglages > Permaliens ;
2. ne changez rien ;
3. cliquez sur Enregistrer les modifications.

WordPress régénère alors ses règles de réécriture.

En WP-CLI, vous pouvez aussi rafraîchir les règles de réécriture :

wp rewrite flush --hard

Le paramètre --hard demande à WordPress de mettre à jour le fichier .htaccess quand l’environnement le permet.

Vous pouvez aussi vérifier la structure active des permaliens :

wp option get permalink_structureLangage du code : JavaScript (javascript)

Exemple courant :

/%postname%/

Où placer vos règles personnalisées ?

Placez vos règles personnalisées en dehors du bloc WordPress. Sinon, WordPress peut les écraser.

Exemple pour une redirection simple :

# Redirections personnalisées
Redirect 301 /ancienne-page/ https://www.example.com/nouvelle-page/

# BEGIN WordPress
# ...
# END WordPressLangage du code : PHP (php)

Pour des règles plus complexes, placez-les avant ou après le bloc WordPress selon leur objectif. Une redirection d’ancienne URL doit souvent être placée avant WordPress, afin d’éviter une résolution inutile côté PHP.

Et pour les performances ?

Modifier trois lignes de réécriture dans .htaccess ne transformera pas un site lent en fusée. Dommage, ce serait pratique.

Pour accélérer réellement un site WordPress, regardez plutôt ces leviers :

• cache page côté serveur ou CDN ;
• OPcache PHP activé et correctement dimensionné ;
• objet cache persistant avec Redis ou Memcached si le site en bénéficie ;
• réduction des plugins lourds ;
• optimisation des requêtes SQL lentes ;
• serveur HTTP correctement configuré ;
• compression Brotli ou gzip ;
• cache navigateur pour les fichiers statiques ;
• images servies en WebP ou AVIF ;
• CDN correctement paramétré.

Sur un site moderne, le gros du gain vient rarement d’une micro-optimisation de mod_rewrite. Il vient plutôt du fait d’éviter d’exécuter WordPress quand une page peut être servie depuis le cache.

Ajouter du cache navigateur dans .htaccess

Si vous voulez vraiment utiliser .htaccess pour les performances, le cache navigateur des fichiers statiques est plus pertinent que la réécriture des permaliens.

Exemple avec mod_expires :

<IfModule mod_expires.c>
ExpiresActive On

ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "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 font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>Langage du code : JavaScript (javascript)

Et avec mod_headers :

<IfModule mod_headers.c>
<FilesMatch "\.(avif|webp|jpe?g|png|gif|svg|ico|css|js|woff2?|pdf)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Langage du code : HTML, XML (xml)

À adapter selon votre stratégie de cache et vos noms de fichiers. L’attribut immutable est très utile si vos assets sont versionnés. Il l’est beaucoup moins si vous remplacez des fichiers sous le même nom.

Cas particulier : Apache VirtualHost plutôt que .htaccess

Si vous administrez votre propre serveur, vous pouvez déplacer certaines règles dans la configuration Apache du VirtualHost. C’est souvent plus propre que d’empiler des directives dans .htaccess.

Le fichier .htaccess existe surtout pour les environnements mutualisés, où l’utilisateur n’a pas accès à la configuration principale d’Apache. Sur un serveur dédié ou VPS, une configuration centralisée est plus lisible et plus performante.

Exemple minimal dans un VirtualHost Apache :

<Directory /var/www/example.com/public>
    AllowOverride All
    Require all granted
</Directory>Langage du code : PHP (php)

Si vous migrez complètement les règles hors de .htaccess, vous pouvez réduire AllowOverride. Mais faites-le seulement si vous maîtrisez toutes les règles nécessaires à WordPress, aux plugins et aux redirections.

Checklist .htaccess WordPress

• Gardez le bloc WordPress standard pour les permaliens.
• Ne modifiez pas directement les directives entre # BEGIN WordPress et # END WordPress.
• Placez vos redirections personnalisées en dehors du bloc WordPress.
• Sauvegardez toujours .htaccess avant modification.
• Testez les permaliens après chaque changement.
• Ne listez pas manuellement quelques extensions pour “optimiser” les fichiers statiques.
• Optimisez plutôt le cache, PHP, la base de données et le CDN.
• Sur Nginx, oubliez .htaccess : il n’est pas lu par Nginx.

À retenir

Pour les permaliens WordPress, le meilleur .htaccess est souvent le plus banal : celui que WordPress génère lui-même.

L’ancienne optimisation à base de liste d’extensions et de saut [S=1] n’est plus une bonne recommandation. Elle complique le fichier, ajoute un risque de maintenance, et n’apporte pas de gain clair sur un site moderne.

Si vous voulez accélérer WordPress, ne commencez pas par torturer mod_rewrite. Commencez par le cache, la pile PHP, les requêtes lentes et les assets. Le serveur vous remerciera. Apache aussi, probablement en silence.

Sources

• WordPress Developer Resources : Apache HTTPD et .htaccess
• WP-CLI : wp rewrite flush
• WP-CLI : wp option get
• Apache HTTP Server : mod_rewrite
• Apache HTTP Server : fichiers .htaccess

Report a typo