SEO-Checkliste nach dem Launch: Triage-System statt Aufgabenablage

Kurzfassung: Die beste SEO-Checkliste nach dem Go-Live ist kürzer, als du erwartest. Ein Relaunch scheitert selten, weil jemand eine Meta Description vergessen hat. Er scheitert, weil Google die neuen URLs nicht crawlen, rendern, vertrauen oder mit den alten Autoritätssignalen verknüpfen kann. Prüfe zuerst Zugriff, Rendering, Redirects, Canonicals, Analytics und Sitemaps. Wenn das passt, brennt die Seite vermutlich nicht. Danach kannst du aufräumen.

Ich habe Kundensites über mindnow live gestellt, vadimkravcenko.com neu aufgebaut und baue jetzt seojuice.io mit statisch gerenderten öffentlichen Seiten plus App-Oberflächen, die nicht ranken müssen. Die Panik nach dem Go-Live lautet fast nie „wir haben ein alt-Attribut vergessen“. Sie lautet „die neue React-Route liefert nur eine leere Hülle“, „die alte URL-Map hat Lücken“ oder „Search Console meldet entdeckt, aber nicht indexiert, und niemand will zugeben, dass die Seiten dünn sind“.

Genau diesen Denkfehler müssen wir brechen. Eine SEO-Checkliste nach dem Go-Live ist ein Triage-System, kein Spreadsheet, in dem jede Zeile dasselbe Gewicht hat. Erst die Blutung stoppen – dann polieren.

Die SEO-Checkliste nach dem Go-Live ist ein Triage-System, kein Task-Dump

Standard-Checklisten glätten das Risiko. Eine fehlende Meta Description und eine robots.txt, die alles blockiert, gehören nicht in dieselbe Kategorie. Genauso wenig wie ein langsames Hero-Bild und eine kaputte 301-Map der alten Site.

Die erste Stunde ist der Beweis (und genau den Schritt übergehen die meisten Teams). Können Crawler die Seiten erreichen? Sieht Google die gewünschte URL, den Canonical, den Inhalt und den Statuscode? Haben alte URLs, interne Links, Analytics und Zitationen überlebt? Erst danach geht es an Verbesserungen.

Darum beginnt ein gutes technisches SEO-Audit nach dem Go-Live mit Fehlermodi, nicht mit Deko. Launches sind politisch. Ohne Ordnung wird jedes Meeting zur Show.

Was in den ersten 60 Minuten nach dem Go-Live zu prüfen ist

Nur weil „die Seite in Chrome lädt“, heißt das nicht, dass Google den Inhalt sieht. Chrome ist dein Browser. Googlebot ist ein Crawler mit Render-Steps, Crawl-Queues, blockierten Ressourcen und einem anderen Job.

Starte mit der produktiven robots.txt. Bestätige, dass die Bereiche, die ranken sollen, erlaubt sind. Prüfe dann Meta-Robots-Tags, x-robots-tag-Header, HTTP-Statuscodes und Canonicals. Live-Seiten müssen 200 liefern. Permanente Redirects 301. Entfernte Seiten 404 oder 410. Canonicals sind selbstreferenziell oder gezielt zusammengefasst.

Nutze anschließend die URL-Prüfung in der Google Search Console. Teste je eine URL pro indexierbarem Seitentyp: Startseite, Kategorie, Produkt, Artikel, Standort, programmatische Seite und jedes neue Template. Hole die Seite ab. Untersuche das gerenderte HTML. Suche nach Hauptinhalt, internen Links, Canonical, Title und strukturierten Daten.

„Das Hauptproblem bei CSR ist meist das Risiko, dass der Nutzer bei Übertragungsfehlern gar keinen Inhalt sieht. Das kann auch SEO-Auswirkungen haben.“

Diese Warnung von Martin Splitt, Developer Advocate bei Google, beschreibt das Launch-Problem auf Deutsch. Client-Side-Rendering ist nicht böse – es ist zum Go-Live fragil, weil ein fehlerhaftes Skript, ein Hydration-Bug, ein Route-Issue oder eine blockierte Ressource eine Seite in eine leere Hülle verwandeln kann.

