Website-Relaunch ohne Rankingverlust: Planung, Weiterleitungen und Monitoring

Stellen wir uns einen Dienstleistungsbetrieb vor, dessen Website vor acht Jahren entstand. Seitdem haben drei Personen Inhalte ergänzt, ein Blog wurde begonnen und wieder vernachlässigt, einzelne Leistungsseiten wurden kopiert und leicht verändert. Die Seite wirkt veraltet, lädt langsam und lässt sich auf dem Smartphone mühsam bedienen. Der Relaunch ist beschlossen.

Was dabei meist fehlt, ist ein Bild davon, was die alte Seite tatsächlich leistet. Die Startseite kennt jeder. Aber welche der vierhundert Adressen bringen Besucher, welche werden von anderen Websites verlinkt, welche stehen seit Jahren ungesehen im Index? Ohne diese Antwort ist jede Entscheidung über die neue Struktur eine Wette.

Die Sorge vor Verlusten ist berechtigt. Ein Relaunch ist für Suchmaschinen kein Schönheitsupdate, sondern ein Umbau am Fundament: Adressen ändern sich, Texte werden gekürzt, Navigation und interne Verlinkung entstehen neu. Google bewertet nach dem Livegang im Prinzip eine neue Website, die an die Geschichte der alten anknüpfen soll.

Die Ursachen sind selten exotisch. Am häufigsten fehlen Weiterleitungen: Die neue Seite hat andere Adressen, und die alten laufen ins Leere oder landen pauschal auf der Startseite. Google wertet das nicht als Umzug, sondern als Wegfall von Seiten. Die Signale, die an diesen Adressen hingen, verpuffen, ebenso die Links anderer Websites darauf.

Fast ebenso häufig sind Inhalte, die im Zuge der Neugestaltung „aufgeräumt“ werden. Ein Text, der für eine bestimmte Suchanfrage seit Jahren auf Seite eins stand, wird gekürzt, weil er im neuen Layout zu lang wirkt. Überschriften werden werblicher formuliert, und das Suchwort, nach dem Menschen tatsächlich suchen, verschwindet.

Dazu kommen technische Fehler, die man erst nach dem Livegang bemerkt: eine Indexsperre aus der Staging-Umgebung, die mitumgezogen ist, eine robots.txt, die alles ausschließt, fehlende Canonical-Angaben, verlorene strukturierte Daten, eine Sitemap mit alten Adressen. Keiner dieser Fehler ist schwer zu vermeiden. Er passiert, wenn niemand eine Liste führt.

Bevor irgendetwas neu gestaltet wird, braucht es eine belastbare Inventur. Sie kombiniert drei Quellen, weil jede für sich blinde Flecken hat. Ein Crawl, etwa mit Screaming Frog, liefert alle erreichbaren Adressen samt Statuscode, Titel, Überschriften, Canonical und interner Verlinkung. Er zeigt, was die Seite technisch ist.

Die Search Console zeigt, was Google daraus macht: welche Seiten Impressionen und Klicks erhalten, für welche Suchanfragen, in welcher Position. Hier zeigt sich oft, dass wenige Seiten den größten Teil der Sichtbarkeit tragen und scheinbar unwichtige Unterseiten still Anfragen liefern. Ein Zeitraum von mindestens zwölf Monaten glättet saisonale Schwankungen.

Die dritte Quelle ist das Backlink-Profil. Welche Adressen verlinken andere Websites, Verzeichnisse oder Presseseiten? Eine Seite mit wenig Traffic, aber mehreren hochwertigen Verweisen verdient mehr Sorgfalt als ihr Traffic vermuten lässt. Dafür genügen die Berichte der Search Console, ergänzt durch ein Backlink-Werkzeug Ihrer Wahl.

Das Ergebnis ist eine Tabelle, in der jede bekannte URL mit Statuscode, Klicks, Impressionen, Verweisen und Hauptsuchanfrage steht. Sie ist das Arbeitsdokument für alles Weitere.

