SEO-Tests vor dem Deployment: die QA-Checkliste

Die meisten Ranking-Einbrüche nach einem Relaunch oder Release haben keine geheimnisvolle Ursache. Es ist ein vergessenes noindex aus der Staging-Umgebung, eine robots.txt, die alles sperrt, ein Canonical, das auf die Startseite zeigt, oder ein Template, das nach dem Umbau plötzlich leere Seiten ausliefert. Solche Fehler sind banal, aber teuer, weil Google sie oft erst nach Tagen verarbeitet und die Erholung danach Wochen dauern kann. SEO-Tests vor dem Deployment sind deshalb nichts anderes als das, was Entwickler bei Funktionen längst tun: Regressionen abfangen, bevor Nutzer sie sehen.

Dieser Beitrag beantwortet eine praktische Frage: Welche Prüfungen gehören in eine Release-Pipeline, welche davon lassen sich automatisieren, und was bleibt Handarbeit? Die Reihenfolge folgt dem Schaden, den ein Fehler anrichten kann. Zuerst die Blocker, die ganze Seiten aus dem Index werfen, dann Statuscodes, Canonicals, Metadaten und am Ende der gerenderte Inhalt. Wie du danach im Live-Betrieb Crawling-Fehler auswertest, ist ein eigenes Thema und hier nur am Rand relevant.

Warum SEO-Regressionen durch das Raster der normalen Tests fallen

Funktionale Tests prüfen, ob ein Button tut, was er soll. Ein SEO-Fehler bricht aber keine Funktion: Die Seite lädt, sieht richtig aus und liefert HTTP 200. Nur der Meta-Robots-Tag im Head sagt Suchmaschinen, sie sollen die Seite ignorieren. Kein Unit-Test schlägt an, kein Nutzer beschwert sich, und die Fehlermeldung kommt Wochen später als Traffic-Kurve nach unten.

Dazu kommt ein Verzögerungseffekt. Google crawlt nicht sofort alles neu. Ein fehlerhaftes Release wirkt deshalb oft gestaffelt: Zuerst verschwinden Seiten, die häufig gecrawlt werden, dann der Rest. Bis jemand im Reporting die Ursache sucht, liegt der Fehler mehrere Releases zurück und ist im Git-Verlauf schwer zu finden. Ein Test, der pro Release läuft, liefert dagegen eine eindeutige Zuordnung: Dieser Commit hat es kaputt gemacht.

Hilfreich ist ein nüchternes Denkmodell. Jede SEO-Prüfung beantwortet eine von drei Fragen. Darf die Seite überhaupt gecrawlt und indexiert werden? Sagt der Server das Richtige über ihren Zustand, also Statuscode, Weiterleitung, Canonical? Und sieht ein Crawler nach dem Rendern tatsächlich den Inhalt, für den die Seite ranken soll? Alles, was in eine Pipeline gehört, lässt sich einer dieser drei Fragen zuordnen.

Die Blocker zuerst: noindex, robots.txt und Staging-Lecks

Die gefährlichste Fehlerklasse ist die, die Indexierung verhindert. Sie hat eine typische Ursache: Staging- und Produktionsumgebung teilen denselben Code, und ein Schalter muss je Umgebung unterschiedlich stehen. Wird dieser Schalter beim Deployment falsch gesetzt oder mitkopiert, landet die Staging-Einstellung auf der Live-Seite. Beachte dabei, dass noindex auf zwei Wegen kommen kann: als Meta-Tag im HTML und als HTTP-Header X-Robots-Tag. Der Header wird bei Tests gern vergessen, weil er im Quelltext nicht auftaucht, und er greift auch bei PDFs und Bildern.

Die robots.txt ist der zweite Kandidat. Eine Staging-Datei mit Disallow: / ist korrekt, solange sie auf Staging liegt. Auf der Produktion sperrt sie den Crawler komplett. Ein zusätzlicher Fallstrick: Wer per robots.txt sperrt, verhindert, dass Google ein vorhandenes noindex überhaupt sieht. Die beiden Mechanismen sind nicht austauschbar, und ein Test sollte sie getrennt prüfen.