• Crawle eine Stichprobe aller Templates, nicht nur die Startseite.
• Teste je eine URL pro indexierbarem Seitentyp.
• Nutze URL-Prüfung für Fetch und gerendertes HTML.
• Staging-noindex-Regeln dürfen nicht in Produktion landen.
• Kerninhalte müssen ohne Nutzer-Interaktion erscheinen.
• Navigationslinks sollten, wo möglich, crawlbare HTML-Links sein.

Bei viel JavaScript folgt ein zusätzlicher JavaScript-SEO-Check. View Source reicht nicht. Entscheidend ist der gerenderte DOM.

Warum Redirects mehr Aufmerksamkeit verdienen als sie bekommen

Wenn sich URLs ändern, ist eine Redirect-Map Pflicht. Sie ist die Brücke zwischen den erarbeiteten Signalen der alten Site und der neuen Struktur.

„Wenn sich URLs ändern und die alten nicht per 301 korrekt auf die neuen gemappt werden, verliert die Site massiv SEO-Power.“

Glenn Gabe, Gründer von G-Squared Interactive, wird deutlich, weil der Fehler häufig ist. Alte URLs leiten auf die Startseite. 302er statt 301er. Redirect-Ketten durch alte CMS-Pfade, Slash-Regeln, HTTP-zu-HTTPS und Sprachordner (meist weil niemand die Map besitzt). Query-String-URLs fallen weg, ohne Backlinks oder Traffic zu prüfen.

Crawle die alte URL-Liste nach dem Go-Live (die neue Site ist der leichte Teil). Dort verstecken sich Traffic-Verluste. Crawl nicht nur die neue Site und erkläre den Sieg.

• Alte URLs sollten auf die nächstgelegene neue Seite leiten.
• Permanente Umzüge nur mit 301.
• Redirect-Ketten verkürzen.
• Interne Links müssen auf die Ziel-URLs, nicht auf Redirects gehen.
• XML-Sitemaps dürfen keine Redirects oder nicht-kanonischen URLs enthalten.

Google folgt Redirects – Ziel ist es nicht, Googles Geduld zu testen. Halte die Wege kurz.

Sitemaps und Search Console: nützlich, aber kein Zauberstab

Die meisten Checklisten setzen „Sitemap einreichen“ weit oben, als würde das Indexing erzwingen. Google Search Central sagt, eine Sitemap sei „nur ein Hinweis“ und garantiere weder Download noch Crawling oder Nutzung.

Sitemaps sind trotzdem wertvoll – sie helfen bei der Entdeckung, decken Reporting-Probleme auf und geben Search Console eine saubere Oberfläche. Besonders wichtig sind sie bei neuen Sites, wenigen externen Links, vielen Seiten oder schwer auffindbaren URLs.

Ich habe einmal gesehen, wie eine Sitemap voller Redirects das eigentliche Problem verdeckte: Die neuen kanonischen Seiten waren kaum verlinkt.

• Reiche das korrekte XML-Sitemap-Index in der Search Console ein.
• Entferne Staging-, Alt-Domain-, Redirect-, blockierte und nicht-kanonische URLs.
• Dateien vor 50 MB unkomprimiert oder 50.000 URLs splitten.
• lastmod nur nutzen, wenn das CMS es korrekt setzt.
• Eingereichte vs. indexierte URLs nach Template vergleichen.

Sitemap einreichen ist Logistik. Indexierung wird verdient.

Ohne Messung kein Debugging des Launches

Alle sagen, das Tracking sei fertig. Dann bricht die Thank-You-Page, das Consent-Banner, der Checkout-Event oder die Cross-Domain-Verweisung.

Bevor du über Rankings streitest, beweise die Messung. GA4 muss auf jedem öffentlichen Template feuern. Search Console muss für die richtige Property verifiziert sein (Protokoll, Subdomain, Domain zählen). Bing Webmaster Tools gehört auf die Liste, wenn Bing, Copilot oder Enterprise-Suche wichtig sind.

• Rank-Tracking vor dem Go-Live exportieren.
• Organische Landingpages nach URL, Template, Land und Gerät sichern.
• Server- oder CDN-Logs bereit halten, falls Crawling einbricht.
• Launch-Annotationen in Analytics-Tools setzen.
• Conversion-Events nach Consent Mode und Tag Manager testen.