Aus der Inventartabelle entsteht die Content-Inventur. Jede Seite bekommt eine von vier Entscheidungen. Behalten: Die Seite funktioniert, Adresse und Inhalt bleiben. Überarbeiten: Das Thema trägt, aber Text oder Struktur sind schwach. Zusammenlegen: Mehrere ähnliche Seiten konkurrieren um dieselbe Suchanfrage und werden zu einer stärkeren. Entfernen: Die Seite hat keinen Zweck mehr.

Entfernen heißt nicht löschen ohne Spur. Auch für wegfallende Seiten wird ein sinnvolles Ziel gesucht, meist die thematisch nächste Seite. Gibt es keines und hat die Adresse weder Traffic noch Verweise, ist ein sauberer Statuscode 410 oder 404 die ehrlichere Antwort als eine Weiterleitung auf eine unpassende Seite. Google behandelt eine Weiterleitung auf irrelevante Inhalte erfahrungsgemäß wie einen Soft-404.

Bei der Frage, ob die Adressstruktur überhaupt geändert werden soll, lohnt Zurückhaltung. Eine neue Navigation oder ein neues Design brauchen keine neuen URLs. Jede Adresse, die bleiben kann, ist ein Risiko weniger. Ändern Sie Adressen nur, wenn das Content-Management-System es erzwingt oder die bisherige Struktur nachweislich Probleme verursacht.

Das URL-Mapping ist die Tabelle, die jede alte Adresse genau einer neuen zuordnet. Es klingt nach Fleißarbeit und ist es auch, aber hier entscheidet sich, ob Signale übertragen werden. Jede Zeile enthält die Alt-URL, die Ziel-URL, den gewünschten Statuscode und eine Notiz zur Begründung. Wo mehrere Alt-Seiten zusammengelegt wurden, zeigen mehrere Zeilen auf dasselbe Ziel.

Das Ziel sollte inhaltlich dasselbe Thema bedienen, nicht die thematisch grobe Verwandtschaft. Eine alte Seite zu „Heizungswartung“ gehört auf die neue Wartungsseite, nicht auf eine allgemeine Leistungsübersicht. Zusätzlich wird geprüft, dass die Ziel-URL selbst mit Status 200 antwortet und nicht ihrerseits weiterleitet.

Hier liegt die Gefahr der Ketten. Wenn ein früherer Relaunch Adresse A auf B geleitet hat und der neue B auf C, entsteht A, B, C. Jeder Zwischenschritt kostet Ladezeit und erhöht das Risiko, dass etwas bricht. Die Regel lautet: Jede Alt-URL leitet in einem einzigen Schritt direkt auf das endgültige Ziel. Dazu müssen auch die Altlasten früherer Weiterleitungen in die Tabelle.

Der Standard für dauerhafte Umzüge ist der Statuscode 301 (alternativ 308). Google hat bestätigt, dass auch 302 nach einiger Zeit Signale weitergibt, aber ein dauerhafter Umzug sollte auch dauerhaft ausgezeichnet sein.

Gebaut wird auf einer Staging-Umgebung, die für Suchmaschinen unsichtbar sein muss. Die zuverlässigste Lösung ist ein Zugriffsschutz per Passwort oder IP-Beschränkung. Eine noindex-Angabe ist die zweite Sicherung, aber eine robots.txt mit Disallow allein reicht nicht, denn gesperrte Adressen können dennoch im Index auftauchen, wenn sie verlinkt werden. Zudem kann Google ein noindex nicht lesen, wenn es die Seite nicht abrufen darf.

Auf dem Staging wird dann nicht nur gestaltet, sondern verglichen. Titel, Meta-Beschreibungen, Hauptüberschriften, Canonical-Angaben, hreflang (falls mehrsprachig) und strukturierte Daten werden aus dem Crawl der alten Seite gegen die neue gestellt. Ein Differenzbericht zeigt jede Abweichung. Nicht jede ist ein Fehler, aber jede sollte eine bewusste Entscheidung sein.

