- Der Go-live-Check ist die technische SEO-Abnahme kurz vor und direkt nach dem Livegang. Er gilt für Relaunch, Migration, neue Templates und größere Releases.
- Die Prüfliste hat über 120 Punkte in 14 Bereichen, von der robots.txt bis zu den Logfiles. Je Punkt steht, woran du den Fehler erkennst, womit du prüfst und wann.
- Prüfe Staging gegen einen Referenz-Crawl der Live-Website und nach dem Deployment dieselben Punkte noch einmal live.
- Danach beobachtest du in festen Abständen, in der ersten Stunde, am ersten Tag und in den ersten Wochen.
Wann brauchst du einen SEO-Check vor dem Go-live?
Immer dann, wenn sich Templates, URLs oder die Auslieferung der Website ändern. Das betrifft einen Relaunch oder einen Wechsel des CMS ebenso wie ein neues Produkt-Template, ein Update des Frontend-Frameworks, einen neuen Hoster oder geänderte CDN-Regeln. Viele SEO-Fehler entstehen bei ganz normalen Releases. Ein Template setzt noindex, ein Canonical zeigt auf die Staging-Domain, oder die robots.txt der Testumgebung landet auf dem Live-Server. Funktionstests der Entwicklung finden solche Fehler selten, weil die Seite für Besucher einwandfrei aussieht.
Auf Staging kostet die Korrektur einen Ticket-Kommentar. Nach dem Go-live kostet sie Crawling, Indexierung und im schlechtesten Fall Klicks. Ein Fehler im Template trifft dabei alle Seiten dieses Typs auf einmal.
- Dieser Ratgeber beschreibt die technische Abnahme kurz vor und direkt nach dem Livegang, Prüfpunkt für Prüfpunkt.
- Die Relaunch-Checkliste beschreibt den ganzen Projektablauf eines Relaunchs, von der Pre-Analyse über das Redirect-Mapping bis zum Domainwechsel.
- Der Ratgeber Staging-Umgebung und SEO zeigt, wie du die Testumgebung selbst absicherst und testbar hältst.
- Wie du ein Redirect-Mapping im Detail testest, steht unter Weiterleitungen testen.
Wie bereitest du die Abnahme vor?
Eine Abnahme braucht einen Vergleich. Prüfst du Staging ohne Referenz, siehst du, was kaputt aussieht, und übersiehst, was fehlt. Leg deshalb vorher fest, wogegen du prüfst, was den Go-live blockiert und wer freigibt.
| Schritt | Was du festlegst |
|---|---|
| Referenz-Crawl | Ein Crawl der Live-Website kurz vor dem Go-live mit Title, Meta Description, H1, Canonical, Robots-Angaben, hreflang, strukturierten Daten und internen Links je URL. Er ist die Vorlage für jeden Vergleich. |
| URL-Stichprobe | Je Template drei bis fünf URLs und dazu die URLs mit den meisten Klicks aus der Search Console. Diese Liste prüfst du von Hand, den Rest im Crawl. |
| Abnahmekriterien | Welche Befunde den Go-live blockieren, etwa noindex auf indexierbaren Templates, eine robots.txt-Sperre oder fehlende Redirects für Top-URLs. Und welche als Ticket nach dem Go-live kommen dürfen. |
| Zuständigkeit | Wer aus SEO-Sicht freigibt und wer am Tag des Go-live deployen und zurückrollen kann. |
| Zeitpunkt | Plane den Go-live so, dass SEO und IT in den Tagen danach erreichbar sind und Korrekturen direkt ausrollen können. |
| Rollback-Plan | Was passiert, wenn live ein kritischer Fehler auffällt. Zurückrollen, Hotfix oder beides, und wer entscheidet. |
| Zugänge | Zugang des Crawlers zu Staging per HTTP-Authentifizierung, IP-Freigabe oder Cookie und Zugriff auf die Logfiles der neuen Umgebung. |
Wie crawlst du Staging für die Abnahme?
Für die Abnahme reicht die Stichprobe nicht. Ein Crawl der Testumgebung zeigt, ob alle Seitentypen erreichbar sind und wo sich etwas gegenüber der Live-Website verändert hat.
- Zugang einrichten. Der Crawler meldet sich per HTTP-Authentifizierung an, nutzt ein Zugangs-Cookie oder kommt über eine freigegebene IP-Adresse.
- Mit Smartphone-Kennung crawlen. Google crawlt die meisten Seiten mit dem Smartphone-Crawler und indexiert überwiegend die mobile Version.
- JavaScript rendern. Sonst fehlen Inhalte und Links, die erst im Browser entstehen.
- Regeln festlegen. Ist die Staging-robots.txt noch nicht die echte, stellst du den Crawler so ein, dass er sie ignoriert. noindex-Seiten crawlt er trotzdem und meldet sie, statt sie zu überspringen.
- Mit dem Referenz-Crawl vergleichen. Fehlende Seitentypen, neue noindex, geänderte Titles und verschwundene Links fallen so auf.
HTTP-Authentifizierung schützt die Testumgebung zuverlässig. Eine robots.txt mit Disallow: / oder noindex auf allen Seiten verhindert dagegen keinen Zugriff und kann beim Deployment mit live gehen. Die Details stehen im Ratgeber Staging-Umgebung und SEO.
Die Prüfliste nach Bereichen
Die folgenden 14 Bereiche enthalten zusammen über 120 Prüfpunkte. Jede Tabelle nennt den Prüfpunkt, woran du den Fehler erkennst, das Werkzeug und den Zeitpunkt. „Staging“ heißt vor dem Go-live, „Live“ direkt danach und „beides“ zweimal. Die Grundlage jedes Bereichs steht im Text darüber, die Links findest du unter Quellen.
Crawlbarkeit und robots.txt
Grundlage ist die robots.txt-Spezifikation von Google. Eine robots.txt gilt nur für den Host, das Protokoll und den Port, unter dem sie liegt. Google speichert die Datei in der Regel bis zu 24 Stunden zwischen. Eine versehentliche Sperre wirkt deshalb auch nach einer schnellen Korrektur noch nach. Der häufigste Fehler ist die Datei der Testumgebung auf dem Live-Server. Regeln für KI-Bots erklärt der Ratgeber KI-Crawler.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Richtige Datei live | Die Live-robots.txt enthält Disallow: / oder Regeln aus der Testumgebung | Browser, curl, robots.txt Tester | Live |
| Keine neuen Sperren | Wichtige Verzeichnisse, Seitentypen oder Parameter sind gegenüber der alten Datei neu gesperrt | Vergleich alte gegen neue Datei | beides |
| Ressourcen erlaubt | CSS, JavaScript, Bilder oder API-Pfade, die zum Rendern nötig sind, liegen unter Disallow | robots.txt-Bericht der Search Console, Crawler mit Rendering | beides |
| Statuscode 200 | Die Datei sendet 5xx. Google stoppt dann in den ersten 12 Stunden das Crawling der Website. Bei 4xx außer 429 behandelt Google die Website so, als gäbe es keine robots.txt | curl -I | Live |
| Weiterleitung der Datei | Die robots.txt leitet über mehrere Schritte weiter. Google folgt mindestens fünf und wertet sie danach wie einen 404 | curl -sIL | Live |
| Dateigröße | Die Datei ist größer als 500 KiB. Google ignoriert alles danach | curl, Dateigröße | beides |
| Alle Hosts | Neue Subdomains, Sprach-Hosts oder ein CDN-Host haben keine eigene oder die falsche robots.txt | curl je Host | Live |
| Sitemap-Angabe | Die Sitemap-Zeile fehlt, ist relativ oder zeigt auf die Staging-Domain | Browser | beides |
| Regeln für KI-Bots | Regeln für GPTBot, OAI-SearchBot, ClaudeBot oder das Token Google-Extended fehlen oder haben sich ungewollt geändert | Vergleich alte gegen neue Datei | beides |
| Bot-Schutz und Firewall | Neue Regeln in WAF, CDN oder Bot-Schutz senden Googlebot 403, 429 oder eine Captcha-Seite | Logfiles, Crawling-Statistiken der Search Console | Live |
Indexierungssignale mit noindex, Canonical und X-Robots-Tag
Grundlage sind Googles Dokumentationen zu noindex und zur Kanonisierung. Ein noindex wirkt nur, wenn Google die Seite crawlen darf. Kombinierst du es mit einer robots.txt-Sperre, sieht Google das noindex nie. Das Canonical akzeptiert Google nur im <head> und empfiehlt dafür absolute URLs. Mehr dazu im Ratgeber Canonical Tag.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Kein neues noindex | Indexierbare Templates tragen noindex im Meta-Robots-Tag | Crawler, Vergleich mit Referenz-Crawl | beides |
| X-Robots-Tag im Header | Der HTTP-Header enthält X-Robots-Tag: noindex, oft aus einer Serverregel der Entwicklung, auch bei PDFs | curl -I | beides |
| Gewollte noindex bleiben | Interne Suche, Filterseiten oder Login-Bereiche sind plötzlich indexierbar | Crawler, Vergleich mit Referenz-Crawl | beides |
| noindex nicht gesperrt | Seiten mit noindex liegen zugleich unter Disallow | Crawler mit robots.txt-Abgleich | beides |
| Gerendert wie im Quelltext | JavaScript ändert die Robots-Angaben nach dem Laden, etwa von index auf noindex | Crawler mit Rendering, URL-Prüfung der Search Console | beides |
| Passwortschutz entfernt | Live-URLs senden 401 oder 403 | curl -I, HTTP Status Code Checker | Live |
| Canonical vorhanden | Indexierbare Seiten haben kein oder ein leeres Canonical | Crawler | beides |
| Canonical absolut und live | Das Canonical ist relativ, enthält die Staging-Domain, http statt https oder einen anderen Host | Crawler | beides |
| Canonical-Ziel sauber | Das Ziel leitet weiter, sendet 404, trägt noindex oder ist pauschal die Startseite | Crawler | beides |
| Ein Canonical je Seite | Das HTML enthält mehrere rel="canonical", oder HTML und Link-Header nennen verschiedene URLs | Crawler, curl -I | beides |
| Canonical im head | Das Canonical steht im <body>, etwa weil ein Skript es dort einfügt | Quelltext, gerendertes HTML | beides |
| Parameter und Paginierung | Filter-, Sortier- und Seiten-URLs verweisen anders als vorher, oder alle paginierten Seiten zeigen auf Seite 1 | Crawler, Vergleich mit Referenz-Crawl | beides |
Statuscodes und Weiterleitungen
Grundlage sind Googles Dokumentationen zu HTTP-Statuscodes und zum Website-Umzug. Google indexiert keine URLs mit 4xx-Status und entfernt bereits indexierte. Bei anhaltenden 5xx-Fehlern fallen URLs nach einiger Zeit ebenfalls heraus. Googles Crawler folgen standardmäßig bis zu zehn Weiterleitungen hintereinander. Für den Umzug rät Google trotzdem, Ketten zu vermeiden und alte URLs direkt auf ihr Ziel zu leiten.
Wie du ein ganzes Redirect-Mapping testest, steht im Ratgeber Weiterleitungen testen, und den Unterschied der Redirect-Typen erklärt 301- und 302-Weiterleitung.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Wichtige URLs senden 200 | Die URLs mit den meisten Klicks senden 3xx, 4xx oder 5xx | Crawler mit URL-Liste, HTTP Status Code Checker | beides |
| Unbekannte URLs senden 404 | Eine ausgedachte URL wie /gibt-es-nicht-123/ antwortet mit 200 oder leitet auf die Startseite | curl -I | beides |
| Kein Soft 404 | Leere Kategorien, ausverkaufte Produkte oder Fehlermeldungen kommen mit Status 200 | Crawler (Wortanzahl, Title), Bericht Seitenindexierung | beides |
| Gelöschte Inhalte | Seiten ohne Nachfolger leiten auf die Startseite, statt 404 oder 410 zu senden | Crawler mit alter URL-Liste | beides |
| Redirect-Mapping | Alte URLs aus dem Mapping landen auf 404, auf einem falschen Ziel oder auf der Startseite | Crawler mit alter URL-Liste | beides |
| Permanente Redirects | Redirects kommen als 302, 307, per JavaScript oder Meta-Refresh statt als 301 oder 308 | curl -sIL, Redirect Checker | beides |
| Keine Ketten | Eine alte URL braucht mehr als einen Schritt bis zum Ziel | Crawler, Redirect Checker | beides |
| Keine Schleifen | Zwei Regeln leiten im Kreis, oft zwischen der Variante mit und ohne Schrägstrich am Ende | Crawler | beides |
| Ziel ist indexierbar | Das Redirect-Ziel sendet 200, trägt aber noindex oder ein fremdes Canonical | Crawler | beides |
| Host-Varianten | http, https, mit und ohne www, Schrägstrich am Ende und Großschreibung brauchen mehrere Schritte oder liefern doppelte Inhalte | curl -sIL je Variante | Live |
| Parameter bleiben | UTM- oder Kampagnen-Parameter gehen beim Redirect verloren, obwohl sie gebraucht werden | curl -sIL | beides |
| Dateien und Medien | Alte Bild-, PDF- und Sitemap-URLs senden 404 | Crawler mit alter URL-Liste | Live |
| Wartung mit 503 | Eine Wartungsseite sendet 200, oder 503 bleibt über Tage stehen | curl -I | Live |
| Last und Serverfehler | Unter Last oder nach dem Leeren des Caches steigen 5xx-Fehler und Antwortzeit | Crawling-Statistiken, Logfiles | Live |
| Keine Weiterleitung nach Standort | Besucher werden nach IP-Adresse oder Browsersprache automatisch umgeleitet. Googlebot crawlt standardmäßig von US-IP-Adressen und sendet keinen Accept-Language-Header, sieht dann also nur eine Version | curl mit und ohne Accept-Language, Logfiles | beides |
Einzelne URLs prüfst du ohne Tool im Terminal. Auf Staging hängst du dafür -u benutzer:passwort an den Befehl an.
Interne Links
Grundlage ist Googles Dokumentation zu crawlbaren Links. Google folgt nur Links in <a>-Elementen mit href-Attribut. Über interne Links findet Google neue Seiten und versteht, wie sie zusammenhängen. Viele Punkte prüfst du im Vergleich mit dem Referenz-Crawl, weil ein fehlender Link in einem einzelnen Crawl nicht auffällt.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Keine Staging-Links | Links, Bilder oder Skripte zeigen auf die Staging-Domain oder auf absolute DEV-URLs | Crawler, Suche im Quelltext | beides |
| Keine Links auf 404 | Navigation, Footer oder Fließtext verlinken auf Seiten mit 404 | Crawler, Link Checker | beides |
| Keine Links auf Redirects | Interne Links zeigen auf alte URLs und laufen über Weiterleitungen | Crawler | Live |
| Crawlbare Links | Navigation oder Filter nutzen onclick, <span> oder Buttons ohne href | Crawler mit und ohne Rendering, Quelltext | beides |
| Navigation im HTML | Das Menü entsteht erst nach einem Klick oder fehlt in der mobilen Ansicht | Crawler mit Smartphone-Kennung und Rendering | beides |
| Breadcrumbs | Die Brotkrumen-Navigation fehlt, und übergeordnete Seiten verlieren die Links aller Unterseiten | Crawler, Vergleich mit Referenz-Crawl | beides |
| Anzahl interner Links | Wichtige Kategorien bekommen deutlich weniger interne Links als vorher | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Klicktiefe | Wichtige Seiten sind von der Startseite aus mehr Klicks entfernt als vorher | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Ankertexte | Neue Labels in Navigation oder Teasern ändern die Ankertexte auf vielen Seiten | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Kein internes nofollow | Interne Links tragen neu rel="nofollow" | Crawler | beides |
| Facetten und Paginierung | Filter erzeugen unzählige crawlbare Kombinationen, oder Seite 2 und folgende sind nicht mehr verlinkt | Crawler | Staging |
| Keine verwaisten Seiten | URLs aus der Sitemap bekommen keinen internen Link mehr | Crawler mit Sitemap-Abgleich | beides |
XML-Sitemaps
Grundlage ist Googles Anleitung zum Erstellen von Sitemaps. Eine Datei darf höchstens 50.000 URLs oder 50 MB unkomprimiert enthalten. Größere Websites teilen die Sitemap auf und fassen die Dateien in einer Index-Sitemap zusammen. Google nutzt lastmod nur, wenn das Datum durchgehend stimmt, und ignoriert priority und changefreq. Mehr im Ratgeber XML-Sitemap.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Erreichbar | Die Sitemap aus der robots.txt sendet 404 oder 5xx oder leitet weiter | curl -I, Sitemap Checker | Live |
| Live-Domain | URLs in der Sitemap enthalten die Staging-Domain, http oder einen falschen Host | Crawler im Listenmodus, Suche in der Datei | beides |
| Nur saubere URLs | Die Sitemap enthält Redirects, 404, noindex-Seiten oder nicht kanonische URLs | Crawler im Listenmodus, Sitemap Checker | beides |
| Limits | Eine Datei überschreitet 50.000 URLs oder 50 MB, oder die Index-Sitemap verweist auf fehlende Dateien | Dateigröße, URLs zählen | beides |
| Vollständig | Seitentypen fehlen, oder die Zahl der URLs je Seitentyp weicht stark vom Referenz-Crawl ab | Vergleich Sitemap gegen Crawl | beides |
| lastmod stimmt | Alle URLs tragen das Datum des Releases statt der letzten echten Änderung | Datei prüfen | beides |
| Gültiges XML | Sonderzeichen sind nicht maskiert, der Namespace fehlt oder die Datei ist nicht UTF-8-codiert | Sitemaps-Bericht der Search Console | Live |
| Zusatz-Sitemaps | Bild-, Video- oder News-Sitemaps des alten Systems fehlen | Vergleich mit alter robots.txt und Search Console | Live |
| hreflang in der Sitemap | Sprachverweise in der Sitemap widersprechen denen im HTML | Crawler | beides |
| Eingereicht | Die neue Sitemap ist nicht eingereicht, oder ihr Status zeigt Fehler | Search Console, Bing Webmaster Tools | Live |
hreflang
Grundlage ist Googles Dokumentation zu lokalisierten Versionen. Jede Sprachversion nennt sich selbst und alle anderen, und die Gegenseite muss zurückverweisen. Fehlt der Rückverweis, ignoriert Google die Angabe. Mehr in den Ratgebern hreflang und hreflang und Canonical.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Selbstverweis | Eine Sprachversion nennt alle anderen, aber nicht sich selbst | Crawler, Hreflang Checker | beides |
| Rückverweise | Version A verweist auf B, B aber nicht auf A | Crawler mit hreflang-Auswertung | beides |
| Gültige Codes | Sprach- oder Ländercodes sind falsch, etwa en-UK statt en-GB | Hreflang Checker | beides |
| Absolute Live-URLs | hreflang-URLs sind relativ oder zeigen auf die Staging-Domain | Crawler | beides |
| Ziele indexierbar | hreflang-Ziele leiten weiter, senden 404, tragen noindex oder ein anderes Canonical | Crawler | beides |
| x-default | Die Länderauswahl oder Standardversion ist nicht als x-default angegeben | Quelltext | beides |
| Eine Methode | hreflang steht in HTML, Header und Sitemap mit unterschiedlichen Angaben | Crawler, curl -I | beides |
| Im head und gerendert | hreflang steht im <body> oder fehlt im gerenderten HTML | Crawler mit Rendering | beides |
| Sprachumschalter | Der Umschalter verlinkt auf die Startseite der anderen Sprache statt auf das Gegenstück | Browser, Crawler | Staging |
Rendering und JavaScript
Grundlage sind Googles Dokumentationen zu JavaScript-SEO, zur Mobile-First-Indexierung und zum Lazy Loading. Google indexiert überwiegend die mobile Version einer Seite und interagiert beim Rendern nicht mit ihr. Von einer HTML-Datei liest Googlebot die ersten 2 MB, unkomprimiert gerechnet. Wie stark sich Quelltext und gerendertes HTML unterscheiden können, zeigt die JavaScript-Crawling-Studie.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Hauptinhalt gerendert | Text, Produktdaten oder Bewertungen fehlen im gerenderten HTML | Crawler mit Rendering, URL-Prüfung mit Live-Test | beides |
| Links gerendert | Links aus Navigation oder Listen entstehen erst nach einer Interaktion | Crawler mit Rendering | beides |
| SEO-Angaben stabil | Title, Canonical, Robots-Angaben oder hreflang unterscheiden sich zwischen Quelltext und gerendertem HTML | Crawler mit beiden Ansichten | beides |
| Ressourcen erreichbar | JavaScript-, CSS- oder API-Dateien senden 4xx oder 5xx oder sind per robots.txt gesperrt | URL-Prüfung (Seitenressourcen), Browser-Entwicklertools | beides |
| Nachladen ohne Interaktion | Inhalte erscheinen erst nach Scrollen oder Klick | Crawler mit Rendering | beides |
| Fehlerstatus in Single-Page-Apps | Unbekannte URLs zeigen eine Fehlermeldung mit Status 200 | curl -I, URL-Prüfung | beides |
| Keine Hash-URLs | Inhalte liegen hinter #-Fragmenten, die Google nicht als eigene URLs crawlt | Crawler | Staging |
| HTML-Größe | Das HTML ist größer als 2 MB, etwa durch eingebettete Daten oder Inline-SVG | Browser-Entwicklertools, Crawler | Staging |
| Mobil wie Desktop | Die mobile Version zeigt weniger Inhalt, weniger Links, weniger strukturierte Daten oder andere Meta-Angaben | Crawler mit Smartphone- und Desktop-Kennung | beides |
| Banner und Overlays | Ein Consent-Banner oder Overlay überdeckt den Inhalt oder lädt ihn erst nach der Einwilligung | Crawler mit Rendering und Screenshot | beides |
Strukturierte Daten
Grundlage sind Googles allgemeine Richtlinien für strukturierte Daten. Das Markup muss den sichtbaren Inhalt der Seite beschreiben. Verstößt es gegen die Richtlinien, kann die Seite ihre Rich-Suchergebnisse verlieren. Wie KI-Systeme mit Markup umgehen, steht im Ratgeber Schema Markup und KI.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Markup vorhanden | Ein Template hat sein Markup verloren, etwa Product, BreadcrumbList oder Organization | Crawler mit Extraktion, Vergleich mit Referenz-Crawl | beides |
| Markup gültig | Pflichtfelder fehlen, oder Werte haben das falsche Format | Test für Rich-Suchergebnisse, Schema Markup Validator | beides |
| Passt zum Inhalt | Preis, Verfügbarkeit oder Bewertungen im Markup weichen von der sichtbaren Seite ab | Stichprobe im Browser | beides |
| Live-URLs im Markup | URLs in Feldern wie url, image oder item enthalten die Staging-Domain | Suche im Quelltext | beides |
| Kein doppeltes Markup | Plugin und Template geben dasselbe Markup zweimal mit unterschiedlichen Werten aus | Test für Rich-Suchergebnisse | beides |
| Berichte nach dem Go-live | Die Berichte zu Rich-Suchergebnissen zeigen neue Fehler oder weniger gültige Elemente | Search Console | Live |
Title, Meta Description und Überschriften
Grundlage ist Googles Dokumentation zu Titellinks. Google bildet den Titel im Suchergebnis aus dem Title-Element und weiteren Angaben der Seite und empfiehlt eindeutige, beschreibende Titles. Vergleiche je URL mit dem Referenz-Crawl, damit Optimierungen aus früherer SEO-Arbeit den Go-live überstehen.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Title übernommen | Titles fehlen, sind leer oder auf den Standard des neuen Systems zurückgefallen | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Keine Platzhalter | Titles oder Überschriften zeigen Template-Variablen wie %product_name% oder „Default Title“ | Crawler, Suche nach Mustern | beides |
| Eindeutige Titles | Viele Seiten teilen sich denselben Title, etwa Filter- oder Paginierungsseiten | Crawler | Staging |
| Meta Description | Beschreibungen fehlen oder sind auf allen Seiten gleich | Crawler | Staging |
| Eine H1 mit Thema | Die H1 fehlt, ist doppelt oder enthält das Keyword der Seite nicht mehr | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Inhalte vollständig | Kategorietexte, Produktbeschreibungen oder FAQ fehlen nach der Datenmigration | Crawler (Wortanzahl), Vergleich mit Referenz-Crawl | Staging |
| Zeichencodierung | Umlaute und Sonderzeichen erscheinen als Zeichensalat in Title, Description oder Text | Browser, Crawler | beides |
| Vorschau für soziale Netzwerke | Open-Graph-Angaben fehlen oder zeigen auf Bilder der Staging-Domain | Quelltext | beides |
Bilder und Medien
Grundlage sind Googles Best Practices für Bilder. Google indexiert keine CSS-Hintergrundbilder und findet Bilder über das src-Attribut des <img>-Elements. Der Alt-Text hilft Google, ein Bild zu verstehen. Außerdem rät Google, ein Bild immer unter derselben URL einzubinden.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Bilder als img | Wichtige Bilder liegen nur noch als CSS-Hintergrund vor | Crawler, Quelltext | Staging |
| Alt-Texte | Alt-Texte aus dem alten System fehlen. Bei verlinkten Bildern dient der Alt-Text auch als Ankertext | Crawler, Vergleich mit Referenz-Crawl | Staging |
| Stabile Bild-URLs | Bild-URLs haben sich geändert, und die alten leiten nicht weiter | Crawler mit alter Bild-URL-Liste | beides |
| Bilder nicht gesperrt | Das Bildverzeichnis oder der CDN-Host liegen unter Disallow | robots.txt des Bild-Hosts, robots.txt Tester | Live |
| Lazy Loading | Bilder haben kein src, nur ein data-src, das erst beim Scrollen gesetzt wird | Crawler mit Rendering | beides |
| Abmessungen | Bilder ohne width und height verschieben das Layout beim Laden | Lighthouse | Staging |
| Videos | Videoseiten, Vorschaubilder oder die Video-Sitemap fehlen | Crawler, Videobericht der Search Console | beides |
| PDFs | PDFs mit Klicks oder Links fehlen, oder ein X-Robots-Tag sperrt sie ungewollt | Crawler mit alter URL-Liste, curl -I | beides |
Performance und Core Web Vitals
Grundlage ist Googles Dokumentation zu Core Web Vitals. Als gut gelten ein LCP von höchstens 2,5 Sekunden, ein INP unter 200 Millisekunden und ein CLS unter 0,1. Vor dem Go-live misst du im Labor, danach zählen die Felddaten echter Nutzer. PageSpeed Insights und der Chrome UX Report fassen diese Felddaten über die letzten 28 Tage zusammen. Änderungen zeigen sich dort deshalb erst nach und nach. Mehr im Ratgeber Core Web Vitals.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Laborwerte je Template | Wichtige Templates sind auf Staging deutlich langsamer als auf der alten Website | Lighthouse, PageSpeed Insights | Staging |
| LCP-Element | Das größte Bild im sichtbaren Bereich hat loading="lazy" oder wird spät angefragt | Lighthouse, Browser-Entwicklertools | Staging |
| Serverantwort | Die Time to First Byte steigt, vor allem bei Seiten ohne Cache | Browser-Entwicklertools, Crawling-Statistiken | beides |
| Caching und CDN | Cache-Header fehlen, oder das CDN liefert HTML ungecacht aus | curl -I | Live |
| Skripte von Drittanbietern | Neue Tags, Chat-Widgets oder A/B-Test-Skripte blockieren das Rendern | Lighthouse, Browser-Entwicklertools | beides |
| Felddaten | Die Felddaten verschlechtern sich in den Wochen nach dem Go-live | Core-Web-Vitals-Bericht der Search Console, PageSpeed Insights | Live |
Tracking und Consent
Ohne saubere Daten kannst du den Go-live nicht bewerten. Prüfe das Tracking deshalb in derselben Abnahme. Grundlage für die Einwilligung ist Googles Dokumentation zum Consent Mode. Welche Tags vor einer Einwilligung laden dürfen, klärst du mit den Verantwortlichen für Datenschutz.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Tag auf allen Templates | Auf einzelnen Templates fehlt das Google-Tag oder der Container des Tag Managers | Tag Assistant, Crawler mit Extraktion | beides |
| Daten kommen an | Seitenaufrufe und Conversions erscheinen nicht in der Echtzeit-Ansicht oder in DebugView | GA4 DebugView, Vorschau im Tag Manager | beides |
| Consent | Tags laden vor der Einwilligung oder nach der Einwilligung gar nicht mehr. Die Signale des Consent Mode fehlen | Tag Assistant, Browser-Entwicklertools | beides |
| Kein doppeltes Tracking | Altes und neues Tag laufen parallel und zählen Aufrufe doppelt | Tag Assistant, Browser-Entwicklertools | Live |
| Kampagnenparameter | UTM- oder gclid-Parameter gehen bei Redirects verloren | curl -sIL, GA4 | Live |
| Release dokumentiert | Datum und Uhrzeit des Go-live fehlen in Analytics, Dashboards und Tickets | Anmerkungen, Changelog | Live |
Search Console
Grundlage sind die Hilfeseiten der Search Console. Die Bestätigung als Inhaber gilt nur, solange Google das Token findet. Liegt es als HTML-Datei oder Meta-Tag im alten Template und fehlt im neuen, verlierst du nach einer Übergangsfrist den Zugriff auf die Property. Eine Domain-Property bestätigst du per DNS-Eintrag, sie hängt also nicht vom Template ab.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Bestätigung bleibt | Das Token als HTML-Datei oder Meta-Tag fehlt im neuen Template | Einstellungen der Search Console, Quelltext | beides |
| Neue Properties vorab | Neue Domains, Subdomains oder Sprachverzeichnisse sind vor dem Go-live nicht bestätigt | Search Console, Bing Webmaster Tools | Staging |
| Zugriffe geklärt | Agentur, IT oder Redaktion haben keinen Zugriff auf die neue Property | Nutzer und Berechtigungen | Staging |
| Sitemaps eingereicht | Neue Sitemaps fehlen, oder alte zeigen Fehler | Sitemaps-Bericht | Live |
| URL-Prüfung je Template | Der Live-Test zeigt noindex, ein anderes Canonical, blockierte Ressourcen oder fehlenden Inhalt | URL-Prüfung mit Live-Test | Live |
| Adressänderung | Bei einem Domain- oder Subdomain-Wechsel ist der Umzug nicht gemeldet. Bei einem Relaunch auf derselben Domain brauchst du das Tool nicht | Tool zur Adressänderung, Site Move Tool bei Bing | Live |
| Berichte beobachten | Die Seitenindexierung zeigt neue Ausschlüsse, die Crawling-Statistiken mehr Fehler oder höhere Antwortzeiten | Seitenindexierung, Crawling-Statistiken | Live |
Logfiles
Logfiles zeigen, was Googlebot wirklich anfragt, auch URLs, die in keinem Crawl auftauchen. Die Kennung Googlebot wird oft gefälscht. Google empfiehlt deshalb, Zugriffe per Reverse-DNS-Lookup oder über die veröffentlichten IP-Bereiche zu prüfen. Mehr im Ratgeber Logfile-Analyse.
| Prüfpunkt | Woran du den Fehler erkennst | Werkzeug | Wann |
|---|---|---|---|
| Logzugriff | Mit neuem Hoster oder CDN fehlen die Logs oder die Zeilen der Bots | Hosting, CDN-Logs | Staging |
| Googlebot geprüft | Gefälschte Googlebot-Zugriffe verzerren die Auswertung | Reverse-DNS-Lookup, IP-Bereiche von Google | Live |
| Statuscodes für Googlebot | Der Anteil von 3xx, 4xx oder 5xx bei Googlebot-Anfragen steigt nach dem Go-live | Logfile-Analyse | Live |
| Gecrawlte URLs | Googlebot fragt vor allem alte URLs, Parameter oder Ressourcen an und kaum neue Seiten | Logfile-Analyse | Live |
| Crawl-Aktivität | Googlebot fragt deutlich weniger Seiten an als vor dem Go-live | Logfile-Analyse, Crawling-Statistiken | Live |
| KI-Bots | Zugriffe von KI-Bots brechen weg, oft wegen neuer Regeln im Bot-Schutz | Logfile-Analyse | Live |
Monitoring nach dem Livegang
Auch ein sauberer Staging-Stand kann live anders aussehen, etwa durch Caches, CDN-Regeln oder Umgebungsvariablen. Prüfe deshalb direkt nach dem Deployment alle Punkte, die in der Prüfliste mit „Live“ oder „beides“ markiert sind. Danach geht es in festen Abständen weiter. Bei mittelgroßen Websites dauert es laut Google einige Wochen oder länger, bis die neuen URLs in der Suche die alten ersetzen. Bei großen Websites dauert es noch länger.
| Zeitraum | Was du prüfst | Werkzeug |
|---|---|---|
| Erste Stunde | robots.txt, Statuscodes, Robots-Angaben und Canonicals der URL-Stichprobe, Redirects der Top-URLs, Tracking in der Echtzeit-Ansicht | curl, Crawler mit URL-Liste, GA4 |
| Erster Tag | Crawl der ganzen Website und der kompletten alten URL-Liste, Sitemaps einreichen, URL-Prüfung je Template, 5xx-Fehler und Antwortzeiten in den Logs | Crawler, Search Console, Logfiles |
| Erste Woche | Seitenindexierung je Sitemap, Crawling-Statistiken, neue 404 aus Logs und Search Console, interne Links auf Redirects, Berichte zu Rich-Suchergebnissen | Search Console, Logfiles, Crawler |
| Woche 2 bis 6 | Klicks und Impressionen je Seitentyp im Vergleich zum Zeitraum vor dem Go-live, Rankings der wichtigsten Keywords, Zahl der organischen Landingpages | Search Console, Rank Tracking |
| Ab Monat 2 | Felddaten der Core Web Vitals, Redirects mit Zugriffen in Logs oder externen Links, alte Sitemap entfernen, sobald die alten URLs aus dem Index sind | Search Console, PageSpeed Insights, Logfiles |
Die Abnahme ist eine Momentaufnahme. Jedes weitere Release kann dieselben Fehler wieder einbauen. Prüfe die kritischen Punkte deshalb laufend, allen voran robots.txt, Robots-Angaben, Canonicals und die Statuscodes der wichtigsten Seiten.
Häufige Fehler
- Die Staging-robots.txt mit
Disallow: /geht mit live. - Ein
X-Robots-Tag: noindexaus der Serverkonfiguration der Entwicklung bleibt stehen. - Canonicals, hreflang oder Sitemap-URLs zeigen auf die Staging-Domain.
- Unbekannte URLs senden 200, und fehlende Redirects fallen deshalb nicht auf.
- Die Bestätigung der Search Console steckte im alten Template und ist weg.
- Neue Regeln im Bot-Schutz sperren Googlebot aus.
- JavaScript setzt Title oder Canonical nach dem Laden um.
- Geprüft wird nur Staging und nicht noch einmal live.
Häufige Fragen
Wann machst du den SEO-Check vor dem Go-live?
Zweimal. Die Abnahme auf Staging läuft, sobald der Stand feststeht, der live gehen soll, mit genug Zeit für Korrekturen. Direkt nach dem Deployment prüfst du dieselben Punkte auf der Live-Website.
Wie viele URLs musst du prüfen?
Von Hand eine Stichprobe mit drei bis fünf URLs je Template und den URLs mit den meisten Klicks. Alles Weitere prüft ein Crawl der ganzen Staging-Umgebung im Vergleich mit einem Crawl der Live-Website.
Was blockiert den Go-live?
Alles, was viele Seiten auf einmal aus dem Index nehmen oder Klicks kosten kann. Dazu gehören eine robots.txt-Sperre, noindex auf indexierbaren Templates, fehlende Redirects für Top-URLs und Canonicals auf die Staging-Domain. Kleinere Befunde wie einzelne fehlende Alt-Texte können als Ticket nach dem Go-live kommen.
Brauchst du nach einem Relaunch das Tool zur Adressänderung?
Nur, wenn sich die Domain oder Subdomain ändert. Bei einem Relaunch auf derselben Domain und beim Wechsel von HTTP auf HTTPS meldest du nichts. Details stehen in der Relaunch-Checkliste.
Was tust du, wenn nach dem Go-live ein noindex auffällt?
Entfernen, ausrollen und die betroffenen URLs neu prüfen. Wichtige URLs beantragst du über die URL-Prüfung der Search Console zur Indexierung, für viele URLs hilft eine aktuelle Sitemap. Danach zeigt der Bericht Seitenindexierung, ob die Seiten zurückkommen.
Wie entferne ich bereits indexierte Staging-URLs?
Lass die Seiten zunächst crawlbar und setze noindex, oder lass sie 404 oder 410 senden. Danach kommt der Passwortschutz. Für eine schnelle, vorübergehende Ausblendung gibt es in der Search Console das Tool zum Entfernen von URLs. Mehr dazu im Ratgeber Staging-Umgebung und SEO.
Quellen
Abgerufen am 03.11.2026. Ist eine Angabe veraltet oder fehlt etwas, schreib uns.
- Google, robots.txt-Spezifikation: https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec · Stand 31.08.2026
- Google, Einführung in robots.txt: https://developers.google.com/search/docs/crawling-indexing/robots/intro · Stand 10.12.2025
- Google, Indexierung mit noindex blockieren: https://developers.google.com/search/docs/crawling-indexing/block-indexing · Stand 10.12.2025
- Google, Doppelte URLs zusammenfassen (Canonical): https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- Google, HTTP-Statuscodes, Netzwerk- und DNS-Fehler: https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
- Google, Weiterleitungen und Google Suche: https://developers.google.com/search/docs/crawling-indexing/301-redirects · Stand 14.04.2026
- Google, Website-Umzug mit URL-Änderungen: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes · Stand 20.08.2026
- Google, Standortabhängige Seiten: https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages
- Google, Crawlbare Links: https://developers.google.com/search/docs/crawling-indexing/links-crawlable
- Google, Sitemap erstellen und einreichen: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- Google, Lokalisierte Versionen (hreflang): https://developers.google.com/search/docs/specialty/international/localized-versions · Stand 21.09.2026
- Google, Grundlagen zu JavaScript-SEO: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- Google, Lazy Loading: https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading
- Google, Mobile-First-Indexierung: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
- Google, Googlebot: https://developers.google.com/search/docs/crawling-indexing/googlebot
- Google, Allgemeine Richtlinien für strukturierte Daten: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Google, Titellinks in den Suchergebnissen: https://developers.google.com/search/docs/appearance/title-link
- Google, Best Practices für Bilder: https://developers.google.com/search/docs/appearance/google-images
- Google, Core Web Vitals und Google Suche: https://developers.google.com/search/docs/appearance/core-web-vitals
- Google, Über PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
- Google, Consent Mode: https://developers.google.com/tag-platform/security/concepts/consent-mode
- Search-Console-Hilfe, Inhaberschaft der Website bestätigen: https://support.google.com/webmasters/answer/9008080?hl=de
- Search-Console-Hilfe, Tool zur Adressänderung: https://support.google.com/webmasters/answer/9370220?hl=de
- Google, Anfragen von Google-Crawlern bestätigen: https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests