Le fichier .htaccess pour configurer et dépanner votre site

À quoi sert le fichier .htaccess

Apache lit ce fichier pour appliquer des directives au répertoire où il se trouve. Elles peuvent aussi concerner ses sous-répertoires. Un .htaccess à la racine du site a donc une portée bien plus large qu’un fichier placé uniquement dans un dossier de documents privés.

Ce fonctionnement explique son succès sur les hébergements mutualisés. Vous pouvez intervenir sur certains réglages sans avoir accès à toute la configuration du serveur. En revanche, l’hébergeur reste maître des directives autorisées. Une commande valide chez un prestataire peut être interdite chez un autre.

Apache, Nginx et LiteSpeed ne se configurent pas de la même façon

Les exemples de ce guide visent Apache 2.4, avec les modules nécessaires activés. Nginx ne lit pas les fichiers .htaccess. Les règles doivent alors être adaptées dans sa configuration ou dans les outils de l’hébergeur. Certains serveurs compatibles, dont LiteSpeed, prennent en charge des directives Apache, avec des différences à vérifier dans leur documentation.

Le nom du serveur visible dans un en-tête HTTP ne raconte pas toujours toute l’histoire. Un proxy peut se trouver devant Apache. En cas de doute, regardez le panneau de votre hébergement ou demandez quel serveur traite réellement les fichiers du site.

Si vous administrez vous-même Apache, sa configuration principale ou celle du VirtualHost est généralement le meilleur endroit pour ces réglages. Elle évite les recherches de fichiers distribués à chaque requête. C’est la recommandation du tutoriel officiel Apache.

Où trouver le bon fichier sur votre hébergement

Connectez-vous au gestionnaire de fichiers de l’hébergeur ou avec un client SFTP. La racine publique porte souvent un nom comme www, public_html ou htdocs. Ce nom n’est pas universel. Pour un domaine supplémentaire, le dossier peut être complètement différent de celui du site principal.

Sur une installation WordPress classique, cherchez le dossier contenant wp-admin, wp-content et wp-includes. Le fichier .htaccess associé aux permaliens est généralement à ce niveau. Un WordPress installé dans un sous-dossier demande de vérifier aussi l’emplacement où ses pages sont effectivement servies.

Afficher les fichiers cachés

Le point placé au début du nom peut rendre le fichier invisible dans votre logiciel. Activez l’affichage des fichiers cachés avant d’en conclure qu’il n’existe pas. Vérifiez également que vous êtes connecté au bon domaine et au bon dossier.

Chez OVHcloud, par exemple, consultez le dossier racine configuré pour le domaine dans la gestion multisite. Ne créez pas automatiquement un fichier dans un dossier www simplement parce qu’un tutoriel utilise ce nom. La documentation de l’hébergement OVHcloud précise les opérations possibles sur sa plateforme.

Plusieurs fichiers peuvent agir sur une même page

Un fichier placé dans un sous-dossier ne remplace pas forcément tout celui du dossier parent. Les directives se combinent selon leurs règles de configuration. Si une restriction paraît inexplicable, regardez les fichiers situés plus haut dans l’arborescence et les réglages du serveur.

Créer ou modifier le fichier en gardant un retour arrière

Téléchargez d’abord une copie du fichier existant sur votre ordinateur. Gardez aussi une copie de travail distincte pour vos modifications. Une sauvegarde laissée dans le dossier public, sous un nom comme .htaccess.old, peut être accessible depuis le Web selon la configuration. Le plus simple est de la conserver hors de la racine publique.

Utilisez un éditeur de texte brut, avec un encodage UTF-8 sans BOM. Le nom attendu est exactement .htaccess, sans extension .txt ajoutée à la fin. Un traitement de texte peut introduire des caractères de mise en forme ou des guillemets qui ne conviennent pas à une configuration Apache.

Appliquez une seule modification, enregistrez, puis visitez une page concernée. Passez ensuite par l’accueil, une page intérieure et la connexion au site. Pour une boutique, ajoutez un produit au panier et vérifiez ce parcours sans effectuer d’achat. Une règle peut fonctionner sur l’URL visée tout en perturbant une autre fonction.

Retrouver l’accès si la modification bloque le site

