Vous avez déjà du vous demander s’il étais possible de créer des redirection, de bloquer l’accès à certains contenus, ou même d’optimiser votre site WordPress, et c’est là qu’entre en jeu le fichier .htaccess ! Ce petit fichier permet d’ajouter de configurer votre serveur Apache et d’effectuer ces différentes tâches.
- Où trouver mon fichier htaccess dans WordPress ?
- À quoi ressemble le fichier htaccess de WordPress ?
- Quelles directives à mettre dans le htaccess sont utiles pour mon site WordPress ?
- Mesures de renforcement supplémentaires pour la sécurité de WordPress via htaccess
- Créer des redirections 301 avec .htaccess
- Forcer le téléchargement de certains fichiers avec .htaccess
- Autoriser la mise en cache du navigateur via .htaccess
- Retirer le /category/ de votre URL avec .htaccess
Où trouver mon fichier htaccess dans WordPress ?
Dans une installation WordPress fonctionnant sur un serveur Apache, le fichier .htaccess
est un élément central du système de réécriture d’URL. Il est généré automatiquement par WordPress lors de la configuration des permaliens, c’est-à-dire lorsque vous personnalisez la structure de vos URL depuis le tableau de bord (Réglages > Permaliens).
Pour localiser ce fichier, il faut accéder aux fichiers système de votre site web. Cela peut se faire de plusieurs manières :
- Via un client FTP (comme FileZilla, Cyberduck, ou Transmit) : connectez-vous à votre hébergement avec vos identifiants FTP. Une fois connecté, rendez-vous dans le répertoire racine de votre site WordPress, c’est-à-dire là où se trouvent les dossiers
wp-content
,wp-includes
etwp-admin
. Le fichier.htaccess
devrait s’y trouver. - Via le gestionnaire de fichiers de votre hébergeur (cPanel, Plesk, etc.) : naviguez jusqu’au dossier de votre site. Veillez à activer l’affichage des fichiers cachés (commençant par un point) car
.htaccess
est masqué par défaut sur de nombreuses interfaces.
Voici un exemple visuel de son emplacement dans une structure WordPress :
Si ce fichier n’apparaît pas, deux cas de figure sont possibles :
- Vous n’avez pas encore enregistré la structure de vos permaliens. Dans ce cas, rendez-vous dans Réglages > Permaliens et cliquez simplement sur « Enregistrer les modifications » — même sans changer la configuration. Cela forcera WordPress à générer le fichier.
- Votre serveur empêche WordPress de l’écrire. Vous devrez alors le créer manuellement dans un éditeur de texte (comme VS Code ou Notepad++) et y copier la configuration par défaut fournie par WordPress.
Il est également possible d’éditer le fichier .htaccess
directement depuis l’administration WordPress à l’aide de certains plugins. Par exemple, Yoast SEO inclut un outil accessible via l’onglet « Outils » qui permet de modifier ce fichier sans passer par FTP. Plus d’informations sur cette fonctionnalité sont disponibles sur cette page dédiée à Yoast SEO.
Important : avant toute modification de votre fichier .htaccess
, pensez toujours à en faire une copie de sauvegarde. Ce fichier agit directement sur le comportement du serveur web. Une erreur de syntaxe ou une directive incorrecte peut bloquer l’accès à votre site, provoquer une erreur 500 ou empêcher le chargement des ressources. En cas de problème, vous pourrez ainsi restaurer la version précédente en quelques clics. Une bonne pratique consiste à nommer vos copies .htaccess.bak
, .htaccess.old
ou avec la date de modification pour les retrouver facilement.
À quoi ressemble le fichier htaccess de WordPress ?
Le fichier .htaccess
joue un rôle fondamental dans la gestion des permaliens (URL lisibles) sur un site WordPress. C’est grâce à lui que vous pouvez avoir des URL du type /blog/mon-article
au lieu de /index.php?p=123
. Le contenu de ce fichier varie en fonction de votre type d’installation WordPress : classique ou multisite.
Configuration htaccess pour une installation simple de WordPress
Dans une installation WordPress standard (monosite), voici le contenu classique que vous trouverez dans votre fichier .htaccess
:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Ce bloc de code permet à Apache de rediriger toutes les requêtes (qui ne pointent ni vers un fichier ni vers un dossier réel) vers le fichier index.php
. C’est ce fichier qui contient la logique WordPress pour charger la bonne page en fonction de l’URL.
Voici ce que chaque ligne fait :
RewriteEngine On
: active le moteur de réécriture Apache.RewriteBase /
: définit la base de l’URL pour le site (utile dans des sous-dossiers).RewriteRule ^index\.php$ - [L]
: évite de réécrireindex.php
lui-même.RewriteCond %{REQUEST_FILENAME} !-f
: ignore les fichiers physiques existants.RewriteCond %{REQUEST_FILENAME} !-d
: ignore les répertoires physiques existants.RewriteRule . /index.php [L]
: redirige toutes les autres requêtes versindex.php
.
Ce comportement est essentiel au fonctionnement du système de permaliens de WordPress. Sans ce fichier, les liens risquent de renvoyer une erreur 404, surtout si vous utilisez une structure d’URL personnalisée.
Configuration htaccess pour une installation WordPress multisite
Dans le cas d’un réseau multisite WordPress utilisant le mode sous-dossiers (ce qui est souvent le cas), le fichier .htaccess
contient des règles plus complexes. Voici un exemple typique :
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# Ajoute un slash final à /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
Cette configuration gère la logique multisite de WordPress, où chaque site du réseau peut être identifié par un préfixe dans l’URL (par exemple monsite.com/site2/
).
Décryptage des lignes spécifiques :
- wp-admin avec slash final : redirige
/wp-admin
vers/wp-admin/
avec une redirection 301 permanente pour éviter les erreurs de chargement. - Exceptions pour fichiers et répertoires : empêche la réécriture si la ressource existe déjà physiquement (image, fichier CSS, etc.).
- Gestion des ressources internes : permet l’accès aux répertoires système comme
wp-content
ouwp-admin
même dans le contexte d’un sous-site. - Réécriture globale : toute autre requête est envoyée à
index.php
pour que WordPress gère dynamiquement le contenu demandé.
Attention aux erreurs et à la sécurité
Un fichier .htaccess
mal rédigé peut provoquer une erreur 500 Internal Server Error, ce qui bloquera totalement l’accès à votre site. Cela peut arriver suite à :
- une faute de syntaxe (espace ou saut de ligne incorrect) ;
- une redirection mal construite créant une boucle infinie ;
- l’activation de modules Apache absents (comme
mod_rewrite
non installé) ; - l’insertion de règles conflictuelles par des plugins de cache ou de sécurité.
Conseil : toujours sauvegarder votre .htaccess
avant de le modifier. Vous pouvez aussi tester les règles dans un environnement de staging ou via un outil comme htaccess tester. Enfin, de nombreux plugins (comme Yoast SEO, Rank Math ou W3 Total Cache) ajoutent automatiquement leurs propres règles dans ce fichier. Il est donc essentiel d’en surveiller régulièrement le contenu pour éviter les conflits ou les surcharges de directives.
Quelles directives à mettre dans le htaccess sont utiles pour mon site WordPress ?
Maintenant que vous savez où trouver et éditer votre fichier .htacces, nous allons voir quelques directives qui sont intéressantes lors de la création de site internet WordPress.
Protéger le fichier wp-config.php avec .htaccess
Le fichier wp-config.php est l’un des fichiers les plus critiques d’un site WordPress. Il contient des informations confidentielles dont la divulgation pourrait compromettre totalement votre site :
- les identifiants de connexion à la base de données (nom d’utilisateur, mot de passe, nom de la base, hôte) ;
- les clés de sécurité (AUTH_KEY, SECURE_AUTH_KEY, etc.) utilisées pour sécuriser les sessions et les cookies ;
- les paramètres avancés de votre installation : activation du mode multisite, débogage, préfixe des tables, réglages personnalisés, etc.
Par défaut, ce fichier n’est pas accessible directement via un navigateur. Mais en cas de mauvaise configuration du serveur (mauvais droits, indexation autorisée, etc.), un attaquant pourrait tenter d’y accéder. Pour renforcer sa sécurité, il est conseillé de bloquer son accès HTTP grâce à une règle .htaccess
.
La directive recommandée à ajouter dans votre .htaccess
<FilesMatch "^(wp-config\.php|php\.ini|\.env|\.git|composer\.json|composer\.lock)$">
Order allow,deny
Deny from all
</FilesMatch>
Détail du fonctionnement ligne par ligne
<FilesMatch "...">
: cette directive cible les fichiers dont le nom correspond à une expression régulière. Elle englobe ici plusieurs fichiers sensibles :wp-config.php
: cœur de la configuration WordPress ;php.ini
: fichier de configuration PHP, parfois présent à la racine ;.env
: utilisé pour les variables d’environnement (frameworks modernes ou configurations avancées) ;.git
,composer.json
,composer.lock
: fichiers liés à Git ou Composer, qui ne devraient jamais être accessibles publiquement.
Order allow,deny
: fixe la priorité des règles. Ici, la règle de refus (deny
) sera appliquée après l’autorisation générale. Comme aucune autorisation spécifique n’est définie, l’interdiction s’applique à tout le monde.Deny from all
: refuse l’accès à tous les utilisateurs, qu’ils soient connectés ou non.</FilesMatch>
: ferme la directive de filtrage des fichiers.
Ce que cette règle empêche concrètement
Si quelqu’un tente d’accéder à l’un des fichiers mentionnés via son navigateur, comme :
https://votresite.com/wp-config.php
… le serveur renverra automatiquement une erreur 403 Forbidden, empêchant la lecture ou l’affichage du fichier. Cela fonctionne uniquement sur les serveurs Apache avec le module mod_access_compat
activé.

