Website-Relaunch ohne Sichtbarkeitsverlust: Ein Praxisplan für österreichische KMU

Warum ein Relaunch Sichtbarkeit und Anfragen berührt

Ein Website-Relaunch ohne Sichtbarkeitsverlust gelingt nicht durch Zufall. Er ist das Ergebnis konkreter Vorbereitungsarbeit, die lange vor der ersten Design-Skizze beginnt. Wer das übersieht, riskiert, dass Anfragen ausbleiben, obwohl die neue Seite technisch einwandfrei funktioniert und optisch überzeugt.

Der Grund liegt im Verhalten von Suchmaschinen. Wenn sich URLs verändern, wenn Inhalte umstrukturiert werden, wenn Domains wechseln oder neue Navigationswege entstehen, müssen Suchmaschinen die gesamte Seite neu verarbeiten. Das braucht Zeit. Während dieser Phase kann es zu Schwankungen in den Positionen kommen. Das ist kein Fehler im System, sondern ein normaler Vorgang. Problematisch wird es erst dann, wenn Fehler in der Vorbereitung dafür sorgen, dass Seiten dauerhaft nicht mehr gefunden werden.

Für österreichische KMU und Selbstständige ist das besonders spürbar, weil der organische Kanal oft die wichtigste Quelle für Erstanfragen ist. Wer lokal gut positioniert ist, wer für bestimmte Leistungen oder Branchen gefunden wird, der hat sich diesen Platz über Monate oder Jahre aufgebaut. Ein schlecht geplanter Relaunch kann diesen Vorsprung innerhalb weniger Wochen zunichtemachen.

Ein Website-Relaunch ohne Sichtbarkeitsverlust bedeutet daher konkret: Die Suchmaschine soll nach dem Wechsel möglichst schnell verstehen, dass bekannte Inhalte weiterhin erreichbar sind, nur unter neuen Adressen oder in neuer Form. Dafür gibt es klare Methoden, die im Folgenden Schritt für Schritt erklärt werden.

Bestandsaufnahme vor Design und Technik

Bevor Farben, Layouts oder technische Plattformen diskutiert werden, steht eine Aufgabe an, die viele KMU überspringen: der vollständige Überblick über das, was die aktuelle Website leistet und wo sie sichtbar ist.

Diese Bestandsaufnahme hat einen klaren Zweck. Man kann nur schützen, was man kennt. Wer nicht weiß, welche Seiten derzeit Traffic erzeugen, welche Seiten in Suchergebnissen gelistet sind und welche URLs überhaupt existieren, trifft Entscheidungen im Dunkeln.

Was zur Bestandsaufnahme gehört

• Eine vollständige Liste aller vorhandenen URLs. Das lässt sich mit einem einfachen Crawling-Tool erstellen, das die gesamte Website durchsucht und alle erreichbaren Adressen auflistet.
• Eine Auswertung, welche Seiten über Suchmaschinen erreichbar sind. Die Google Search Console zeigt, für welche Suchanfragen Seiten erscheinen und wie oft sie angeklickt werden.
• Eine Einschätzung, welche Inhalte nach dem Relaunch erhalten bleiben, welche zusammengeführt werden und welche entfallen sollen.
• Externe Verlinkungen auf die eigene Website, die nach dem Relaunch erhalten bleiben sollen. Auch diese zeigt die Search Console unter dem Punkt eingehende Links.

Das Ergebnis ist eine strukturierte Übersicht, die als Grundlage für alle weiteren Entscheidungen dient. Sie zeigt auch, ob Seiten zusammengelegt werden können oder ob eine bestimmte Unterseite trotz unscheinbarem Design überraschend gut gefunden wird und daher besonderes Augenmerk verdient.

Warum mehrere große Änderungen gleichzeitig problematisch sind

Wer gleichzeitig den Domain-Namen wechselt, das Content-Management-System tauscht, die URL-Struktur komplett umstellt und die Inhalte stark überarbeitet, macht es der Suchmaschine schwer, dem Prozess zu folgen. Die Empfehlung lautet daher, Migrationsschritte nach Möglichkeit zu trennen und zeitlich zu staffeln. Das gilt vor allem dann, wenn gleichzeitig auch Inhalte grundlegend überarbeitet werden sollen.