Bei der Überschriftenstruktur gilt eine einfache Regel: Eine Seite hat genau eine H1, die das Thema trägt, darunter eine nachvollziehbare Gliederung. Neue Templates nutzen Überschriften oft als Gestaltungsmittel und zerstören damit die Struktur. Auch interne Links müssen im neuen System auf die neuen Adressen zeigen, nicht auf alte, die erst per Weiterleitung korrigiert werden.

Strukturierte Daten, etwa Organization, LocalBusiness, FAQPage oder Article nach schema.org, wandern selten automatisch mit. Sie werden im neuen Template neu ausgegeben und mit dem Test für Rich-Ergebnisse geprüft.

Der Livegang ist ein Ablauf mit festen Prüfpunkten, kein Knopfdruck. Am Vortag steht die Mapping-Tabelle als Weiterleitungsregeln im Server oder System bereit und wurde auf dem Staging gegen jede Alt-URL getestet. Am Tag selbst wird zuerst die neue Seite live geschaltet, dann die Indexsperre entfernt, dann geprüft. Die Reihenfolge ist wichtig, weil kein Schritt die Prüfung des vorigen ersetzt.

Besonders kritisch ist die Sperre. Passwortschutz, noindex-Meta-Tag und X-Robots-Tag-Header müssen weg, die robots.txt darf nichts ausschließen, was indexiert werden soll. Prüfen Sie das nicht im Backend, sondern an der echten Adresse: Quelltext der Startseite, Antwort-Header, robots.txt, URL-Prüfung in der Search Console.

Anschließend wird die neue XML-Sitemap mit den endgültigen Adressen eingereicht, nicht die alte. Stichproben aus dem Mapping bestätigen, dass Weiterleitungen in einem Schritt auf ein 200er-Ziel führen. Die wichtigsten Seiten werden einzeln in der Search Console zur Indexierung angestoßen.

Bleibt die Domain gleich, ist der Relaunch ein Umbau im selben Haus. Wechselt sie, etwa wegen einer Umbenennung, ist es ein Umzug in ein anderes Haus, und das Risiko ist deutlich höher. Neben dem URL-Mapping braucht es dann Weiterleitungen von der alten Domain auf die neue, auch für die Variante mit und ohne www sowie für http und https.

In der Search Console werden beide Domains als Property angelegt, und das Tool zur Adressänderung wird für die alte Domain genutzt. Die Weiterleitungen sollten mindestens ein Jahr bestehen bleiben, besser länger, solange noch Verweise oder Nutzer die alte Adresse ansteuern. Wer die alte Domain früh abschaltet, schneidet Signale ab, die noch unterwegs sind.

Weitere Sonderfälle sind Mehrsprachigkeit mit hreflang, die jede Sprachversion korrekt aufeinander verweisen lassen muss, Parameter-URLs und Filterseiten, Medien und PDF-Dateien, die extern verlinkt werden, sowie Subdomains. Auch eingebettete Dienste und Formulare sollten geprüft werden, denn manch wichtige Anfragequelle hängt an einer Adresse, die niemand auf dem Schirm hatte.

Ein weiterer Stolperstein ist der Systemwechsel selbst. Neue Content-Management-Systeme erzeugen oft eigene Adressmuster, hängen Schrägstriche an oder entfernen sie, schreiben Adressen in Kleinbuchstaben um oder liefern dieselbe Seite unter mehreren Pfaden aus. Das führt zu Dubletten, die Google erst mühsam zusammenführen muss. Legen Sie vorab fest, welche Schreibweise gilt, und erzwingen Sie sie per Weiterleitung und Canonical-Angabe.

Auch Inhalte, die erst im Browser per JavaScript entstehen, verdienen einen Blick. Rendert das neue System Texte und Links erst clientseitig, sieht ein Crawler im ersten Abruf womöglich wenig. Ein Vergleich von Quelltext und gerendertem Ergebnis, etwa mit der URL-Prüfung der Search Console, zeigt schnell, ob die wesentlichen Inhalte zuverlässig ankommen.

