Générateur de .htaccess
Générez des règles .htaccess courantes pour votre site web. Sélectionnez les options dont vous avez besoin et copiez le code généré.
Performance
Security
• The .htaccess file should be placed in the root directory of your website
• Make sure mod_rewrite is enabled on your Apache server
• Always backup your existing .htaccess file before replacing it
• Some hosting providers may restrict certain .htaccess directives
Comment utiliser Générateur de .htaccess
- 1
Saisissez votre domaine
Tapez votre nom de domaine, comme exemple.com, dans le champ Paramètres du domaine.
- 2
Sélectionnez les règles
Cochez les options voulues, comme Forcer HTTPS, Forcer ou Supprimer www, la compression GZIP, la protection anti-hotlink ou les pages d'erreur personnalisées.
- 3
Ajoutez des redirections
Pour les redirections d'URL, saisissez les anciens et nouveaux chemins et choisissez une redirection permanente 301 ou temporaire 302.
- 4
Copiez ou téléchargez
Utilisez Copier dans le presse-papiers ou Télécharger le .htaccess, puis envoyez le fichier dans le répertoire racine de votre site.
Maîtriser le fichier .htaccess d'Apache
Ce que fait réellement un fichier .htaccess
Un fichier .htaccess est un fichier de configuration par répertoire pour le serveur web Apache. Lorsqu'Apache est compilé avec AllowOverride activé, il lit le fichier .htaccess du répertoire qu'il dessert, ainsi que ceux de tous les répertoires parents, et applique leurs directives à cette requête. Cela vous permet de modifier le comportement du serveur, les redirections, la mise en cache, le contrôle d'accès et bien plus, sans toucher à la configuration principale du serveur ni redémarrer Apache. Les changements prennent effet dès la requête suivante, ce qui rend .htaccess si commode sur l'hébergement mutualisé, où vous n'avez pas accès à la configuration principale.
Le nom de fichier est littéralement .htaccess, avec un point en tête et sans extension, et sur les systèmes de type Unix le point en fait un fichier caché. Il a sa place dans le répertoire dont vous voulez modifier le comportement ; le plus souvent il s'agit de la racine du site. Une règle placée à la racine s'applique à l'ensemble du site, à moins qu'un .htaccess plus profond ne la remplace.
Apache uniquement : Nginx et les autres l'ignorent
C'est la première chose à vérifier avant d'écrire la moindre règle : .htaccess est une fonctionnalité d'Apache. Nginx, l'autre serveur web dominant, ne lit pas du tout les fichiers .htaccess et ne le fera jamais, par conception. Si votre site tourne sous Nginx, déposer un .htaccess à la racine ne fait rien, et les redirections, réécritures et en-têtes équivalents doivent être exprimés dans le bloc serveur de Nginx à la place. LiteSpeed et quelques serveurs compatibles Apache comprennent bien la syntaxe .htaccess, mais Nginx, Caddy et IIS utilisent chacun leur propre format de configuration.
Si vous ne savez pas quel serveur vous avez, vérifiez l'en-tête de réponse Server, que le Visualiseur d'en-têtes HTTP de ce site peut vous montrer. Y voir Apache confirme que .htaccess fonctionnera ; y voir nginx signifie que vous faites fausse route avec ce fichier.
Redirections et canonisation avec mod_rewrite
La tâche la plus courante d'un .htaccess est la redirection d'URL, qu'il réalise via le module mod_rewrite encadré par un bloc RewriteEngine On. Un simple déplacement permanent utilise Redirect 301 d'un ancien chemin vers un nouveau, tandis que RewriteRule gère les redirections basées sur des motifs au moyen d'expressions régulières. Les deux tâches de canonisation dont presque chaque site a besoin sont l'imposition d'un nom d'hôte unique (toujours www ou toujours sans www) et l'imposition de HTTPS, toutes deux obtenues avec un RewriteCond qui teste la requête entrante, suivi d'un RewriteRule qui émet une 301 vers la version canonique.
Utilisez toujours une 301 (permanente) pour les déplacements que vous comptez conserver, car la 301 transmet la valeur des liens vers la destination et indique aux moteurs de recherche de mettre à jour leur index. Un détail subtil mais important est d'éviter les chaînes de redirections : envoyez http://example.com directement vers https://www.example.com en un seul saut plutôt que de rebondir d'abord par https://example.com. Chaque saut supplémentaire ajoute de la latence et dilue légèrement les signaux de classement, ce que le Vérificateur de chaînes de redirections de ce site peut vous aider à repérer.
Performance : compression, mise en cache et le coût d'AllowOverride
Deux fonctionnalités de .htaccess apportent des gains de performance immédiats. La compression GZIP, configurée via mod_deflate, réduit la taille des réponses textuelles comme le HTML, le CSS et le JavaScript avant leur envoi, diminuant souvent la taille de transfert de 60 à 80 pour cent. La mise en cache du navigateur, réglée avec les en-têtes Cache-Control et Expires via mod_expires ou mod_headers, indique aux navigateurs de réutiliser les ressources statiques comme les images et les polices au lieu de les retélécharger à chaque visite. Ensemble, ce sont parmi les améliorations de vitesse les plus efficaces et les moins coûteuses en effort.
Il y a toutefois un coût caché à .htaccess lui-même. Comme Apache doit chercher un fichier .htaccess dans chaque répertoire du chemin de chaque requête, avoir AllowOverride activé ajoute des accès au système de fichiers à chaque requête. Sur un site à fort trafic que vous contrôlez, déplacer ces directives dans la configuration principale du serveur et fixer AllowOverride None est mesurablement plus rapide. Sur l'hébergement mutualisé, vous n'avez généralement pas le choix, et la commodité l'emporte sur le surcoût, mais il est utile de savoir pourquoi .htaccess est déconseillé sur les serveurs où la performance est critique.
Sécurité, pages d'erreur et contrôle d'accès
Au-delà des redirections et de la performance, .htaccess est largement utilisé pour renforcer et soigner un site. Les pages d'erreur personnalisées, définies avec la directive ErrorDocument, remplacent les écrans d'erreur Apache par défaut, austères et peu engageants, par des pages aux couleurs de la marque pour les réponses 404 et 500, ce qui est meilleur à la fois pour les utilisateurs et pour la sécurité. La protection anti-hotlink utilise RewriteCond sur l'en-tête Referer pour empêcher d'autres sites d'intégrer vos images et de consommer votre bande passante. Vous pouvez aussi envoyer des en-têtes de sécurité tels que X-Frame-Options, Content-Security-Policy et Strict-Transport-Security via la directive Header.
Pour le contrôle d'accès, .htaccess peut restreindre un répertoire par adresse IP ou exiger un mot de passe via .htpasswd, et il peut bloquer les scans d'énumération d'auteurs qui sondent les noms d'utilisateur des systèmes de gestion de contenu. Ces contrôles sont réellement utiles, mais rappelez-vous qu'ils ne s'exécutent que lorsqu'Apache traite la requête par le chemin normal ; combinez-les avec une véritable sécurité au niveau de l'application plutôt que de vous reposer sur .htaccess seul.
La syntaxe est impitoyable : testez avant de faire confiance
Le plus grand risque avec .htaccess est qu'une erreur de syntaxe n'échoue généralement pas en silence. Au contraire, elle déclenche une erreur 500 Internal Server Error pour chaque page sous ce répertoire, mettant tout le site hors ligne jusqu'à ce que le fichier soit corrigé. Il n'y a ni étape de compilation ni validation avant le déploiement : une faute de frappe, un module manquant ou une directive que votre hébergeur a désactivée peut tout casser instantanément. Les directives Apache sont aussi sensibles à l'ordre : les règles de réécriture sont évaluées de haut en bas, et une règle large placée avant une règle précise peut avaler les requêtes que la règle précise devait intercepter.
Le flux de travail sûr consiste à toujours sauvegarder le .htaccess existant avant de le modifier, à déployer les changements pendant les heures creuses et à charger immédiatement le site ensuite pour confirmer qu'il répond toujours. Si vous voyez une erreur 500, restaurez d'abord la sauvegarde et déboguez ensuite. Lorsqu'une directive dépend d'un module comme mod_rewrite ou mod_deflate, confirmez que votre hébergeur a ce module activé, car des règles visant un module absent peuvent provoquer une erreur.
Questions fréquentes
Quelles règles ce générateur peut-il créer ?
Quelle est la différence entre une redirection 301 et 302 ?
Où dois-je placer le fichier .htaccess généré ?
Cela fonctionne-t-il sur Nginx ou d'autres serveurs ?
Le code généré est-il envoyé quelque part ?
Outils similaires
Continuez avec ces outils pratiques