Gardez votre accès SFTP ou le gestionnaire de fichiers ouvert pendant l’intervention. Si le site tombe, remettez la copie précédente au même emplacement. Vous n’avez pas besoin que l’administration WordPress fonctionne pour restaurer ce fichier.

Si vous n’avez aucune sauvegarde, retirez uniquement les dernières lignes ajoutées lorsque vous les connaissez. Renommer provisoirement le fichier peut aider à isoler une panne, mais cela enlève aussi ses redirections et protections. Sur WordPress, des pages peuvent alors passer en 404. Ce test doit rester bref et maîtrisé.

Choisir des permissions cohérentes

Le mode 644 est fréquent pour ce fichier. Il donne au propriétaire la lecture et l’écriture, et au groupe comme aux autres utilisateurs la lecture seule. Il ne donne aucun droit d’exécution. Il faut aussi que le propriétaire, le groupe et les permissions des dossiers permettent au serveur d’atteindre et de lire le fichier.

Ne passez pas en 777 pour faire disparaître un message d’erreur. Cela élargit les droits d’écriture sans résoudre nécessairement la cause du problème. À l’inverse, un mode 0000 n’est pas une manière propre de désactiver les règles. Un fichier de configuration illisible peut provoquer un refus d’accès. En cas de blocage des permissions, faites vérifier le propriétaire du fichier par l’hébergeur.

Comprendre les directives et leur ordre

Chaque instruction indique à un module Apache ce qu’il doit faire. Un commentaire commence par # sur sa propre ligne. Les noms des directives ne se traduisent pas, même dans un guide français. Il faut écrire ErrorDocument, jamais une traduction de ce nom.

Les directives AllowOverride et AllowOverrideList décident de ce que votre fichier a le droit de modifier. Elles se configurent dans Apache, pas dans le .htaccess que vous tentez de faire fonctionner. Les ajouter dans ce dernier peut justement déclencher une erreur 500.

Une section <IfModule> permet d’ignorer certaines instructions si un module manque. Cela peut être pratique pour une optimisation facultative. Pour une protection indispensable, ignorer silencieusement les lignes serait trompeur. Vérifiez que le module et la restriction fonctionnent réellement.

Choisir la page d’accueil d’un dossier

Pour un répertoire qui contient plusieurs fichiers d’index, DirectoryIndex indique lesquels essayer et dans quel ordre. Ici, Apache cherche d’abord index.php, puis index.html. Le navigateur reste à la même adresse.

Cette directive peut elle aussi être limitée par l’hébergement. Dans un CMS, vérifiez le comportement existant avant de changer la priorité des fichiers.

Le fichier .htaccess de WordPress

WordPress utilise généralement des règles de réécriture pour faire parvenir les URL de vos articles à son fichier index.php. C’est notamment ce qui permet à une adresse lisible comme /mon-article/ de fonctionner sans qu’un dossier de ce nom existe sur le serveur.

Si l’accueil fonctionne mais que les articles affichent une erreur 404, commencez par ouvrir Réglages puis Permaliens dans l’administration. Un enregistrement peut régénérer les règles. Cela suppose que WordPress puisse écrire dans le fichier. Sinon, l’administration peut vous demander de les ajouter manuellement.

Le bloc d’une installation simple à la racine

Voici le bloc de référence pour une installation WordPress simple servie à la racine. Il ne représente pas tout ce que peut contenir votre fichier. Les règles de cache, les protections de l’hébergeur ou celles d’une extension peuvent se trouver autour.

Les conditions !-f et !-d laissent passer les fichiers et les dossiers qui existent réellement. Les autres chemins sont confiés à WordPress. La ligne concernant HTTP_AUTHORIZATION préserve cet en-tête pour les usages qui en dépendent, notamment certaines authentifications d’API.

Placez vos redirections personnelles avant le bloc généré, hors des marqueurs # BEGIN WordPress et # END WordPress. Une règle ajoutée après la réécriture vers index.php risque de ne jamais rencontrer l’URL attendue. Une modification à l’intérieur du bloc peut disparaître lors d’un nouvel enregistrement des permaliens.

Pour WordPress multisite ou une installation dans un sous-dossier, utilisez les règles correspondant exactement à votre installation. La documentation WordPress sur Apache distingue ces cas. Remplacer tout le fichier par le bloc ci-dessus pourrait supprimer des réglages nécessaires.

Faire une redirection 301 ou 302

