Website vor dem Launch SEO-sicher vorbereiten

So bereiten Sie eine Website auf den Launch vor, ohne SEO-Traffic zu verlieren

Ein Launch ist nicht nur ein Design-Moment. Er ist auch ein Such-Moment. Wenn Sie planen, wie Sie eine Website auf den Launch vorbereiten, ohne SEO-Traffic zu verlieren, ist der sicherste Weg nicht, auf das Gedächtnis oder auf das Versprechen „wir prüfen das später“ zu vertrauen. Schreiben Sie die Änderungen Seite für Seite auf und legen Sie fest, was unverändert bleibt, bevor jemand Code ausrollt, denn es lohnt sich, Website vor Launch SEO prüfen.

Der größte Fehler ist, den Launch-Tag wie einen kompletten Neustart zu behandeln. Suchmaschinen sehen das nicht so. Sie sehen alte URLs, alte Links, alte Titel, alte Canonicals und erwarten, dass die neue Version sich wie ein sorgfältiger Umzug verhält, nicht wie ein Abriss. Ein einziger kaputter Redirect kann eine Seite ins Aus schicken, deshalb ist es wichtig, SEO-Traffic beim Website-Launch schützen.

1. Legen Sie die SEO-Elemente fest, die vor dem Launch unverändert bleiben sollen

Beginnen Sie mit einer kurzen Checkliste für die Teile einer Seite, die Suchwert tragen können. Dazu gehören URLs, Title-Tags, Meta-Descriptions, Überschriften, interne Links und Canonical-Tags. Diese Liste sollte kurz genug sein, um sie in einem Durchgang zu lesen, aber konkret genug, damit ein Entwickler jeden Punkt als beibehalten, geändert oder entfernt markieren kann.

Machen Sie die Checkliste nicht abstrakt. Notieren Sie das exakte URL-Muster, etwa /services/ oder /blog/post-name/, und halten Sie fest, ob es bestehen bleibt. Wenn ein Title-Tag umgeschrieben wird, dokumentieren Sie den alten und den neuen Titel. Wenn ein Canonical-Tag auf eine andere URL zeigt, braucht auch das eine eigene Zeile. Auf diese Details kommt es an.

Einige Seiten können sich frei verändern. Andere nicht. Eine Startseite kann mehr Änderungen verkraften als eine Seite, die für drei Kernanfragen rankt und Backlinks aus fünf Artikeln erhält. Dieser Unterschied sollte in der Checkliste sichtbar sein, nicht in einer Tabelle versteckt, die niemand zweimal öffnet.

Wenn Ihr Team im selben Sprint auch mit Seitensicherheit und Redirects arbeitet, legen Sie die SEO-Checkliste neben die Sicherheits-Checkliste. Ein Launch kann beides zugleich kaputtmachen. Deshalb entdeckt eine gemeinsame Prüfung oft Probleme, die getrennte Teams übersehen. Siehe auch Website-Sicherheit, wenn Sie die andere Seite dieser Prüfung brauchen.

2. Ordnen Sie die alte Website Seite für Seite der neuen zu

Erstellen Sie eine Ersatz-Mapping-Liste, bevor Inhalte verschoben werden. Jede wichtige alte URL braucht ein exaktes neues Ziel, nicht nur eine vage Kategorieseite und auch keinen „ungefähr passenden“ Ersatz. Wenn ein alter Artikel zu zwei neuen Seiten wird, notieren Sie beide Ziele und den Grund für die Aufteilung, denn Redirects und URL-Mapping vor dem Relaunch sollten von Anfang an sauber dokumentiert sein.

Diese Zuordnung sollte auch zusammengeführte, umbenannte oder eingestellte Seiten enthalten. Auch eine eingestellte Seite braucht eine Antwort. Wenn sie Links, Traffic oder eine Historie in den Suchergebnissen hatte, sollte sie nicht einfach verschwinden. Die Zuordnung sollte festhalten, ob die Seite auf einen Ersatz, eine übergeordnete Seite oder eine neue Entsprechung mit derselben Suchintention verweist.