Das Team muss wissen, ob Traffic wegen Rankings, Indexierung, Messfehlern, Saisonalität oder kaputten Redirects schwankt. Ohne Baselines wird das Post-Launch-Meeting Rätselraten mit Charts.

Core Web Vitals nach dem Go-Live: jetzt messen, nicht auf CrUX warten

Der HTTP Archive Web Almanac 2025 zeigt, warum Performance am Launch-Tag zählt. HTTPS und Title-Tags sind Standard: HTTPS auf ~91 % der Desktop- und Mobile-Seiten, Title auf ~98 %. Core Web Vitals sind schwächer: Desktop-Passrate 56 %, Mobile 48 %.

Damit sind Core Web Vitals einer der häufigsten Launch-Stolpersteine – kein Randthema.

INP wurde am 12. März 2024 stabiler Core Web Vital und ersetzte FID. Schwellenwerte: ≤ 200 ms gut; 200–500 ms verbesserungswürdig; > 500 ms schlecht. Laut Almanac bestehen 77 % der mobilen Seiten INP, 97 % der Desktop-Seiten. Nur 53 % der Top-1000-Sites bestehen – ein Signal für große JS-Last.

CrUX nutzt ein 28-Tage-Fenster, neue Seiten haben daher anfangs keine Felddaten. Nutze Lighthouse, PageSpeed Insights, WebPageTest, RUM und Template-Tests, bis Felddaten reifen.

• Mobile zuerst testen.
• Das langsamste Template testen, nicht die schönste Seite.
• LCP bei Hero-Bildern und Server-Antwort beobachten.
• INP bei Menüs, Filtern, Akkordeons, Suche, Formularen, Konfiguratoren prüfen.
• CLS nach Fonts, Ads, Bannern, Embeds und Cookie-Hinweisen beobachten.

Content-Qualität und interne Links: „Entdeckt, derzeit nicht indexiert“ ist kein Button-Problem

Viele sehen „Entdeckt, derzeit nicht indexiert“ und reichen URLs erneut ein. Das hilft Google, eine Seite nochmal zu finden. Es macht sie nicht indexierungswürdig.

„In den meisten Fällen geht es jedoch um die Gesamtqualität der Website.“

Dieser Satz von John Mueller, Search Advocate bei Google, ist ein nützlicher Denkzettel. Die meisten Post-Launch-Checklisten behandeln Indexierung als Konfigurationsproblem. Mueller definiert sie als Qualitätsproblem.

Prüfe, ob wichtige Seiten aus crawlbarer Navigation, Hubs, Breadcrumbs oder Related-Blocks verlinkt sind. Suche Body-Links, die im Redesign verschwanden. Analysiere dünne Standort-, Kategorie-, Tag- oder programmatische Seiten, die sich vermehrt haben. Stelle sicher, dass einzigartiger Content nicht unter Tabs, Skripten oder generischem Hero-Text vergraben ist.

Hier zählt die Strategie interner Links. Interne Links sind nicht nur Crawl-Pfade. Sie sind redaktionelle Priorität. Wenn die Site nicht auf eine Seite verweist, signalisiert sie Suchmaschinen, dass die Seite nicht zentral ist.

Titel, Canonicals, Schema und Metadaten prüfen – aber nicht vergöttern

Metadaten sind wichtig. Sie gehören nur in die richtige Ebene.

Der Web Almanac 2025 fand Canonicals auf ~68 % der Desktop- und ~67 % der Mobile-Seiten. Titles sind fast universell. HTTPS sowieso. Das sind Pflicht-Checks, aber selten der Ort für Launch-Katastrophen.

Bei einem Relaunch gelangte Staging-Schema mit Fake-Review-Markup in die Produktion. Jeder View-Source-Check hätte das gesehen.

• Eindeutige Title-Tags auf indexierbaren Templates.
• Meta Descriptions für Seiten, bei denen CTR zählt.
• Pro indexierbare Seite genau ein Canonical.
• Open-Graph-Previews für geteilte Launch-Seiten prüfen.
• Strukturierte Daten für Produkte, Artikel, Breadcrumbs, Organisation, Local, FAQs, Reviews validieren.
• Hreflang testen, falls Sprach- oder Regionalvarianten existieren.
• Schema aus Staging, alten Brands oder falschen URLs entfernen.

