htaccess-Generator: 301-Weiterleitungen für Relaunch und Umzug

Google empfiehlt in der eigenen Dokumentation zum Domainumzug wörtlich, 301-Weiterleitungen „so lange wie möglich, in der Regel mindestens ein Jahr" bestehen zu lassen. Genau daran scheitern die meisten Relaunches: Die Regeln werden hektisch am Umzugstag geschrieben, keiner prüft sie, und nach drei Monaten räumt jemand die .htaccess auf. Der Generator hier baut Ihnen den Block – für Apache und für Nginx – und sagt Ihnen vorher, wo Ketten, Dubletten und Regex-Fallen stecken.

htaccess-Redirect-Generator

Tragen Sie Ihre Paare aus alter und neuer Adresse ein – eine Zeile je Weiterleitung, getrennt durch Komma, Semikolon, Tabulator oder Leerzeichen. Ein CSV-Export aus Excel lässt sich direkt hineinkopieren. Über die Voreinstellungen oben schalten Sie die Standardfälle dazu: kompletter Domainumzug, http auf https, www hinzufügen oder entfernen, Schrägstrich am Ende vereinheitlichen, index.php aus den URLs werfen.

Der Block erscheint hier.

Der Block erscheint hier.

Welche Regeln der Generator baut

Der Block hat immer dieselbe Reihenfolge, und die ist kein Zufall: zuerst die spezifischen Einzelregeln, danach die allgemeinen. Der Grund ist einfach zu rechnen. Angenommen, jemand ruft http://www.alte-domain.de/produkte/alt-artikel.html auf, Sie ziehen auf https://neue-domain.de um, und der Artikel heißt jetzt anders.

• Allgemeine Regel zuerst: Sprung 1 auf https, Sprung 2 auf die neue Domain, Sprung 3 auf die neue Adresse. Drei Weiterleitungen für einen Aufruf.
• Spezifische Regel zuerst, Ziel als vollständige URL: ein einziger Sprung direkt auf https://neue-domain.de/shop/neuer-artikel/.

Deshalb setzt der Generator die Einzelregeln nach oben und schreibt die Ziele auf Wunsch als vollständige Adresse mit Schema und Domain. Das kostet Sie ein paar Zeichen mehr in der Datei und spart bei jedem Aufruf zwei Netzwerkrunden. Erst darunter folgen index.php-Regel, Schrägstrich-Regel, der Umzugs-Fallback für alle übrigen Pfade und ganz zum Schluss die Kanonisierung auf https und die gewählte www-Variante.

Bei den Einzelregeln haben Sie die Wahl zwischen zwei Formen. Redirect 301 stammt aus dem Modul mod_alias und ist die kürzere. Apache empfiehlt sie in der eigenen Dokumentation ausdrücklich: „This kind of simple redirection of one URL, or a class of URLs, to somewhere else, should be accomplished using these directives rather than RewriteRule." Sie hat aber eine Eigenheit, die viele überrascht: Sie vergleicht nur den Anfang des Pfades und hängt den Rest an das Ziel an. Aus Redirect 301 /shop /neu wird auch /shop/artikel zu /neu/artikel. Der Generator warnt, sobald ein Quellpfad der Anfang eines anderen ist.

RewriteRule aus mod_rewrite ist genauer, weil das Muster ein regulärer Ausdruck mit Anfang und Ende ist. Dafür müssen Sonderzeichen maskiert werden – der Punkt in .html steht in einem regulären Ausdruck sonst für ein beliebiges Zeichen. Der Generator setzt die Rückstriche automatisch. Und eine Falle, die reihenweise Regeln stillschweigend wirkungslos macht: In der .htaccess wird der Verzeichnispfad vor dem Vergleich entfernt. Ein Muster, das mit ^/ beginnt, trifft laut Apache-Dokumentation deshalb niemals. Richtig ist ^alte-seite$, nicht ^/alte-seite$.

301, 302, 307 oder 308 – welcher Code wann

Google unterscheidet in der Dokumentation zu Weiterleitungen nur zwei Gruppen. Dauerhafte Weiterleitungen (301 und 308) führen dazu, dass in den Suchergebnissen das neue Ziel erscheint. Temporäre Weiterleitungen (302, 303 und 307) führen dazu, dass weiterhin die alte Seite angezeigt wird. Für alles, was dauerhaft ist, gibt es damit nur eine sinnvolle Wahl.