Eine gute Zuordnung hilft auch Design- und Content-Teams. Wenn /pricing-old/ jetzt /pricing/ ist, muss niemand raten. Wenn drei Produktseiten zu einer stärkeren Seite zusammengelegt werden, sollte diese Bündelung vor dem Launch klar erkennbar sein. Rätselraten erzeugt später Redirect-Chaos.

Ein praktischer Trick: Drucken Sie die Zuordnung aus und gehen Sie die wichtigsten 20 URLs mit einem Stift durch. Klingt altmodisch. Funktioniert aber. Auf Papier fallen fehlende Ziele schneller auf als in einer überfüllten Tabelle mit 400 Zeilen.

3. Schützen Sie Seiten, die bereits Suchtraffic bringen

Nutzen Sie Analyse- und Search-Console-Daten, um die Seiten zu finden, die bereits Impressionen, Klicks und Links bringen. Diese Seiten sind launchkritische Assets. Behandeln Sie sie besonders sorgfältig, denn sie sind nicht nur Inhalte, sondern Traffic-Quellen mit Geschichte.

Prüfen Sie für jede Seite drei Dinge: die Landing-Queries, die Backlinks und das verwendete Template. Eine Seite kann im CMS ganz gewöhnlich aussehen und trotzdem konstant Traffic über eine wichtige Suchanfrage liefern. Wenn eine Template-Änderung 15 Seiten auf einmal betrifft, ist das keine kleine Änderung mehr.

Prüfen Sie nicht nur die Seiten mit dem meisten Traffic. Schauen Sie auch auf Seiten mit ungewöhnlichem Linkwachstum, Seiten mit starken Brand-Queries und Seiten, die Conversion-Pfade unterstützen. Ein Artikel ist vielleicht nicht die trafficstärkste Seite der Website, aber die Seite, auf die andere Websites verlinken, wenn sie Ihr Produkt beschreiben. Diese Seite verdient Schutz.

Hier hilft auch ein Monitoring-Stack. Wenn Sie bereits eine Website-Analyse- und Monitoring-Plattform nutzen, ziehen Sie die letzten 30 Tage, die letzten 90 Tage und den Search-Console-Export nebeneinander. Drei Ansichten sind besser als eine. Sie zeigen, welche Seiten stabil sind und welche bereits fragil.

4. Legen Sie Redirect-Regeln für entfernte, umbenannte und zusammengeführte Inhalte fest

Wählen Sie für jeden URL-Typ ein Redirect-Muster und bleiben Sie dabei. Umbenannte Seiten sollten auf ihre neuen Entsprechungen führen. Entfernte Seiten sollten zur nächstpassenden relevanten Seite weiterleiten, nicht standardmäßig zur Startseite. Zusammengeführte Seiten sollten auf die eine Seite verweisen, die der alten Intention am besten entspricht.

Redirects sind keine Dekoration. Sie sind der Routenplan, dem Suchmaschinen und Besucher nach dem Launch folgen. Eine Redirect-Kette verlangsamt die Dinge und kann Signale verwässern. Eine Schleife kann Crawler festhängen lassen. Ein „weicher Ersatz“, der ähnlich aussieht, aber die falsche Absicht hat, kann in der Praxis wie eine Sackgasse wirken.

Nutzen Sie exakt das Ziel, das die Bedeutung erhält. Wenn zwei alte Artikel zum selben Thema zusammengeführt werden, leiten Sie beide auf die fertige neue Seite weiter. Wenn eine Produktkategorie eingestellt wird, schicken Sie Nutzer zur nächsten aktiven Kategorie mit demselben Zweck, nicht zu einem zufälligen Homepage-Banner. Diese kleine Disziplin spart viel Nacharbeit.

