SEO-Relaunch Teil 2: Struktur, CMS und Content

Hinweis vorab: Dieser Leitfaden behandelt den klassischen Relaunch, bei dem die Domain gleich bleibt. Wenn ein Domainwechsel geplant ist, gelten andere Regeln und eine andere Reihenfolge. Lies in dem Fall zuerst SEO-Relaunch Teil 1: Domainwechsel.

Erst die Grundsatzfrage: Muss das wirklich ein Relaunch sein?

Bevor du anfängst, Agenturen zu briefen und Budgets zu planen, lohnt eine ehrliche Antwort auf diese Frage. Die meisten Websites brauchen keinen Relaunch. Sie brauchen Pflege, gezielte technische Verbesserungen und frischen Content. Amazon, Wikipedia und die meisten erfolgreichen Nachrichtenportale haben noch nie einen klassischen "Relaunch" gemacht. Sie entwickeln sich kontinuierlich weiter, Schritt für Schritt.

Ein Relaunch macht Sinn, wenn mindestens eines dieser Szenarien zutrifft:

• Das aktuelle CMS ist technisch nicht mehr updatebar oder systembedingt langsam
• Die URL-Struktur ist so chaotisch, dass eine saubere Konsolidierung über Redirects nicht mehr ausreichend ist
• Das Design verhindert nachweislich Conversions, und ein Redesign erfordert zwingend eine neue technische Basis
• Das Unternehmen repositioniert sich grundlegend, und die Informationsarchitektur der Website spiegelt das nicht mehr wider

Klingt banal, ist es aber nicht. Sehr häufig startet ein Relaunch, weil jemand die Website "nicht mehr schön" findet oder weil die neue Marketingleiterin einen anderen Farbton bevorzugt. Das sind keine Relaunch-Gründe. Das ist Farbwahl. Wenn die Rankings gut sind und der Traffic stimmt, ist ein Relaunch kein Gewinn, sondern ein Risiko.

Hast du die Frage ehrlich beantwortet und kommst zum Ergebnis, dass ein Relaunch tatsächlich notwendig ist: Gut, dann mach es aber richtig.

---

Phase 1: Bestandsaufnahme und Strategie

Ein Relaunch ohne vollständige Bestandsaufnahme der bestehenden Website ist ein Blindflug. Das klingt wie ein Gemeinplatz, ist aber in der Praxis der häufigste Ausgangsfehler. Design-Agenturen wollen gestalten, Entwickler wollen bauen, und niemand möchte zuerst zwei Wochen lang Daten auswerten.

Das SEO-Baseline-Dokument

Bevor auch nur ein Wireframe gezeichnet wird, brauchst du ein vollständiges Bild des Status quo. Dieses Dokument ist deine Versicherung. Es zeigt dir später, ob der Relaunch tatsächlich besser war als vorher, und welche Rankings verloren gegangen sind.

Das Dokument sollte mindestens umfassen:

• Vollständige URL-Liste aller indexierten Seiten (via Screaming Frog oder Search Console)
• Rankings für alle Keywords im Long-Tail und Short-Tail (Export aus einem Ranking-Tool)
• Organischer Traffic pro URL und pro Zeitraum aus Google Analytics oder einem vergleichbaren Tool
• Conversion-Raten nach Landingpage
• Backlink-Profil mit den wichtigsten verlinkten URLs
• Core Web Vitals Baseline (PageSpeed Insights, Search Console)
• Aktuelle interne Verlinkungsstruktur

Erst wenn dieses Dokument vorliegt, beginnt die Planung der neuen Struktur. Alles andere ist Bauchgefühl.

Der Content-Audit: Behalten, zusammenführen, streichen

Das ist die Arbeit, die die meisten überspringen, und die gleichzeitig den größten Einfluss auf die SEO-Performance nach dem Relaunch hat.

Jede URL, die aktuell indexiert ist, landet in einer von vier Kategorien:

Behalten: Die Seite rankt gut, generiert Traffic, hat ein klares Keyword-Thema und erfüllt die Suchintention. Sie wird 1:1 übernommen und optimiert, die URL bleibt erhalten.

Zusammenführen (Merge): Mehrere dünne Seiten decken dasselbe oder sehr ähnliche Themen ab, kannibalisieren sich gegenseitig oder sind einzeln zu schwach. Sie werden zu einer konsolidierten, inhaltlich stärkeren Seite zusammengefasst. Die alten URLs bekommen 301-Redirects auf die neue Zielseite.

Redirect auf thematisch passende Seite: Die Seite hat keinen eigenständigen Wert, aber es gibt thematisch relevante Inhalte, auf die sie weitergeleitet werden kann. 301-Redirect ohne neue Seite.

Löschen (Delete): Keine Rankings, kein Traffic, kein Backlink-Wert, kein inhaltlicher Mehrwert. Diese Seiten verschwinden ohne Redirect. Bei echter inhaltlicher Leere ist ein 410-Statuscode (Gone) gegenüber einem 404 vorzuziehen, da er Google explizit signalisiert, dass die Seite absichtlich entfernt wurde.

Keine Angst vor der Kategorie "Löschen". Eine Website mit 800 indexierten Seiten, von denen 400 kaum Traffic und kein erkennbares Keyword-Thema haben, profitiert davon, auf 400 starke Seiten reduziert zu werden. Crawl-Budget, interne Verlinkungsqualität und die thematische Autorität in den Augen von Google steigen.

Ziele und KPIs definieren

Schreib auf, was der Relaunch verbessern soll, und zwar messbar. "Bessere User Experience" ist kein Ziel. "Organischer Traffic auf /leistungen/ um 25% steigern innerhalb von 6 Monaten nach Go-live" ist eines.

Konkrete KPIs könnten sein:

• Organischer Traffic (gesamt und pro Seitengruppe)
• Rankings für definierte Priority Keywords
• Core Web Vitals (LCP, INP, CLS) auf bestimmten Schwellenwerten
• Conversion-Rate auf wichtigen Landingpages
• Crawl-Fehlerrate in der Search Console

Diese KPIs fließen in die technische und inhaltliche Planung ein. Wer sie erst nach dem Go-live definiert, hat keine Basis für eine ehrliche Erfolgsmessung.

---

Phase 2: Die CMS-Entscheidung

Der Artikel heißt "Struktur, CMS und Content", also kommt das CMS auch wirklich vor. Nicht als Checkbox, sondern als strategische Entscheidung, die erheblichen Einfluss auf den SEO-Erfolg hat.

Wann ein CMS-Wechsel sinnvoll ist

Ein CMS-Wechsel ist immer ein Risikofaktor beim Relaunch. Er ist dann sinnvoll, wenn das alte System:

• URL-Strukturen erzwingt, die sich nicht anpassen lassen (z.B. systemgenerierte Parameter-URLs)
• Keine saubere robots.txt- oder Canonical-Steuerung erlaubt
• Serverseitig so langsam ist, dass Core Web Vitals dauerhaft rot bleiben
• Keine modernen Bildformate (WebP, AVIF) unterstützt
• JavaScript-Rendering erzwingt, das für SEO-kritische Inhalte problematisch ist

"Wir wollen mal etwas Neues probieren" ist kein Grund für einen Wechsel des CMS!

Was beim CMS-Wechsel aus SEO-Sicht schiefgeht

Das häufigste Problem: Das neue System generiert andere URL-Strukturen als das alte. Was vorher /leistungen/webdesign/ war, heißt jetzt /services/webdesign-und-entwicklung/. Das CMS macht das von Haus aus so, und im Eifer des Projekts bemerkt es niemand, bis das URL-Mapping erstellt werden soll, und dann ist bereits zu viel gebaut worden.

Zweithäufigstes Problem: Die Staging-Umgebung ist korrekt mit noindex gesperrt, aber beim Deployment auf Produktion wird die noindex-Direktive nicht entfernt, oder sie steckt noch in der robots.txt. Ergebnis: Eine frisch gelaunchte Website, die Google aktiv aus dem Index ausperrt. Das klingt nach einem Fehler, der nicht vorkommt. Er kommt regelmäßig vor.

Weiteres Problem bei CMS-Wechsel: Schema Markup, Canonical-Tags und hreflang-Attribute sind im alten System händisch oder via Plugin gepflegt. Im neuen System müssen sie komplett neu implementiert werden. Das geht oft vergessen, weil es visuell nicht sichtbar ist.