Eine ehrliche Empfehlung: Verbinden Sie Domainwechsel, Systemwechsel und kompletten Inhaltsumbau nicht in einem Schritt, wenn es sich vermeiden lässt. Je weniger Variablen sich gleichzeitig ändern, desto eindeutiger lassen sich Schwankungen später zuordnen.

Garantien gibt es hier nicht, und wer sie verspricht, verspricht zu viel. Google muss die neue Struktur erneut crawlen, die Weiterleitungen nachvollziehen und die Seiten neu bewerten. Erfahrungsgemäß zeigen sich in den ersten Tagen und Wochen Schwankungen in Positionen und Klicks, auch bei sauberer Umsetzung. Das ist normal und kein Grund zur Panik.

Entscheidend ist, die Bewegung einzuordnen. Ein leichtes Auf und Ab bei einzelnen Suchanfragen ist etwas anderes als ein Einbruch ganzer Seitengruppen. Letzterer deutet auf ein konkretes Problem hin, das sich in den Daten finden lässt: ein Bereich, der nicht indexiert wird, ein Muster von 404-Fehlern, eine fehlerhafte Weiterleitungsregel.

Gemessen wird mit den Berichten der Search Console: Indexierungsstatus, Crawling-Statistiken, 404-Fehler, Klicks und Impressionen im Vergleich zum Zeitraum vor dem Relaunch. Ergänzend zeigen die Server-Logs, ob Googlebot die neuen Adressen abruft. Einen Zeitraum von mehreren Wochen bis wenigen Monaten sollten Sie einplanen, bis sich ein stabiles Bild ergibt.

Bessere Ladezeiten, saubere Struktur und klarere Inhalte können nach dem Relaunch zu besserer Sichtbarkeit führen. Zusagen dazu lassen sich nicht seriös treffen, weil Wettbewerb und Algorithmen mitspielen.

Der wichtigste Grundsatz: Ein Relaunch ist ein Migrationsprojekt mit Designanteil, nicht umgekehrt. Wer SEO erst vor dem Livegang einbindet, kann nur noch retten. Wer es am Anfang einbindet, kann gestalten, was erhalten bleibt, und die Seitenstruktur an dem ausrichten, was Besucher ohnehin finden.

Zweitens: Bewahren ist eine legitime Strategie. Nicht jede Adresse, jeder Titel und jeder Text muss neu sein. Was bei Google gut funktioniert, bleibt zunächst unangetastet. Verbessern können Sie später, in kleinen Schritten, mit sauberem Vorher-Nachher-Vergleich.

Drittens: Dokumentation schützt. Die Mapping-Tabelle, der Altstand-Crawl und die Go-Live-Checkliste sind keine Bürokratie, sondern das Archiv, mit dem Sie in drei Monaten erklären können, warum eine Seite anders ist als vorher. Fehler lassen sich so schnell eingrenzen statt in einem Nebel aus Vermutungen zu suchen.

Die Angst vor Rankingverlusten ist begründet, aber beherrschbar. Die meisten Verluste entstehen nicht durch das, was neu ist, sondern durch das, was unbemerkt verloren geht: Adressen ohne Weiterleitung, Inhalte, die gestrichen wurden, Sperren, die stehen blieben. Genau dafür gibt es eine Methode, die aus Inventur, Mapping, Staging-Vergleich, Checkliste und Monitoring besteht.

Wir würden einen solchen Relaunch deshalb mit der Bestandsaufnahme beginnen, noch bevor ein Layout existiert. Das Ergebnis ist eine nüchterne Entscheidungsgrundlage: Welche Seiten tragen, welche nicht, wo ist eine neue Struktur sinnvoll und wo reicht ein neues Gewand. Danach lässt sich ehrlich sagen, wie hoch das Risiko ist.

Ein sinnvoller nächster Schritt ist ein kurzer Check Ihrer bestehenden Website: Crawl, Search-Console-Auswertung und eine Einschätzung, welche Seiten besonders schützenswert sind. Daraus ergibt sich, ob ein Relaunch nötig ist, in welchem Umfang und mit welchem Aufwand.