Tech-SEO Authority
Redirects: das eine Detail das den Migrations-Erfolg entscheidet
Backlink-Equity, organische Sichtbarkeit, User-Erlebnis. 301-Redirects sind der unsichtbare Bandkleber der dafuer sorgt dass beim Relaunch nichts kaputt geht. Wer hier schludert, verliert 30 bis 70 Prozent Sichtbarkeit in 8 Wochen.
301 vs. 302
Der eine Status-Code, der ueber Equity-Transfer entscheidet
Permanent
301 Moved Permanently
- • PageRank wandert vollstaendig auf neue URL
- • Backlink-Equity uebertraegt sich
- • Suchmaschinen aktualisieren Index relativ schnell
- • Browser cachen den Redirect aggressiv
Temporaer
302 Found
- • PageRank bleibt auf alter URL
- • Equity-Transfer findet nicht statt
- • Suchmaschinen behalten alte URL im Index
- • Browser cachen nicht (jeder Request neu)
Redirect-Map als Source of Truth
Eine JSON-Datei, drei Plattformen, kein Drift
Wir pflegen Redirects als JSON im Repository. Aus dieser Source generieren wir die Plattform-spezifischen Configs (Vercel rewrites, Cloudflare _redirects, nginx config). Kein manuelles Synchronisieren, keine vergessenen Mappings.
// redirects.json (Source of Truth)
[
{ "from": "/produkte/", "to": "/leistungen/", "status": 301 },
{ "from": "/produkte/(.*)", "to": "/leistungen/$1", "status": 301 },
{ "from": "/blog/2019/(.*)", "to": "/insights/$1", "status": 301 }
] Vercel-Variante (vercel.json)
{
"redirects": [
{ "source": "/produkte", "destination": "/leistungen", "permanent": true },
{ "source": "/produkte/:path*", "destination": "/leistungen/:path*", "permanent": true }
]
} Cloudflare Pages (public/_redirects)
/produkte /leistungen 301
/produkte/* /leistungen/:splat 301
/blog/2019/* /insights/:splat 301 nginx (location blocks)
location = /produkte/ {
return 301 /leistungen/;
}
location ~ ^/produkte/(.*)$ {
return 301 /leistungen/$1;
} Die 4 Regeln
Was wir jedem Migrations-Mandat als Pflicht-Set geben
- 1. Niemals Redirect-Chains. Maximal 1 Hop von alter zu neuer URL. Wenn sich URLs zweimal aendern, immer beide alten URLs direkt auf die finale mappen.
- 2. Niemals 302 fuer Migrationen. 302 ist nur fuer A/B-Tests, Wartungsarbeiten und temporaere Umleitungen. Migration ist permanent.
- 3. Externe Backlinks vor Migration scannen. Tools wie Ahrefs oder eigener Search-Console-Export. Jede URL mit Backlinks muss explizit gemappt sein.
- 4. 404-Sweep weekly fuer 90 Tage nach Go-Live. Search Console Coverage-Report durchgehen, jeden neuen 404 in die Map nachpflegen wenn er Backlinks oder organischen Traffic hatte.
Häufig gestellte Fragen
301 oder 302, was ist der Unterschied? +
301 ist Permanent Redirect, signalisiert Google und Browsern: die alte URL ist endgueltig durch die neue ersetzt. PageRank, Backlink-Equity, Indexierungs-Status werden uebertragen. 302 ist Temporary Redirect, signalisiert: kommt spaeter zurueck. Equity wird nicht uebertragen. Bei Migrationen immer 301, nie 302.
Was ist eine Redirect-Chain und warum ist sie schlecht? +
Wenn /alt -> /neu-v1 -> /neu-v2 -> /final, sind das 3 Redirect-Hops. Jeder Hop kostet Latenz fuer User und Crawl-Budget fuer Google. Ab 5 Hops ignoriert Googlebot oft den Endpunkt. Best Practice: jede alte URL direkt zu finaler neuer URL, max 1 Hop.
Wie pflegen wir 301s nach dem Relaunch? +
Search Console weekly checken auf 404er. Jeden 404 mappen: gibt es ein Backlink darauf, dann 301 nachziehen. Ohne Backlink darf der 404 stehen, Google de-indexiert ihn nach 60 bis 90 Tagen. Wir loggen alle 301s in einer JSON-Map die im Repo lebt.
Was passiert bei Pfad-Aenderungen ohne saubere Migration? +
Wenn /produkte/widget zu /shop/widget wird ohne 301, sieht Google einen 404 auf /produkte/widget. Backlinks dorthin verlieren Equity, organische Klicks aus alten SERP-Positionen landen auf 404, User bouncen, Google de-indexiert. Nach 4 Wochen ist die Sichtbarkeits-Halbwertszeit klar im Search-Console-Chart.
Migration ohne Equity-Verlust
Schick uns die alte und die geplante neue URL-Struktur. Wir bauen die Redirect-Map und schicken sie in 48h zurueck.
Antwort innerhalb von 24h · Keine versteckten Kosten