CMS-Entscheidung und AI Search

Ein Aspekt, der 2026 zunehmend relevant wird: Wie gut kann das CMS strukturierte Daten ausgeben? ChatGPT, Perplexity und Gemini beziehen Inhalte auch über das reguläre Web-Crawling. Websites, die saubere strukturierte Daten (Schema.org) für alle relevanten Seitentypen ausgeben, werden von KI-Systemen zuverlässiger korrekt eingeordnet.

Ein CMS, das strukturierte Daten nur über umständliche Plugins mit eingeschränkten Schema-Typen unterstützt, ist langfristig ein Nachteil. Das ist kein Ausschlusskriterium, aber ein legitimer Faktor in der Entscheidung.

---

Phase 3: URL-Struktur und Website-Architektur

Das ist der Teil, bei dem die meisten Ranking-Verluste entstehen. URL-Strukturen werden im Briefing oft als "technisches Detail" behandelt, das die Entwickler klären. Sie sind in Wahrheit eine strategische Entscheidung mit direkten Konsequenzen für Rankings.

Das Grundprinzip: so wenig Änderungen wie möglich

Wenn eine URL rankt und Traffic bringt, ist die URL gut. Nicht im Sinne von "ästhetisch ansprechend", sondern im Sinne von "funktioniert für Suchmaschinen und Nutzer". Jede URL-Änderung erfordert einen 301-Redirect, und jeder 301-Redirect überträgt nicht 100% des Linkjuice. Bei tiefen Redirect-Ketten und bei URLs mit starken Backlinks bedeutet jede Umleitung einen Signalverlust.

Die Faustregel lautet: URL-Änderungen nur vornehmen, wenn es einen konkreten SEO-Grund gibt. "Sauberer aussehen" ist kein SEO-Grund. Gute URL-Struktur erkennst du an drei Kriterien:

1. Die URL beschreibt den Inhalt knapp und präzise
2. Die Hierarchie der URL spiegelt die Informationsarchitektur der Website wider
3. Die URL enthält das primäre Keyword der Seite in lesbarer Form

Wenn die bestehenden URLs diese Kriterien erfüllen, lass sie so wie sie sind.

Wann URL-Änderungen trotzdem sinnvoll sind

Es gibt legitime Gründe für URL-Änderungen:

• Seiten, die in der alten Struktur schlecht positioniert waren und thematisch falsch einsortiert sind
• Zusammenführung mehrerer schwacher Seiten zu einer starken, was eine neue konsolidierte URL erfordert
• Seitenkategorien, die im alten System systembedingt kryptische URLs hatten (z.B. ?page_id=347)
• Internationalisierung oder neue Sprachversionen, die eine klare URL-Logik erfordern

In diesen Fällen: URL-Änderungen durchführen, aber mit einem vollständigen 301-Redirect-Plan für jede betroffene URL.

Website-Architektur: Flach gewinnt

Eine flache Hierarchie, bei der jede wichtige Seite in wenigen Klicks von der Startseite erreichbar ist, ist sowohl für Nutzer als auch für Google-Crawler optimal. Als Faustregel gilt: Keine wichtige Seite sollte mehr als 3 Klicks von der Startseite entfernt sein.

Tiefe Verzeichnisstrukturen wie /blog/kategorie/unterkategorie/thema/artikel/ verteilen das Crawl-Budget ineffizient und signalisieren Google eine geringere Wichtigkeit der tiefer liegenden Seiten. Eine Bereinigung der Hierarchie beim Relaunch ist eine der wenigen Maßnahmen, die sich mittel- bis langfristig fast immer auszahlt.

Internes Linking als Rankingsignal

Die interne Verlinkungsstruktur der neuen Website bestimmt, welche Seiten Google als wichtig einstuft. Seiten, die viele interne Links erhalten, ranken in der Regel besser. Seiten, die kaum intern verlinkt sind, werden von Google als weniger relevant eingestuft, unabhängig vom Inhalt.

Beim Relaunch bietet sich die Gelegenheit, das interne Linking strategisch aufzubauen:

