Kostenloser .htaccess-Regel-Tester

Der .htaccess Rule Tester ist ein kostenloses Online-Tool, das rewriterules und Weiterleitungen in .htaccess testet, mit einer schrittweisen Regelauswertung für jede url. Es läuft vollständig in deinem Browser, ohne Installation oder Anmeldung.

RewriteRule, RewriteCond, Redirect, RedirectMatch und Header-Direktiven.

Ja – die schrittweise Auswertung zeigt, welche Bedingungen erfüllt oder übersprungen wurden.

Ja, völlig kostenlos.

Absolut. Der .htaccess Rule Tester verarbeitet alles clientseitig in deinem Browser. Es werden keine Daten auf einen Server hochgeladen oder dort gespeichert. Deine Inhalte bleiben jederzeit privat auf deinem Gerät.

Ja, der .htaccess Rule Tester ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Du kannst ihn auf jedem Gerät mit einem modernen Webbrowser nutzen, ohne eine App herunterzuladen.

Es ist kein Konto und keine Registrierung erforderlich. Öffne einfach den .htaccess Rule Tester in deinem Browser und beginne sofort mit der Nutzung. Es gibt keine Anmeldeschranken oder Nutzungsbeschränkungen.

Gib einfach deine Eingabe in das vorgesehene Feld ein, passe die Einstellungen nach Wunsch an, und das Tool verarbeitet sie sofort. Anschließend kannst du das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der .htaccess Rule Tester funktioniert in allen modernen Browsern, darunter Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwende die neueste Version deines bevorzugten Browsers.

In einer .htaccess-RewriteRule löst das Flag [R=301] einen dauerhaften Redirect aus und [R=302] einen temporären — und diese Wahl ist für SEO entscheidend. Ein 301 signalisiert Suchmaschinen, dass der Umzug dauerhaft ist, sodass Ranking-Signale von der alten auf die neue URL übertragen und der Index aktualisiert wird. Ein 302 signalisiert, dass die ursprüngliche URL zurückkehren wird, sodass Suchmaschinen die alte Adresse weiter indexieren und Autorität möglicherweise nicht weitergeben. Der häufige Fehler ist, die Standardeinstellung stehen zu lassen, denn ein nacktes [R]-Flag löst sich zu 302 auf. Verwende 301 für umbenannte Seiten, www- oder HTTPS-Kanonisierung sowie ausrangierte URLs; hebe 302 für wirklich kurzfristige Umzüge wie Wartungsseiten auf. Füge deine Regeln oben mit einer Test-URL ein, und der Tester zeigt den exakten HTTP-Status jedes Redirects an, sodass du bestätigen kannst, dass wirklich 301 zurückkommt, bevor du live gehst.

Das Flag [L] bedeutet "last": Wenn eine RewriteRule mit [L] greift, stoppt Apache die Verarbeitung der übrigen Rewrite-Regeln in diesem Durchlauf und verwendet das bisherige Ergebnis. Da Apache Regeln der Reihe nach von oben nach unten auswertet, verändert die Reihenfolge deiner Regeln das Ergebnis genauso stark wie die Regeln selbst. Eine breit gefasste Regel weiter oben kann bereits greifen und die Verarbeitung stoppen, bevor eine spezifischere Regel weiter unten überhaupt zum Zug kommt, oder ein fehlendes [L] lässt mehrere Regeln nacheinander feuern und erzeugt eine ganz andere URL als beabsichtigt. Das ist eines der Dinge, die sich am schwersten allein durch das Lesen von Rohtext nachvollziehen lassen. Der Tester arbeitet deine Regeln in derselben Reihenfolge von oben nach unten ab wie Apache und markiert genau, wo [L] die Verarbeitung stoppt, sodass du siehst, ob eine Regel die darunterliegenden vorzeitig aussticht, bevor es live geht.

Der häufigste Grund ist der führende Schrägstrich. In einer .htaccess-Datei auf Verzeichnisebene übergibt Apache das Muster deiner RewriteRule bereits ohne den führenden Schrägstrich, sodass ein Muster wie ^/alte-seite niemals greift — du willst stattdessen ^alte-seite verwenden. Weitere häufige Ursachen sind ein nicht escapter Punkt (verwende \. für einen wörtlichen Punkt), ein zu gieriges Muster wie (.*), das mehr erfasst als beabsichtigt, eine RewriteCond oberhalb der Regel, die still scheitert, sodass die Regel übersprungen wird, oder RewriteEngine, das nie auf On gesetzt wurde. Auch Regex-Anker spielen eine Rolle: ^ und $ fixieren Anfang und Ende des Pfads. Die Schritt-für-Schritt-Auswertung hier zeigt den Wert, der mit deinem Muster verglichen wird, und einen verständlichen Hinweis, ob es gegriffen hat oder übersprungen wurde und warum — das grenzt die Ursache meist in Sekunden ein. Füge die Regel und einen Beispielpfad ein, um es zu prüfen.

Eine Redirect-Schleife entsteht, wenn eine Regel eine URL immer wieder auf ein Ziel umschreibt, das dieselbe Regel erneut trifft, sodass der Browser endlos hin- und herspringt und einen ERR_TOO_MANY_REDIRECTS-Fehler anzeigt. Typische Ursachen sind eine HTTPS-erzwingende Regel, deren Bedingung hinter einem Proxy nie erfüllt wird, eine www-Regel, die durch ihre eigene Ausgabe erneut ausgelöst wird, oder zwei Regeln, die aufeinander verweisen. Die Lösung ist meist eine engere RewriteCond, die den bereits korrekten Zustand ausschließt — zum Beispiel nur weiterzuleiten, wenn %{HTTPS} aus ist — plus ein korrektes [L]-Flag, um die weitere Verarbeitung zu stoppen. Statisches Lesen der Regeln deckt eine Schleife nur selten auf. Führe dein Snippet gegen eine Test-URL im Tester aus und beobachte die Auswertung: Würde die Ausgabe-URL erneut dieselbe passende Regel treffen, macht die Schritt-für-Schritt-Auswertung diese Kette sichtbar, sodass du sie durchbrechen kannst, bevor du live gehst.

Nicht zuverlässig, und das ist so gewollt. Bedingungen wie RewriteCond %{REQUEST_FILENAME} !-f oder -d fragen Apache, ob auf der Festplatte eine echte Datei oder ein echtes Verzeichnis existiert, und ein Browser hat keinen Zugriff auf das Dateisystem deines Servers. Deshalb nähert der Tester diese an: Datei- und Verzeichnis-Existenztests lösen sich immer zu false auf, und %{REQUEST_FILENAME} wird durch den Request-Pfad ersetzt statt durch einen echten Dateisystempfad. Das bedeutet, dass Logik, die von -f, -d oder -e abhängt — üblich bei Front-Controller-Setups, die fehlende Dateien an index.php weiterleiten — sich hier nicht exakt so verhält wie auf Apache. Das Tool ist dafür gebaut, Logik, Reihenfolge und Flags deiner Rewrite- und Redirect-Regeln schnell und privat zu prüfen. Nutze es, um Muster, Capture-Gruppen, Statuscodes und das [L]-Verhalten hier zu bestätigen, und verifiziere alles Dateisystem-Abhängige anschließend auf deinem tatsächlichen Server, bevor es live geht.