Une redirection demande au navigateur de charger une autre adresse. Le code 301 indique un déplacement permanent. Le code 302 indique une destination temporaire. Pour un changement définitif, vérifiez d’abord la règle en 302, puis passez-la en 301 une fois la destination validée.

Cette précaution évite de garder une mauvaise redirection permanente en cache dans le navigateur. Les codes 307 et 308 existent aussi et préservent la méthode HTTP. Pour une API, un formulaire ou une requête POST, il faut réfléchir à ce comportement avant de choisir le statut.

Envoyer une ancienne page vers sa remplaçante

Pour déplacer uniquement /ancienne-page.html, vous pouvez utiliser la règle suivante. Adaptez le chemin de départ et l’adresse de destination à vos deux pages.

Le caractère ^ marque le début du chemin, et $ sa fin. Le point de l’extension est précédé de \ pour représenter un vrai point. Une URL comme /ancienne-page.html/suite ne correspond donc pas à cette règle.

RedirectMatch permet ici de viser une seule page. La directive Redirect, elle, travaille par préfixe et peut transmettre une portion supplémentaire du chemin. Ce comportement est utile pour certains déplacements, mais il faut en tenir compte avant de choisir la règle. La documentation de mod_alias détaille la différence.

Pour une page provisoire, la même logique s’écrit avec le statut 302. Cet exemple est une alternative, pas une deuxième règle à ajouter pour la même adresse.

Déplacer un dossier en conservant ses pages

Dans le fichier à la racine, cette règle envoie /ancien-dossier/article/ vers /nouveau-dossier/article/. Ici, la correspondance par préfixe de Redirect est justement utile. Apache transmet la partie située après le premier dossier et conserve les paramètres de la requête.

Le statut temporaire facilite les essais. Essayez une page profonde, une URL avec paramètres et la racine du dossier avec sa barre oblique, puis remplacez 302 par 301 si le déplacement est définitif. Le chemin /ancien-dossier sans barre oblique finale n’est pas visé par ce préfixe. Prévoyez sa redirection exacte si cette adresse existe aussi.

Changer de domaine en gardant les chemins

Pour une migration complète, la condition suivante limite la règle à l’ancien domaine, même si les deux noms utilisent le même hébergement. Le nouveau domaine doit déjà répondre et proposer les pages équivalentes. Cette forme utilise mod_alias et les sections conditionnelles d’Apache 2.4, qui doivent être autorisés par l’hébergement.

Les noms ancien.example et nouveau.example sont à remplacer. Le suffixe du chemin est transmis sans reconstruire l’URL à partir d’une capture déjà décodée. Pour une exception, placez son Redirect plus précis avant le Redirect "/" général, dans la même section <If>. Si la migration comporte de nombreux changements de structure, préparez une table de correspondance et faites vérifier sa configuration au niveau du domaine.

Gardez également un certificat valide sur les anciens noms accessibles en HTTPS. Le navigateur vérifie le certificat avant de pouvoir recevoir la redirection. Enfin, ne mélangez pas des règles RedirectMatch et RewriteRule pour piloter la même famille d’URL sans vérifier leur priorité. Leur ordre de traitement ne correspond pas simplement à leur ordre visuel dans le fichier.

Comprendre le sort des paramètres d’URL

Le chemin et la chaîne de paramètres sont deux choses différentes. Le motif de RewriteRule ne contient pas la partie située après ?. Une condition sur %{QUERY_STRING} sert à la tester.

Avec mod_rewrite, une destination sans nouvelle chaîne de paramètres conserve normalement celle de départ. Une destination qui en fournit une la remplace. Le drapeau QSA permet de les combiner, et QSD de supprimer les paramètres lorsque la destination n’en définit pas. Gardez les paramètres utiles au fonctionnement du site. Ne les supprimez pas tous pour faire paraître les URL plus propres.

Voir une redirection expliquée en vidéo

Numelion Web présente en français la création d’une redirection et la manipulation du fichier. Les exemples écrits ci-dessus précisent les correspondances exactes et les vérifications à effectuer.

Voir la vidéo sur YouTube · Numelion Web · Français

Passer en HTTPS et choisir une seule adresse du site

Commencez par vérifier le certificat sur votre domaine principal et sur sa variante avec ou sans www. La redirection ne crée pas de certificat et ne corrige pas une erreur de connexion TLS.