• Jede Kategorieseite verlinkt auf alle relevanten Unterseiten
• Jede Unterseite verlinkt auf die übergeordnete Kategorieseite und auf thematisch verwandte Seiten
• Wichtige Zielseiten (Leistungsseiten, High-Traffic-Artikel) erhalten interne Links aus möglichst vielen thematisch relevanten Seiten
• Anchor-Texte interner Links enthalten das Keyword der Zielseite, natürlich formuliert

Breadcrumbs sind dabei ein unterschätztes Werkzeug. Sie erzeugen automatisch interne Links mit sinnvollen Ankertexten auf jeder Seite und helfen gleichzeitig dem Nutzer bei der Orientierung.

---

Phase 4: Technische SEO-Umsetzung

Technisches SEO beim Relaunch ist keine Checkliste, die man am Ende abarbeitet. Es ist eine parallele Spur, die von Beginn der Entwicklung an mitläuft.

301-Redirect-Plan: Vollständig oder nicht

Jede URL, die den Ort wechselt oder gelöscht wird, braucht einen 301-Redirect. Keine Ausnahmen. Der Redirect-Plan wird aus dem Content-Audit abgeleitet und enthält jede alte URL mit ihrer neuen Ziel-URL.

Häufige Lücken im Redirect-Plan:

• Blog-Artikel werden vergessen, weil der Fokus auf den Hauptseiten liegt
• Ressourcen wie PDFs, Bilddateien und Downloads werden nicht berücksichtigt
• Paginierte Seiten (Seite 2, Seite 3...) werden ignoriert
• Die alten URLs in Großschreibung oder mit trailing Slash werden nicht als separate URLs erkannt

Tools wie Screaming Frog crawlen die alte Website vollständig und liefern die Basis-URL-Liste. Der Redirect Generator hilft beim Generieren der .htaccess- oder Nginx-Regeln.

Beim Testen der Redirects auf der Staging-Umgebung: Immer auf Redirect-Ketten prüfen. URL A → URL B → URL C ist eine Kette und verliert mehr Linkjuice als URL A → URL C.

Core Web Vitals

LCP (Largest Contentful Paint), INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift) sind seit 2021 offizielle Google-Rankingfaktoren, und sie werden bei einem Relaunch leicht verschlechtert statt verbessert. Animationen, schwere Schriften, große Hero-Images und JavaScript-intensive Komponenten sind die häufigsten Ursachen.

Die wichtigsten Maßnahmen:

LCP verbessern: Das größte sichtbare Element im Viewport (meist ein Hero-Bild oder H1-Text) muss schnell laden. Bilder als WebP oder AVIF, Preload-Directive für das LCP-Element, kein lazy loading für Above-the-fold-Inhalte.

INP verbessern: Langsame JavaScript-Ausführung ist der Haupttreiber. Drittanbieter-Scripts (Analytics, Chat-Widgets, Social Buttons) verzögern die Interaktivität. Kritische Pfade identifizieren, unkritische Scripts async oder defer laden.

CLS minimieren: Layout-Verschiebungen entstehen durch Bilder ohne definierte Dimensionen, Ads die ihren Platz verändern, und Schriften die beim Laden springen. Immer width und height-Attribute für Bilder setzen, Font-Display-Strategie definieren.

Messe vor dem Relaunch, was die aktuelle Website liefert. Wenn die neue Website schlechtere Core Web Vitals hat als die alte, ist das kein Fortschritt, sondern ein Rückschritt mit neuem Design.

HTTPS, Canonical-Tags, hreflang

HTTPS ist seit Jahren Standard und kein differenzierender Rankingfaktor mehr, aber ein fehlerhaft implementiertes SSL-Zertifikat oder gemischte HTTP/HTTPS-Inhalte auf einer Seite sind aktive Ranking-Schäden.

Canonical-Tags auf jeder Seite: Sie sollten auf sich selbst verweisen und keine Parameter enthalten. Bei einem CMS-Wechsel werden sie oft nicht korrekt übernommen.

hreflang für mehrsprachige Websites: Wenn die Website in mehreren Sprachen existiert, müssen die hreflang-Attribute für jede Sprachversion korrekt auf alle anderen Sprachversionen verweisen. Eine häufige Falle: die hreflang-Implementierung funktioniert in der alten Website und wird im neuen CMS einfach vergessen.

