Testeur de règles .htaccess gratuit

Le .htaccess Rule Tester est un outil en ligne gratuit qui teste les rewriterules et redirections de .htaccess, avec une évaluation pas à pas des règles pour n'importe quelle url. Il fonctionne entièrement dans votre navigateur, sans installation ni inscription.

RewriteRule, RewriteCond, Redirect, RedirectMatch et les directives Header.

Oui — l'évaluation pas à pas montre quelles conditions ont été remplies ou ignorées.

Oui, entièrement gratuit.

Absolument. Le .htaccess Rule Tester traite tout côté client, dans votre navigateur. Aucune donnée n'est téléversée ni stockée sur un serveur. Votre contenu reste privé sur votre appareil à tout moment.

Oui, le .htaccess Rule Tester est entièrement responsive et fonctionne sur les smartphones et tablettes. Vous pouvez l'utiliser sur tout appareil doté d'un navigateur web moderne, sans aucun téléchargement d'application.

Aucun compte ni inscription n'est nécessaire. Ouvrez simplement le .htaccess Rule Tester dans votre navigateur et commencez à l'utiliser immédiatement. Il n'y a ni page d'inscription ni restriction d'utilisation.

Saisissez simplement vos données dans le champ prévu, ajustez les réglages selon vos préférences, et l'outil les traitera instantanément. Vous pouvez ensuite copier le résultat dans le presse-papiers ou le télécharger.

Le .htaccess Rule Tester fonctionne dans tous les navigateurs modernes, dont Chrome, Firefox, Safari, Edge et Opera. Pour une expérience optimale, utilisez la dernière version de votre navigateur préféré.

Dans une RewriteRule .htaccess, le drapeau [R=301] déclenche une redirection permanente et [R=302] une redirection temporaire — et ce choix a un impact direct sur le SEO. Une 301 indique aux moteurs de recherche que le déplacement est définitif, ce qui les pousse à transférer les signaux de classement de l'ancienne URL vers la nouvelle et à mettre à jour leur index. Une 302 signale que l'URL d'origine reviendra, donc les moteurs continuent d'indexer l'ancienne adresse et ne transmettent pas forcément l'autorité. L'erreur classique consiste à laisser le comportement par défaut, car un simple drapeau [R] équivaut à un 302. Utilisez le 301 pour les pages renommées, la canonicalisation www ou HTTPS, et les URL retirées définitivement ; réservez le 302 aux déplacements réellement temporaires, comme les pages de maintenance. Collez vos règles ci-dessus avec une URL de test, et le testeur indique le code de statut HTTP exact que chaque redirection renverrait, afin de confirmer qu'il s'agit bien d'un 301 avant la mise en ligne.

Le drapeau [L] signifie « last » (dernière) : lorsqu'une RewriteRule avec [L] correspond, Apache arrête le traitement des règles de réécriture restantes pour ce cycle et utilise le résultat obtenu. Comme Apache évalue les règles dans l'ordre, du haut vers le bas, l'ordre de vos règles modifie le résultat autant que les règles elles-mêmes. Une règle trop large placée en début de liste peut correspondre et interrompre le traitement avant qu'une règle plus spécifique située plus bas n'ait la moindre chance de s'exécuter ; à l'inverse, l'absence de [L] peut laisser plusieurs règles se déclencher en chaîne et produire une URL que vous n'aviez pas prévue. C'est l'un des aspects les plus difficiles à raisonner en lisant simplement le texte brut. Le testeur parcourt vos règles dans le même ordre qu'Apache et indique précisément où [L] arrête le traitement, afin que vous puissiez voir si une règle court-circuite celles situées en dessous avant la mise en production.

La raison la plus fréquente est la barre oblique de tête. Dans un fichier .htaccess par répertoire, le chemin qu'Apache transmet à votre motif RewriteRule a déjà sa barre oblique de tête retirée, donc un motif comme ^/ancienne-page ne correspondra jamais — il faut utiliser ^ancienne-page à la place. Les autres coupables fréquents sont un point non échappé (utilisez \. pour un point littéral), un motif trop permissif comme (.*) qui capture plus que prévu, une RewriteCond placée au-dessus de la règle qui échoue silencieusement et fait ignorer la règle, ou le RewriteEngine jamais activé (On). Les ancres d'expression régulière comptent aussi : ^ et $ fixent respectivement le début et la fin du chemin. La trace pas à pas de cet outil montre la valeur comparée à votre motif ainsi qu'une note en langage clair indiquant si cela a correspondu ou a été ignoré et pourquoi, ce qui permet généralement d'identifier le décalage en quelques secondes. Collez la règle et un exemple de chemin pour vérifier.

Une boucle de redirection se produit lorsqu'une règle réécrit sans cesse une URL vers une cible qui correspond à nouveau à la même règle, si bien que le navigateur rebondit indéfiniment et affiche une erreur ERR_TOO_MANY_REDIRECTS. Les causes typiques sont une règle forçant le HTTPS dont la condition ne devient jamais satisfaite derrière un proxy, une règle www qui se redéclenche sur son propre résultat, ou deux règles qui se renvoient mutuellement l'une vers l'autre. La solution consiste généralement à resserrer une RewriteCond pour exclure l'état déjà correct — par exemple, ne rediriger que lorsque %{HTTPS} est désactivé — accompagnée d'un drapeau [L] approprié pour arrêter tout traitement ultérieur. La simple lecture statique des règles révèle rarement une boucle. Exécutez votre extrait sur une URL de test dans le testeur et observez la trace : si l'URL de sortie devait rentrer dans la même règle correspondante, l'évaluation pas à pas rend cette chaîne visible afin que vous puissiez la briser avant le déploiement.

Pas de manière fiable, et c'est voulu. Des conditions comme RewriteCond %{REQUEST_FILENAME} !-f ou -d demandent à Apache si un fichier ou un répertoire réel existe sur le disque, et un navigateur n'a aucun accès au système de fichiers de votre serveur. Le testeur les approxime donc : les tests d'existence de fichier et de répertoire renvoient faux, et %{REQUEST_FILENAME} est remplacé par le chemin de la requête plutôt que par un véritable chemin du système de fichiers. Cela signifie que la logique dépendant de -f, -d ou -e — courante dans les configurations de contrôleur frontal qui redirigent les fichiers manquants vers index.php — ne se comportera pas exactement comme sur Apache. Cet outil est conçu pour valider rapidement et en toute confidentialité la logique, l'ordre et les drapeaux de vos règles de réécriture et de redirection. Utilisez-le pour confirmer les motifs, les groupes de capture, les codes de statut et le comportement de [L] ici, puis vérifiez tout ce qui dépend du système de fichiers sur votre serveur réel avant la mise en production.