L’exemple suivant convient à un site où Apache reçoit directement les connexions HTTP et HTTPS. Il choisit https://example.com comme adresse canonique, sans www, et garde le chemin demandé. Il utilise lui aussi mod_alias et une section <If> d’Apache 2.4. Si votre choix est la version avec www, remplacez la condition et la destination ensemble.

La cible est écrite en dur pour garder le contrôle du domaine de destination. Dans la condition, || signifie que l’une des deux situations suffit. Une requête arrive en HTTP, ou sur un autre nom, et la redirection s’applique. Apache présente cette association de conditions et de redirections dans son guide des noms canoniques.

Vérifiez les quatre variantes de votre adresse, avec et sans HTTPS, avec et sans www. La version canonique doit s’afficher normalement. Les autres doivent l’atteindre sans tourner en boucle. Passez en 301 après ces essais, en tenant compte des éventuelles règles déjà présentes dans WordPress ou chez l’hébergeur.

Testez également les espaces et les caractères encodés présents dans vos vraies adresses. Recapturer un chemin décodé dans une RewriteRule, puis ajouter le drapeau NE au hasard, peut changer le sens de %3F ou %23. La redirection par préfixe choisie ici évite cette reconstruction. Un slash encodé %2F dépend cependant d’un réglage du serveur et peut être refusé avant même la redirection.

Le cas d’un proxy ou d’un CDN

Si Cloudflare ou un autre proxy termine la connexion HTTPS, Apache peut recevoir une requête HTTP alors que le visiteur utilise déjà HTTPS. La condition précédente peut alors rediriger indéfiniment vers la même adresse.

Réglez la redirection au niveau qui connaît réellement le protocole du visiteur, ou utilisez la configuration documentée par votre hébergeur. Ne faites pas confiance à un en-tête X-Forwarded-Proto envoyé librement par n’importe quel client. Il doit être transmis et normalisé par un proxy de confiance.

Avec Cloudflare, le mode Flexible combiné à une redirection HTTPS à l’origine est une cause classique de boucle. Une liaison chiffrée et correctement vérifiée jusqu’à l’origine, généralement avec Full strict et un certificat adapté, évite ce désaccord. La documentation Cloudflare sur les boucles de redirection permet de distinguer les différents cas.

Réécrire une URL sans changer l’adresse visible

Une réécriture interne change la ressource traitée par le serveur, sans demander au navigateur d’aller ailleurs. C’est utile pour une petite application PHP, mais inutile de recréer ce routage au hasard dans WordPress, qui possède déjà son propre système.

Dans cet exemple, /produit/42 est traité par produit.php?id=42. Le script doit exister à la racine du site. Le groupe ([0-9]+) accepte uniquement un identifiant numérique.

Les fichiers et dossiers existants sont exclus par les deux conditions. Ici, la nouvelle chaîne id=42 remplace les paramètres entrants. On n’ajoute pas QSA, car une URL comme /produit/42?id=999 pourrait sinon fournir deux identifiants concurrents à PHP. Si votre application a besoin d’autres paramètres, sélectionnez et validez ceux qu’elle accepte.

END, disponible avec Apache 2.4, arrête les traitements de réécriture en contexte de répertoire pour cette requête. L arrête seulement la série courante, ce qui peut laisser place à un nouveau passage après une réécriture interne.

Dans /boutique/.htaccess, le même motif est relatif à ce dossier. Il ne doit pas commencer par boutique/. C’est une cause fréquente de règle qui semble ignorée. La référence des drapeaux mod_rewrite explique notamment END, QSA et QSD.

Le routage ne remplace pas les contrôles de votre application. produit.php doit toujours valider l’identifiant reçu et les droits du visiteur.

Protéger un dossier et les fichiers sensibles

Les exemples suivants servent à limiter des accès précis. Ils ne corrigent pas une extension vulnérable, une injection SQL ou un mot de passe compromis. Pour ces problèmes, consultez aussi mon guide sur les failles d’un site web et leurs corrections.

Demander un identifiant et un mot de passe

L’authentification Basic convient, par exemple, à un répertoire de préproduction ou à des documents internes. Utilisez-la sur une connexion HTTPS. Sans chiffrement, les identifiants ne sont pas protégés pendant leur transport.