Strukturierte Daten: Relaunch als Upgrade-Chance

Ein Relaunch ist ein natürlicher Zeitpunkt, um strukturierte Daten (Schema.org Markup) systematisch zu implementieren oder zu erweitern. Das neue CMS-Setup erlaubt es, Schema-Typen sauber und vollständig einzubauen, statt sie nachträglich zu ergänzen.

Die relevanten Typen hängen vom Seitentyp ab:

• Unternehmensseiten: Organization, LocalBusiness, ProfessionalService
• Artikel und Blog: Article, BlogPosting mit Author- und datePublished-Attributen
• FAQ-Seiten oder -Abschnitte: FAQPage
• Anleitungen: HowTo
• Produktseiten: Product mit Review und AggregateRating
• Veranstaltungen: Event

Für die AI Search Optimierung ist strukturiertes Markup besonders wertvoll: KI-Systeme wie ChatGPT und Perplexity können Entitätsdaten (Wer ist das Unternehmen? Was bietet es an? Wer ist Autor?) präziser zuordnen, wenn Schema.org-Daten sauber ausgegeben werden. Das zahlt auf Share of Model ein, also darauf, wie oft und wie korrekt du in KI-Antworten auftauchst.

XML-Sitemap und robots.txt

Die XML-Sitemap enthält ausschließlich URLs, die indexiert werden sollen. Keine noindex-Seiten, keine Weiterleitungs-URLs, keine paginierten Seiten, es sei denn sie haben eigenständigen Wert.

Die robots.txt der Staging-Umgebung sperrt alle Crawler. Die robots.txt der Produktionsumgebung hat diesen Sperreintrag nicht. Das klingt selbstverständlich. Es ist der Fehler, der am häufigsten passiert.

---

Phase 5: On-Page und Content

Content-Audit in die Praxis umsetzen

Aus der Analyse in Phase 1 liegen die Kategorien "behalten", "zusammenführen", "redirecten" und "löschen" vor. Jetzt werden sie umgesetzt.

Bei Seiten in der Kategorie "behalten" lohnt es sich, während des Relaunches auch den Inhalt zu optimieren. Nicht neu schreiben um des Schreibens willen, sondern gezielt verbessern: Ist die primäre Suchintention klar erfüllt? Fehlen Aspekte, die Mitbewerber abdecken? Sind Fakten und Zahlen aktuell?

Bei zusammengeführten Seiten muss die neue konsolidierte Seite inhaltlich stärker sein als jede der alten Einzelseiten. Wenn zwei dünne Seiten zusammengeführt werden und das Ergebnis ist eine mitteldicke Seite ohne klares Profil, hat die Zusammenführung nichts gebracht.

Keyword-Mapping und Suchintention

Jede Seite hat genau ein primäres Keyword und eine klar definierte Suchintention. Das ist keine akademische Übung, sondern die Grundlage für alles, was danach kommt: Title Tag, H1, URL, internes Linking, strukturierte Daten.

Wichtig: Keyword-Mapping vor dem Erstellen der Seitenstruktur. Wer zuerst eine Navigationsstruktur entwirft und dann schaut, welche Keywords dazu passen, landet regelmäßig in einer Situation, in der mehrere Seiten dasselbe Keyword bedienen (Keyword-Kannibalisierung) oder wichtige Keywords gar keine dedizierte Seite haben.

Der Google Keyword Planner ist für diese Arbeit übrigens nicht geeignet. Er zeigt aggregierte Daten für breite Begriffe und unterschätzt Long-Tail-Volumen systematisch. Besser: Sistrix oder SE Ranking für den DACH-Markt, kombiniert mit Search Console Daten der bestehenden Website.

Title Tags, Meta Descriptions, H1

Title Tags sind immer noch einer der stärksten On-Page-Rankingfaktoren. Für jeden Seitentyp gilt:

• Das primäre Keyword möglichst früh im Title Tag platzieren
• Maximal 60 Zeichen, um Abschneiden in den SERPs zu vermeiden
• Kein Gedankenstrich, keine Sonderzeichen, die den Lesefluss brechen
• Für transaktionale Seiten einen impliziten CTA einbauen ("...für KMU | Jetzt anfragen")