Affichage forbidden
Les bonnes pratiques complémentaires à mettre en place
- Permissions du fichier : le fichier
wp-config.php
doit avoir des droits de lecture restreints. En général,644
(lecture pour le propriétaire et le serveur web) est suffisant. Sur un serveur VPS, on peut descendre à600
. - Déplacement hors de la racine web : WordPress permet de déplacer
wp-config.php
un niveau au-dessus du répertoire racine (/public_html
ou/www
). Il le détecte automatiquement. - Sur Nginx : cette règle ne fonctionnera pas. Il faudra ajouter une directive comme :
location ~* wp-config.php { deny all; }
Protéger wp-config.php
est l’une des premières étapes de sécurisation d’un site WordPress. Associée aux permissions de fichiers, à la désactivation de l’indexation et au durcissement d’autres points d’entrée, cette mesure réduit significativement les risques d’intrusion par exploitation de fichier.
Protéger les fichiers sensibles de WordPress exposés publiquement
WordPress expose plusieurs fichiers système à la racine de votre installation, dont certains sont des cibles fréquentes pour les bots et scripts automatisés. Il est vivement recommandé de bloquer l’accès à ces fichiers si vous ne les utilisez pas activement.
Bloquer l’accès à xmlrpc.php
Le fichier xmlrpc.php
permet des interactions distantes avec WordPress (Jetpack, applications mobiles…), mais il est aussi massivement utilisé pour des attaques par brute force et des abus de pingbacks. Si vous n’en avez pas besoin, bloquez-le avec :
<Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>
Pour les serveurs modernes, version mod_rewrite :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/xmlrpc\.php$
RewriteRule .* - [F,L]
</IfModule>
Désactiver wp-trackback.php
Le fichier wp-trackback.php
est une relique du système de trackbacks de WordPress, aujourd’hui obsolète et souvent abusé pour générer du spam. Sauf cas particulier, son blocage est recommandé :
<Files wp-trackback.php>
Order allow,deny
Deny from all
</Files>
Bloquer les fichiers readme.html et license.txt
Ces fichiers exposent publiquement la version exacte de WordPress que vous utilisez, ce qui peut aider les attaquants à cibler des failles connues. Vous pouvez soit les supprimer, soit les protéger avec :
<FilesMatch "^(readme\.html|license\.txt)$">
Order allow,deny
Deny from all
</FilesMatch>
Bloquer l’accès à votre site internet à certaines adresses IP ou pays
Si votre site WordPress est régulièrement ciblé par des comportements malveillants — spam de commentaires, tentatives de connexion non autorisées, exploration abusive des URL — vous pouvez restreindre l’accès à votre site en bloquant certaines adresses IP ou même des régions géographiques entières. Cette approche est particulièrement utile pour :
- empêcher des bots de pays étrangers de scanner votre site ;
- limiter l’accès à un site intranet ou régionalisé à une seule zone géographique ;
- bloquer manuellement des IP problématiques identifiées dans vos logs ou via un plugin de sécurité.
Blocage manuel d’adresses IP via .htaccess
Voici une règle simple à intégrer dans votre fichier .htaccess
à la racine de votre site WordPress :
<Limit GET POST>
Order allow,deny
Deny from 192.168.1.10
Deny from 203.0.113.42
Allow from all
</Limit>
Vous pouvez ajouter autant de lignes Deny from
que nécessaire. Ce bloc empêche ces adresses IP spécifiques d’effectuer des requêtes HTTP de type GET ou POST, bloquant ainsi totalement l’accès au site.
Explication des directives :
<Limit GET POST>
: la directive s’applique aux requêtes HTTP classiques (consultation de pages, formulaires, connexions, etc.).Order allow,deny
: applique d’abord les autorisations générales (allow
), puis les restrictions (deny
), ce qui permet de bloquer certains cas spécifiques tout en laissant l’accès aux autres visiteurs.Deny from
: interdit l’accès à une adresse IP ou plage IP donnée.Allow from all
: autorise tout le reste du trafic légitime.
Exemple avec plusieurs adresses IP à bloquer :
Deny from 185.45.12.23
Deny from 62.210.105.18
Deny from 185.130.5.19
Blocage par pays : Est-ce possible avec .htaccess ?
Il n’est pas possible de bloquer directement un pays par son nom avec .htaccess
. En revanche, vous pouvez le faire indirectement en utilisant des plages IP géolocalisées (GeoIP). Il existe deux solutions :
1. Blocage par plages IP manuelles
Certains services comme ipdeny.com ou IP2Location proposent des fichiers à jour regroupant les plages IP par pays. Par exemple, pour bloquer tout le trafic venant de la Chine :
# Exemple partiel
Deny from 36.96.0.0/11
Deny from 42.0.0.0/10
Deny from 58.14.0.0/15
Attention : ce type de filtrage peut alourdir considérablement le fichier .htaccess
et ralentir le serveur si vous ajoutez des centaines de lignes. Il est recommandé pour des sites à fort enjeu de sécurité ou à public exclusivement régional.
2. Utilisation du module Apache mod_geoip
Pour un filtrage plus propre, certains hébergeurs permettent l’utilisation du module mod_geoip
(ou sa version plus récente mod_maxminddb
). Celui-ci identifie le pays de chaque visiteur à partir de son IP et permet des règles conditionnelles comme :
<IfModule mod_geoip.c>
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry
</IfModule>
Ici, tout le trafic en provenance de la Chine (CN
) et de la Russie (RU
) est bloqué. Ce système est très performant mais nécessite un hébergement configuré avec GeoIP et une base de données à jour.
Les bonnes pratiques avant de bloquer une IP ou un pays
- Analysez vos logs serveur ou utilisez des plugins comme Wordfence, iThemes Security ou WP Cerber pour identifier les IP hostiles ;
- Ne bloquez jamais des plages IP sans en avoir vérifié l’origine : vous risqueriez de bloquer des moteurs de recherche ou des visiteurs légitimes ;
- Gardez une liste des IP bloquées dans un fichier à part pour faciliter leur gestion ;
- Testez vos règles sur un site de préproduction ou mettez en place une exception temporaire pour votre propre IP si vous gérez à distance.
Remarque : les directives Order
, Deny
et Allow
ne fonctionnent que si le module Apache mod_access_compat
est activé. Sur Nginx, vous devrez utiliser deny IP;
dans la configuration nginx.conf
ou gérer les restrictions via un WAF comme Cloudflare ou Imunify360. Que ce soit pour une simple IP ou un bloc de pays entier, bloquer à la source évite de surcharger WordPress inutilement. C’est une mesure défensive efficace, complémentaire à la surveillance par plugins de sécurité.
Mesures de renforcement supplémentaires pour la sécurité de WordPress via htaccess
En complément des règles de protection des fichiers sensibles, certaines directives .htaccess permettent de renforcer davantage la sécurité d’un site WordPress. Ces mesures agissent à un niveau bas, avant même que WordPress ne soit chargé, ce qui en fait des boucliers très efficaces contre les attaques automatisées, les abus de requêtes ou les mauvaises pratiques d’hébergement.
Limiter l’accès à wp-login.php à certaines adresses IP
Le fichier wp-login.php
est le point d’entrée du formulaire d’identification de WordPress. Il est régulièrement ciblé par des attaques de type brute force. Si vous gérez votre site depuis une ou plusieurs IP fixes, vous pouvez restreindre son accès à ces seules adresses :
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from 123.45.67.89
Allow from 98.76.54.32
</Files>
- Deny from all bloque l’accès à tout le monde par défaut ;
- Allow from autorise uniquement les IP que vous spécifiez (vous pouvez en ajouter plusieurs).
Cette règle est particulièrement efficace si vous n’avez pas besoin de vous connecter depuis des connexions publiques ou variables. En cas de changement d’IP, vous devrez modifier la règle ou la désactiver temporairement.
Sur certains serveurs, si un répertoire ne contient pas de fichier index.php
ou index.html
, son contenu peut être affiché dans le navigateur sous forme de liste. Cela peut révéler des fichiers sensibles ou oubliés. Pour empêcher cela :
Options -Indexes
Cette directive interdit l’affichage automatique des fichiers d’un dossier. Elle est à insérer tout en haut de votre fichier .htaccess
.
Désactiver les méthodes HTTP dangereuses
Par défaut, certains serveurs autorisent des méthodes HTTP comme TRACE
, TRACK
, DELETE
, ou OPTIONS
, qui peuvent être détournées pour effectuer des attaques XST (Cross Site Tracing) ou exécuter des actions non désirées. Pour bloquer toutes les méthodes sauf les classiques :
<LimitExcept GET POST HEAD>
Deny from all
</LimitExcept>
Cette règle autorise uniquement les requêtes légitimes liées à la consultation et à l’envoi de données depuis les navigateurs. Toutes les autres méthodes sont interdites côté serveur.
Limiter la taille maximale des fichiers uploadés
Pour éviter que des utilisateurs malveillants n’essaient de surcharger votre serveur en envoyant des fichiers très volumineux (par exemple via un formulaire ou un script), vous pouvez limiter la taille autorisée des uploads HTTP avec :
LimitRequestBody 10485760
Ici, la limite est fixée à 10 Mo
(1 Mo = 1 048 576 octets). Vous pouvez ajuster cette valeur selon vos besoins. Cela ajoute une couche de protection contre les tentatives de saturation mémoire ou disque.
Note : cette directive peut ne pas être supportée par tous les hébergements mutualisés. Dans ce cas, privilégiez un paramétrage au niveau PHP (upload_max_filesize
) dans php.ini
ou via le fichier .user.ini
.
Ces règles avancées ne remplacent pas une bonne politique de sécurité globale (mises à jour, plugins de sécurité, sauvegardes), mais elles agissent en première ligne pour bloquer les comportements anormaux avant même qu’ils n’atteignent WordPress.
Créer des redirections 301 avec .htaccess
La redirection 301 est une directive essentielle en gestion de site WordPress. Elle permet de rediriger de manière permanente une URL vers une autre, directement depuis le fichier .htaccess
, sans avoir recours à un plugin. C’est l’une des pratiques les plus courantes lors de :
- la migration d’un site de HTTP vers HTTPS ;
- la refonte d’un site ou la modification de l’arborescence des pages ;
- la suppression ou la fusion de contenus ;
- la correction d’URL cassées (404) identifiées via la Search Console ou des outils SEO.
Voici la syntaxe de base à utiliser :
Redirect 301 /ancienne-page/ https://www.monsite.com/nouvelle-page/
Décryptage de la syntaxe
- Redirect 301 : indique qu’il s’agit d’une redirection permanente (code HTTP 301). Ce type de redirection est pris en compte par Google pour transmettre la popularité SEO de l’ancienne URL vers la nouvelle.
- /ancienne-page/ : correspond au chemin de l’URL d’origine, relatif à la racine du site (ne pas inclure le domaine complet).
- https://www.monsite.com/nouvelle-page/ : nouvelle destination vers laquelle l’utilisateur (et les robots) seront redirigés.
Exemples courants de redirections .htaccess
Voici quelques cas d’usage typiques :
# Redirection simple de page
Redirect 301 /contact.html https://www.monsite.com/contact/
# Redirection d’un répertoire entier
Redirect 301 /blog/ https://www.monsite.com/nouveau-blog/
# Redirection d’un ancien domaine vers un nouveau
Redirect 301 / https://www.nouveaudomaine.com/
Important : toutes les redirections doivent être placées en haut de votre fichier .htaccess
, avant le bloc # BEGIN WordPress
, pour éviter les conflits avec le système de réécriture des permaliens.
Rediriger l’ensemble du trafic HTTP vers HTTPS
Lors d’un passage vers un site sécurisé (HTTPS), il est recommandé de forcer toutes les requêtes HTTP à être redirigées vers leur équivalent sécurisé :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Ce code détecte si une connexion HTTP est utilisée, et la redirige automatiquement vers HTTPS, en conservant la structure exacte de l’URL d’origine (paramètres compris).
Bonnes pratiques SEO liées aux redirections :
- Évitez les chaînes de redirection (plusieurs 301 consécutives). Elles ralentissent le chargement et diluent le jus SEO.
- Vérifiez toutes vos redirections à l’aide d’un outil comme httpstatus.io ou Redirect Checker.
- Supprimez les anciennes redirections obsolètes pour ne pas surcharger inutilement le fichier
.htaccess
. - Pensez à rediriger les versions
www
versnon-www
(ou inversement) pour éviter les duplications de contenu.
La maîtrise des redirections via .htaccess
est indispensable pour tout webmaster, référenceur ou développeur WordPress. C’est un outil léger, rapide, et fiable ( à condition d’être bien structuré et testé régulièrement).
Forcer le téléchargement de certains fichiers avec .htaccess
Par défaut, certains types de fichiers comme les PDF, vidéos ou documents Office sont affichés directement dans le navigateur lorsque l’utilisateur clique dessus. Si vous souhaitez que ces fichiers soient téléchargés automatiquement plutôt que consultés en ligne, il est possible de le configurer via le fichier .htaccess
.
C’est une pratique utile dans de nombreux cas :
- offrir un fichier PDF sans qu’il soit prévisualisé dans le navigateur ;
- éviter la lecture en streaming de fichiers vidéo ou audio pour contrôler le téléchargement ;
- proposer des fichiers Excel, ZIP ou autres formats comme pièce jointe directe ;
- empêcher les utilisateurs d’ouvrir un document sécurisé directement dans leur navigateur.
Voici la directive à ajouter dans votre fichier .htaccess
:
AddType application/octet-stream .avi .pdf .xls .mp4
Explication sur le code de forçage
AddType
: indique au serveur de modifier le type MIME (type de contenu) associé aux extensions listées.application/octet-stream
: type MIME générique utilisé pour signaler au navigateur que le contenu doit être téléchargé, quel que soit son type réel..avi .pdf .xls .mp4
: extensions ciblées. Vous pouvez les modifier ou en ajouter selon les types de fichiers que vous souhaitez forcer au téléchargement.
Exemples d’extensions fréquemment utilisées
AddType application/octet-stream .zip .rar .doc .docx .ppt .pptx .mp3 .mp4 .mov .csv
À savoir avant utilisation :
- Cette directive affecte tous les fichiers du type concerné dans le dossier où se trouve le
.htaccess
et ses sous-dossiers. - Il est possible de créer un
.htaccess
dédié dans un répertoire spécifique (/downloads
, par exemple) pour n’appliquer la règle qu’à certains fichiers. - Certains navigateurs peuvent toujours essayer d’ouvrir certains fichiers selon les plugins ou extensions installés. L’en-tête HTTP
Content-Disposition: attachment
est une alternative complémentaire côté PHP.
Exemple avancé : Forcer le téléchargement uniquement pour les fichiers PDF
Si vous souhaitez restreindre le comportement uniquement aux fichiers PDF, voici un .htaccess
plus spécifique à insérer dans un dossier comme /docs/
:
<FilesMatch "\.pdf$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
Ce code combine deux approches :
ForceType
impose un type MIME générique (octet brut) ;Content-Disposition: attachment
demande explicitement au navigateur de proposer le téléchargement au lieu de l’affichage.
Remarque : l’instruction Header
nécessite que le module mod_headers
soit activé sur votre serveur Apache. Vérifiez sa disponibilité via votre hébergeur ou fichier phpinfo()
.
Forcer le téléchargement de fichiers est une mesure simple à mettre en place, mais très utile pour améliorer l’expérience utilisateur, sécuriser certains contenus ou gérer efficacement les ressources téléchargeables sur votre site WordPress.
La mise en cache du navigateur est une technique d’optimisation essentielle pour améliorer les performances de votre site WordPress. Elle permet de réduire le temps de chargement en demandant au navigateur de conserver localement certains fichiers (images, scripts, feuilles de style, etc.) pendant une durée définie. Ainsi, lors des visites suivantes, l’utilisateur n’aura pas à retélécharger tous les fichiers depuis le serveur, ce qui diminue considérablement le temps d’affichage et la consommation de bande passante.
Un exemple de configuration à insérer dans votre fichier .htaccess
## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
# Images
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/webp "access 1 year"
ExpiresByType image/x-icon "access 1 year"
# Feuilles de style
ExpiresByType text/css "access 1 month"
# JavaScript
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
# PDF et autres documents
ExpiresByType application/pdf "access 1 month"
# Flash (obsolète mais parfois encore présent)
ExpiresByType application/x-shockwave-flash "access 1 month"
# Fichiers par défaut
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES CACHING ##
Explication de la directive
ExpiresActive On
: active la gestion des dates d’expiration pour les ressources.ExpiresByType
: définit une durée de conservation spécifique pour chaque type MIME (format de fichier).access 1 year
: signifie que le fichier peut rester en cache pendant 1 an après le premier accès.ExpiresDefault
: s’applique aux types non explicitement listés (durée plus courte recommandée).
Pourquoi cette configuration est bénéfique
- Amélioration du score PageSpeed : Google et d’autres outils de performance (GTmetrix, Pingdom) valorisent fortement la mise en cache des ressources.
- Diminution du temps de chargement : les ressources en cache n’ont pas besoin d’être rechargées à chaque page consultée.
- Économie de bande passante serveur : les fichiers déjà stockés sur l’appareil de l’utilisateur ne consomment pas de nouvelles ressources serveur.
Bonnes pratiques à prendre en compte
- Adaptez les durées selon la nature des fichiers. Par exemple, les images changent rarement, mais les fichiers CSS ou JS peuvent évoluer fréquemment lors de modifications du thème.
- Pensez à versionner vos fichiers statiques (ex. :
style.css?v=2.1
) si vous modifiez souvent les contenus pour forcer leur rechargement côté client. - Placez toujours ces directives avant
# BEGIN WordPress
pour éviter tout conflit avec les règles de permaliens générées automatiquement.
Alternatives avec un plugin WordPress
Bien que cette méthode via .htaccess
fonctionne parfaitement, il est souvent plus simple (et plus flexible) d’utiliser un plugin spécialisé. Nous recommandons notamment WP Rocket, un plugin premium qui offre :
- une gestion automatique de la mise en cache navigateur ;
- la minification et concaténation des fichiers JS/CSS ;
- la création de règles d’expiration optimisées sans écrire une ligne de code ;
- une interface intuitive avec options avancées pour développeurs et non-techniciens.
Attention : si vous utilisez WP Rocket ou tout autre plugin de cache (comme W3 Total Cache, LiteSpeed Cache, etc.), vos règles .htaccess
peuvent être écrasées. Il est donc préférable de les gérer depuis l’interface du plugin pour éviter les conflits. La mise en cache navigateur est l’un des moyens les plus simples et efficaces d’accélérer WordPress. Bien configurée, elle améliore à la fois l’expérience utilisateur et les performances SEO de votre site.
Retirer le /category/ de votre URL avec .htaccess
Par défaut, WordPress ajoute le préfixe /category/
dans l’URL des pages d’archives de catégories. Par exemple :
https://www.votresite.com/category/actualites/
Ce comportement est souvent considéré comme inutile d’un point de vue SEO et peut alourdir la structure de vos permaliens. Pour améliorer la lisibilité des URLs et faciliter le maillage interne, il peut être judicieux de supprimer ce préfixe.
Voici la redirection à insérer dans votre fichier .htaccess
pour supprimer le /category/
de vos URLs :
RewriteRule ^category/(.+)$ https://www.votresite.com/$1 [R=301,L]
Explication de la règle
RewriteRule
: directive utilisée pour réécrire une URL correspondant à un motif donné.^category/(.+)$
: capture toute URL commençant parcategory/
et récupère le reste de l’URL dans une variable$1
.https://www.votresite.com/$1
: redirige vers l’URL propre sans le préfixe/category/
. Remplacez bien sûrvotresite.com
par votre propre nom de domaine.[R=301,L]
: applique une redirection permanente (301) et arrête le traitement des règles supplémentaires si celle-ci correspond.
Exemple avant/après
Avant redirection | Après redirection |
---|---|
https://www.votresite.com/category/astuces/ |
https://www.votresite.com/astuces/ |
https://www.votresite.com/category/tutoriels/seo/ |
https://www.votresite.com/tutoriels/seo/ |
À savoir concernant la suppression de /category/
- Cette règle agit comme une redirection visuelle : elle conserve le contenu de la page, mais change l’URL dans la barre d’adresse.
- Pour fonctionner correctement, veillez à ce que votre structure de permaliens soit bien configurée dans Réglages > Permaliens de WordPress.
- Il est recommandé de combiner cette méthode avec un plugin comme Yoast SEO ou Rank Math, qui proposent aussi des options pour supprimer
/category/
proprement dans les réglages SEO sans recourir à une redirection manuelle. - Cette règle ne supprime pas le slug dans le back-office, elle redirige simplement les visiteurs vers une version propre de l’URL.
Important : placez toujours ce type de redirection avant le bloc # BEGIN WordPress
dans votre fichier .htaccess
, pour qu’elle soit prioritaire sur les règles de permaliens par défaut générées par WordPress.
Supprimer le préfixe /category/
contribue à simplifier votre structure d’URL, améliore l’expérience utilisateur et renforce la clarté de votre navigation, ce qui est toujours apprécié par les moteurs de recherche.
Nous avons fait le tour des directives du htaccess les plus fréquentes, et vous, êtes-vous capable de configurer vous-même votre htaccess ?
0 commentaires