SEO-Checkliste nach WordPress-Update: Das prüfst du danach

Eine SEO-Checkliste nach WordPress-Update ist eine kurze Liste von Punkten, die du auf der Live-Website prüfst, nachdem Core, ein Theme oder ein Plugin aktualisiert wurde: Robots-Meta, Titles, Canonicals, Sitemap, robots.txt und Tracking-Tags. Prüfen musst du das, weil Updates Dateien ersetzen und Einstellungen migrieren, während das Frontend meist genauso aussieht wie vorher und sich nur das Markup darunter verändert hat.

Dieser Artikel behandelt die Stunde nach einem Update. Welche Einstellungen du das ganze Jahr über im Blick behalten solltest, steht in WordPress-SEO-Monitoring, und für einen Domain- oder Plattformwechsel gibt es die SEO-Checkliste für Website-Migrationen.

Updates von SEO-Plugins: Title-Vorlagen, Robots-Standards und Sitemap

Yoast SEO und Rank Math bauen Titles aus Vorlagen mit Variablen. Yoast schreibt sie als %%title%% %%sep%% %%sitename%%, Rank Math als %title% %sep% %sitename%. Wird eine Vorlage zurückgesetzt oder löst eine Variable nicht mehr auf, zeigt sich das Ergebnis im <title> aller URLs dieses Inhaltstyps gleichzeitig. Achte auf einen Title, in dem wörtlich „%%sitename%%“ steht oder der den Seitennamen verloren hat.

Dieselben Plugins steuern die Robots-Meta für Archive, Schlagwörter, Autorenseiten und die URLs von Medienanhängen. Eine Migration der Einstellungen bei einem Major-Update kann diese Standards verändern. Vergleiche deshalb das <meta name="robots"> auf einem Schlagwort- oder Autorenarchiv mit dem Stand davor.

Öffne dann den Sitemap-Index. Beide Plugins liefern ihn unter /sitemap_index.xml aus, und beide haben einen Schalter, der ihn abschaltet (in Rank Math das Sitemap-Modul, in Yoast die Funktion XML-Sitemaps). Liefert der Index einen 404 oder ist ein Inhaltstyp daraus verschwunden, liest die Search Console weiter die alte Einreichung und meldet später Fehler. Verlorene Sitemap-Einträge behandelt aus der Sitemap entfernte Seiten ausführlicher.

Theme-Updates, die die header.php überschreiben

Ein Theme-Update ersetzt die Theme-Dateien durch die Version des Anbieters. Alles, was direkt im Parent-Theme statt in einem Child-Theme bearbeitet wurde, ist weg. Auf vielen älteren Websites betrifft das ein GTM-Snippet, das in die header.php kopiert wurde, oder ein von Hand eingefügtes Meta-Tag zur Verifizierung.

Schwerer wiegt ein fehlender Aufruf von wp_head(). Plugins geben ihre Ausgabe über diesen Hook aus. Ruft ein angepasstes Header-Template ihn nicht mehr auf, verschwinden Title, Description, Canonical und Robots-Tags des SEO-Plugins alle zusammen, mitsamt allem, was Site Kit oder ein GTM-Plugin einfügt. Die Seite wird trotzdem ganz normal angezeigt. Sieh dir den Quelltext an und suche nach dem Canonical. Fehlt es, prüfe, ob auch der Kommentarblock des SEO-Plugins fehlt.

Page-Builder-Updates und die H1

Elementor, Divi und ähnliche Builder speichern Überschriften als Widgets mit einer Einstellung für das HTML-Tag. Ein Update, das ein globales Template, einen Header im Theme Builder oder die Art ändert, wie das Theme den Seitentitel ausgibt, kann eine Seite mit zwei H1 oder ganz ohne H1 zurücklassen. Ein typisches Beispiel ist ein Theme, das plötzlich den Beitragstitel als H1 über einem Builder-Layout ausgibt, das bereits eine eigene H1 hat. Prüfe die H1 auf der Startseite, auf einer Landingpage und in einem Beitrag.

Caching- und Optimierungs-Plugins, die GTM verschieben

WP Rocket, LiteSpeed Cache, Autoptimize und ähnliche Plugins können JavaScript aufschieben, verzögern oder zusammenfassen. Nach einem Update kann ein neuer Standardwert oder eine geänderte Ausschlussliste den GTM-Container hinter eine Regel schieben, die JavaScript bis zur ersten Nutzerinteraktion verzögert. Das Tag steht weiterhin im HTML, eine Prüfung des Quelltexts bleibt also unauffällig, aber Seitenaufrufe von Besuchern, die nie scrollen oder klicken, werden nicht mehr gesendet.