Mach die Arbeit. Verwechsele nur nicht Metadaten-Vollständigkeit mit Launch-Sicherheit.

Launch-Check 2026: AI-Crawler-Regeln und Zitations-Kontinuität

AI-Crawler-Policy ist jetzt eine Launch-Entscheidung (2026 ist das nicht mehr optional). Der Web Almanac 2025 fand gptbot-Regeln in robots.txt auf 4,5 % der Desktop- und 4,2 % der Mobile-Seiten – +55 % YoY. claudebot fast verdoppelt auf 3,6 % bzw. 3,4 %.

Das heißt nicht, dass GPTBot-Freigabe Sichtbarkeit garantiert. Es heißt, robots.txt steuert vermehrt AI-Crawler-Zugriff, und das Launch-Team braucht eine dokumentierte Policy.

1. Vor dem Go-Live entscheiden, ob große AI-Crawler erlaubt oder geblockt werden.
2. Zitations-Kontinuität sichern, indem alte URLs mit Erwähnungen, Links und Forenreferenzen weitergeleitet werden.
3. Entitätssignale konsistent halten: Brand-Name, Autoren, Organization-Schema, About-, Kontakt-, Produktseiten und kanonische Quellseiten.

Kaputte URLs zerstören Zitationspfade, auf die Suche und Answer-Engines setzen. Die Seiten, die beweisen, wer du bist, müssen crawlbar bleiben.

Die 7-Tage-Überwachungsschleife nach dem Go-Live

Tag 0: Zugriff und Rendering. Tag 1: Redirects, Analytics, Sitemap-Berichte. Tag 2–7: Mustererkennung.

• Search-Console-Coverage und Indexierung nach Template prüfen.
• Serverfehler und Soft-404s checken.
• Alte URL-Liste erneut crawlen.
• Verschwundene organische Landingpages finden.
• Branded Queries und Startseiten-Index prüfen.
• Neue Seiten in entdeckt oder gecrawlt, aber nicht indexiert beobachten.
• Crawl-Spikes oder Drops in Logs prüfen.
• Conversion-Tracking erneut testen.
• Wichtige Keywords tracken, aber frühe Volatilität erwarten.

Geduld hilft – nicht jeder Dip ist ein Desaster. Aber jeder ungemessene Dip wird zur politischen Debatte.

Der 30-Tage-Review: Was zu verbessern ist, wenn das Feuer gelöscht ist

Nach Woche 1 nicht mehr nur nach Katastrophen suchen. Schwache Systeme verbessern.

• Core Web Vitals Feld-Daten prüfen, sobald verfügbar.
• Seiten mit Impressionen, aber schwacher CTR finden.
• Interne Links zu neuen strategischen Seiten ergänzen.
• Indexierung nach Template vergleichen.
• Umleitende interne Links bereinigen.
• Content prüfen, der nach Rewrites oder Merges Rankings verlor.
• Schema-Warnungen und Rich-Result-Eligibility fixen.
• AI-Crawler-Policy mit Legal und Brand abstimmen.
• Expertise-Signale, Autorenkontext und Supporting-Content stärken.

Hier zahlt sich ein sauberes SEO-Monitoring endlich aus. Nicht jedes Ergebnis sieht man in 48 Stunden. Aber man sieht, ob das System gesünder wird.

Copy-Paste-Checkliste für SEO nach dem Go-Live

Zugriff und Indexierbarkeit

• Produktive robots.txt erlaubt die gewünschten Bereiche.
• Keine Staging-noindex-Direktiven mehr vorhanden.
• Indexierbare Seiten liefern 200.
• Entfernte Seiten liefern 404 oder 410.
• Canonicals zeigen auf die Ziel-URLs.
• URL-Prüfung bestätigt Fetch & Render.

Rendering und Templates

• Hauptinhalt erscheint im gerenderten HTML.
• Navigationslinks sind crawlbar.
• Wichtige Links nicht hinter Interaktion versteckt.
• Keine JavaScript-Fehler blockieren Content.
• Jedes Haupt-Template auf Mobile getestet.

Redirects und URL-Kontinuität

• Alte URL-Liste nach dem Go-Live gecrawlt.
• Ein-Hop-301s für geänderte URLs gesetzt.
• Redirects führen zur Äquivalent-Seite, nicht zur Startseite.
• Interne Links zeigen auf Ziel-URLs.
• XML-Sitemap enthält keine Redirects.