Umgekehrt gibt es das Leck in die andere Richtung. Ist die Staging-Umgebung öffentlich erreichbar und nicht per Login geschützt, kann sie indexiert werden und mit der Produktion konkurrieren. Der zuverlässigste Schutz ist eine HTTP-Authentifizierung oder eine IP-Beschränkung; noindex allein ist nur ein Hinweis, kein Zugriffsschutz. Eine sinnvolle Pipeline-Regel lautet deshalb: Auf Produktion muss eine definierte Stichprobe von URLs indexierbar sein, auf Staging darf keine erreichbar sein.

• Automatisiert: Für eine feste URL-Liste (Startseite, je ein Vertreter pro Template, die wichtigsten Kategorien) prüfen, dass weder im Meta-Robots-Tag noch im X-Robots-Tag-Header noindex steht.
• Automatisiert: Die robots.txt der Produktion muss erreichbar sein, Statuscode 200 liefern und darf die Kernverzeichnisse nicht per Disallow sperren. Ein Vergleich gegen eine versionierte Sollvorlage ist robuster als eine Musterprüfung.
• Automatisiert: Die Sitemap-Zeile in der robots.txt muss auf die Produktions-Domain zeigen, nicht auf eine Staging-Adresse.
• Manuell oder per Einmaltest: Prüfen, dass Staging ohne Zugangsdaten nicht abrufbar ist.

Statuscodes und Weiterleitungen: was der Server über die Seite behauptet

Der Statuscode ist die erste Information, die ein Crawler bekommt, und er entscheidet, wie alles danach gelesen wird. Ein Release verändert ihn häufiger, als man denkt: Routen werden umbenannt, ein Framework-Update ändert das Verhalten bei fehlenden Slashes, oder eine neue Fehlerseite liefert 200 statt 404. Letzteres nennt man Soft-404, und es füllt den Index mit wertlosen Seiten.

Für Migrationen und Relaunches ist die Weiterleitungsliste der wichtigste Testfall. Hier genügt keine Stichprobe: Die komplette Liste alter URLs wird gegen die Zielumgebung geprüft. Jede alte URL muss in einem Schritt per 301 auf die erwartete neue URL führen, die selbst 200 liefert. Ketten aus mehreren Weiterleitungen, Schleifen und Weiterleitungen auf die Startseite statt auf das thematisch passende Ziel sind die häufigsten Befunde. Ein einfaches Skript mit einer CSV aus Alt-URL und Soll-Ziel ersetzt hier stundenlanges Klicken.

Zwei weitere Kleinigkeiten lohnen einen festen Test. Erstens die Normalisierung: http auf https, mit und ohne www, mit und ohne Schrägstrich am Ende. Jede Variante muss genau einmal auf die bevorzugte Adresse zeigen. Zweitens die Fehlerseiten selbst: Eine nicht existierende URL muss 404 oder 410 liefern, ein Wartungszustand ein 503. Wie das Letztere sauber funktioniert, steht im Beitrag zum Wartungsmodus und SEO.

• Alle URLs aus der Migrationsliste: genau eine Weiterleitung, Code 301, Ziel liefert 200.
• Stichprobe der Templates: Statuscode 200, keine unerwartete Weiterleitung.
• Eine absichtlich erfundene URL: muss 404 zurückgeben, nicht 200 mit Fehlertext.
• Die vier Protokoll- und Host-Varianten der Startseite: alle landen nach einem Schritt auf derselben Adresse.

Canonicals, hreflang und Metadaten: die stillen Fehler

Ein Canonical-Tag wirkt harmlos und ist doch eine der häufigsten Fehlerquellen nach Releases. Typische Muster: Das Template baut den Canonical aus der Anfrage-URL und übernimmt dadurch Parameter oder die Staging-Domain. Oder es schreibt für jede Seite dieselbe Adresse hinein, weil eine Variable im Layout statt im Seitenkontext gesetzt wurde. Google behandelt den Canonical als Hinweis, nicht als Befehl, aber ein massenhaft falscher Hinweis richtet trotzdem Schaden an.