Meta Descriptions sind kein direkter Rankingfaktor, aber sie beeinflussen die Klickrate erheblich. Maximal 155 Zeichen, mit einem konkreten Nutzenversprechen, das die Suchintention aufgreift.

H1 und Title Tag können identisch sein, müssen es aber nicht. Auf einer Landingpage kann der Title Tag kürzer und keyword-fokussierter sein, während die H1 etwas ausformulierter ist und direkt in den Lesefluss einführt.

E-E-A-T konkret

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) ist kein abstraktes Konzept, sondern ein Satz konkreter Signale, die Google bei der Bewertung von Seiten heranzieht.

Beim Relaunch umsetzen:

Experience (Erfahrung): Originalinhalte, die auf echter Praxiserfahrung basieren, Fallbeispiele aus eigenen Projekten, Aussagen die zeigen, dass jemand mit dem Thema tatsächlich gearbeitet hat. Generische Informationen, die man in jedem SEO-Ratgeber findet, helfen hier nicht.

Expertise: Autorenprofile mit Nachweisen der Fachkompetenz (Berufserfahrung, Referenzen, Veröffentlichungen). Jeder Artikel sollte einer echten Person zugeordnet sein, mit einer verlinkten Autorenseite.

Authoritativeness: Externe Verlinkungen von relevanten Quellen (Backlinks), Erwähnungen in Fachmedien, Zitationen. Das kann der Relaunch selbst nicht erzeugen, aber er kann die Basis schaffen, auf der Link-Building aufbaut.

Trustworthiness: Vollständiges Impressum und Datenschutzerklärung, HTTPS, klar erkennbare Kontaktinformationen, transparente Angaben zu Quellen und Datenbasis bei faktischen Aussagen. Eine "Über uns"-Seite, die tatsächlich Informationen enthält statt Marketingprosa.

Für YMYL-Seiten (Your Money or Your Life, also Seiten zu Gesundheit, Finanzen, Recht) legt Google besonders strenge E-E-A-T-Maßstäbe an. Für ein SEO-Beratungs-Angebot gilt dasselbe: Wer Budgets, Rankings und Geschäftsergebnisse beeinflusst, muss nachweisbare Expertise mitbringen.

Content-Formatierung für Lesbarkeit und AI Search

Gut strukturierter Content ist sowohl für Nutzer als auch für Suchmaschinen leichter zu verstehen. Beim Relaunch bietet sich die Gelegenheit, Formatierungsstandards für die gesamte Website zu definieren:

• Klare H2/H3-Hierarchie mit keyword-relevanten Subheadings
• Absätze mit maximal 4 bis 5 Sätzen, kein ununterbrochener Textwall
• Tabellen für Vergleichsaussagen und strukturierte Gegenüberstellungen
• Nummerierte Listen für Prozesse mit klarer Reihenfolge
• Inhaltsverzeichnisse mit Anchor-Links bei langen Seiten (ab ca. 2.000 Wörtern)

Für AI Search kommt eine weitere Anforderung dazu: KI-Systeme extrahieren bevorzugt präzise, faktische Aussagen in klarer, direkter Formulierung. Ein FAQ-Abschnitt mit FAQPage-Schema, der echte Nutzerfragen direkt und knapp beantwortet, hat hohe AEO-Extraktion-Wahrscheinlichkeit. Langer, mäandernder Fließtext hat sie nicht.

---

Phase 6: Staging, Launch und die erste Woche

Staging-Umgebung

Die neue Website wird vollständig auf einer Staging-Umgebung entwickelt und getestet, bevor sie live geht. Die Staging-Umgebung muss vor unerwünschter Indexierung geschützt werden. Der zuverlässigste Weg ist HTTP-Passwortschutz: Crawler kommen gar nicht erst rein, und auch neugierige Nutzer mit der URL sehen nichts. Ist Passwortschutz nicht möglich, ist ein noindex-Meta-Tag auf allen Staging-Seiten die nächstbeste Option. Google crawlt dann zwar, nimmt die Seiten aber nicht in den Index auf. Was man vermeiden sollte: ausschließlich Disallow: / in der robots.txt. Das verhindert das Crawling, nicht die Indexierung. Kennt Google die URL aus anderen Quellen, zum Beispiel einem externen Link auf die Staging-Domain, kann sie trotzdem im Index landen, nur ohne lesbares Snippet. Ein Index-Eintrag ohne Inhalt ist schwerer zu bereinigen als einer, der gar nicht erst entstanden ist.

