301-Redirects sind die SEO-Falle jeder Help-Center-Migration. Ohne sauberes Redirect-Mapping verlierst du Google-Rankings über Nacht. Externe Backlinks von Branchen-Blogs, Foren oder bezahlten Anzeigen werden zu 404s. Bookmarks von Bestandskunden funktionieren nicht mehr. Wer mehrere Jahre Inhalte aufgebaut hat, wirft mit der Migration die mühsam erarbeitete Domain-Authority weg, wenn die Redirects fehlen.
Dieser Artikel behandelt das vollständige Redirect-Setup nach einer Help-Center-Migration: Redirect-Mapping als CSV, Wildcard-Patterns, Sitemap-Update, Search-Console-Resubmit, und die häufigsten Fehler, die DACH-Teams in der Praxis machen.
Was 301 wirklich macht und warum es kritisch ist
Ein 301-Redirect ist die HTTP-Antwort "Moved Permanently". Der Browser oder der Suchmaschinen-Crawler bekommt die neue URL zurückgespielt und folgt ihr. Wichtig: Google überträgt etwa 90 bis 100 Prozent des PageRank-Werts der alten URL auf die neue, wenn der Redirect 301 ist und die Ziel-URL inhaltlich passt. Bei 302 (Found, Temporary) oder bei Soft-404 (alte URL liefert 200, aber Inhalt ist weg) gibt es keinen Transfer.
Das heisst: ein Help Center mit 200 indexierten Artikeln, die regelmässig Traffic bekommen, muss 200 saubere 301-Redirects bekommen, sonst sind die Rankings nach drei bis sechs Wochen weg. Bei mehreren tausend Artikeln ist die Redirect-Map ein eigenes Teil-Projekt der Migration.
Schritt 1: Redirect-Map als CSV erstellen
Ausgangspunkt ist eine vollständige Liste aller alten URLs. Quellen: bestehende XML-Sitemap, Google Search Console Performance-Report der letzten 12 Monate, interne Datenbank-Query gegen den alten Help-Center-Anbieter.
Zu jeder alten URL gehört die neue Ziel-URL. Bei einer 1:1-Migration ist das eindeutig: ein altes Article wird zu einem neuen Article. Bei einer Restrukturierung ist es komplizierter: ein alter Article wird auf eine Section-Übersicht umgeleitet, oder mehrere alte Articles werden zu einem konsolidiert. Wichtig: die Ziel-URL muss inhaltlich passen. Ein Article über Pricing redirected auf eine Pricing-Page ist okay. Ein Article über Pricing redirected auf die Startseite ist Soft-404 und kostet Rankings.
Format der CSV: old_url,new_url,redirect_type. redirect_type ist in fast allen Fällen 301. Nur bei Übergangsphasen oder A/B-Tests wird 302 gesetzt. Bei mehreren Sprachen kommt eine Spalte locale hinzu.
Schritt 2: Wildcard-Patterns für skalierbare Redirects
Bei mehreren tausend Articles ist eine individuelle Zeile pro Article unhandlich. Wildcard-Patterns helfen, wenn die URL-Strukturen ähnlich sind.
Beispiel: alle Zendesk-Guide-URLs der Form support.company.com/hc/de/articles/12345-Title sollen zu support.company.com/de/articles/title-slug. Mit einem Regex-Pattern wie /hc/de/articles/(\d+)-(.+) zu /de/articles/$2 deckt das alle Artikel-URLs in einem Rutsch ab.
Vorsicht: Wildcard-Patterns brauchen Testing. Ein zu greedy Pattern fängt Pages, die nicht migriert werden sollen. Vor dem Live-Schalten Stichprobe testen, mindestens 50 zufällige URLs.
Schritt 3: Implementierung auf der alten Domain
Wenn die Domain bleibt und nur das Backend wechselt: 301-Redirects als Konfiguration im Webserver. Apache via .htaccess oder mod_rewrite, Nginx via location-Blocks, Cloudflare Workers, AWS CloudFront Functions oder Lambda@Edge. Bei kleineren Setups ist die Webserver-Config der schnellste Weg.
Wenn die Domain wechselt (z.B. von support.company.com zu help.company.com): die alte Domain muss noch eine Weile erreichbar bleiben, mit 301 auf die neue. Bei DNS-Wechsel ist das oft kurz unterbrochen, plane einen Übergang von 30 bis 90 Tagen, bevor die alte Domain abgeschaltet wird.
Wenn der alte Anbieter direkt die Redirects nicht setzen kann (z.B. Confluence Cloud bei Migration zu Zendesk Guide): Cloudflare-Worker oder reverse-Proxy in Eigenregie. Mehr Hintergrund findest du in unserem Artikel zur Help-Center-Aktualität.
Schritt 4: Sitemap und Robots
Nach den Redirects: neue Sitemap.xml mit allen neuen URLs auf der neuen Domain oder dem neuen Pfad. Bei Search Console alte Sitemap entfernen und neue einreichen. Robots.txt muss erlauben, dass der Crawler den neuen Pfad indexiert. Wenn der alte Pfad noindex gewesen sein sollte (z.B. Staging-Domain), unbedingt vor dem Live-Schalten auf index umschalten.
Pro-Tipp: Sitemap mit lastmod-Timestamps auf den Migrationstag setzen, dann crawled Google bevorzugt die migrierten Seiten in den ersten Wochen.
Schritt 5: Search Console Resubmit und Monitoring
Google Search Console hat die Index-Status- und Coverage-Reports. In den zwei Wochen nach Cutover regelmässig prüfen: wie viele alte URLs sind noch im Index, wie viele neue URLs werden gecrawlt, gibt es Coverage-Errors. Klick-Rate und Impressions in den Performance-Reports zeigen, ob Rankings stabil bleiben.
Bing Webmaster Tools nicht vergessen, auch wenn der Traffic kleiner ist. Bing reagiert oft langsamer auf Redirects, kann dafür aber bei Voice-Search und Edge-Browser relevant sein.
Häufige Fehler
Erster Fehler: 302 statt 301 setzen. Verändert PageRank-Transfer und kostet Rankings.
Zweiter Fehler: Soft-404, also alte URL liefert 200, aber Inhalt ist weg. Schlimmer als ein sauberer 404, weil Suchmaschinen das nicht als Migration erkennen.
Dritter Fehler: alte URLs auf die Help-Center-Startseite umleiten. Das ist Soft-404 in der Wirkung, weil die Ziel-URL inhaltlich nichts mit der alten zu tun hat.
Vierter Fehler: Slug-Format-Wechsel ohne Redirect. Wenn alte URLs IDs hatten (/articles/12345) und neue nur Slugs (/articles/title-slug), brauchst du IDs-zu-Slugs-Mapping.
Fünfter Fehler: Sprach-Pfad-Wechsel übersehen. Wenn alte URLs /de/ hatten und neue /de-DE/ oder umgekehrt, müssen alle Sprachversionen einzeln redirected werden.
Sechster Fehler: Anhang-URL-Verlust. Bilder, PDFs, Anhänge auf der alten Plattform haben oft eigene URLs. Wenn die nicht rehostet und redirected werden, werden Inline-Bilder zu Broken Images.
Testing vor dem Cutover
Vor dem Live-Schalten der Redirects: Stichprobe von mindestens 50 URLs testen. Tools wie curl -I auf der Kommandozeile, Screaming Frog für Bulk-Checks, oder ein einfaches Python-Script, das alle URLs aus der CSV durchläuft und HTTP-Status prüft. Erwartungs-Output: 301 mit Location-Header, der auf die neue URL zeigt, die ihrerseits 200 zurückgibt.
In den ersten 48 Stunden nach Cutover: Live-Monitoring mit einem Uptime-Tool wie StatusCake oder UptimeRobot, das stichprobenartig Old-URLs prüft und Alerts schickt bei 404 oder 5xx.
HappySupport im Kontext
HappySupport unterstützt 301-Redirect-Imports beim Onboarding. Wer von einem anderen Help-Center-Anbieter migriert, kann seine alte URL-Liste als CSV hochladen, und HappySupport erzeugt automatisch die Redirects auf die neuen Artikel-URLs. Damit entfällt der Aufwand der manuellen Konfiguration auf der alten Domain.
Mehr zur Architektur und zum HappySupport-Ansatz findest du in der selbst-aktualisierenden Wissensdatenbank, in Help Center aufbauen in einer Woche und in der Help-Center-Aktualität.