Le fichier .htpasswd contient les empreintes des mots de passe. Placez-le hors du dossier public, à un emplacement lisible par Apache. Si vous disposez de l’outil htpasswd en ligne de commande, voici comment créer un fichier avec un premier compte. Le mot de passe est demandé de manière interactive.

Remplacez le chemin et le nom du compte. -B sélectionne bcrypt. L’option -c crée le fichier et peut écraser un fichier existant. Pour ajouter ensuite un compte, utilisez htpasswd -B /chemin/prive/.htpasswd bob, sans -c. Sans accès à cet outil, utilisez la fonction de protection des dossiers de votre hébergeur.

Placez ensuite ce bloc dans le .htaccess du dossier à protéger. AuthUserFile attend un chemin absolu sur le serveur, pas une URL de votre site.

Sans identifiants valides, le serveur doit répondre avec un statut 401 et demander une authentification. Une fenêtre privée permet de faire l’essai sans réutiliser un identifiant déjà mémorisé. Le guide Apache de l’authentification explique les réglages d’autorisation nécessaires.

Autoriser une adresse IP précise

Pour un répertoire réservé à une équipe qui dispose d’une adresse IP fixe, vous pouvez autoriser cette seule adresse. Remplacez l’adresse de démonstration avant l’essai, sinon votre propre accès sera refusé.

Pour refuser une adresse précise tout en autorisant les autres, il faut combiner une autorisation et une exclusion. Une condition négative isolée ne suffit pas.

Ces deux exemples répondent à des besoins opposés. Ne les superposez pas. Avec un proxy, vérifiez quelle adresse Apache considère comme celle du client. Sinon vous risquez de bloquer le proxy et tous les visiteurs qui passent par lui. Pour un blocage par pays, utilisez un dispositif alimenté par une base géographique à jour, souvent au niveau du pare-feu ou du CDN. Une ancienne recette GeoIPEnable On n’est pas portable sur tous les hébergements.

Masquer la liste des fichiers d’un dossier

Si un dossier n’a pas de fichier d’index et que le listage est activé, Apache peut afficher la liste de ses fichiers. Cette directive désactive ce comportement.

Un répertoire sans index peut alors renvoyer une erreur 403. C’est attendu. En revanche, une personne qui connaît l’URL d’un fichier peut encore le télécharger si aucune autre règle ne le protège. Masquer une liste n’est pas rendre son contenu privé.

Refuser l’accès HTTP à certains fichiers de configuration

Cette restriction vise des noms précis, dont .env, ses variantes, .htaccess, .htpasswd et wp-config.php. Elle bloque leur consultation par HTTP. Elle n’empêche pas WordPress de lire son propre fichier de configuration depuis le système de fichiers.

Ne conservez pas pour autant des sauvegardes SQL, des archives de déploiement ou des fichiers de secrets dans le dossier public. Cette expression n’est pas un inventaire de tous les noms possibles. Évitez aussi les expressions très larges copiées sans les lire, qui peuvent bloquer des fichiers indispensables. La syntaxe Require est documentée dans mod_authz_core et les contrôles IP dans mod_authz_host.

Personnaliser une page d’erreur sans masquer le problème

Sur un site statique, créez une page /404.html avec une explication courte, un lien vers l’accueil et quelques pistes utiles. Demandez ensuite à Apache de l’utiliser lorsqu’une ressource manque.

Le chemin commence ici par / parce qu’il désigne une ressource locale depuis la racine du site. Apache peut ainsi conserver le statut 404 tout en affichant une page plus accueillante. Une URL externe dans ErrorDocument provoquerait une redirection et changerait ce comportement.

Ne redirigez pas toutes les pages introuvables vers l’accueil en 301. Le visiteur perd le contexte et les moteurs peuvent interpréter le résultat comme une fausse page valide. Sur WordPress, les URL réécrites sont souvent traitées par le CMS. Son modèle de page 404 reste alors l’endroit adapté pour travailler le contenu affiché.

Testez une adresse qui n’existe vraiment pas. Vous devez voir votre page personnalisée et recevoir un statut 404. La directive ErrorDocument précise les différences entre une destination locale et une destination externe.

Régler le cache et la compression

Le cache navigateur évite de télécharger à nouveau des ressources inchangées. Il concerne ici les fichiers statiques, comme les images, les feuilles CSS, les scripts et les polices. Il ne faut pas appliquer les mêmes durées à un panier, à une page de compte ou à une réponse privée.