Der Unterschied zwischen 302 und 307 liegt nicht bei Google, sondern beim Client. Laut MDN garantiert 307, dass Methode und Body der Anfrage unverändert bleiben; bei 302 haben ältere Clients fälschlich auf GET gewechselt. Bei einem GET-Aufruf – also praktisch jedem Seitenaufruf – verhalten sich beide identisch. 308 ist die methodenerhaltende Variante von 301. Für Weiterleitungen von Webseiten reicht 301; 308 ist dort interessant, wo auch POST-Anfragen weitergeleitet werden, etwa bei APIs.

Ein Punkt, der in der Praxis oft übersehen wird: Google zählt einen sofortigen Meta-Refresh (0 Sekunden) als dauerhafte Weiterleitung und einen verzögerten als temporäre. JavaScript-Weiterleitungen sollen Sie laut Dokumentation nur nutzen, wenn serverseitige Weiterleitungen und Meta-Refresh nicht möglich sind, weil das Rendering aus verschiedenen Gründen fehlschlagen kann. Serverseitige Weiterleitungen haben „the highest chance of being interpreted correctly by Google". Genau die erzeugt dieses Werkzeug.

Wie lange Weiterleitungen bestehen bleiben müssen

Die kürzeste belastbare Antwort steht in Googles Dokumentation zum Domainumzug: mindestens ein Jahr, besser länger. Wörtlich heißt es dort: „Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs." Aus Nutzersicht spricht nichts dagegen, sie unbefristet zu behalten – alte Links in E-Mails, PDFs, Foren und Lesezeichen laufen noch Jahre später auf.

Wie lange der Umzug selbst dauert, sagt dieselbe Quelle ebenfalls: Bei kleinen und mittleren Websites ziehen die meisten Seiten „a few weeks" um, bei größeren länger. Wer nach zehn Tagen in Panik gerät und Regeln zurückdreht, macht es schlimmer. Meine Empfehlung aus der Praxis: Setzen Sie sich einen Kalendereintrag 14 Monate nach dem Umzug. Erst dann prüfen Sie, welche alten Adressen laut Server-Logs und Search Console überhaupt noch aufgerufen werden, und räumen nur die auf, die seit Monaten niemand mehr anfasst.

Ein Detail zum Aufräumen: Google warnt ausdrücklich davor, viele alte Adressen auf ein einziges, thematisch unpassendes Ziel weiterzuleiten – typischerweise die Startseite. Das kann als Soft 404 gewertet werden. Wenn es keine passende neue Seite gibt, ist ein sauberer 410 oder 404 die ehrlichere Lösung als eine Weiterleitung ins Nichts.

Redirect-Ketten und Linkkraft

Eine Redirect-Kette entsteht, wenn das Ziel einer Regel gleichzeitig die Quelle einer anderen ist: A leitet auf B, B leitet auf C. Bei jedem Relaunch, der auf einen früheren Relaunch folgt, wächst so eine Kette, ohne dass es jemand merkt. Der Generator meldet solche Fälle, sobald sie in Ihrer Liste stehen.

Die Zahlen dazu stehen in zwei Dokumentationen. Google schreibt zum Domainumzug, dass der Googlebot bis zu zehn Sprüngen in einer Kette folgt, empfiehlt aber die direkte Weiterleitung auf das Endziel und nennt als Richtwert weniger als drei, maximal fünf. Die Lighthouse-Prüfung in Chrome bewertet eine Seite bereits ab zwei Weiterleitungen als durchgefallen und begründet das mit der Ladezeit: Jede zusätzliche Runde durch das Netz kann das Laden „by hundreds of milliseconds" verzögern.

Und die Frage, die bei jedem Relaunch gestellt wird: Geht Linkkraft verloren? Die meistzitierte Antwort stammt von Gary Illyes, damals bei Google, vom 26. Juli 2016: „30x redirects don't lose PageRank anymore." Das war ein Beitrag in einem sozialen Netzwerk, keine Aussage aus der Dokumentation, und Google hat sie nie dorthin übernommen – ich zitiere sie deshalb als das, was sie ist. Dokumentiert ist etwas anderes, aber Verwandtes: Eine dauerhafte Weiterleitung ist laut Google „a strong signal that the target of the redirect should become canonical", und die Kanonisierung hilft Suchmaschinen, „the signals they have for the individual URLs (such as links to them) into a single, preferred URL" zusammenzuführen. Die in SEO-Blogs kursierende Zahl von 15 Prozent Verlust pro Weiterleitung hat Google nie bestätigt. Ich lasse sie deshalb weg.