Search Console und Sitemaps

• Korrekte Property verifiziert.
• Sitemap-Index eingereicht.
• Sitemap nur kanonische, indexierbare URLs.
• Eingereicht vs. indexiert nach Template überwacht.
• Manuelle Maßnahmen und Security-Issues geprüft.

Analytics und Tracking

• GA4 auf allen öffentlichen Templates feuert.
• Organische Landingpages erfasst.
• Conversions getestet.
• Launch-Annotation gesetzt.
• Baseline-Rankings & Traffic exportiert.

Performance

• LCP auf Schlüssel-Templates geprüft.
• INP auf interaktiven Elementen getestet.
• CLS nach Bannern, Fonts, Embeds beobachtet.
• Lab-Tools bis CrUX-Daten reifen.
• Mobile vor Desktop getestet.

Content und interne Links

• Prioritätsseiten über Hubs/Navi verlinkt.
• Wichtiger alter Content nicht ohne Ersatz gelöscht.
• Dünne programmatische Seiten geprüft.
• Titel & Überschriften passen zur Suchintention.
• Waisen-Seiten identifiziert.

Strukturierte Daten und Metadaten

• Titel auf indexierbaren Seiten eindeutig.
• Meta Descriptions für Schlüssel-Seiten geprüft.
• Breadcrumb-Schema validiert.
• Produkt-, Artikel-, Organisation-, Local- oder Review-Schema getestet.
• Hreflang getestet, falls zutreffend.

AI-Suche und Crawler-Policy

• AI-Crawler-Regeln in robots.txt dokumentiert.
• Alte zitierte URLs weitergeleitet.
• Brand- und Autoren-Entität konsistent.
• About-, Kontakt-, Quell-Seiten crawlbar.
• Wichtige Info-Seiten bei Migration erhalten.

Wenn du nur eine Stunde hast, prüfe Crawl-Zugriff, Rendering, Redirects, Canonicals, Analytics und Sitemap. Wenn das passt, brennt der Launch vermutlich nicht. Dann beginnt die eigentliche SEO-Arbeit.

FAQ

Wie schnell sollte ich eine SEO-Checkliste nach dem Go-Live ausführen?

Prüfe Zugriff, Rendering, Robots, Statuscode, Canonical, Analytics und Redirects in der ersten Stunde. Sitemap, Search Console und Crawls der alten URLs am ersten Tag. Indexierung, Logs, Rankings und Conversions in der ersten Woche beobachten.

Reicht Sitemap-Einreichung, um eine neue Site zu indexieren?

Nein. Google sagt, Sitemap-Einreichung ist „nur ein Hinweis“. Reiche sie ein, weil sie Discovery und Reporting hilft, besonders bei neuen oder großen Sites. Behandle sie nicht als Index-Button.

Was ist der größte SEO-Fehler nach dem Go-Live?

Die teuersten Fehler sind blockiertes Crawling, kaputtes Rendering, falsche Redirects, fehlerhafte Canonicals und fehlende Messung. Metadaten lassen sich leichter fixen, wenn die Site stabil ist.

Sollte ich alte URLs prüfen oder nur die neue Site?

Beides, aber crawle die alte URL-Liste nach dem Go-Live. Dort tauchen verlorene Equity, kaputte Backlinks, falsche Mappings und Startseiten-Redirects auf. Das ist Kernarbeit bei Site-Migrationen.

Wann sollten Core Web Vitals nach dem Go-Live geprüft werden?

Sofort mit Lab-Tools und RUM testen. CrUX-Felddaten brauchen ein 28-Tage-Fenster, neue Seiten benötigen also Zeit, bis stabile Felddaten vorliegen.

Brauchst du Hilfe, die wirklich relevanten Launch-Probleme zu finden?

SEOJuice hilft Teams, die Punkte zu erkennen, die Ergebnisse verändern: kaputte interne Links, schwache Page-Priorität, fehlender Kontext und SEO-Probleme, die nach dem Go-Live unter der Oberfläche lauern. Wenn deine Site gerade live gegangen ist, starte mit den Triage-Checks oben und nutze dann SEOJuice, um die Aufräumarbeiten voranzutreiben.