Donner une durée de cache aux ressources statiques

Placez cet exemple dans un dossier réellement consacré aux ressources statiques. Un tri par type MIME peut aussi concerner une image générée à la demande, y compris une réponse privée. Ce réglage utilise mod_expires et des durées courtes pour les fichiers qui peuvent encore changer sous le même nom. Vérifiez d’abord si votre hébergeur, votre extension de cache ou votre CDN définit déjà ces en-têtes.

Le serveur génère les informations d’expiration à partir du type MIME envoyé avec la ressource. Si une feuille CSS reste servie sous un mauvais type, il faut corriger cela à la source. Évitez un ExpiresDefault très long qui s’appliquerait aussi à des réponses auxquelles vous n’avez pas pensé.

Vous pouvez choisir une durée bien plus longue pour des fichiers versionnés, par exemple app.a83f2.css, dont le nom change à chaque nouvelle version. L’instruction immutable doit être réservée à ces ressources réellement immuables pendant leur durée de cache. Un fichier modifié sous le même nom risque sinon de rester ancien chez vos visiteurs.

Vider le cache du CDN ne vide pas celui des navigateurs. Cette distinction est essentielle après un changement de CSS ou de JavaScript. La documentation de mod_expires décrit aussi son interaction avec les en-têtes existants.

Compresser les réponses textuelles

Si la compression n’est pas déjà prise en charge en amont, mod_deflate peut réduire le poids des réponses textuelles. La directive utilisée ici demande aussi mod_filter. Installez cette recette dans le dossier de ressources statiques concerné. Le navigateur et le serveur négocient ensuite son utilisation.

Il n’y a généralement pas d’intérêt à ajouter les JPEG, WebP, AVIF ou archives ZIP à cette liste. Ces formats sont déjà compressés. Si votre CDN utilise déjà Brotli ou Gzip, contrôlez le résultat avant d’empiler un autre réglage.

Le module ajoute normalement l’information Vary adaptée à la négociation. Ne supprimez pas les en-têtes de variation pour gagner quelques octets. Ils permettent aux caches de distinguer les réponses. L’exemple n’ajoute pas le HTML dynamique. Pour les pages qui combinent des secrets et du contenu contrôlé par un visiteur, la compression demande une analyse spécifique, comme l’indique la documentation de mod_deflate.

Ajouter un en-tête sans recopier une politique entière

nosniff demande au navigateur de respecter les types MIME déclarés, notamment pour les scripts et les feuilles de style. Il ne remplace pas une configuration correcte des types de fichiers.

Les deux instructions évitent de cumuler les deux tables habituelles d’en-têtes Apache. Vérifiez aussi ce qu’ajoute votre CDN et que les ressources se chargent encore avec leurs types attendus. N’ajoutez pas une politique CSP complète ou un HSTS de longue durée uniquement parce qu’un générateur les propose. Une CSP trop stricte peut bloquer des fonctions du site. HSTS peut imposer HTTPS durablement, y compris aux sous-domaines si cette option est choisie. Ces politiques demandent un déploiement préparé.

Adapter les règles aux images et aux ressources partagées

Le hotlinking consiste à intégrer l’URL de votre image sur un autre site. Un filtre fondé sur l’en-tête Referer peut limiter ce trafic, mais il reste imparfait. Cet en-tête peut être absent ou falsifié. Il ne constitue pas un contrôle d’accès à une image confidentielle.

Limiter certaines intégrations externes d’images

Cet exemple autorise les requêtes sans référent et celles qui viennent de example.com ou www.example.com. Les autres intégrations des formats visés reçoivent une réponse 403. Le domaine doit être adapté au vôtre.

La règle renvoie un refus d’accès, sans image de remplacement. Si vos images sont utilisées par un CDN, une application, un autre domaine ou certains outils éditoriaux, leurs usages peuvent être affectés. Contrôlez ces parcours et les aperçus de partage. Pour une image réellement privée, utilisez une authentification ou des URL signées.

Autoriser des polices depuis un autre domaine

Une ressource peut être publique tout en restant soumise aux règles CORS du navigateur. Si un domaine distinct héberge vos polices, vous pouvez autoriser une origine précise sur ces seuls fichiers avec mod_headers.