URL-Mapping als verbindlicher Migrationsplan

Das URL-Mapping ist das Herzstück eines Website-Relaunchs ohne Sichtbarkeitsverlust. Es ist ein schriftlich festgehaltener Plan, der jeder alten URL eine passende neue URL zuordnet. Nicht ungefähr, nicht pauschal, sondern konkret und inhaltlich begründet.

Die Grundidee dahinter: Eine Suchmaschine, die bisher eine bestimmte Seite kannte, soll nach dem Relaunch an exakt jene Stelle weitergeleitet werden, die denselben oder einen vergleichbaren Inhalt enthält. Nur dann kann der aufgebaute Vertrauenswert einer Seite auf die neue URL übertragen werden.

So wird ein URL-Mapping erstellt

1. Alle bestehenden URLs werden in einer Tabelle erfasst, idealerweise mit Angabe zu Inhalt und bisheriger Suchsichtbarkeit.
2. Für jede alte URL wird die passende neue URL definiert. Seiten, die es nach dem Relaunch nicht mehr gibt, werden der thematisch nächsten Alternative zugeordnet.
3. Seiten, die ersatzlos wegfallen und für die es keine sinnvolle Alternative gibt, werden in der Planung entsprechend markiert. In diesem Fall ist eine Weiterleitung auf die Startseite keine gute Lösung, weil sie inhaltlich nicht passt.
4. Das fertige Mapping wird von allen Beteiligten, also Auftraggeber, Agentur und gegebenenfalls Technik, freigegeben, bevor die Umsetzung beginnt.

Ein häufiger Fehler ist es, alle alten URLs pauschal auf die neue Startseite umzuleiten. Das mag technisch einfach sein, hilft der Suchmaschine aber nicht. Eine Weiterleitung soll inhaltlich sinnvoll sein, damit sie ihren Zweck erfüllt.

Redirects, Canonicals, interne Links und Sitemap vorbereiten

Sobald das URL-Mapping steht, werden die technischen Maßnahmen vorbereitet, die nach dem Relaunch sofort greifen sollen.

Permanente serverseitige Redirects

Für dauerhafte URL-Änderungen sind permanente serverseitige Weiterleitungen vorgesehen. Diese teilen der Suchmaschine mit, dass eine Seite unter einer neuen Adresse dauerhaft erreichbar ist. Solche Weiterleitungen werden direkt auf dem Server eingerichtet, nicht über JavaScript oder Meta-Angaben. Redirect-Ketten, also Weiterleitungen, die auf weitere Weiterleitungen zeigen, sind zu vermeiden, weil sie die Verarbeitung verlangsamen.

Canonical-Tags richtig setzen

Ein Canonical-Tag ist ein Hinweis im Seitenquelltext, der der Suchmaschine mitteilt, welche URL als die maßgebliche Version einer Seite gilt. Nach einem Relaunch müssen diese Tags auf die jeweils neue URL zeigen, nicht mehr auf die alte.

Interne Links aktualisieren

Alle Links innerhalb der Website sollen nach dem Relaunch direkt auf die neuen URLs verweisen, nicht über Weiterleitungen. Das ist effizienter und vermeidet unnötige Umwege.

Sitemap aktualisieren und einreichen

Die XML-Sitemap listet alle relevanten Seiten der Website und hilft der Suchmaschine, diese rasch zu finden. Nach dem Relaunch wird sie auf Basis der neuen URLs erstellt und in der Search Console eingereicht. Dabei soll die Sitemap ausschließlich Seiten enthalten, die tatsächlich erreichbar und indexierbar sind.

Diese vier Maßnahmen arbeiten zusammen. Erst wenn Redirects, Canonicals, interne Links und Sitemap aufeinander abgestimmt sind, ist die technische Grundlage für einen Website-Relaunch ohne Sichtbarkeitsverlust gelegt.

Go-live in kontrollierten Schritten