Bei großen Websites überschneidet sich die Redirect-Planung oft mit Infrastruktur-Arbeiten. Wenn Ihr Launch Migrationen, Subdomains oder Zugriffsregeln umfasst, koordinieren Sie sich mit dem Team für private Netzwerkinfrastruktur. Eine Redirect-Datei in der falschen Umgebung kann einen ganzen Tag kosten, und niemand debuggt so etwas gern um 19 Uhr.

5. Erhalten Sie die Indexierungs-Signale in der neuen Version

Prüfen Sie vor dem Launch Robots-Anweisungen, Canonicals, Pagination, Hreflang und Sitemap-Einträge. Diese Signale sagen Suchmaschinen, was gecrawlt werden soll und welche Version bevorzugt werden sollte. Wenn sie sich widersprechen, vertraut der Crawler womöglich dem falschen Signal und ignoriert die Seite, die eigentlich indexiert werden sollte.

Canonical-Tags verdienen besondere Sorgfalt. Eine Seite, die auf die falsche URL canonicalisiert, kann aus den Suchergebnissen verschwinden, obwohl sie im Browser einwandfrei aussieht. Robots-Anweisungen können ebenso schädlich sein. Ein versehentliches Noindex auf einer Template-Seite kann viele URLs auf einmal blockieren. Das ist eine unangenehme Überraschung.

Pagination sollte auf Seiten mit mehreren Ansichten getestet werden, und Hreflang sollte dort geprüft werden, wo Sprachversionen existieren. Sitemaps sind keine Magie, helfen Suchmaschinen aber, nach einem Launch die richtigen URLs zu entdecken. Stellen Sie sicher, dass die Sitemap die Live-Struktur widerspiegelt, nicht die alte Entwurfsstruktur.

Wenn Ihr Launch eine neue Informationsarchitektur umfasst, hilft es, sie mit einem gut strukturierten Unternehmenswebsite-Modell zu vergleichen. Es geht nicht darum, eine Vorlage zu kopieren. Es geht darum, die Signale so konsistent zu halten, dass Crawler nicht raten müssen, welche Seite die endgültige Version ist.

6. Testen Sie den Launch in einer Staging-Umgebung auf SEO-Regressions

Crawlen Sie die Staging-Site und vergleichen Sie sie mit der alten Website. Achten Sie auf kaputte Links, fehlende Metadaten, Redirect-Schleifen, doppelte Seiten und versehentliche Noindex-Einstellungen. Staging ist der Ort, an dem Sie die offensichtlichen Probleme finden, bevor sie öffentlich werden.

Ein guter Staging-Test ist nicht nur ein Crawl. Führen Sie bei großen Websites mindestens zwei Durchläufe aus: einen für die Content-Struktur und einen für die gerenderten Seiten. Manche Probleme erscheinen erst nach dem Laden von JavaScript. Manche nur im Quellcode. Das kann nerven, ist aber wichtig.

Vergleichen Sie wenn möglich Seite für Seite. Prüfen Sie Titel, Descriptions, H1s, Canonicals und Statuscodes. Wenn die alte Seite einen sauberen 200-Status hatte und die Staging-Version auf eine staging-interne URL mit 302 weiterleitet, ist das nicht bereit. Wenn ein Template doppelte Facettenseiten erzeugt, beheben Sie das vor dem Launch. Nach dem Launch kostet die Reparatur mehr Zeit.

Staging ist auch der richtige Ort, um Content-Delivery-Systeme zu testen, die Hinweise nach dem Launch oder Nutzerwarnungen verschicken. Wenn Ihr Team auch eine E-Mail-, SMS- und Push-Messaging-Ebene betreibt, stellen Sie sicher, dass Launch-Nachrichten nicht auf Entwurfs-URLs zeigen. Eine Launch-Mail mit einem toten Link ist ein kleiner Albtraum – und ein sehr öffentlicher.