Zwei Gewohnheiten helfen. Leere nach jedem Update den Seiten-Cache, denn das HTML, das du eingeloggt siehst, umgeht ihn meist. Lade die Seite danach in einem privaten Fenster mit geöffnetem Netzwerk-Tab und prüfe, ob die Anfrage an gtm.js abgesetzt wird, bevor du mit der Seite interagierst. Die Schritte für GA4 stehen in So prüfst du, ob GA4 installiert ist.

Permalinks, robots.txt und Pushes aus dem Staging

Plugins, die eigene Inhaltstypen oder Taxonomien registrieren, können bei einem Update ihre Rewrite-Regeln ändern. Bis die Regeln neu geschrieben sind, liefern diese URLs einen 404, während normale Seiten funktionieren. Ein Besuch unter Einstellungen > Permalinks mit Klick auf „Änderungen speichern“ schreibt sie neu, ebenso wp rewrite flush in WP-CLI. Teste eine URL aus jedem eigenen Inhaltstyp, statt es einfach anzunehmen.

Die robots.txt braucht einen eigenen Blick. Gibt es keine physische Datei, liefert WordPress eine virtuelle aus, die SEO-Plugins bearbeiten können, und ein Plugin-Update oder ein Import von Einstellungen kann sie umschreiben, ohne dass sich auf dem Server eine Datei ändert. Gibt es eine physische Datei, hat sie Vorrang, und ein Deploy kann eine Staging-Version mit Disallow: / darüberkopieren.

Bei Pushes aus dem Staging wird die Einstellung „Sichtbarkeit für Suchmaschinen“ vielen zum Verhängnis. Die Option liegt in der Datenbank. Ein Datenbank-Push von einer Staging-Website, auf der „Suchmaschinen davon abhalten, diese Website zu indexieren“ angehakt ist, setzt daher noindex auf die gesamte Live-Website. Wie du das erkennst, zeigt ein noindex in der Produktion finden.

SEO-Checkliste nach WordPress-Update: die 10-Minuten-Routine

Arbeite sie auf der Live-Domain ab, ausgeloggt und nachdem der Cache geleert wurde.

1. Prüfe, ob Startseite und eine Unterseite den Status 200 liefern und nicht die Meldung „Für geplante Wartungsarbeiten kurzzeitig nicht verfügbar“ zeigen (auf englischen Installationen „Briefly unavailable for scheduled maintenance“).
2. Sieh dir den Quelltext von Startseite, einem Beitrag und einer Kategorieseite an und suche nach noindex.
3. Führe curl -I auf der Startseite aus und prüfe, dass kein unerwarteter X-Robots-Tag-Header auftaucht.
4. Vergleiche <title> und Meta Description dieser Seiten mit dem Stand vor dem Update.
5. Prüfe, ob jede Seite genau eine H1 hat und ob es die erwartete ist.
6. Bestätige, dass das Canonical vorhanden ist und auf die eigene URL der Seite zeigt, mit richtigem Protokoll und Host.
7. Öffne /sitemap_index.xml (oder /wp-sitemap.xml ohne SEO-Plugin) und prüfe, ob alle Inhaltstypen noch aufgeführt sind.
8. Öffne /robots.txt und vergleiche sie mit der vorherigen Version.
9. Ruf eine URL pro eigenem Inhaltstyp und pro Taxonomie auf und stell sicher, dass keine davon einen 404 liefert.
10. Prüfe in einem privaten Fenster, ob GTM, GA4 und das Meta Pixel laden und ob das Cookie-Banner noch erscheint.

Sichere vor dem Update eine Kopie der robots.txt und einiger Titles. Ohne Vorher-Stand werden die meisten dieser Prüfungen zum Ratespiel.

Was du automatisierst und was du weiter von Hand prüfst

Für eine einzelne Website nach einem geplanten Update ist das realistisch. Für dreißig Kunden-Websites, auf denen sich Plugins nachts automatisch aktualisieren, nicht, denn oft weißt du gar nicht, dass ein Update gelaufen ist.

Deltio übernimmt den automatisierten Teil. Es liest einmal täglich Sitemap und Seiten jeder Website, vergleicht sie mit dem vorherigen Check und schickt für die betroffene Website Alerts per Slack und E-Mail, wenn sich noindex, robots.txt, Canonicals, Titles, Meta Descriptions, H1s oder Sitemap-URLs ändern, wenn GA4, GTM, das Meta Pixel oder die Cookie-Consent-Plattform fehlen oder wenn eine Wartungsseite den Inhalt ersetzt. Uptime, SSL- und Domain-Ablauf werden ebenfalls überwacht.

Weil der Check täglich läuft, erfährst du von einem automatischen Update, das etwas kaputt gemacht hat, am nächsten Tag. Bei einem Update, das du selbst ausführst, arbeitest du die Checkliste trotzdem sofort ab oder startest in Deltio einen manuellen SEO-Scan, sobald der Cache geleert ist.

Wenn du auch die nächtlichen Updates abgedeckt haben willst, kannst du Deltio 14 Tage kostenlos testen.