Überprüfe vor dem Launch explizit: Ist die robots.txt-Sperre für Crawler auf dem Produktionssystem entfernt? Sind die noindex-Direktiven, die im Staging gesetzt waren, auf Produktion nicht mehr vorhanden?

Der vollständige Crawl der Staging-Version mit Screaming Frog vor dem Go-live ist Pflicht. Er zeigt:

• Seiten mit fehlendem oder doppeltem Title Tag
• Fehlende H1-Tags
• Fehlerhafte oder fehlende Canonical-Tags
• Seiten, die versehentlich noindex gesetzt haben
• Broken Links in der internen Verlinkung
• Bilder ohne Alt-Texte

Diese Probleme auf der Staging-Umgebung zu finden ist angenehm. Sie nach dem Go-live zu finden kann teuer werden.

Launch-Zeitpunkt

Der Go-live findet zu einem Zeitpunkt mit geringem Traffic statt, typischerweise nachts oder am Wochenende. Das minimiert die Auswirkungen möglicher Probleme auf Nutzer und gibt dem Team Zeit, Fehler zu beheben, bevor der reguläre Betrieb beginnt.

Am Launch-Tag sofort prüfen:

• 301-Redirects für alle geänderten URLs funktionieren korrekt
• robots.txt gibt keine Crawler-Sperre für Produktion aus
• XML-Sitemap ist aktualisiert und in der Google Search Console eingereicht
• HTTPS läuft auf allen Seiten ohne Mixed-Content-Warnungen
• Alle wichtigen Tracking-Codes sind aktiv (Analytics, Search Console, Conversion-Tracking)
• Navigation, Formulare und Suchfunktionen sind funktionsfähig

In den ersten 24 bis 48 Stunden:

• Search Console auf Crawl-Fehler und Coverage-Probleme prüfen
• Core Web Vitals auf Regression gegenüber Baseline prüfen
• Rankings für Priority Keywords tracken
• Server-Logs auf Crawler-Aktivität überprüfen

Die kritischen ersten Wochen

In den ersten Wochen nach einem Relaunch schwanken Rankings. Das ist normal und kein Grund zur Panik. Google crawlt und bewertet die neue Struktur, verarbeitet die Redirects und aktualisiert den Index.

Was nicht normal ist und sofortige Reaktion erfordert:

• Rankings für Brand-Keywords brechen ein (deutet auf ein fundamentales Crawling- oder Indexierungsproblem hin)
• Traffic geht auf nahezu null (deutet auf robots.txt-Sperrung oder noindex auf wichtigen Seiten hin)
• Große Gruppen von Seiten erscheinen nicht im Index (Redirect-Ketten, falsche Canonical-Tags oder Crawling-Blockaden)

Tägliches Monitoring in den ersten zwei Wochen ist keine Übervorsicht, sondern Pflicht.

---

Häufige Fehler beim SEO-Relaunch

Das Folgende ist keine theoretische Liste. Es sind Fehler, die regelmäßig passieren, auch bei Projekten mit ausreichend Budget und erfahrenen Beteiligten.

Unvollständiger 301-Redirect-Plan
Die wichtigsten Seiten sind abgedeckt, Blog-Artikel und tiefe Unterseiten nicht. Jede URL, auf die externe Backlinks zeigen, ist eine potenzielle Verlustquelle, wenn sie keinen Redirect bekommt.

noindex auf Produktion vergessen zu entfernen
Der Klassiker. Passiert regelmäßig, weil Staging und Produktion häufig fast identische Konfigurationen haben. Ein Check am Launch-Tag und am Tag danach ist Pflicht.

CMS generiert andere URL-Strukturen als erwartet
Das neue System erstellt automatisch andere URL-Pfade als dokumentiert. Wird oft erst beim Abgleich des Redirect-Plans bemerkt, wenn bereits viel gebaut ist.

Content-Audit übersprungen
Schwache Seiten werden 1:1 übernommen, weil "das schon Bestandteil des alten Designs war". Das Ergebnis ist eine neue Hülle mit alten Problemen.