Praktisch relevant bleibt trotzdem: Ketten kosten Ladezeit, Crawl-Budget und Nerven. Wenn Sie beim zweiten Relaunch die alte Zuordnungstabelle nehmen und die Ziele direkt auf die neuen Endadressen umschreiben, statt eine zweite Regelebene daraufzusetzen, haben Sie das Problem gar nicht erst.

Relaunch-Checkliste in neun Schritten

Diese Reihenfolge hat sich bei mir bewährt. Sie folgt weitgehend Googles eigener Anleitung zum Domainumzug und ergänzt sie um die Punkte, an denen es in der Praxis hakt.

1. Alte URLs vollständig sammeln. Quellen: XML-Sitemap, Server-Logfiles der letzten zwölf Monate, Analytics, Search Console und ein Crawl der alten Website. Logfiles sind die wichtigste Quelle, weil dort auch Adressen auftauchen, die intern längst nicht mehr verlinkt sind.
2. Zuordnungstabelle bauen. Zwei Spalten, alt und neu, als Tabelle. Sortieren Sie nach Sitzungen oder Backlinks absteigend – die obersten 200 Zeilen entscheiden über den Großteil des Traffics.
3. Seiten ohne Nachfolger entscheiden. Für jede alte Adresse ohne passendes neues Pendant: nächstliegende Kategorieseite oder bewusst 410. Nicht sammelweise auf die Startseite.
4. Regeln erzeugen und lokal testen. Tabelle in den Generator kopieren, Warnungen abarbeiten, Block auf einer Staging-Umgebung einspielen.
5. Interne Links umstellen. Alle internen Verweise sollen direkt auf die neuen Adressen zeigen. Weiterleitungen sind für externe Links und Lesezeichen da, nicht für die eigene Navigation.
6. Sitemap und robots.txt anpassen. Nur die neuen Adressen in die Sitemap, alte Sitemap nach dem Umzug entfernen. Prüfen, dass die robots.txt die neuen Pfade nicht sperrt.
7. Umzug melden. Bei einem Wechsel der Domain oder Subdomain die Adressänderung in der Search Console nutzen. Bei einem Wechsel von http auf https, von www auf non-www oder bei reinen Pfadänderungen innerhalb derselben Domain ist das laut Google nicht nötig.
8. Am Umzugstag stichprobenartig prüfen. Zwanzig wichtige alte Adressen mit curl durchlaufen lassen, Statuscode und Endziel notieren.
9. Vier Wochen beobachten. Search Console, Sitemap-Bericht, Indexierung, 404-Fehler und Server-Logs. Jede alte Adresse, die noch 404 liefert, kommt als Regel nach.

Weiterleitungen testen: curl, DevTools, Screaming Frog

Eine Weiterleitung, die niemand geprüft hat, ist eine Vermutung. Google selbst verweist für den Test auf die URL-Prüfung in der Search Console für Einzelfälle und auf „command line tools or scripts to test large numbers of URLs" für große Mengen. Genau so gehe ich vor.

Für den Massentest reicht eine Textdatei mit den alten Adressen und eine Schleife in der Kommandozeile: while read u; do curl -sIL -o /dev/null -w "%{http_code} %{url_effective} $u" "$u"; done < alte-urls.txt. Sie bekommen pro Zeile den finalen Statuscode und die Zieladresse. Alles, was nicht mit 200 endet oder auf der Startseite landet, ist ein Kandidat für die Nacharbeit. Wichtig beim Testen: Browser cachen 301-Antworten hartnäckig. Prüfen Sie im privaten Fenster oder mit curl, sonst sehen Sie eine Regel, die es längst nicht mehr gibt.

Reihenfolge der Regeln in der .htaccess