Der eigentliche Launch-Tag ist für viele KMU der nervenaufreibendste Moment eines Website-Relaunches. Dabei lässt sich das Risiko erheblich reduzieren, wenn der Wechsel nicht als einmaliger großer Sprung, sondern als gesteuerter Übergang geplant wird. Google empfiehlt ausdrücklich, mehrere größere Änderungen nicht gleichzeitig vorzunehmen – wer also gleichzeitig die Domain wechselt, die URL-Struktur umbaut und das CMS austauscht, macht die spätere Fehlersuche unnötig schwierig.

Ein bewährter Ablauf sieht so aus: Zunächst wird die neue Website auf einer Testumgebung fertiggestellt und vollständig geprüft, bevor sie öffentlich erreichbar ist. Dort überprüft man alle Seiten, Formulare und Ladezeiten in Ruhe. Erst wenn alles stimmt, wird die neue Version live geschaltet. Direkt danach – idealerweise noch am selben Tag – werden alle Weiterleitungen aktiviert, die interne Verlinkung geprüft und die neue XML-Sitemap bei Google eingereicht.

Wenn auch die Domain wechselt, kommt das sogenannte Adressänderungstool in der Google Search Console ins Spiel. Dieses Tool ist allerdings nur für tatsächliche Domain- oder Subdomain-Wechsel gedacht. Wer lediglich den Hosting-Anbieter wechselt oder von einer Unterseite zu einer anderen umzieht, ohne dass sich die sichtbare Webadresse ändert, braucht dieses Tool nicht. Voraussetzung ist außerdem, dass man sowohl die alte als auch die neue Domain in der Search Console als Eigentümer bestätigt hat und dass die Weiterleitungen bereits funktionieren.

Kontrollen in Search Console und auf der Website

Nach dem Go-live beginnt die Beobachtungsphase – und die ist mindestens genauso wichtig wie die Vorbereitung. Google muss die neue Seitenstruktur erst neu einlesen und verarbeiten. In dieser Phase können Rankings vorübergehend schwanken, was nach einer Migration als normal gilt. Entscheidend ist, dass keine dauerhaften technischen Fehler vorliegen.

Was in der Search Console zu prüfen ist

• Wurden die neuen URLs bereits gecrawlt und indexiert? Das zeigt der Bericht zur Seitenindexierung.
• Gibt es Crawling-Fehler, also Seiten, die Google nicht erreichen konnte? Auch das zeigt die Search Console klar an.
• Werden die alten URLs korrekt weitergeleitet? Im URL-Prüftool lässt sich jede einzelne Adresse testen.
• Ist die neue Sitemap eingetragen und wurde sie verarbeitet?

Was direkt auf der Website zu prüfen ist

• Funktionieren alle internen Links auf die richtigen Zielseiten?
• Sind Canonical-Tags korrekt gesetzt, also verweisen sie jeweils auf die bevorzugte Version einer Seite?
• Laden Seiten vollständig, ohne fehlerhafte Bilder oder nicht funktionierende Formulare?
• Sind externe Links von anderen Websites, soweit bekannt, noch gültig oder laufen sie in eine Weiterleitung?

Die Kontrollen sollten nicht einmalig, sondern in den ersten Wochen nach dem Relaunch regelmäßig wiederholt werden, da Google die neuen Seiten schrittweise verarbeitet und Fehler manchmal erst nach einigen Tagen sichtbar werden.

Typische Relaunch-Fehler und ihre Vermeidung

Viele Sichtbarkeitsverluste nach einem Relaunch haben keine mysteriösen Ursachen – sie entstehen durch bekannte, vermeidbare Fehler. Wer diese kennt, kann gezielt gegensteuern.

Weiterleitungen auf die Startseite

Ein sehr häufiger Fehler: Alle alten URLs werden pauschal auf die Startseite weitergeleitet. Das klingt praktisch, führt aber dazu, dass Google nicht erkennt, welche alte Seite welcher neuen entspricht. Die aufgebaute Stärke einzelner Unterseiten geht dabei verloren. Stattdessen sollte jede alte URL auf die inhaltlich passende neue Seite weiterleiten – also die alte Produktseite für Fensterreinigung auf die neue Produktseite für Fensterreinigung, nicht auf die Startseite.

Redirect-Ketten

