- 301 ist dauerhaft: Google überträgt die Linkkraft und aktualisiert den Index. 302 und 307 sind temporär: der ursprüngliche URL bleibt im Index, die Linkkraft wird nicht zuverlässig weitergegeben.
- Nach jedem Relaunch, Domainumzug oder HTTPS-Wechsel müssen alle alten URLs per 301 auf die neuen zeigen, sonst entstehen 404-Fehler und Ranking-Verluste.
- Serverseitige Weiterleitungen per .htaccess sind schneller und zuverlässiger als Plugin-Lösungen, benötigen aber einen Apache-Server mit aktivem mod_rewrite.
- Bei einem korrekt gesetzten 301 geht keine Linkkraft verloren. Redirect-Ketten und Schleifen kosten dagegen Ladezeit und können die Übertragung verzögern oder abschwächen. Jede Weiterleitung sollte direkt auf das Ziel zeigen, nie über Zwischenstopps.
Eine Weiterleitung ist schnell gesetzt, aber falsch konfiguriert kostet sie Rankings und Link-Kraft. Dieser Ratgeber richtet sich an alle, die eine WordPress-Website nach einem Relaunch, einem Domainumzug oder einer HTTPS-Umstellung absichern wollen und die Technik dahinter wirklich verstehen möchten, nicht nur den Copy-Paste-Code.
Was 301, 302, 307 und 308 bedeuten
HTTP-Statuscodes im 3xx-Bereich signalisieren dem Browser und Suchmaschinen-Crawlern, dass eine Ressource nicht mehr an der angefragten Adresse liegt. Vier Codes sind im Alltag relevant.
| Statuscode | Bedeutung | Methode erhalten? | SEO-Wirkung |
|---|---|---|---|
| 301 Moved Permanently | Ressource dauerhaft verschoben | Nein (Browser wechselt meist zu GET) | Linkkraft wird weitergegeben, alter URL wird aus dem Index entfernt |
| 302 Found | Ressource vorübergehend woanders | Nein (Browser wechselt meist zu GET) | Alter URL bleibt im Index, Linkkraft wird kaum weitergegeben |
| 307 Temporary Redirect | Temporär, Methode muss gleich bleiben | Ja (POST bleibt POST) | Wie 302, aber methodengenau |
| 308 Permanent Redirect | Dauerhaft, Methode muss gleich bleiben | Ja (POST bleibt POST) | Wie 301, aber methodengenau |
Der Unterschied zwischen 301 und 307 ist für Formularverarbeitungen relevant: sendet ein Browser per POST eine Anfrage und bekommt einen 301 zurück, wechselt er für den Folgerequest auf GET. Das ist in der Praxis oft erwünscht, bei Checkout-Flows aber problematisch. 307 erzwingt, dass POST als POST bleibt. Für normale URL-Umzüge in WordPress spielt das keine Rolle, weil dort immer GET-Requests weitergeleitet werden.
Technisch korrekt definiert sind alle vier Codes in RFC 9110, dokumentiert von MDN. Google behandelt 301 und 308 gleich: beide übertragen Linkkraft und lösen eine Index-Aktualisierung aus.
Wann welcher Statuscode richtig ist
Die Entscheidung ist einfacher als sie klingt. Wer sich an drei Fragen hält, liegt richtig.
Ist die Änderung dauerhaft? Dann 301. Das gilt für Relaunch mit neuer URL-Struktur, Domainumzug, HTTPS-Umstellung, Slug-Änderung und das Zusammenlegen von Seiten. Alles, was nicht mehr rückgängig gemacht wird, bekommt einen 301.
Ist die Änderung wirklich nur temporär? Dann 302 oder 307. Das trifft auf Wartungsseiten zu, auf A/B-Tests oder saisonale Kampagnenseiten, die nach der Aktion wieder auf die ursprüngliche URL zeigen sollen. Der Originalurl bleibt im Index, der Test-URL taucht dort nicht dauerhaft auf.
Muss die HTTP-Methode erhalten bleiben? Bei normalen WordPress-Seiten nie. Bei API-Endpunkten oder Formular-Zielen manchmal, dann 307 statt 302, beziehungsweise 308 statt 301.
Weiterleitungen per .htaccess einrichten
Wer auf einem Apache-Server hostet, was bei den meisten Shared-Hosting-Paketen in Deutschland der Fall ist, hat zwei Direktiven zur Wahl: Redirect aus mod_alias und RewriteRule aus mod_rewrite. Beide landen in der .htaccess-Datei im WordPress-Wurzelverzeichnis.
Die WordPress-eigene .htaccess enthält den Rewrite-Block für Permalinks. Eigene Weiterleitungen kommen oberhalb dieses Blocks, damit sie vor dem WordPress-Routing greifen.
Einzelne URL mit mod_alias umleiten
Redirect aus mod_alias ist für einfache 1:1-Weiterleitungen die sauberste Wahl. Die Syntax ist geradlinig. Legen Sie vor jeder Änderung eine Sicherungskopie der .htaccess an, denn eine fehlerhafte Regel kann die ganze Website mit einem 500-Fehler lahmlegen, und testen Sie wenn möglich erst auf einer Staging-Kopie. Ordnen Sie Ihre Regeln von spezifisch nach allgemein an, sonst fängt ein Catch-all am Ende die Einzelregeln davor ab:
# Einzelne Seite dauerhaft weiterleiten (301)
Redirect 301 /alter-slug/ https://www.beispiel.de/neuer-slug/
# Einzelne Seite temporaer weiterleiten (302)
Redirect 302 /kampagne-sommer/ https://www.beispiel.de/angebote/Der erste Parameter ist der Statuscode, der zweite der Pfad ohne Domain, der dritte das vollständige Ziel mit Protokoll.
Muster mit mod_rewrite und RewriteRule
RewriteRule aus mod_rewrite erlaubt reguläre Ausdrücke und ist damit für Massen-Umzüge und Muster unverzichtbar. Der Block baut auf dem aktivierten Rewrite-Modul auf:
# mod_rewrite aktivieren und Basis setzen
RewriteEngine On
RewriteBase /
# HTTP auf HTTPS weiterleiten
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# www-Variante auf non-www weiterleiten (oder umgekehrt)
RewriteCond %{HTTP_HOST} ^www.beispiel.de [NC]
RewriteRule ^(.*)$ https://beispiel.de/$1 [R=301,L]
# Altes Verzeichnis auf neues umleiten (alle URLs darunter)
RewriteRule ^blog/(.*)$ /ratgeber/$1 [R=301,L]Die Flags in den eckigen Klammern bedeuten: R=301 ist der Statuscode, L beendet die Regelverarbeitung nach dieser Regel (Last). Ohne L laufen alle folgenden Regeln durch, was zu unerwarteten Doppelweiterleitungen führt.
HTTPS-Umstellung: die vollständige .htaccess
Bei einer HTTPS-Umstellung müssen zwei Fälle abgedeckt sein: HTTP auf HTTPS und www auf non-www (oder umgekehrt). Die Reihenfolge ist entscheidend, damit keine Kette entsteht:
RewriteEngine On
RewriteBase /
# 1. HTTP auf HTTPS (greift für www und non-www gleichzeitig)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# 2. www auf non-www (nur für HTTPS, da HTTP-Regel oben schon abgefangen)
RewriteCond %{HTTP_HOST} ^www.beispiel.de [NC]
RewriteRule ^(.*)$ https://beispiel.de/$1 [R=301,L]
# BEGIN WordPress (nicht veraendern)
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressAuf Hosting-Umgebungen, die HTTPS über einen Load-Balancer oder Proxy abwickeln (etwa all-inkl.com oder Strato), meldet %{HTTPS} manchmal off, obwohl die Verbindung verschlüsselt ist. Dann greift der Header X-Forwarded-Proto:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]Die Dokumentation zu allen mod_rewrite-Direktiven und Flags liegt auf httpd.apache.org, mod_alias-Syntax auf der mod_alias-Seite.
Plugin-Lösung: Redirection für WordPress
Wer keinen direkten Zugriff auf die .htaccess hat oder Weiterleitungen ohne Serverkenntnis verwalten will, greift auf Redirection zurück. Das Plugin ist das meistgenutzte seiner Art in der WordPress-Welt und hat eine übersichtliche Oberfläche für einzelne URLs und Gruppen.
Redirection speichert seine Regeln in einer eigenen Datenbanktabelle und greift in WordPress-Hooks ein, bevor der eigentliche Request verarbeitet wird. Das ist etwas langsamer als eine .htaccess-Regel, die direkt auf Apache-Ebene greift, in der Praxis aber vernachlässigbar, sofern die Weiterleitungsliste nicht auf Tausende Einträge anwächst.
Was das Plugin leistet, was .htaccess nicht bietet:
- Protokollierung jedes Hits auf eine Weiterleitung
- Automatische Erkennung von 404-Fehlern und Vorschlag passender Ziele
- Import und Export per CSV
- Reguläre Ausdrücke über die Oberfläche, ohne .htaccess-Syntaxkenntnisse
Wann .htaccess besser ist: Bei Massen-Redirects nach einem Relaunch mit Hunderten URLs ist eine .htaccess-Datei schneller im Durchsatz. Wann das Plugin besser ist: Wenn ein Kunde selbst Weiterleitungen verwalten soll, ohne Serverzugriff, oder wenn eine detaillierte Fehlerprotokollierung gewünscht wird.
Massen-Redirects aus einer Mapping-Liste
Nach einem Relaunch mit geänderter URL-Struktur stehen oft Dutzende oder Hunderte alter URLs an, die weitergeleitet werden müssen. Das läuft am saubersten über eine CSV-Mapping-Datei: zwei Spalten, alt und neu, eine URL pro Zeile.
Variante 1: .htaccess aus CSV generieren
Eine einfache PHP-Zeile wandelt die CSV in Redirect-Direktiven um:
// mapping.csv: alte-url,neue-url (eine Zeile pro Redirect)
$rows = array_map('str_getcsv', file('mapping.csv'));
foreach ($rows as $row) {
echo 'Redirect 301 ' . trim($row[0]) . ' https://www.beispiel.de' . trim($row[1]) . "\n";
}Die Ausgabe direkt in die .htaccess oberhalb des WordPress-Blocks einfügen. Bei mehr als 500 Weiterleitungen die Performance prüfen, denn Apache liest die Datei bei jedem Request.
Variante 2: CSV in Redirection importieren
Das Plugin Redirection versteht ein CSV-Format mit den Spalten source und target. Über Tools > Redirection > Import/Export eine CSV dieser Struktur hochladen und der Import setzt alle Regeln in einem Schritt. Vorteil: Änderungen sind über die Oberfläche nachvollziehbar, ohne Serverzugang.
Bei einem Relaunch mit vielen Produktseiten erzeugt man die URL-Mapping-Tabelle aus dem alten Sitemap-Export und dem neuen URL-Schema und importiert sie per CSV in Redirection. Die Konfiguration ist meist schnell erledigt. Entscheidend ist, die Slugs vorab in einem Staging-System zu testen, bevor der scharfe DNS-Wechsel läuft. Dazu eignet sich eine Staging-Umgebung besonders gut.
Redirect-Ketten und Schleifen vermeiden
Redirect-Ketten entstehen häufig durch nacheinander angelegte Regeln ohne Kontrolle des Gesamtbilds. Typisches Muster nach einem doppelten Relaunch: die erste Umstellung leitet /seite-alt/ auf /seite-interim/ weiter, die zweite Umstellung leitet /seite-interim/ auf /seite-neu/ weiter. Browser und Crawler folgen der Kette, aber Google gibt bei langen Ketten an, dass Linkkraft mit jedem Hop abnehmen kann.
Ketten erkennen:
- Alle Weiterleitungen in eine Tabelle exportieren (Redirection-Export oder manuelle .htaccess-Analyse)
- Für jeden Quell-URL das echte Endziel per
curl -L -Iprüfen und die Zwischenstopps zählen - Mehr als ein Hop ist immer vermeidbar
Ketten beheben: Die älteste Regel aktualisieren, sodass sie direkt auf das endgültige Ziel zeigt, und die Zwischenregel entfernen. Bei .htaccess-Regeln heißt das: die Quell-URL aus der alten Regel direkt auf den finalen Ziel-URL umbiegen.
# Schlecht: Kette über zwei Schritte
Redirect 301 /alt/ /interim/
Redirect 301 /interim/ /neu/
# Richtig: direkt ans Ziel
Redirect 301 /alt/ /neu/
Redirect 301 /interim/ /neu/Schleifen erkennt man daran, dass curl -L -I <url> abbricht oder eine sehr lange Folge gleicher URLs ausgibt. Apache selbst bricht bei einer Redirect-Schleife mit einem 500-Fehler ab und schreibt das in das Error-Log.
Weiterleitung vs. Canonical-Tag
Beide Mechanismen signalisieren Suchmaschinen, welche URL die bevorzugte ist. Sie lösen aber unterschiedliche Probleme und ersetzen sich nicht gegenseitig.
| Merkmal | 301-Weiterleitung | Canonical-Tag |
|---|---|---|
| Wirkung auf Besucher | Browser landet automatisch auf dem Ziel | Besucher bleibt auf der aktuellen URL |
| Wirkung auf Google | Alter URL wird aus dem Index entfernt | Alter URL kann im Index bleiben, Ranking geht ans Canonical |
| Typischer Einsatz | URL existiert nicht mehr oder ist permanent umgezogen | Duplizierter Inhalt unter mehreren URLs, z.B. Filterkombinationen |
| Linkkraft | Wird auf Ziel übertragen | Wird auf Canonical-URL zugeschrieben |
| Stärke des Signals | Hart, Google folgt fast immer | Empfehlung, Google kann abweichen |
Beispiele für die richtige Wahl: Der alte Slug /über-uns/ wurde zu /unternehmen/ umbenannt? Eine 301-Weiterleitung ist die einzig richtige Lösung, nicht ein Canonical. Ein Produktfilter erzeugt URLs wie /schuhe/?farbe=rot? Ein Canonical auf die Hauptkategorie /schuhe/ ist richtig, eine Weiterleitung wäre falsch, weil die Filterseite für Besucher erreichbar bleiben soll.
Ein häufiger Fehler: Nach einem Relaunch wird ein Canonical auf die neue URL gesetzt, aber die alte URL bleibt ohne Weiterleitung erreichbar. Google sieht dann zwei Seiten mit ähnlichem Inhalt und muss entscheiden, welche es indexiert. Das Ergebnis ist unsicher und dauert länger als eine saubere 301-Weiterleitung.
SEO-Erhalt: Ranking und Linkkraft mitnehmen
Google überträgt bei einem 301 die Bewertung einer Seite auf das Ziel. In der Praxis heißt das: externe Links, die auf eine alte URL zeigen, arbeiten nach der Weiterleitung für die neue URL. Das dauert einige Wochen bis Monate, bis der Crawler alle betroffenen URLs erneut besucht hat und den Index aktualisiert.
Was beim Relaunch beachtet werden muss:
- Jede alte URL, die in Google Search Console Impressionen oder Klicks hatte, braucht eine 301-Weiterleitung. Nicht nur die Top-Seiten, sondern alle.
- URLs, die von externen Seiten verlinkt werden, haben besonders hohe Priorität. Die Linkliste aus Google Search Console (Verknüpfungen) oder einem Backlink-Tool exportieren und gegen die Weiterleitungsliste abgleichen.
- Interne Links im neuen System sollten direkt auf die neuen URLs zeigen, nicht auf die alten und dann durch die Weiterleitung laufen.
- Die XML-Sitemap nach dem Launch sofort aktualisieren: nur neue URLs, keine Weiterleitungen und keine 404-Seiten in der Sitemap.
Wie viel Ranking tatsächlich verloren geht, hängt davon ab, wie viele externe Links auf die alten URLs zeigen und wie konsistent die Weiterleitungen gesetzt sind. Eine vollständige Mapping-Datei vor dem Launch und ein XML-Sitemap-Abgleich nach dem Launch sind die zwei wichtigsten Kontrollpunkte. Den größeren Kontext zum Relaunch-Prozess erklärt der Artikel Content-Migration beim Relaunch ohne Ranking-Verlust.
Google beschreibt das Verhalten bei Umzügen und dauerhaften Weiterleitungen in seinen offiziellen Richtlinien zu 301-Redirects und im Leitfaden zu Website-Umzügen mit URL-Änderungen.
404-Monitoring einrichten
Weiterleitungen zu setzen ist der erste Schritt. Der zweite ist sicherzustellen, dass keine URL vergessen wurde und keine neue 404-Seite durch spätere Content-Änderungen entsteht.
Google Search Console ist die einfachste Monitoring-Quelle: Unter Abdeckung beziehungsweise Indexierung zeigt die Konsole alle URLs, die mit einem Fehler gecrawlt wurden. Nach einem Relaunch täglich prüfen, in den ersten vier Wochen mindestens. Jede neue 404-Meldung zeigt, dass eine Weiterleitung fehlt.
Das Plugin Redirection protokolliert ebenfalls 404-Fehler und schlägt passende Weiterleitungen vor, wenn der Ziel-URL semantisch ähnlich ist. Das hilft besonders bei URLs, die organisch auftauchen, etwa weil ein externer Artikel verlinkt, der nicht in der ursprünglichen Mapping-Datei stand.
Für automatisches Monitoring eignen sich Dienste wie Website Monitoring, die bei einem Statuscode-Wechsel oder beim Auftauchen von 404-Seiten auf wichtigen URLs eine Benachrichtigung senden.
Sofort-Checkliste
- Ist jede alte URL mit einem 301 auf die neue URL verwiesen?
- Haben HTTP-Varianten (http://) und www-Varianten ebenfalls eine Weiterleitung auf HTTPS und die bevorzugte Domain?
- Zeigt die XML-Sitemap ausschließlich neue, indexierbare URLs?
- Sind alle internen Links im neuen System auf die neuen URLs aktualisiert?
- Gibt es keine Redirect-Ketten mit mehr als einem Hop?
- Gibt es keine Redirect-Schleifen?
- Liefern alle Weiterleitungs-URLs mit curl -L -I den HTTP-Status 301?
- Ist ein 404-Monitoring aktiv (Google Search Console oder Redirection-Plugin)?
- Haben externe Backlink-Quellen eine gültige Weiterleitung auf den neuen URL?
- Sind Canonical-Tags im neuen System auf die neuen URLs gesetzt?
- 301 ist dauerhaft und überträgt Linkkraft. 302 und 307 sind temporär und sollten nur eingesetzt werden, wenn die ursprüngliche URL wirklich erhalten bleiben soll.
- Serverseitige Weiterleitungen per .htaccess sind schneller als Plugin-Lösungen. Redirection ist besser, wenn Protokollierung und Verwaltung ohne Serverzugriff nötig sind.
- Redirect-Ketten immer auf direkten Sprung ans Ziel kürzen. Jeder Zwischenstopp schwächt die übertragene Linkkraft.
- Ein Canonical-Tag ersetzt keine Weiterleitung, wenn der alte URL dauerhaft entfernt wird. Beide Mechanismen haben unterschiedliche Aufgaben.
Häufige Fragen
Was passiert mit dem Ranking, wenn ich einen 301 setze?
Google überträgt die Bewertung eines URL auf das Ziel, wenn ein 301 gesetzt ist. Das dauert einige Wochen bis Monate, weil der Crawler alle betroffenen Seiten erneut besuchen muss. Kurzfristig kann es zu leichten Schwankungen kommen, langfristig sollte das Ranking stabil bleiben, sofern alle alten URLs lückenlos weitergeleitet sind.
Wie viel Linkkraft geht bei einer 301-Weiterleitung verloren?
Google hat mehrfach erklärt, dass bei einem korrekt gesetzten 301 keine PageRank-Verluste entstehen. In älteren Quellen war von einem geringen Verlust die Rede, das gilt nach aktuellem Stand aber nicht mehr. Ketten aus mehreren 301s können die Übertragung verzögern oder abschwächen, ein direkter 301 ohne Zwischenstopps ist aber gleichwertig mit einem direkten Link.
Darf ich einen 302 setzen und später auf 301 ändern?
Ja. Wenn der Ziel-URL zum Zeitpunkt der Weiterleitung noch nicht feststeht, ist ein 302 als Platzhalter sinnvoll. Browser cachen 302-Antworten kürzer oder gar nicht, sodass die Korrektur auf 301 ohne hartnäckige Cache-Probleme greift. Den Wechsel so früh wie möglich machen, damit der Index sauber ist.
Kann ich einen gesetzten 301 wieder rückgängig machen?
Technisch ja: die Regel entfernen oder ändern. Der Haken ist der Browser-Cache. 301-Antworten werden von manchen Browsern sehr lange gespeichert, manchmal dauerhaft bis zum manuellen Cache-Löschen. Google hingegen folgt bei einem geänderten Statuscode relativ schnell und aktualisiert den Index nach dem nächsten Crawl.
Was tun, wenn nach dem Relaunch viele 404-Fehler auftauchen?
Zuerst in Google Search Console unter Indexierung nach den betroffenen URLs suchen. Dann prüfen, ob diese URLs in der Mapping-Datei fehlen. Fehlende Weiterleitungen sofort nachtragen, entweder per .htaccess oder im Redirection-Plugin. Parallel prüfen, ob interne Links im neuen System noch auf alte URLs zeigen.
Brauche ich für HTTPS ein Plugin oder reicht .htaccess?
Bei einem Apache-Server reicht die .htaccess. Das Plugin Redirection kann HTTP-auf-HTTPS ebenfalls verwalten, aber eine .htaccess-Regel greift auf Serverebene noch bevor WordPress oder PHP geladen wird, was schneller und zuverlässiger ist. Viele Hosting-Anbieter bieten die HTTPS-Weiterleitung auch direkt in der Hosting-Oberfläche an, was noch besser ist als eine .htaccess-Regel.
Was ist der Unterschied zwischen Redirect und RedirectMatch in Apache?
Redirect behandelt Pfade als genaue Zeichenfolge oder Präfix. RedirectMatch erlaubt reguläre Ausdrücke im Pfad, ähnlich wie RewriteRule in mod_rewrite. Für einzelne genaue URLs ist Redirect sauberer und schneller. Für Muster wie alle PDFs in einem Verzeichnis ist RedirectMatch oder RewriteRule die richtige Wahl.
Wie teste ich, ob meine Weiterleitungen korrekt funktionieren?
Mit dem Kommandozeilen-Tool curl: curl -L -I https://alte-url.de/pfad/ zeigt alle Statuscodes entlang der Weiterleitungskette. Wichtig ist das -L-Flag, das Weiterleitungen folgt, damit die gesamte Kette sichtbar wird. Online-Tools wie httpstatus.io zeigen dasselbe mit grafischer Oberfläche.