Ein brauchbarer Automatiktest prüft pro Template mehrere Dinge: Es gibt genau einen Canonical im Head. Er ist absolut, nutzt das richtige Protokoll und die Produktions-Domain. Bei einer indexierbaren Seite zeigt er auf sich selbst, sofern keine bewusste Zusammenführung vorliegt. Und die Zieladresse liefert 200 und keine Weiterleitung. Bei paginierten Serien oder Filterseiten kommt die Frage hinzu, ob die Regeln zur Paginierung noch stimmen.

Bei mehrsprachigen Seiten gilt Ähnliches für hreflang: Die Annotationen müssen gegenseitig sein, also jede Sprachversion verweist auf die anderen und auf sich selbst, und die Zielseiten müssen erreichbar und indexierbar sein. Ein Test, der das Netz der Sprachversionen einer Beispielseite auflöst, fängt die häufigsten Fehler ab.

Bei Titeln und Meta-Beschreibungen geht es in der Pipeline nicht um Qualität, sondern um Existenz und Plausibilität. Fehlt der Title, ist er leer oder steht in allen Seiten derselbe Platzhaltertext, ist etwas im Template kaputt. Solche Prüfungen sind billig: Title vorhanden, nicht leer, nicht identisch mit dem einer anderen Testseite, und genau eine h1 pro Seite.

• Canonical: genau einer, absolut, Produktions-Domain, selbstreferenzierend bei indexierbaren Seiten.
• hreflang: gegenseitig, inklusive Selbstverweis, Ziele erreichbar.
• Title und h1: vorhanden, nicht leer, nicht zwischen Templates dupliziert.
• Strukturierte Daten: Das JSON-LD lässt sich parsen und enthält die Pflichtfelder des jeweiligen Typs.

Gerenderter Inhalt: sieht der Crawler, was der Nutzer sieht?

Der Rohtext der Serverantwort und das gerenderte DOM sind bei JavaScript-lastigen Seiten zwei verschiedene Dinge. Wer nur den HTML-Quelltext prüft, übersieht Fehler im Client-Code. Wer nur im Browser schaut, übersieht, dass der Inhalt erst nach dem Rendern existiert und damit vom Rendering-Verhalten des Crawlers abhängt. Die Pipeline sollte beides vergleichen: ein Abruf ohne JavaScript und ein Abruf in einem Headless-Browser.

Die zentrale Frage ist, ob die Inhalte, für die die Seite ranken soll, im gerenderten Ergebnis stehen. Dafür reichen oft wenige Erwartungswerte: Die Überschrift h1 enthält den erwarteten Text, der Hauptinhalt hat eine Mindestlänge, die internen Links zur Navigation sind als echte Anker-Elemente mit href vorhanden und nicht nur als Klick-Handler. Ein Test, der an der Wortzahl des Hauptbereichs scheitert, fängt das klassische Muster der leeren Seite ab, etwa wenn ein API-Aufruf im Build-System auf die falsche Adresse zeigt. Mehr zu den Besonderheiten findest du im Beitrag zu React und SEO.

Ein weiterer Kandidat sind Ressourcen, die Rendering erst ermöglichen. Werden CSS- oder JavaScript-Dateien durch eine neue Regel in der robots.txt gesperrt, kann der Crawler die Seite nicht korrekt aufbauen. Auch eingebettete Inhalte verdienen einen Blick; was Google mit iFrames macht, ist ein eigener Stolperstein. Nach dem Rendern lohnt außerdem ein Blick auf interne Verlinkung: Hat eine wichtige Seite nach dem Release noch eingehende Links, oder wurde sie zur verwaisten Seite?

• Ohne JavaScript abrufen und mit Headless-Browser abrufen, beide Ergebnisse gegen Erwartungswerte prüfen.
• h1, Hauptinhalt mit Mindestwortzahl und Links als echte a-Elemente mit href.
• Keine gesperrten CSS- oder JavaScript-Ressourcen.
• Kernseiten haben weiterhin eingehende interne Links.