Staging-Crawl nicht durchgeführt
Fehler, die vor dem Launch erkennbar gewesen wären, werden erst nach dem Go-live gefunden.

Tracking nicht vor dem Launch verifiziert
Analytics-Lücken in den ersten Tagen nach dem Launch machen eine saubere Vorher-Nachher-Analyse unmöglich.

SEO erst nach dem Briefing der Agentur eingebunden
Wenn die Informationsarchitektur, URL-Struktur und das CMS bereits entschieden sind, bevor jemand SEO-relevante Anforderungen eingebracht hat, sind viele Entscheidungen nicht mehr rückgängig zu machen.

SEO muss vor dem Briefing der Umsetzungspartner eingebunden sein.

Strukturierte Daten nicht übernommen
Schema Markup aus dem alten System wird nicht in das neue migriert. Ergebnis: Verlust von Rich Snippets und schlechtere AI Search Sichtbarkeit.

---

Nach dem Relaunch: Dauerhafte Optimierung

Ein Relaunch ist kein Abschluss. Er ist ein Neustart auf besserer Basis. Was danach kommt, entscheidet langfristig über den Erfolg.

Monatliches SEO-Monitoring

Monatliche Auswertung der KPIs aus dem Baseline-Dokument: Wie haben sich Rankings, Traffic und Conversions gegenüber der Vorperiode entwickelt? Was läuft besser als erwartet? Was schlechter?

Besonders wertvoll: Search Console Coverage Report monatlich prüfen. Neue Crawl-Fehler, versehentlich noindexierte Seiten und fehlgeschlagene Redirects tauchen dort früh auf.

Content kontinuierlich weiterentwickeln

Seiten, die nach dem Relaunch schlechter ranken als vorher, brauchen keine weitere technische Diagnose, solange Redirects und Indexierung stimmen. Sie brauchen besseren Inhalt. Konkret: Themen, die Mitbewerber umfassender abdecken, Fragen, die Nutzer stellen und die die Seite nicht beantwortet, fehlende Daten und Beispiele.

Seiten, die besser ranken als erwartet, verdienen mehr interne Links und Content-Tiefe.

Backlink-Profil im Blick behalten

Nach dem Relaunch können externe Links, die auf nicht mehr existierende URLs zeigen, zu 404-Fehlern führen, wenn Redirects fehlen oder nachträglich entfernt wurden. Monatlicher Export der 404-Fehler aus der Search Console und Abgleich mit dem Backlink-Profil.

SEO als fortlaufenden Prozess verstehen

Das Ziel eines erfolgreichen Relaunches ist nicht, drei Monate nach dem Go-live dieselben Rankings wie vorher zu haben. Das wäre ein Nullsummenspiel. Das Ziel ist eine technisch saubere, inhaltlich starke Website als Basis, von der aus SEO-Maßnahmen eine überproportionale Wirkung haben.

Das erfordert keinen nächsten Relaunch in drei Jahren. Es erfordert kontinuierliche Pflege, regelmäßige Content-Aktualisierungen, technische Wartung und die Bereitschaft, auf Daten zu reagieren statt auf Bauchgefühl.

---

Fazit

Ein Relaunch birgt erhebliche SEO-Risiken, und zwar unabhängig davon, wie viel Budget und Expertise im Projekt stecken. Die Risiken sind nicht unvermeidbar. Sie entstehen fast immer aus demselben Grundproblem: SEO wird als Teilaspekt behandelt, der am Ende noch "mit eingebaut" wird, statt als strukturgebende Anforderung, die das gesamte Projekt durchzieht.

Die Konsequenz ist, dass die Informationsarchitektur ohne SEO-Input definiert wird, die URL-Struktur aus CMS-Defaults entsteht, der Content-Audit übersprungen wird und der 301-Redirect-Plan unvollständig bleibt.

Wer diese Reihenfolge dreht, wer zuerst Bestandsaufnahme und Strategie macht, dann Architektur und CMS, dann Technik und Content, und SEO in jede dieser Phasen einbettet, hat gute Chancen, aus dem Relaunch besser herauszukommen als er hineingegangen ist. Nicht nur optisch, sondern in den Zahlen, die zählen.

---