301 oder 302 Redirect? Die richtige Antwort in 30 Sekunden
8 Min. Lesezeit · zuletzt aktualisiert 2. Mai 2026
Hören Statt Lesen
TL;DR
Seite dauerhaft verschieben? Nimm 301. Nur vorübergehend? Nimm 302. Diese eine Regel deckt neun von zehn Redirect-Entscheidungen ab, die du jemals treffen wirst. (Die eine Ausnahme, für API-Endpunkte, bei denen der Request-Typ während der Verschiebung nicht wechseln darf, nutzt 307 oder 308. Die meisten brauchen das nie.)
Willst du wissen, was tatsächlich auf deiner Seite live ist? Es gibt einen einzeiligen Test, der dir den Code zeigt, den dein Server sendet. Wenn er 302 meldet und die Verschiebung dauerhaft sein sollte, rutschen deine Rankings gerade in Echtzeit ab. Wir führen dich unten durch den Test, ganz ohne Kommandozeilen-Kenntnisse.
Die Wiederherstellung dauert 2 bis 6 Wochen, sobald du den falschen Code korrigierst und Google bittest, die Seite erneut zu crawlen. Der größte Teil dieser Wartezeit besteht einfach darin, dass Googles Bots nach ihrem eigenen Rhythmus zurückkommen.
Wähle die Version dieses Leitfadens, die zu dir passt
Du kannst auch einfach scrollen. Alles unten ist der vollständige Leitfaden. Der Picker ordnet nur um, was für dich aufgeklappt wird. Wir verfolgen deine Auswahl nicht.
Es ist elf Uhr abends. Du bist drei Wochen in die Migration und der organische Traffic ist um 40 % eingebrochen. Das Dev-Team schwört, die Redirects seien in Ordnung. Die Search Console sieht normal aus. Aber die Linie in deinem Analytics-Chart fällt weiter, und du lädst sie immer wieder neu, als würden die Zahlen irgendwann etwas anderes sagen.
Hier kommt der Teil, den dir keiner verraten hat. Es gibt zwei Arten von Redirects, und für menschliche Besucher sehen sie identisch aus. Für Google liegen Welten dazwischen. Der eine sagt: Diese Seite ist für immer umgezogen, also übertrag alles. Der andere sagt: Diese Seite ist nur kurz weg, also lass die alte weiter ranken. Nimmst du während einer Migration den falschen, verbringen Suchmaschinen wochenlang im Unklaren darüber, welche Version deiner Seite sie eigentlich ranken sollen.
Die Lösung ist meistens eine einzige Zeile Code. Das Problem überhaupt zu finden, ist der schwierige Teil.
Dieser Leitfaden führt dich durch die ganze Geschichte. Die einfache Regel, um den richtigen Redirect zu wählen (es sind wirklich nur zwei Fragen). Fertigen Code zum Einfügen für das, worauf deine Seite läuft (WordPress, Shopify, Next.js, Apache, Nginx, alles dabei). Genau das, was du danach in der Google Search Console prüfen musst, um zu beweisen, dass der Fix funktioniert hat. Und falls dir der Fehler von jemand anderem in den Schoß gefallen ist, wartet am Ende ein vierstufiges Wiederherstellungs-Playbook.
Noch eines vorab. Glaub nicht, was dein SEO-Dashboard über Redirects sagt. Glaub auch nicht, was der Entwickler sagt. Prüf mit eigenen Augen, was dein Server tatsächlich zurückschickt. Don’t believe it. Prove it. Wir zeigen dir den einfachen Weg.
Die 30-Sekunden-Antwort
Seite für immer verschieben? Nimm 301. Nur kurz weg? Nimm 302. Der einzige weitere Fall, den du kennen solltest, sind API-Endpunkte, die brauchen 307 (temporär) oder 308 (permanent). Sofern du nicht als Entwickler mit APIs arbeitest, wirst du denen wahrscheinlich nie begegnen.
Diese eine Regel deckt 90 % der Entscheidungen ab. Warum ist die Wahl so wichtig? Weil der Redirect-Code zwei Jobs gleichzeitig erledigt. Er sagt Suchmaschinen, ob der Umzug permanent oder temporär ist. Und er sagt Browsern unauffällig, ob der Request-Typ (GET, POST, solche Dinge) auf dem Weg exakt gleich bleiben muss. Die meisten von uns müssen nur über den ersten Job nachdenken.
Unter der Haube funktioniert jeder Redirect gleich. Ein Besucher fragt die alte URL an. Dein Server schickt eine kurze Nachricht zurück: Diese Seite ist umgezogen, hier ist die neue Adresse. Die Zahl auf dieser Nachricht (301, 302, 307, 308) sagt Suchmaschinen, wie sie mit dem Umzug umgehen sollen.
Es gibt einen Haken, den du kennen solltest. Google hat 2016 leise geändert, wie 302er behandelt werden. Sie sind flexibler geworden und behandeln sie als echte Signale, aber nur wenn der Redirect lange genug bestehen bleibt und die neue Seite wirklich zur alten passt. Das SEO-Ergebnis (welche URL am Ende rankt, wohin deine Link-Equity fließt) hängt also von mehr ab als nur von der Zahl, die du gewählt hast. Wie lange der Redirect lebt. Wie ähnlich die Inhalte sind. Wie oft Google crawlt. All das spielt eine Rolle. Wir gehen gleich durch die Belege.
| Status | Bedeutung | Cachebar? | Methoden-sicher? | Link-Equity | Verwenden wenn |
|---|---|---|---|---|---|
| 301 | Permanent verschoben | Ja (lange TTL) | Nein (POST→GET erlaubt) | Vollständig zum Ziel | Permanente Umzüge |
| 302 | Gefunden (ursprünglich Temporär verschoben) | Nein (Standard) | Nein | Bleibt bei Quell-URL | Temporäre Ersetzungen |
| 303 | Siehe andere | Nein | Erzwingt GET | Bleibt bei Quell-URL | Nach Formular-Übermittlung |
| 307 | Temporärer Redirect | Nein | Ja (strikt) | Bleibt bei Quell-URL | Temporär, methoden-sicher (API) |
| 308 | Permanenter Redirect | Ja | Ja (strikt) | Vollständig zum Ziel | Permanent, methoden-sicher (API) |
Diese Tabelle ist die Kurzantwort. Der Rest dieses Leitfadens erklärt, was tatsächlich mit deinen Rankings, deinem Crawl-Budget und deinen indexierten URLs passiert, wenn du das eine oder das andere wählst. Du bekommst fertigen Code zum Einfügen für jede große Plattform, und die Belege, gezogen aus echten Crawl-Daten und Googles eigener Dokumentation.
Definitionen: 301, 302, 307, 308 und der Location-Header
Hier sind die Definitionen, denen du im Rest dieses Leitfadens begegnen wirst. Es lohnt sich, ein Lesezeichen zu setzen. Du wirst zurückkommen.
301 Moved Permanently: Ein Antwort-Statuscode, der dem Browser mitteilt, dass die Ressource dauerhaft an die im Location-Header angegebene URL verschoben wurde. Suchmaschinen übertragen Ranking-Signale an die neue URL, Browser cachen die Weiterleitung aggressiv.
302 Found: Ein Antwort-Statuscode, der dem Browser mitteilt, dass die Ressource vorübergehend unter einer anderen URL zu finden ist, die im Location-Header angegeben ist. Suchmaschinen behalten die ursprüngliche URL im Index, Browser cachen standardmäßig nicht.
307 Temporary Redirect: Wie 302, aber mit strikter Methodenerhaltung. Der Client muss die Anfrage mit derselben Methode wiederholen (POST bleibt POST). Nutze es, wenn ein API-Vertrag keine Verben ändern darf.
308 Permanent Redirect: Wie 301, aber mit strikter Methodenerhaltung. Dauerhaft und methodensicher.
Location-Header: Der HTTP-Antwort-Header, der die Ziel-URL jeder 3xx-Weiterleitung transportiert.
Was das in der Praxis bedeutet. Stell dir eine 301 vor wie einen Umzug, bei dem du deine Post für immer nachsenden lässt. Eine 302 ist, als würdest du in den Urlaub fahren und die Post bitten, zwei Wochen lang umzuleiten, dann Schluss. Die “methodensicheren” 307 und 308 legen genau fest, wie die Post behandelt werden soll. Nicht öffnen. Nicht für mich antworten. Diese Regel brauchen Anwendungen, damit sie weiter funktionieren, wenn du ihre Endpunkte umleitest.
Herkunft der Spezifikation. Der Statuscode 301 geht auf HTTP/1.1 zurück, und RFC 9110 — HTTP Semantics ist jetzt die maßgebliche Referenz (§15.4.2). Die Geschichte des Codes 302 ist unübersichtlicher. HTTP/1.0 (1996) definierte ihn als “Moved Temporarily”, aber Browser begannen sofort, POST-Anfragen beim Redirect in GET umzuwandeln, ein Verhalten, das die Spezifikation nie autorisiert hatte. RFC 2616 (1999) benannte 302 in “Found” um und gab zu, dass der Schaden bereits angerichtet war.
Die Spezifikationsänderung von 1999, die 302 kaputt machte: RFC 2616 räumte ein, dass 302 im gesamten Web falsch implementiert worden war. Statt zu versuchen, Milliarden von Clients zu reparieren, führte die Spezifikation 303 und 307 ein, um einen sauberen Ausweg zu schaffen.
Die Codes 307 und 308 existieren genau deshalb, weil das methodenverändernde Verhalten von 302 für immer blieb. Wenn dein API-Vertrag keine Verbwechsel verträgt (ein POST, das ein POST bleiben muss), halten 307 (temporär) und 308 (dauerhaft) die Methode fest. Für browserseitige Weiterleitungen, bei denen das Ziel ohnehin ein GET erwartet, sind 301 und 302 weiterhin der Standard.
Siehe auch den Canonical-URL-Leitfaden für den verwandten, aber eigenständigen Mechanismus von <link rel=canonical>. Für tiefere Implementierungsdetails bieten die MDN Web Docs zu HTTP-Weiterleitungen gute Hinweise zum browserspezifischen Verhalten.
Wann 301 vs. 302 verwenden: Die Entscheidungsregel
Es läuft auf eine Frage hinaus: Ist der Umzug dauerhaft oder nur vorübergehend? Die folgenden Fälle zeigen dir, auf welcher Seite du stehst.
Verwende 301, wenn …
Du dauerhaft auf eine neue Domain umziehst. Wenn aus oldbrand.com ein newbrand.com wird und es keine Rückkehr gibt, nimm einen 301. Er sagt den Suchmaschinen: Übergib alles, was du über die alte Domain weißt, an die neue und entferne die alte aus dem Index.
Du von HTTP auf HTTPS umziehst. Jede Seite deiner Website wechselt von der unsicheren Version (ohne Schloss im Browser) zur sicheren. Das ist dauerhaft. Ein 301 sorgt dafür, dass Browser und Suchmaschinen HTTPS ab sofort als offizielle Version behandeln.
Du deine URL-Struktur umbaust. Wenn /blog/post-1 im Rahmen einer seitenweiten Umstrukturierung zu /posts/post-1 wird, soll der alte Pfad nie wieder zurückkommen. Ein 301 übergibt die gesamte Rang-Kraft an die neue Struktur.
Du Seiten zusammenlegst oder ausdünnst. Wenn du zwei kurze Seiten zu einer stärkeren vereinst, leite die alte URL dauerhaft um. Die zusammengeführte Seite erbt die Rang-Kraft beider.
Du eine gelöschte Seite auf ihre übergeordnete Kategorie schickst. Statt bei einem eingestellten Produkt eine “Seite nicht gefunden”-Meldung zu zeigen, leite auf die übergeordnete Kategorieseite um. Nutzer landen an einem sinnvollen Ort und die Rang-Kraft fließt auf eine relevante Seite, statt zu verschwinden.
Du dich zwischen Slash und ohne Slash entscheidest. Wähle entweder /page oder /page/ und leite die andere Version dauerhaft um. Konsistenz verhindert, dass Google sie als zwei getrennte Seiten behandelt.
Du dich zwischen www und ohne www entscheidest. Wähle www.domain.com oder domain.com als deine Hauptversion. Leite die andere mit einem 301 um, damit Suchmaschinen alle Signale auf eine Version bündeln.
Eine E-Commerce-Migration (Shopify zu WooCommerce, ein eigener Shop zu Shopify Plus) ist einer der größten 301-Redirect-Jobs, die eine Marke je umsetzt. Das komplette Migrations-Playbook, einschließlich der Redirect-Map, die du vor jeder URL-Änderung erstellst, findest du in der Revenue Funnel SEO-Methodik.
Verwende 302, wenn …
Du einen A/B-Test fährst. Wenn die Hälfte deines Traffics auf eine Varianten-Seite geht, soll während des Experiments keine der beiden Versionen als Haupt-URL übernehmen. Ein 302 signalisiert Suchmaschinen: Die ursprüngliche URL bleibt zuständig, während wir Daten sammeln.
Du in einem Wartungsfenster bist. Wenn du Besucher während geplanter Ausfallzeiten auf eine Statusseite schickst, ist das per Definition vorübergehend. Ein 302 erhält den Stand der ursprünglichen URL bei Google, damit die Rankings nicht ins Rutschen kommen, während du Dinge reparierst.
Du noch keine Länder-Tags eingerichtet hast. Du schickst indische Besucher auf /in/ und US-Besucher auf /us/? Wenn du hreflang noch nicht hinzugefügt hast, nutze 302. (Hreflang ist das Tag, das Google sagt, welche Version in welchem Land anzuzeigen ist.) Es verhindert, dass Google die falsche regionale Version als Haupt-URL wählt.
Du eine Aktionsseite betreibst, die wieder verschwindet. Eine Black-Friday-Seite, die nach dem 1. Dezember verschwindet, soll nicht die Rang-Kraft deiner Hauptseite übernehmen. Ein 302 hält die ursprüngliche URL als Hauptseite, und die Aktionsseite existiert nur für die Kampagne.
Du während eines Umbaus eine Platzhalterseite nutzt. Wenn du einen Bereich deiner Website neu gestaltest, bewahrt eine temporäre Umleitung auf einen Platzhalter den Stand der ursprünglichen URL. Sobald der Umbau live geht, entfernst du die Umleitung und die ursprüngliche URL übernimmt wieder.
Grenzfälle, die die Regeln nicht ganz klären
Umleitungen nach einem Checkout sollten technisch eigentlich einen 303 nutzen (er sagt dem Browser: Vergiss die Formulardaten, lade einfach diese Seite). Die meisten Plattformen senden stattdessen einen 302, und Browser behandeln ihn gleich. API-Verschiebungen, bei denen Clients POST-Daten senden, sollten eigentlich 308 verwenden, um die Request-Art festzuschreiben. Die meisten Teams greifen stattdessen zu 301. Das funktioniert seit einem Jahrzehnt und nichts ist bisher kaputtgegangen. Login-Umleitungen nutzen meist 302. Der Besucher springt zur Login-Seite und kehrt nach dem Anmelden zurück.
Was nach deiner Entscheidung mit deiner SEO passiert (Realität 2026)
Den richtigen Code zu wählen ist nicht nur ein technisches Häkchen. Er entscheidet still über drei Dinge gleichzeitig. Ob Google die Rank-Power auf deine neue URL überträgt. Ob deine neue URL die alte in den Suchergebnissen ersetzt. Und ob AI-Suchmaschinen wie ChatGPT dich überhaupt zitieren. Jeder Punkt zieht den nächsten nach sich, und den Schaden später rückgängig zu machen kostet mehr Aufwand, als es gleich richtig zu machen.
Übertragung von Link-Equity
Link-Equity ist die SEO-“Reputation”, die deine URLs mit der Zeit aufbauen. Andere Seiten, die auf dich verlinken, Inhalte, die du veröffentlicht hast, und wie sich echte Nutzer auf der Seite verhalten. All das ergibt zusammen einen Score, der der URL beim Ranken hilft.
Wenn du mit einer 301 (permanent) weiterleitest, überträgt Google die Reputation auf die neue URL. Die neue URL erbt die Rank-Power.
Wenn du mit einer 302 (temporär) weiterleitest, behält Google die Reputation auf der alten URL. Die neue URL wird wie eine Nebenadresse behandelt, die nie eigene Autorität aufbaut. Wenn du also versehentlich eine 302 für einen permanenten Umzug nutzt, hast du in Googles Augen am Ende zwei URLs. Keine davon stark genug, um allein zu ranken. Deine Rank-Power ist für immer geteilt, bis du den Code korrigierst.
Das ist der teuerste Einzelfehler in der technischen SEO.
Jahrelang gingen SEOs davon aus, dass 302s Link-Equity killen. Sie behandelten temporäre Weiterleitungen wie Equity-Blackholes. PageRank, der an der Quell-URL stoppt und das Ziel nie erreicht.
John Mueller von Google hat das 2016 klargestellt und es in den Search Central Office Hours seitdem wiederholt. Sowohl 301- als auch 302-Weiterleitungen geben Link-Equity weiter. Die Google-Search-Central-Dokumentation zu URL-Weiterleitungen bestätigt es. Muellers wiederholte Formulierung: “It’s been like this for years now.”
Equity wird so oder so weitergegeben. Was sich ändert, ist, wo sie landet.
Eine 302 behält die alte URL als Canonical. Google behandelt die alte URL weiterhin als Chef, sodass die neue URL nie eigene Ranking-Signale aufbaut. Auch wenn technisch Equity durch die Weiterleitung fließt. Das praktische Ergebnis: Mit einer 301 erbt die neue URL die Page-Level-Metriken und wird zur rankenden Entität. Mit einer 302 verteilt sich Equity auf zwei URLs ohne klaren Gewinner. Keine baut die konzentrierte Autorität auf, die du brauchst, um bei schwierigen Queries mitzuspielen.
Link-Equity ist das thematische Scharnier zwischen Redirect-Kompetenz und Off-Page-SEO. Die Earned-Authority-Methode ist das Framework, das sie überhaupt erst aufbaut. Und genau deshalb ist es wichtiger, als die meisten Operator ahnen, sie durch korrekten 301-Einsatz zu erhalten.
Die Aufspaltung zählt am meisten bei Migrationen. Eine Seite, die mit 302s von HTTP auf HTTPS umzieht, verliert keine Equity. Sie fragmentiert sie nur für immer über verschiedene Protokoll-Varianten.
Was Googles Index mit jedem macht
Googlebot ist Googles Crawler. Er behandelt 301s und 302s sehr unterschiedlich, wenn er Seiten in seinen Index aufnimmt. (Der Index ist die riesige Datenbank mit jeder Seite, die Google kennt.)
Eine 301 sagt Google: Tausche die alte URL gegen die neue aus. Über die nächsten Besuche macht Google genau das. Meist innerhalb von 2 bis 6 Wochen bei einer typischen Seite, schneller bei großen Seiten, die Google öfter prüft. Die neue URL wird diejenige, die Google in den Suchergebnissen zeigt. Die alte fällt still raus.
Eine 302 sagt Google: Behalte die alte URL. Google zeigt die alte URL weiter als Haupt-URL in den Suchergebnissen. Die neue URL wird vielleicht besucht, übernimmt aber nie. Google liest die Weiterleitung als kurzfristigen Umweg, nicht als permanenten Adresswechsel.
Die Google Search Console (Googles kostenloses Tool für Website-Betreiber) hat eine Funktion namens URL-Prüfung, mit der man das leicht selbst sehen kann. Eine URL mit 301 zeigt irgendwann “URL ist nicht auf Google” mit dem Grund “Seite mit Weiterleitung”, und die neue URL taucht als indexiert auf. Eine URL mit 302 behält die ursprüngliche als Haupt-URL mit dem Tag “Seite mit Weiterleitung”. Und die neue URL bleibt einfach liegen, wird nie aufgenommen.
Für Migrationen bedeutet das: 302s erzeugen eine dauerhafte Aufspaltung zwischen zwei URLs, es sei denn, du gehst zurück und korrigierst den Code.
AI-Suche und Weiterleitungen: die ChatGPT-Daten 2025
Eine Studie von SE Ranking vom Dezember 2025 hat etwas Auffälliges gezeigt. AI-Suchmaschinen (ChatGPT, Perplexity, Googles AI Overviews) zitieren weitergeleitete URLs deutlich seltener als die reguläre Google-Suche.
Die Zahlen erzählen die Geschichte. Nur 0,79 % der ChatGPT-Zitationen zeigen auf URLs, die über eine Weiterleitung gehen, gegenüber 5,75 % in regulären Google-Ergebnissen. Das heißt, ChatGPT zitiert weitergeleitete URLs 3- bis 7-mal seltener als Google.
Hier der überraschende Teil. Wenn ChatGPT einer Weiterleitung folgt, bevorzugt es deutlich permanente. Dieselbe Studie fand heraus, dass ChatGPT 301s 1,6-mal häufiger folgt als 302s. Perplexity und die AI-Features von Bing zeigen dasselbe Muster. AI-Suchsysteme behandeln permanente Weiterleitungen als vertrauenswürdiger als temporäre.
Was das für deine Migration heißt: Eine 302, die irgendwo in deinen Weiterleitungen versteckt ist, senkt still deine Chancen, von AI-Suche zitiert zu werden. Du verlierst an zwei Fronten gleichzeitig. Googles reguläre Suche behandelt deine URLs als fragmentiert, und die neue Welle der AI-Suchmaschinen hört auf, dich in ihren Antworten zu erwähnen.
Wenn dein falscher Code dazu führt, dass ChatGPT aufhört, deine Inhalte zu zitieren, muss deine bezahlte Suche die Lücke schließen. Die Pincer-Methode ist genau der Grund, warum wir Paid und Organic aus einem Playbook fahren. Wenn AI-Suche einen Kanal wegbrechen lässt, muss der andere die Nachfrage auffangen.
Copy-Paste-Code für 7 Plattformen
Suche bei Google nach “301 vs 302 redirect” und die Top-Ergebnisse nennen sieben Plattformen, zeigen dir aber nie den tatsächlichen Code. Hier ist er also. Jedes Snippet unten ist bereit zum Kopieren und Einfügen, gegen die aktuelle Plattformdokumentation geprüft und auf die häufigsten Fehler getestet.
Apache (.htaccess)
Bei Apache kommt das in deine .htaccess-Datei im Document Root.
Apache .htaccess-Code anzeigen
# Single URL 301
Redirect 301 /old-url /new-url
# Pattern-based 301 (regex)
RedirectMatch 301 ^/old/(.*)$ /new/$1
# Domain change with HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]
Fallstrick: RewriteEngine On vor der Nutzung von RewriteRule zu vergessen. Die Direktive schlägt ohne sie still fehl, und du verbringst zwanzig Minuten damit, dich zu fragen, warum nichts funktioniert. Wir behandeln den Vergleich im Detail in htaccess vs Nginx für Redirect-Regeln.
Nginx
Bei Nginx kommt das in deine Server-Block-Konfigurationsdatei (meist /etc/nginx/sites-available/yourdomain).
Nginx-Konfigurationscode anzeigen
# Single URL 301
location = /old-url {
return 301 /new-url;
}
# Domain change
server {
listen 443 ssl;
server_name oldbrand.com;
return 301 https://newbrand.com$request_uri;
}
Fallstrick: rewrite zu verwenden, wenn return schneller wäre. return 301 läuft vor der Regex-Auswertung und spart dem Server etwas Arbeit. Die vollständige Aufschlüsselung findest du in htaccess vs Nginx für Redirect-Regeln.
Cloudflare Workers + Page Rules
Page Rules (UI, kein Code): Cloudflare-Dashboard → Rules → Page Rules → “Forwarding URL” → 301 oder 302 aus dem Dropdown wählen. Free-Pläne sind auf 3 aktive Page Rules begrenzt, was sich auf Sites mit mehreren Redirect-Anforderungen schnell füllt.
Workers (Code, flexibler):
Cloudflare Workers-Code anzeigen
export default {
fetch(request) {
const url = new URL(request.url);
if (url.pathname === '/old-url') {
return Response.redirect('https://example.com/new-url', 301);
}
return fetch(request);
}
}
Fallstrick: Workers kosten $5/Monat für 10M Requests, aber sie geben dir Pattern-Matching-Power, mit der Page Rules einfach nicht mithalten können. Wir behandeln fortgeschrittene Anwendungsfälle in Cloudflare Workers Redirect-Patterns.
WordPress: RankMath PRO + Redirection-Plugin + manuelle .htaccess
RankMath PRO: WordPress Admin → Rank Math → Redirections → Add New. 301 oder 302 aus dem Dropdown wählen, Quell- und Ziel-URLs eintragen. Änderungen sind sofort live, kein Server-Neustart.
Redirection-Plugin (kostenlos, John Godley): Tools → Redirection. Am besten für umfangreiche Migrationen. Unterstützt CSV-Import/Export, Regex-Patterns und 404-Tracking. Das Plugin protokolliert Redirect-Hits, was dir hilft, Ketten oder Schleifen zu erkennen, bevor sie sich aufstauen.
Manuelle .htaccess: Funktioniert, aber überlebt keine Plugin- oder Theme-Updates, die .htaccess berühren. Nutze es nur für dauerhafte System-Regeln, die unabhängig vom WordPress-Zustand bestehen bleiben müssen.
Wenn du WordPress-nativ bist und jede Redirect-Änderung als Teil der größeren Content-Engine behandelst, ist der Redirect-Schritt nur ein Zug innerhalb der breiteren Methodik. Die Content-Compounder-Methodik ist das, was diese Engine antreibt. Die Feedback-Schleife mit sechs Säulen, die Redirect-Kompetenz als Pillar-2-Infrastruktur nutzt. Für plugin-spezifische Vergleiche geht der WordPress-Redirect-Plugin-Guide tief in die Auswahlkriterien.
WooCommerce + Shopify
WooCommerce: Nutzt die oben genannten WordPress-Redirect-Tools. Die Massen-Migration von Produkt-URLs braucht allerdings eine Deduplizierungslogik. Ein Store mit 500 SKUs kann 500 Redirect-Regeln erzeugen, die das .htaccess-Parsing verlangsamen. Wir behandeln den Deduplizierungs-Workflow im Abschnitt zu häufigen Fehlern unten.
Shopify: Online Store → Navigation → URL Redirects. Shopify unterstützt über das Standard-Admin nur 301. Du kannst 302 nicht ohne eine eigene Shopify Function oder eine Drittanbieter-App wie Easy Redirects konfigurieren.
Fallstrick: Shopify-URL-Redirects überleben Theme-Wechsel, aber sie brechen in dem Moment, in dem du das Quellprodukt oder die Seite löschst. Exportiere deine Redirect-Liste immer vor jeder strukturellen Änderung. Settings → Files rettet dich hier nicht.
Next.js (next.config.js)
Bei Next.js kommt das in deine next.config.js-Datei im Projekt-Root.
Next.js redirects-Konfiguration anzeigen
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-url',
destination: '/new-url',
permanent: true, // permanent: true = 308; permanent: false = 307
},
];
},
};
Fallstrick: Next.js verwendet standardmäßig 307/308 (die Strict-Method-Varianten), nicht 301/302. Wenn du speziell 301/302 brauchst, weil ein älteres SEO-Tool 308 noch nicht erkennt, setze statusCode: 301 statt permanent: true.
Express-Middleware
Bei Express kommt das in deine Haupt-Server-Datei (meist app.js oder server.js).
Express-Middleware-Code anzeigen
// Express
app.get('/old-url', (req, res) => {
res.redirect(301, '/new-url');
});
// Pattern-based redirect
app.use('/old-section/*', (req, res) => {
const newPath = req.originalUrl.replace('/old-section', '/new-section');
res.redirect(301, newPath);
});
Fallstrick: res.redirect() fällt auf 302 zurück, wenn du keinen Statuscode übergibst. Sei immer explizit. Implizite 302er sind die häufigste Ursache für “Ich habe Redirects eingerichtet, aber meine Rankings sind abgestürzt”-Support-Tickets, die wir sehen.
Vercel (vercel.json oder next.config.js)
Bei Vercel leben Redirects in vercel.json im Projekt-Root oder innerhalb von next.config.js, wenn du Next.js verwendest (oben behandelt).
Vercel vercel.json-Code anzeigen
{
"redirects": [
{
"source": "/old-url",
"destination": "/new-url",
"permanent": true
},
{
"source": "/old/:path*",
"destination": "/new/:path*",
"permanent": true
}
]
}
Fallstrick: wie bei Next.js. permanent: true bedeutet 308, permanent: false bedeutet 307. Wenn du speziell 301/302-Statuscodes brauchst, nutze "statusCode": 301 statt "permanent".
Netlify (_redirects-Datei)
Bei Netlify kommen Redirects in eine _redirects-Datei in deinem Publish-Verzeichnis (oder public/).
Netlify _redirects-Code anzeigen
# Single URL 301
/old-url /new-url 301
# Wildcard
/old/* /new/:splat 301
# Domain change (full URL on the right)
https://oldbrand.com/* https://newbrand.com/:splat 301!
Fallstrick: Das nachgestellte ! (Force-Flag) sorgt dafür, dass der Redirect bestehende Dateien am Ziel überschreibt. Ohne es leitet Netlify nur um, wenn die Quelle nicht mit einer tatsächlichen Datei übereinstimmt. Nützlich, aber leicht zu vergessen.
AWS CloudFront (Functions oder Lambda@Edge)
Bei CloudFront können Redirects als CloudFront Function (günstiger, einfacher) oder Lambda@Edge (mächtiger, teurer) laufen. Für die meisten Redirect-Arbeiten ist Functions die richtige Wahl.
CloudFront Function-Code anzeigen
function handler(event) {
var request = event.request;
if (request.uri === '/old-url') {
return {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
location: { value: 'https://example.com/new-url' }
}
};
}
return request;
}
Hänge die Function an ein CloudFront-Distribution-Behaviour mit dem Event-Typ viewer-request. CloudFront Functions sind auf 10ms Ausführungszeit begrenzt und haben keinen Netzwerkzugriff, aber sie sind für die ersten 10M Aufrufe pro Monat kostenlos.
Caddy
Bei Caddy kommen Redirects in dein Caddyfile und sind kinderleicht.
Caddyfile-Code anzeigen
# Single URL 301
oldbrand.com {
redir /old-url /new-url permanent
}
# Domain change with HTTPS preserved
oldbrand.com {
redir https://newbrand.com{uri} 301
}
Fallstrick: permanent in Caddy ist 301. Nutze temporary für 302. Caddy handhabt HTTPS automatisch über Let’s Encrypt, daher sind Domain-Redirects meist eine Einzeiler-Angelegenheit.
IIS (Windows Server, web.config)
Bei IIS leben Redirects in der web.config-Datei deiner Site unter dem Abschnitt <system.webServer>. Erfordert das URL-Rewrite-Modul (kostenloser Microsoft-Download).
IIS web.config-Code anzeigen
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Old URL 301" stopProcessing="true">
<match url="^old-url$" />
<action type="Redirect" url="/new-url" redirectType="Permanent" />
</rule>
<rule name="Domain change" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^oldbrand\.com$" />
</conditions>
<action type="Redirect" url="https://newbrand.com/{R:0}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Fallstrick: redirectType="Permanent" ist 301 in IIS. Nutze Found für 302, SeeOther für 303, Temporary für 307. Die Benennung ist nicht offensichtlich. Viele Entwickler gehen davon aus, dass Temporary für 302 steht, und liefern den falschen Code aus.
Mitten in der Migration und brauchst ein zweites Paar Augen? Schick uns deine Sitemap und deine
.htaccess. Wir machen ein kostenloses 30-minütiges Audit in einem Call. Dein Screen, unsere Stimme, echter curl-Output. Kein Deck. Kein Angebot. Retainer ab ₹40,000 / $499 monatlich, wenn du möchtest, dass wir die Arbeit übernehmen.30-Minuten-Strategiegespräch buchen → · WhatsApp +91 96366 50036
So überprüfst du es: Glaube es nicht. Beweise es.
Es gibt drei Wege, um zu prüfen, was ein Redirect tatsächlich tut. Der erste braucht keine speziellen Tools. Der zweite nutzt eine kostenlose Funktion, die bereits in Chrome eingebaut ist. Der dritte nutzt Googles eigenes kostenloses Dashboard. Wähle den, mit dem du dich am wohlsten fühlst. Alle sagen dir die Wahrheit.
curl -I, der Ein-Zeilen-Check (für Entwickler)
Wenn du kein Entwickler bist, springe weiter zur Browser-DevTools- oder Google-Search-Console-Methode weiter unten. Sie zeigen dir die gleichen Informationen ohne Kommandozeile.
Führe auf einem beliebigen Computer mit Terminal (das schwarz-weiße Textfenster, das Entwickler benutzen) aus:
curl -I https://example.com/old-url
Beispielausgabe:
HTTP/2 301
date: Tue, 1 May 2026 09:00:00 GMT
location: https://example.com/new-url
cache-control: max-age=31536000
HTTP/2-301-Zeile leuchtet golden, der Location-Header zeigt auf die neue URL, der cache-control max-age-Wert ist hervorgehoben. Markenpalette in Marineblau und Gold." loading="lazy" width="1600" height="900">
Die erste Zeile verrät dir den Status. Hier 301. Der location:-Header sagt dir, wohin der Redirect zeigt: auf deine neue URL, genau wie angegeben. Das cache-control: max-age=31536000 (ein Jahr in Sekunden) zeigt, dass der Redirect aggressiv gecached wird, was zu einer permanenten Weiterleitung passt. Browser und CDNs respektieren diese Anweisung und überspringen den Lookup bei wiederholten Besuchen.
Falle: Manche Server liefern HTTP/1.1 statt HTTP/2. Die Statuszeile lautet dann HTTP/1.1 301 Moved Permanently statt des knapperen HTTP/2 301. Das Verhalten ist identisch. Die Versionsnummer spiegelt nur wider, was dein Server unterstützt, nicht, ob der Redirect gültig ist.
Browser DevTools Netzwerk-Tab
Öffne Chrome DevTools → Netzwerk-Tab → aktiviere “Preserve log” → lade die ALTE URL direkt in der Adressleiste.
Die erste Anfrage zeigt Status 301 oder 302 in der Status-Spalte. Klicke diese Zeile an, um den Location-Header und die vollständigen Response-Header im rechten Panel einzusehen.
Diese Methode eignet sich hervorragend, um Redirect-Ketten visuell zu erkennen. Jeder Hop erscheint als eigene Zeile. Wenn du drei Zeilen vor dem finalen 200 siehst, hast du eine Kette, die zusammengefasst werden muss.
GSC URL-Prüfung, der Check nach dem Deploy
Google Search Console → URL-Prüfung → füge die ALTE URL ein.
Bei einem erfolgreichen 301 siehst du “URL ist nicht auf Google” mit dem Grund “Seite mit Weiterleitung”. Das bestätigt, dass Google den Redirect gecrawlt, registriert und begonnen hat, Autorität an das Ziel zu übertragen.
Nach zwei bis sechs Wochen fügst du die NEUE URL ein. Was du sehen willst: “URL ist auf Google” mit “Seite ist indexiert” und “Vom Nutzer angegebener Canonical”. Das bestätigt, dass die Konsolidierung abgeschlossen ist. Die neue URL hält jetzt die Autorität, die die alte URL aufgebaut hat.
Die vollständige Funktionsreferenz zur URL-Prüfung findest du in Googles Dokumentation zur URL-Prüfung.
Das ist der Screenshot, den du an deinen Kunden weiterleitest, um zu beweisen, dass die Migration funktioniert hat. Kein Semrush-Export. Kein Bericht eines kostenpflichtigen Tools. Googles eigene Konsole, die sagt, dass die URL auf Google ist. Glaube nicht dem Dashboard. Lies die Antwort.
Wenn Du bereits den falschen Code verwendet hast: Recovery-Playbook
Die Wiederherstellung besteht aus vier kleinen Schritten. Finde die defekten URLs. Repariere den Code. Bitte Google, wiederzukommen. Warte. Die meiste Zeit verbringst Du mit Warten. Die eigentliche Reparatur geht schnell. Der gesamte Job dauert in der Regel 2 bis 6 Wochen, und jeden einzelnen Schritt zu überstürzen verlängert die Wartezeit nur.
So sieht das in der Praxis aus. Letztes Quartal haben wir einer Hautpflegemarke geholfen, die gerade ihren Shop von Shopify zu WooCommerce umgezogen hatte. Ihre Entwickler hatten bei jeder URL 302-Weiterleitungen verwendet, weil das Migrations-Plugin standardmäßig auf “temporär” gestellt war, ohne jemanden zu warnen. In Woche 4 war der organische Traffic um 38% gesunken. Wir haben 60 Produktseiten geprüft, bestätigt, dass jede Weiterleitung den falschen Typ hatte, und alle auf 301 umgestellt. Dann haben wir ihre Sitemap erneut eingereicht und Google gebeten, die 12 umsatzstärksten Seiten neu zu crawlen. Achtzehn Tage später wurden die neuen URLs als Hauptversion angezeigt, und der Traffic lag wieder innerhalb von 4% des Niveaus vor der Migration.
Symptome
Die Rankings sind 2 bis 6 Wochen nach Deiner Migration gefallen, und der zeitliche Zusammenhang ist zu auffällig, um Zufall zu sein. Die Google Search Console meldet “Seite mit Weiterleitung” für URLs, die eigentlich längst die neue Hauptversion sein sollten. Google behandelt die alte URL immer noch als die primäre. Die KI-Suche macht es schlimmer: ChatGPT, Claude und Gemini schicken Leute weiterhin zu den alten URLs, weil ihre Trainingsdaten das Signal der temporären Weiterleitung aufgenommen haben. Deine neuen URLs tauchen bei Google kaum oder gar nicht auf, obwohl Google Deine Sitemap ohne Beanstandung akzeptiert hat. Direkter Traffic auf alte URLs schwankt unvorhersehbar, weil Browser und Lesezeichen sich die alte Adresse merken und Besucher in Weiterleitungsschleifen oder auf veraltete Seiten schicken.
Diagnose
Wähle 20 bis 50 Deiner alten URLs aus und prüfe, was der Server tatsächlich zurückschickt. (Wenn Du Entwickler bist, nutze curl -I. Andernfalls öffne die URL in Chrome mit den DevTools im Network-Tab.) Notiere den tatsächlichen Statuscode, nicht das, was Dein CMS behauptet zu senden. Lass dann dieselben URLs durch das URL-Prüftool der Google Search Console laufen. Die Abweichungen zeigen, wo das Leck ist. Schau in Deine Plattform-Einstellungen oder Server-Konfiguration, um die Ursache zu finden. Drei häufige Übeltäter: ein Weiterleitungs-Plugin, das standardmäßig auf “temporär” eingestellt ist, ein Express-Aufruf ohne expliziten Statuscode oder eine Next.js-Weiterleitung mit permanent: false. Notiere Ketten separat. Eine Kette wie A→B→C→D fügt dem Problem mit dem falschen Code ein zweites hinzu.
Reparieren
Stelle jede relevante Einstellung auf 301 um (oder 308, wenn Du den Request-Typ für eine API festschreiben musst) und veröffentliche die Änderung. Prüfe jede Reparatur auf dieselbe Weise, wie Du das Problem gefunden hast, und bestätige, dass 301 erscheint. Reiche Deine Sitemap erneut in der Google Search Console ein, damit Google weiß, dass sich etwas geändert hat. Nutze das URL-Prüftool der GSC und klicke bei Deinen wichtigsten Ziel-URLs auf “Indexierung beantragen”. Priorisiere die Seiten, die Umsatz oder Backlinks bringen. Bei Weiterleitungen mit sehr hohem Traffic kannst Du Google beschleunigen, indem Du vorübergehend von Deiner Startseite auf die neue URL verlinkst. Dieser interne Link schubst Google, früher vorbeizukommen und nachzusehen.
Neu indexieren
Die typische Wartezeit beträgt 2 bis 6 Wochen, bis die neue URL als Hauptversion übernommen wird. Schneller bei größeren Seiten, die Google oft besucht. Die Erholung in der KI-Suche variiert. ChatGPT und Gemini zitieren die richtige URL, sobald sich ihre Trainingszyklen aktualisieren. Perplexity und der Chat von Bing holen in der Regel innerhalb von 1 bis 2 Wochen auf, sobald die neue URL stabil ist. Für konkrete Benchmarks dazu, wie lange eine 301-Weiterleitung bei Google dauert, veröffentlichen wir in einem zukünftigen Beitrag detaillierte Crawl-Timing-Daten.
Hast Du ein Weiterleitungs-Chaos geerbt und weißt nicht, wo es blutet? Füge Deine Sitemap in ein kostenloses 5-Minuten-Audit ein, und wir schicken Dir eine Liste jeder 301, 302 und Kette in Deinem Weiterleitungs-Graphen zurück, plus die, die Dir gerade die Indexierung kosten. Die meisten Kunden rufen uns in Woche 3 eines unerklärlichen Traffic-Einbruchs an. Spare 2 Wochen.
7 Fehler, die leise Rankings kosten
Das sind die sieben Fehler, die wir in fast jedem Audit sehen. Zu jedem gibt es einen schnellen Weg, ihn zu erkennen, und einen schnellen Weg, ihn zu beheben.
So sieht das in der Praxis aus. Letztes Jahr haben wir ein Softwareunternehmen auditiert, das sich auf seine erste große Investitionsrunde vorbereitete. Über sechs Jahre Produktänderungen hatten sich in ihrer Server-Konfiguration 4.200 Weiterleitungsregeln angesammelt. Einundvierzig bildeten Ketten mit vier oder mehr Sprüngen. Sechs waren aktive Loops, die den Server im Kreis drehten. Wir haben jede Kette zu Single-Hop-Weiterleitungen zusammengefasst, die Loops beseitigt und die Gesamtzahl auf 1.180 reduziert. Die Seiten luden 340ms schneller. Zwei Wochen später crawlte Google wieder mehr von ihrer Seite.
-
Weiterleitungs-Ketten (A geht zu B, B geht zu C, C geht zu D). Du erkennst sie, indem Du die komplette Kette Schritt für Schritt verfolgst. Jeder Sprung verliert etwas Rank-Power und fügt Verzögerung hinzu. Behebe es, indem Du A direkt zu D schickst. Der Debugging-Leitfaden für Weiterleitungs-Ketten beschreibt den gesamten Schritt-für-Schritt-Prozess.
-
Weiterleitungs-Loops. Der Server liefert Fehler, oder Dein Browser läuft in ein Timeout, weil die Weiterleitung im Kreis springt. Behebe es, indem Du die Regel entfernst, die zurück auf eine frühere URL in der Kette zeigt.
-
Gemischte 301er und 302er bei einer Migration. Einige Seiten haben den permanenten Code bekommen, andere den temporären, und Google sieht ein inkonsistentes Bild. Behebe es, indem Du jede URL auf Deiner Sitemap prüfst und jede Regel auf 301 umstellst.
-
Vergessen, dass
/pageund/page/unterschiedliche URLs sind. Mit oder ohne abschließenden Schrägstrich behandelt Google sie als zwei separate Seiten. Beide müssen auf dieselbe weiterleiten, sonst teilst Du Deine Rank-Power zwischen zwei Versionen. -
Die
http://- undwww.-Varianten vergessen. Jede URL hat vier Versionen: mit und ohnehttps, mit und ohnewww. Drei davon müssen per 301 auf eine Hauptversion zeigen. Wenn Du eine davon auslässt, zersplittert Deine Autorität auf mehrere Adressen.
Die Varianten-URL-Explosion ist ein verwandter, WC-spezifischer Fehlermodus. Fünf Attribute mit je acht Werten können aus einem einzigen Produkt 40.000 indexierbare URLs erzeugen. WooCommerce-spezifisches technisches SEO behandelt das Varianten-URL-Deduplizierungsmuster, das auf Floor 3 des WC Towers sitzt.
-
Leere Seiten nach einer Weiterleitung. Die Ziel-URL funktioniert, aber die Seite ist kurz oder im Grunde leer. Google behandelt das als “Soft 404” (eine Seite, die technisch lädt, sich aber wie eine fehlende verhält) und lässt sie leise fallen. Behebe es, indem Du sicherstellst, dass das Ziel echten, nützlichen Inhalt hat. Das Recovery-Playbook für Soft 404 beschreibt genau, wie viel Inhalt ausreicht.
-
Nutzer automatisch basierend auf ihrem Land umleiten. Besucher ohne Opt-out auf eine andere Seite zu schicken, je nachdem, von wo sie surfen, verstößt gegen Googles Regeln. Behebe es gemäß Layer 1 des Multi-Region Authority Stack, der den richtigen Weg zeigt, Nutzer nach Region zu routen.
Geo-IP-Auto-Redirect ohne manuelles Override ist ein Cloaking-Risikomuster, das Googles Spam-Team markiert. Für korrektes Multi-Region-Routing (
hreflang, ccTLD-Architektur und die Geo-IP-Regeln von Layer 1, die nicht stillschweigend 302 senden) siehe den Multi-Region Authority Stack.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem 301- und einem 302-Redirect?
Ein 301 signalisiert eine dauerhafte Umleitung. Google ersetzt die alte URL durch die neue als kanonische Version. Ein 302 signalisiert eine temporäre Umleitung. Google behält die ursprüngliche URL als kanonische Version bei. Beide übertragen laut Googles Dokumentation Link-Equity, aber das Indexierungsverhalten unterscheidet sich völlig. Nutze 301, wenn der Umzug permanent ist. Nutze 302, wenn du zurückwechseln wirst.
Schadet ein 302-Redirect der SEO?
Ja. Wenn du ihn falsch einsetzt. Ein 302 für einen dauerhaften Umzug bedeutet, dass Google die Quell-URL auf unbestimmte Zeit als kanonische behält. Die Ziel-URL baut also niemals ihre eigenen Ranking-Signale auf. Equity wird zwar in beide Richtungen übertragen (Mueller hat das 2016 bestätigt), aber sie splittet sich auf beide URLs auf, statt sich auf der neuen zu konsolidieren. Das Ergebnis: Keine der beiden URLs baut die Autorität auf, die du für schwierige Suchanfragen brauchst. Die Lösung: auf 301 umstellen, Sitemap erneut einreichen und Indexierung anfordern.
Überträgt ein 302-Redirect Link-Equity?
Ja. John Mueller von Google hat bestätigt, dass sowohl 301- als auch 302-Redirects Link-Equity übertragen. Der Haken: Bei einem 302 wird die Ziel-URL nicht kanonisch. Die Equity bleibt also über beide URLs verteilt, statt sich zu konsolidieren. Deine Link-Signale bleiben gesplittet, bis du entweder auf 301 wechselst oder den Redirect komplett entfernst.
Wann sollte ich einen 302-Redirect statt eines 301 nutzen?
Nutze 302 für explizit temporäre Szenarien. A/B-Tests, bei denen du zurückwechseln wirst. Wartungsfenster von Stunden oder Tagen. Aktionsseiten, die nach einer Kampagne ablaufen. Länderspezifische temporäre Auslieferung bei Geo-Tests. Das Kriterium: Du hast tatsächlich vor, die ursprüngliche URL innerhalb eines vernünftigen Zeitraums wiederherzustellen.
Wie lange braucht Google, um einen 301-Redirect zu honorieren?
Normalerweise 2 bis 6 Wochen, bis die neue kanonische URL die alte im Google-Index vollständig ersetzt. Seiten mit hoher Autorität und aktivem Crawl-Budget werden schneller verarbeitet. Seiten mit niedriger Autorität können 8 bis 12 Wochen brauchen, bis die Konsolidierung abgeschlossen ist. Verfolge den Fortschritt mit dem URL-Prüftool in der GSC. Die Frage, wie lange ein 301-Redirect bei Google dauert, hängt hauptsächlich davon ab, wie oft Google deine Seite crawlt.
Kann ich einen 302 später in einen 301 ändern? Erholen sich meine Rankings?
Ja. Aktualisiere deine Serverkonfiguration von 302 auf 301, reiche deine Sitemap erneut in der Google Search Console ein und fordere die Indexierung der betroffenen URLs an. Rankings erholen sich normalerweise innerhalb von 2 bis 6 Wochen, während Google den Redirect neu verarbeitet und die Signale auf der Ziel-URL konsolidiert. Je früher du den Fehler behebst, desto schneller erfolgt die Erholung.
Was ist der Unterschied zwischen 301 und 308? Zwischen 302 und 307?
308 ist strikt permanent (methoden-sicher). Es verbietet Clients, die HTTP-Methode während des Redirects zu ändern. 307 ist strikt temporär (methoden-sicher) mit derselben Methodenbewahrung. 301 und 302 erlaubten historisch Clients, POST-Requests in GET-Requests umzuwandeln. Nutze 307 und 308 für API-Endpunkte, bei denen die Bewahrung der ursprünglichen Request-Methode entscheidend ist.
Wie leite ich eine URL in WordPress um?
Drei Optionen. Der Redirect-Manager von RankMath PRO hat die sauberste Oberfläche und automatische 404-Erkennung. Das kostenlose Plugin Redirection bietet ähnliche Funktionalität ohne Premium-Kosten. Manuelles Bearbeiten der .htaccess gibt dir maximale Kontrolle, benötigt aber Serverzugriff. Für die umfassendere technische SEO-Methodik bei WordPress siehe unser WordPress-SEO-Playbook.
Wie prüfe ich, ob ein Redirect korrekt funktioniert?
Führe curl -I [alte-url] im Terminal aus, um den Statuscode und den Location-Header zu sehen, den dein Server tatsächlich zurückgibt. Der Netzwerk-Tab der Browser-DevTools zeigt dieselben Informationen mit visueller Darstellung der Kette. Das URL-Prüftool der Google Search Console zeigt dir, wie Google selbst den Redirect liest.
Schadet eine 301-Redirect-Kette meiner SEO?
Ja. Jeder Sprung verliert einen kleinen Bruchteil der Link-Equity und erhöht die Latenz. Google folgt Ketten möglicherweise nach etwa 5 Sprüngen nicht mehr und lässt Equity unterwegs liegen. Prüfe deine Redirects jedes Quartal und kürze Ketten auf einen einzigen Sprung. Screaming Frog erkennt Ketten automatisch.
Behandeln KI-Suchmaschinen (ChatGPT, Claude, Gemini) Redirects anders als Google?
Ja. ChatGPT zitiert umgeleitete URLs 3- bis 7-mal seltener als Google, laut einer Studie von SE Ranking vom Dezember 2025. KI-Systeme bevorzugen stabile, nicht umgeleitete URLs bei der Quellenauswahl. Wenn KI-Traffic für deine Strategie wichtig ist, priorisiere 301 gegenüber 302 und eliminiere Redirect-Ketten in deinen wertvollen Inhalten.
Wie lange sollte ich einen 301-Redirect bestehen lassen?
Mindestens 12 Monate, idealerweise dauerhaft. Sobald Google die Signale auf die neue URL konsolidiert hat, könntest du denken, der Redirect wird nicht mehr gebraucht. Wird er doch. Behalte ihn. Andere Seiten, die auf die alte URL verlinken, schicken Nutzer (und Bots) noch jahrelang durch den Redirect. Entferne ihn, und diese Links landen im 404. Vernünftige Faustregel: Behalte 301er für immer, es sei denn, die Ziel-URL selbst wird abgeschaltet.
Wie leite ich Query-String-Parameter wie ?utm_source=X um?
Zwei Optionen. Bewahren: Die meisten Plattformen reichen Query-Strings automatisch durch (Apache RewriteRule, Nginx $request_uri, Cloudflare Workers request.url). Entfernen: Explizit zum Ziel ohne Query umleiten (z. B. Apache RewriteRule ^old$ /new? [R=301,L], wobei das abschließende ? die Query löscht). Standardmäßig bewahren, außer du hast einen bestimmten Grund (Analytics-Hygiene, Canonical-Bereinigung), sie zu entfernen.
Beeinflussen Redirects Core Web Vitals oder Seitengeschwindigkeit?
Ja. Jeder Redirect-Sprung fügt 100-400 ms Latenz hinzu, abhängig von DNS, TLS-Handshake und Server-Antwortzeit. Ein einzelner Redirect ist selten ein CWV-Problem. Eine Kette von 3+ Redirects auf einer kritischen Ressource kann LCP über 2,5 Sekunden drücken und deine CWV ruinieren. Kürze Ketten immer und hoste Redirects am Edge (Cloudflare Workers, CloudFront Functions) für die schnellste Antwort.
Was ist der Unterschied zwischen einem harten 301 und einem weichen 301?
Im HTTP-Standard gibt es keinen “weichen 301”. Der Begriff taucht manchmal in SEO-Texten auf, um einen JavaScript-basierten oder Meta-Refresh-Redirect zu beschreiben. Das sind keine echten 301er. Das sind clientseitige Hacks. Ein harter (echter) 301 ist eine HTTP-Level-Antwort mit Statuscode 301, die vom Server zurückgegeben wird. Ein “weicher 301” (JS oder Meta-Refresh) überträgt Equity nicht zuverlässig, wird nicht von allen Crawlern respektiert und erhöht die Latenz. Verwende immer einen echten HTTP-Level-301.
Kann ich auf eine externe Domain umleiten?
Ja. Der Redirect-Mechanismus ist identisch. Der Location-Header zeigt auf die externe URL, der Statuscode ist der, den du wählst. Die SEO-Konsequenzen sind ebenfalls dieselben: Ein 301 auf eine externe Domain überträgt Ranking-Signale auf diese Domain, ein 302 behält die Signale auf deiner. Verwende externe 301-Redirects sparsam. Du überträgst Equity an die Seite eines anderen. Häufige legitime Anwendung: Weiterleitungen nach Akquisitionen, Partner-Site-Referrals oder Abschaltung einer Marke.
Wie behebe ich eine Redirect-Schleife?
Führe curl -L -I [url] aus. Das -L-Flag folgt Redirects, -I zeigt Header an. Wenn der Trace zwischen zwei oder mehr URLs hin- und herspringt, hast du eine Schleife. Häufige Ursachen: A→B-Redirect plus ein B→A-Canonical-Tag, widersprüchliche .htaccess-Regeln oder ein CDN-Redirect, der mit einem Origin-Server-Redirect kollidiert. Behebung: Identifiziere die störende Regel (meist die zuletzt hinzugefügte) und entferne sie. Nach der Korrektur mit curl -L -I erneut validieren. Erfolgreiche Auflösung zeigt einen einzelnen 200 am Ende des Traces.
Mitten in einer Migration? Hier ist das Angebot.
Schick uns deine Sitemap und deine .htaccess. Wir verbringen 30 Minuten mit dir in einem Call. Dein Bildschirm plus unserer. Wir führen curl live auf fünf deiner URLs aus, schauen uns deinen Redirect-Graph in der GSC an und sagen dir, welche Korrektur die meiste Ranking-Equity rettet. Kein Deck, kein Angebot, keine Follow-up-Verkaufssequenz.
30-Minuten-Strategie-Call buchen → · WhatsApp +91 96366 50036
Erst Preise sehen? Der veröffentlichte Preis-Index zeigt jede Retainer-Stufe in INR, USD, GBP, EUR, AUD. Kein Discovery-Call-Multiplikator.
Die Master-Methodik? Siehe das Prove-It-Protokoll. Ship → Measure → Prove → Iterate.
Über den Autor
Kunal Singh Dabi ist der Gründer von KD Digital. Ausgezeichnet als Best SEO Specialist in India für MSMEs beim WASME World MSME Business Summit 2023 in New Delhi. Über 250 Unternehmen seit Mai 2021 in mehr als 17 Ländern skaliert. 4,9★ aus über 140 verifizierten Bewertungen. Begründer der übergeordneten SEO-Beratungspraxis, die jede Änderung mit einem Monday Report ausliefert.