Die Pipeline aufbauen: was automatisch läuft, was ein Mensch sieht

Der Einstieg muss nicht groß sein. Ein einzelnes Skript, das eine versionierte Liste von Prüf-URLs gegen die Vorschauumgebung abruft und die oben genannten Regeln als Assertions formuliert, deckt einen großen Teil der Risiken ab. Es läuft als Schritt nach dem Build und vor der Freigabe. Schlägt eine Regel der Kategorie Blocker an, bricht das Deployment ab. Weniger schwere Befunde, etwa ein fehlender Title auf einer einzelnen Seite, erzeugen eine Warnung im Pull Request, damit die Pipeline nicht wegen jeder Kleinigkeit blockiert und das Team sie irgendwann ignoriert.

Die Wahl der Testseiten ist wichtiger als die Menge. Pro Template mindestens eine echte Seite, dazu die Randfälle: eine Seite mit Sonderzeichen in der URL, eine mit Parametern, eine paginierte, eine mehrsprachige. Wer nur die Startseite prüft, merkt nicht, dass das Produktseiten-Template kaputt ist. Fertige Crawler und Linter lassen sich ebenfalls in eine Pipeline einbauen, etwa über die Kommandozeile. Wichtiger als das Werkzeug ist, dass die Regeln als Code im Repository liegen und Entwickler sie bei Änderungen mitpflegen.

Manuell bleiben Dinge, die Urteilsvermögen brauchen. Ist der Inhalt einer neuen Vorlage aus Sicht der Suchintention sinnvoll? Stimmt die Seitenarchitektur noch, sind die wichtigsten Seiten weiterhin von der Startseite in wenigen Klicks erreichbar? Sieht das Snippet sinnvoll aus, und steuern die Snippet-Direktiven wie geplant? Dazu kommt ein Blick auf die Crawl-Budget-Seite: Erzeugt ein neuer Filter unendlich viele Kombinationen? Diese Fragen gehören in eine kurze Release-Checkliste, die ein Mensch vor größeren Änderungen abhakt.

• Blocker (Abbruch): noindex, Robots-Sperre, falscher Canonical im Template, Weiterleitungsfehler in der Migrationsliste.
• Warnung (Kommentar im Pull Request): fehlende Metadaten, doppelte Titel, fehlende Strukturdaten-Felder.
• Manuell vor großen Releases: Architektur, Filter- und Parameterlogik, Suchintention neuer Seiten.
• Die Testliste wird mit jedem Vorfall erweitert: Jeder echte Fehler bekommt danach einen Test.

Nach dem Go-live: der Schnellcheck und warum er trotzdem nötig ist

Auch die beste Vorabprüfung ersetzt nicht den Blick auf die Produktion. Manche Fehler entstehen erst durch die Umgebung: ein CDN, das Header überschreibt, eine Firewall, die Crawler blockiert, oder Caching, das eine alte robots.txt ausliefert. Dieselben Prüfungen, die auf der Vorschau laufen, sollten deshalb kurz nach der Freigabe noch einmal gegen die Produktions-Domain laufen. Das Zusammenspiel mit der Auslieferungsschicht beschreibt der Beitrag zu CDN und SEO.

In der Search Console lohnt sich an den Tagen nach dem Release der Blick auf die Seitenindexierung und die Crawling-Statistiken. Steigen Fehler wie Serverfehler oder die Statusgruppe der nicht indexierten Seiten sprunghaft an, ist das ein Signal. Mit der URL-Prüfung lässt sich für einzelne Seiten live testen, was Google sieht. Ein Rollback-Plan gehört dazu: Wer weiß, welcher Schritt einen Blocker rückgängig macht, verliert im Ernstfall Stunden statt Wochen.

Zuletzt zur Haltung. Eine SEO-QA ist kein Gatekeeper, der Entwicklern Arbeit macht, sondern eine Absicherung, die ihnen Nachtschichten erspart. Teams, die einige wenige, klare Regeln automatisieren, erleben weniger Streit über Verantwortung, weil jeder Befund einem Commit zugeordnet ist und niemand im Nachhinein rätseln muss.