Die .htaccess wird von oben nach unten gelesen, und bei mod_rewrite gilt laut Dokumentation: „The order in which rules are defined is important – they are applied in order at runtime." Für WordPress-Websites heißt das konkret: Ihre Weiterleitungen gehören über den WordPress-Block, also oberhalb der Zeile # BEGIN WordPress. Der Block darunter schickt alles, was keine Datei und kein Verzeichnis ist, an die index.php – danach kommt Ihre Regel nicht mehr zum Zug. Verlassen Sie sich außerdem nicht darauf, dass eigene Regeln zwischen den beiden Markern erhalten bleiben; WordPress schreibt diesen Bereich beim Speichern der Permalink-Einstellungen neu.

Wer eine WordPress-Website umzieht, findet in meinem Beitrag zu SEO für WordPress die Punkte, die zusätzlich zu den Weiterleitungen anstehen – von Permalink-Struktur über Indexierungssteuerung bis zu den Einstellungen, die ein Relaunch gerne zurücksetzt.

Zwei weitere Ordnungsregeln, die Zeit sparen. Erstens: spezifisch vor allgemein. Eine Regel, die ^(.*)$ abfängt, gehört ans Ende, sonst greift sie zuerst und alles darunter ist tot. Zweitens: pro Aufgabe ein Modul. Apache empfiehlt Redirect und RedirectMatch für einfache Weiterleitungen und stuft mod_rewrite als letztes Mittel ein. Das Mischen beider Module in einer Datei ist möglich, macht die tatsächliche Reihenfolge aber schwer vorhersagbar – das ist meine Einschätzung, keine dokumentierte Aussage. Wenn Sie unsicher sind, nehmen Sie im Generator durchgehend RewriteRule.

Apache und Nginx im Vergleich

Nginx kennt keine .htaccess. Alle Regeln stehen in der Server-Konfiguration und werden erst nach einem Reload aktiv – das ist der wesentliche Unterschied im Arbeitsablauf. Dafür ist die Syntax knapper: return 301 beendet die Verarbeitung sofort und schickt die Antwort, rewrite … permanent entspricht dem Apache-Flag [R=301]. Laut nginx-Dokumentation werden auch hier die Anweisungen „sequentially in order of appearance" abgearbeitet.

Ein Hinweis für große Regelsätze: Bei einigen hundert Weiterleitungen sind viele einzelne location-Blöcke unhandlich. Nginx bietet dafür einen map-Block, der die alte Adresse als Schlüssel und die neue als Wert führt; die eigentliche Weiterleitung besteht dann aus einer einzigen Zeile. Der Generator gibt der Übersichtlichkeit halber die location-Variante aus – sie ist leichter zu prüfen und für die typischen zwanzig bis hundert Regeln völlig ausreichend.

Typische Fehler

• Alles auf die Startseite: Der Klassiker beim Relaunch. Google wertet viele Weiterleitungen auf ein unpassendes Ziel als Soft 404 – der Effekt ist derselbe wie bei einem 404, nur ohne die ehrliche Fehlermeldung.
• 302 statt 301: Bei einer temporären Weiterleitung zeigt Google laut Dokumentation weiterhin die alte Seite in den Ergebnissen an. Bei einem Relaunch ist das genau das Gegenteil dessen, was Sie wollen.
• Schleifen: Eine Regel, die auf sich selbst zeigt, oder zwei Regeln, die sich gegenseitig aufrufen. Im Browser erscheint ERR_TOO_MANY_REDIRECTS. Der Generator markiert beide Fälle.
• Muster mit führendem Schrägstrich:RewriteRule ^/alte-seite$ trifft in der .htaccess nie, weil der Verzeichnispfad vorher entfernt wird. Ohne Fehlermeldung, die Regel ist einfach wirkungslos.
• Query-Strings vergessen: Weder Redirect noch das Muster einer RewriteRule prüfen den Teil hinter dem Fragezeichen. Für /index.php?id=12 brauchen Sie eine RewriteCond %{QUERY_STRING} davor.
• Groß- und Kleinschreibung: Der Pfadvergleich bei Redirect ist laut Apache-Dokumentation case-sensitive. Wer alte Adressen in gemischter Schreibweise hatte, braucht zusätzlich das Flag [NC] in einer RewriteRule.
• Schrägstrich am Ende ignorieren: Google behandelt /seite und /seite/ als zwei verschiedene URLs – so steht es seit dem Beitrag vom 21. April 2010 unverändert im Search-Central-Blog. Welche Variante Sie wählen, ist Google egal, Hauptsache konsistent. Nur die Startseite ist ausgenommen: Sie lässt sich nicht umleiten.
• Weiterleitung vergisst die Parameter: Zeigt ein Kampagnenlink auf eine Adresse, die weiterleitet, gehen UTM-Parameter verloren, wenn die Regel sie nicht mitnimmt. Bei mod_rewrite hilft das Flag [QSA].
• Keine Sicherungskopie: Eine kaputte .htaccess legt die komplette Website mit einem 500er lahm. Vor jeder Änderung eine Kopie mit Datum im Namen ablegen und nach dem Einspielen sofort eine beliebige Seite aufrufen.

Häufige Fragen

Wie erstelle ich eine 301-Weiterleitung in der htaccess?

Sie legen im Wurzelverzeichnis Ihrer Website eine Datei namens .htaccess an und schreiben pro Weiterleitung eine Zeile hinein, zum Beispiel: Redirect 301 /alte-seite.html https://ihre-domain.de/neue-seite/. Der Quellpfad muss mit einem Schrägstrich beginnen, ein relativer Pfad ist laut Apache-Dokumentation nicht erlaubt. Alternativ nutzen Sie RewriteRule mit dem Flag R=301, dann brauchen Sie vorher die Zeile RewriteEngine On.

Was ist der Unterschied zwischen 301 und 302?

Ein 301 ist dauerhaft, ein 302 vorübergehend. Google zeigt bei dauerhaften Weiterleitungen laut eigener Dokumentation das neue Ziel in den Suchergebnissen an, bei temporären dagegen weiterhin die alte Seite. Für Relaunch, Domainumzug, die Umstellung auf https und die Vereinheitlichung von www nehmen Sie deshalb immer 301.

Wie lange muss eine 301-Weiterleitung bestehen bleiben?

Google empfiehlt in der Dokumentation zum Domainumzug wörtlich, die Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. In dieser Zeit überträgt Google die Signale auf die neuen Adressen. Aus Nutzersicht spricht nichts dagegen, sie dauerhaft stehen zu lassen, solange die Liste gepflegt bleibt.

Geht bei einer 301-Weiterleitung Linkkraft verloren?

Gary Illyes von Google schrieb am 26. Juli 2016 auf Twitter, dass 30x-Weiterleitungen keinen PageRank mehr verlieren. Das ist eine Mitarbeiteraussage und steht so nicht in der offiziellen Dokumentation. Dokumentiert ist, dass eine dauerhafte Weiterleitung ein starkes Signal für die Kanonisierung ist und Google die Signale mehrerer URLs auf einer bevorzugten Adresse zusammenführt. Die oft genannte Zahl von 15 Prozent Verlust hat Google nie bestätigt.

Wie viele Weiterleitungen darf eine Kette haben?

Laut Googles Dokumentation zum Domainumzug folgt der Googlebot bis zu zehn Sprüngen in einer Kette. Empfohlen wird trotzdem, direkt auf das Endziel weiterzuleiten und unter drei Weiterleitungen zu bleiben, maximal fünf. Die Lighthouse-Prüfung in Chrome stuft eine Seite schon ab zwei Weiterleitungen als durchgefallen ein.

Warum funktioniert meine RewriteRule in der htaccess nicht?

Der häufigste Grund: In der .htaccess wird der Verzeichnispfad vor dem Vergleich entfernt. Ein Muster, das mit ^/ beginnt, kann laut Apache-Dokumentation deshalb niemals treffen. Schreiben Sie ^alte-seite$ statt ^/alte-seite$. Weitere Ursachen sind eine fehlende Zeile RewriteEngine On, ein AllowOverride, das die Datei ignoriert, und eine frühere Regel mit dem Flag L, die vorher greift.

Wie leite ich eine komplette Domain auf eine neue Domain um?

Mit zwei Zeilen in der .htaccess der alten Domain: RewriteCond %{HTTP_HOST} ^(www\.)?alte-domain\.de$ [NC] und RewriteRule ^(.*)$ https://neue-domain.de/$1 [R=301,L]. Damit landet jeder Pfad auf demselben Pfad der neuen Domain. Für die wichtigsten Seiten legen Sie zusätzlich einzelne Regeln davor, wenn sich die Adresse ändert. Bei einem echten Domainwechsel melden Sie den Umzug außerdem über die Adressänderung in der Google Search Console.