Wenn eine Weiterleitung selbst wieder auf eine weitere Weiterleitung zeigt und das über mehrere Stufen, spricht man von einer Redirect-Kette. Google empfiehlt, solche Ketten zu vermeiden und stattdessen direkt auf das finale Ziel weiterzuleiten. Ketten verlangsamen das Crawling und können dazu führen, dass manche Seiten gar nicht mehr vollständig verarbeitet werden.

Fehlende oder falsche Canonical-Tags

Canonical-Tags teilen Google mit, welche URL als die maßgebliche Version einer Seite gilt. Werden diese nach dem Relaunch vergessen oder falsch gesetzt, kann es vorkommen, dass Google die falsche Version einer Seite bevorzugt oder gar keine klare Entscheidung trifft.

Zu viele gleichzeitige Änderungen

Wer beim Relaunch gleichzeitig Domain, Struktur, Inhalte und Technik verändert, macht es sich unnötig schwer. Falls danach etwas nicht stimmt, ist kaum nachvollziehbar, welche Änderung die Ursache war. Wann immer möglich, sollten größere Eingriffe zeitlich gestaffelt werden.

Praxischeckliste für die ersten vier Wochen

Die folgende Liste gibt einen realistischen Überblick über die wichtigsten Aufgaben nach dem Go-live. Sie ersetzt keine individuelle technische Beratung, hilft aber dabei, keinen wesentlichen Schritt zu vergessen.

Woche eins: Technische Grundlagen sichern

1. Alle Weiterleitungen auf korrekte Zielseiten überprüfen – keine pauschalen Weiterleitungen auf die Startseite.
2. Neue XML-Sitemap in der Search Console einreichen.
3. Bei echtem Domain-Wechsel: Adressänderungstool in der Search Console verwenden, sofern Eigentum an beiden Properties bestätigt ist.
4. Canonical-Tags auf allen wichtigen Seiten kontrollieren.
5. Ladezeiten und mobile Darstellung testen.

Woche zwei: Erste Indexierungsergebnisse auswerten

1. In der Search Console prüfen, welche neuen URLs bereits indexiert wurden.
2. Crawling-Fehler identifizieren und beheben.
3. Interne Links auf Fehler überprüfen.
4. Alte URLs stichprobenartig im URL-Prüftool testen.

Woche drei: Sichtbarkeit beobachten

1. Rankingveränderungen im Leistungsbericht der Search Console verfolgen – vorübergehende Schwankungen sind in dieser Phase normal.
2. Prüfen, ob wichtige Seiten in den Suchergebnissen noch erscheinen.
3. Bei auffälligen Verlusten einzelner Seiten gezielt die Weiterleitungen und Canonical-Tags dieser Seiten nachprüfen.

Woche vier: Nacharbeiten und Dokumentation

1. Offene Crawling-Fehler aus den Vorwochen abarbeiten.
2. Redirect-Ketten auflösen, falls solche entdeckt wurden.
3. Ergebnisse dokumentieren: Welche URLs wurden weitergeleitet, welche Fehler traten auf, wie hat sich die Indexierung entwickelt?
4. Externe Backlinks, soweit bekannt, auf Aktualität prüfen und bei Bedarf Websitebetreiber kontaktieren.

Ein Website-Relaunch ohne Sichtbarkeitsverlust ist kein Zufall, sondern das Ergebnis sorgfältiger Vorbereitung, eines kontrollierten Go-lives und konsequenter Nachkontrolle. Österreichische KMU und Selbstständige, die diese Schritte systematisch abarbeiten, geben Google alle nötigen Signale, um die neue Website schnell und korrekt einzuordnen – und schützen damit das Ranking, das sie sich über Monate oder Jahre aufgebaut haben.

Nächster sinnvoller Schritt

Prüfen Sie die wichtigsten Punkte für Ihr Unternehmen und setzen Sie zuerst die Maßnahme um, die Auffindbarkeit und Vertrauen nachvollziehbar verbessert. Wer sein Unternehmen zusätzlich öffentlich sichtbar machen möchte, kann den Firmeneintrag auf firmenwebseiten.at anlegen oder aktualisieren.

Quellen und weiterführende Informationen

• Site Moves and Migrations (developers.google.com)
• Redirects and Google Search (developers.google.com)
• Adressänderungstool in der Search Console (support.google.com)