Ce bloc appartient au serveur qui distribue les polices. Remplacez l’origine par celle du site qui les utilise, avec le bon protocole et le bon nom. Il ne faut pas ajouter une autorisation générale à toutes les réponses authentifiées. La directive Header permet de cibler les réponses concernées.

Vérifier une règle et comprendre une erreur

Commencez par le résultat HTTP, pas seulement par ce que le navigateur affiche. Une page peut être jolie et renvoyer le mauvais statut. Une redirection peut sembler corrigée dans un onglet et rester stockée dans un autre.

Contrôler les redirections et les statuts

Avec curl, ces commandes envoient une requête GET, masquent le corps et affichent les en-têtes. La première montre la réponse initiale. La seconde suit les redirections jusqu’à leur terme, avec une limite pour repérer une boucle. Sous Windows, utilisez curl.exe si votre terminal associe curl à une autre commande.

Sous Windows, remplacez /dev/null par NUL. Regardez le statut et l’en-tête Location. Le domaine final et le chemin doivent correspondre à ce que vous avez prévu. Testez aussi une URL avec paramètres et un nom contenant un caractère encodé, car un exemple qui fonctionne sur /test/ peut encore mal traiter ces cas.

Pour vérifier le cache et la compression d’une ressource, demandez une version compressée et observez notamment Content-Encoding, Cache-Control, Expires et Vary. Le fichier choisi doit réellement exister sur votre site.

Vous pouvez également utiliser l’onglet Réseau des outils de développement du navigateur, avec son cache désactivé pendant le test. Un en-tête absent ne prouve pas à lui seul que le .htaccess est ignoré. Un cache ou un proxy peut servir la réponse à la place de l’origine.

Lire le message du serveur

Les journaux d’erreurs de l’hébergement donnent souvent le nom du fichier, la ligne concernée et la raison du refus. Corrigez ce point précis. Supprimer toutes les protections pour faire disparaître une erreur 403 ne vous dit pas laquelle posait problème.

Si vous gérez Apache vous-même, apachectl configtest contrôle sa configuration principale. Ce contrôle ne valide pas à l’avance tous les fichiers .htaccess, qui sont traités lors des requêtes. Il faut visiter les chemins concernés et consulter les journaux. Un diagnostic de réécriture plus détaillé se règle dans la configuration serveur avec LogLevel, pas avec l’ancienne directive RewriteLog recopiée depuis un vieux tutoriel.

Quand le cache donne l’impression que rien ne change

Essayez une fenêtre privée, désactivez le cache du navigateur et vérifiez le cache de l’hébergeur ou du CDN. Une redirection 301 peut rester mémorisée. Après une modification, ne concluez pas que la nouvelle règle est fausse en observant uniquement une réponse ancienne.

Pour les contrôles avancés, utilisez les outils de l’hébergeur afin de distinguer la réponse de l’origine de celle du proxy. Ajouter un paramètre aléatoire ne contourne pas tous les caches. Gardez aussi une seule couche responsable de chaque redirection pour éviter les chaînes difficiles à comprendre.

Comprendre un fichier qui se modifie ou revient tout seul

WordPress peut réécrire son bloc lors d’un enregistrement des permaliens. Une extension de cache ou de sécurité peut maintenir ses propres marqueurs. L’hébergeur peut aussi gérer certaines lignes. Un fichier qui se régénère n’est donc pas automatiquement un signe de piratage.

Comparez la copie précédente et la version actuelle. Regardez quelles lignes changent, à quel moment, et après quelle action. Si seules les règles contenues entre les marqueurs WordPress sont réécrites, commencez par sortir vos personnalisations de cette zone.

Des redirections vers des domaines inconnus, des restrictions apparues sans explication ou des modifications répétées en dehors des blocs gérés demandent une investigation. Effacer le fichier ne supprime pas le script ou le compte qui le recrée. Conservez une copie du contenu suspect, vérifiez les comptes et les fichiers du site, puis traitez la cause. En cas de compromission avérée, je peux vous accompagner pour réparer un site WordPress piraté.

Ne rendez pas le fichier illisible pour tenter d’arrêter sa régénération. Il faut comprendre qui l’écrit et pourquoi, puis corriger les droits ou le composant responsable.

Les questions fréquentes sur le fichier .htaccess