7. Überwachen Sie den ersten Crawl nach dem Launch und die Traffic-Muster

Beobachten Sie nach dem Launch den Indexierungsstatus, 404-Fehler, Redirect-Verhalten und den Traffic auf Landingpages. Warten Sie nicht eine Woche. Der erste Crawl nach dem Launch kann zeigen, ob die neue Struktur akzeptiert wird oder ob Suchmaschinen an den falschen Pfaden hängen bleiben.

Prüfen Sie die ersten 24 Stunden besonders genau. Danach noch einmal nach 48 Stunden. Ein plötzlicher Rückgang der Impressionen bei einem Template weist meist auf ein strukturelles Problem hin, nicht auf Saisonalität. Ein Anstieg der 404-Fehler spricht meist für einen Zuordnungsfehler oder einen vergessenen Redirect. Ein seltsames Crawl-Muster kann auf blockierte Assets oder ein fehlerhaftes Canonical-Tag hinweisen.

Das Traffic-Monitoring sollte sich auf die Seiten konzentrieren, die vor dem Launch wichtig waren. Wenn diese Seiten Klicks verlieren, während weniger wertvolle Seiten stabil bleiben, ist das Problem wahrscheinlich nicht sitewide. Wahrscheinlich handelt es sich um einen spezifischen Redirect-, Template- oder Indexierungsfehler. Das ist eine gute Nachricht, weil sie Ihnen ein klares Ziel gibt.

Nutzen Sie Suchdaten zusammen mit Server-Logs, wenn möglich. Die Search Console zeigt das Indexierungsverhalten. Logs zeigen echte Crawler-Anfragen. Stellen Sie beides nebeneinander, und das Fehlermuster wird viel leichter erkennbar. Genau hier ist schnelles Reporting wichtiger als perfektes Reporting.

8. Halten Sie für die Launch-Woche einen schnellen Fehlerbehebungsprozess bereit

Benennen Sie vor dem Launch Verantwortliche. Content braucht eine verantwortliche Person, Development braucht eine, und SEO braucht eine. Wenn um 10 Uhr morgens ein Problem auftaucht, sollte niemand überlegen müssen, wer es beheben darf.

Bereiten Sie einen kurzen Eskalationsweg für dringende Probleme vor: fehlende Redirects, blockierte Seiten oder hochwertige Inhalte, die während des Deployments verschwunden sind. Der Ablauf sollte festlegen, wer das Problem zuerst prüft, wer den Fix freigibt und wer ihn live stellt. Drei Schritte reichen, wenn sie klar sind.

Halten Sie eine Liste mit Launch-Wochen-Fixes bereit, die sich schnell umsetzen lassen, ohne die Website neu zu schreiben. Redirect-Ergänzungen, Canonical-Korrekturen, Robots-Änderungen und die Wiederherstellung von Inhalten sind typische Beispiele. Ein kleines Team mit sauberem Prozess kann solche Dinge schneller beheben als ein großes Team, das jeden Ticketfall diskutiert.

Wenn die Website an ein inhaltsstarkes Produkt gekoppelt ist, halten Sie Ihr Support-Team in der Nähe. Seiten müssen nach dem Launch vielleicht aktualisiert werden, und diese Aktualisierungen sollten nicht bis zum nächsten Sprint warten. Für die fortlaufende Betreuung nach dem Release sehen Sie Website-Support nach dem Launch. Ein Launch ist ein Ereignis; das Erholungsfenster ist ein Prozess.

Ein Launch ist am sichersten, wenn sich die Website dort wie die alte Website verhält, wo es wichtig ist, und wie die neue Website dort, wo Veränderung beabsichtigt ist. Genau diese Balance ist die eigentliche Arbeit. Bringen Sie die Zuordnung in Ordnung, testen Sie sie zweimal und lassen Sie Platz für einen schnellen Fix, wenn der erste Crawler auftaucht.