Yoast SEO: Unknown column ‘seo_title_score’ – Datenbank reparieren

Ein vollständiges Backup erstellen und prüfen

Sichere vor jeder schreibenden Reparatur die gesamte betroffene WordPress-Datenbank einschließlich der vorhandenen Yoast-Tabellen. Ein WordPress-Inhaltsexport reicht dafür nicht. Verwende den etablierten Sicherungsweg deines Hostings oder ein korrekt konfiguriertes Datenbankwerkzeug wie mariadb-dump.

Prüfe, ob der Export fehlerfrei abgeschlossen wurde und Struktur sowie Daten enthält. Ein Prüfsummenvergleich hilft bei Übertragungsfehlern; belastbarer ist zusätzlich ein erfolgreicher Wiederherstellungstest in einer getrennten Umgebung. Nur eine vorhandene Dateigröße beweist keine wiederherstellbare Sicherung.

Plane ein Wartungsfenster und verhindere parallele Schemaänderungen oder Migrationsläufe. Halte außerdem die bisherige Tabellenstruktur mit SHOW CREATE TABLE fest. So kannst du später auch die bestehenden Spaltendefinitionen vergleichen.

Präfix, Schema, Zeilenformat und Status kontrollieren

Ermittle das tatsächliche Präfix der betroffenen Site. Mit installiertem WP-CLI kannst du im richtigen WordPress-Verzeichnis den dokumentierten Lesebefehl verwenden:

wp db prefix

Bei Multisite muss auch der Zielsite-Kontext stimmen. WP-CLI dokumentiert dafür unter anderem den Parameter –url. Alle folgenden SQL-Beispiele verwenden wp_ nur als Beispiel: Ersetze es überall durch das ermittelte Site-Präfix und wähle zuerst die richtige Datenbank aus.

SELECT DATABASE() AS aktuelle_datenbank,
       VERSION() AS datenbank_version,
       @@innodb_page_size AS seitengroesse_bytes,
       @@SESSION.innodb_strict_mode AS innodb_strict_mode;

SELECT TABLE_NAME, ENGINE, ROW_FORMAT
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'wp_yoast_indexable';

SHOW CREATE TABLE `wp_yoast_indexable`;

Kontrolliere anschließend die beiden Spalten. Die Abfrage liest nur das Schema:

SELECT COLUMN_NAME, DATA_TYPE, COLUMN_TYPE,
       IS_NULLABLE, COLUMN_DEFAULT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'wp_yoast_indexable'
  AND COLUMN_NAME IN ('seo_title_score', 'meta_description_score')
ORDER BY COLUMN_NAME;

Kein Treffer bedeutet bei bestätigter Datenbank und Tabelle, dass beide Spalten fehlen. Ein Treffer bedeutet eine Teilmigration; zwei Treffer müssen noch anhand ihrer Definitionen beurteilt werden.

Im geprüften Yoast-Code wird die Tabelle für die einzelnen Kennungen als <Präfix>yoast_migrations gebildet. Prüfe nach Bestätigung dieses Namens den Eintrag zur betreffenden Migration:

SELECT version
FROM `wp_yoast_migrations`
WHERE version = '20260709144332';

Zusätzlich kannst du den allgemeinen Status yoast_migrations_free lesend in der passenden Options-Tabelle prüfen. Lösche oder ändere diese Markierungen nicht als vermeintliche Reparatur. Dokumentiere den Widerspruch zwischen Status und Schema.

Bei bestätigtem COMPACT-Problem nur diese Tabelle umstellen

Wenn Untersuchung und Fehlerprotokoll das COMPACT-Zeilenformat-Problem bestätigen, stelle ausschließlich die betroffene Yoast-Tabelle um:

ALTER TABLE `wp_yoast_indexable`
ROW_FORMAT=DYNAMIC;

Prüfe unmittelbar das Ergebnis und bei Bedarf die SQL-Diagnose mit SHOW WARNINGS;. Lies danach das Zeilenformat erneut aus. Schlägt die Änderung fehl, brich den Reparaturlauf ab und untersuche die konkrete Meldung. Die Datenbank ist kein Ort für optimistisches Weiterklicken.

Ändere nicht pauschal alle WordPress-Tabellen. Setze auch nicht einfach den globalen Standard um: Ein neuer Standardwert ist kein Nachweis, dass eine bestehende Tabelle konvertiert wurde. Die hier verwendete Tabellenänderung ist in der MariaDB-Dokumentation zu DYNAMIC beschrieben.

Ist die Tabelle bereits DYNAMIC, ist diese Umstellung kein obligatorischer Reparaturschritt. Fehlen dennoch Spalten, müssen Fehlerursache und aktueller Tabellenaufbau bewertet und die fehlenden Änderungen kontrolliert vervollständigt werden.

Die versionsgenaue Originalmigration kontrolliert nachholen

Verwende die zur tatsächlich installierten Yoast-Version gehörende Originaldatei. Für Yoast SEO 28.7 ist das src/config/migrations/20260709144332_AddSeoTitleAndMetaDescriptionScores.php. Prüfe auch den zugehörigen Adapter, statt nur eine aktuelle Datei aus dem Entwicklungszweig zu übernehmen.

Bei einer automatisierten Ausführung muss ein überprüfender Adapter fehlgeschlagene SQL-Abfragen als Fehler weitergeben und bereits korrekt vorhandene Spalten berücksichtigen. Ein erneutes Scheitern darf nicht unbemerkt als Erfolg durchlaufen.

Für einen solchen Reparaturweg müssen mindestens diese Bedingungen erfüllt sein:

• Vor jedem Hinzufügen wird geprüft, ob die Spalte fehlt oder bereits korrekt existiert.
• Eine existierende Spalte mit abweichender Definition führt zur Untersuchung statt zu einem automatischen Überschreiben.
• SQL-Fehler beenden den Lauf mit einer aussagekräftigen Meldung.
• Nach der Ausführung wird das reale Schema unabhängig vom Rückgabestatus geprüft.
• Bereits gespeicherte Migrationsmarkierungen werden nicht pauschal zurückgesetzt.

Für die beschriebene gezielte Reparatur wird hier kein offizieller Yoast-WP-CLI-Migrationsbefehl vorausgesetzt. Ein dafür erstellter Adapter wäre individuelle Reparaturlogik und müsste gegen die installierte Version geprüft werden.

SQL-Alternative für MariaDB

Wer statt einer Adapter-Ausführung direkt SQL verwendet, muss die Anweisungen gegen die installierte Migration prüfen. Der Abgleich des offiziellen 28.7-Pakets ergibt für beide neuen Felder INT(3), vorzeichenbehaftet und nullable, ohne einen abweichenden expliziten Standardwert.

Die folgende MariaDB-Alternative ergänzt nur fehlende Spalten und berücksichtigt damit auch eine Teilmigration. Voraussetzung sind das geprüfte Backup, ein geeigneter Tabellenaufbau und die Vorabkontrolle vorhandener Spalten. Für andere Yoast-Versionen nicht ungeprüft übernehmen:

ALTER TABLE `wp_yoast_indexable`
  ADD COLUMN IF NOT EXISTS `seo_title_score` INT(3) NULL,
  ADD COLUMN IF NOT EXISTS `meta_description_score` INT(3) NULL;

IF NOT EXISTS überspringt bereits vorhandene Spalten; es korrigiert deren Definition nicht. Entsprechende Warnungen sind möglich. Kontrolliere die Diagnose direkt nach dem Befehl und danach beide Definitionen. Die MariaDB-Referenz zu ALTER TABLE dokumentiert diese Syntax. Sie ist nicht unverändert auf jede MySQL-Version übertragbar.

Diese SQL-Alternative ersetzt gezielt die beiden Spaltenergänzungen. Sie führt nicht den gesamten Yoast-Migrationsrunner aus und aktualisiert keinen allgemeinen Migrationsstatus. Im Fall der bereits als ausgeführt gespeicherten Originalmigration muss keine neue Erfolgsmarkierung erfunden werden.

Verlasse dich außerdem nicht auf ein einfaches ROLLBACK für Tabellenänderungen. ALTER TABLE verursacht bei MariaDB einen impliziten Commit. Das erklärt auch, warum ein Reparaturlauf nach einem Teilfehler den vorhandenen Zustand erneut prüfen muss.

Beide Spalten und die bisherigen Definitionen vergleichen

Führe nach der Reparatur erneut die Schemaabfrage aus. Erwartet werden zwei passende Spalten, nicht nur ein Erfolgstext des Skripts:

SELECT COLUMN_NAME, DATA_TYPE, COLUMN_TYPE,
       IS_NULLABLE, COLUMN_DEFAULT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'wp_yoast_indexable'
  AND COLUMN_NAME IN ('seo_title_score', 'meta_description_score')
ORDER BY COLUMN_NAME;

Die Metadatenfelder DATA_TYPE, COLUMN_TYPE, IS_NULLABLE und COLUMN_DEFAULT sind in information_schema.COLUMNS dokumentiert. Vergleiche die Ausgabe mit der Originalmigration und dem vorher gesicherten Schema.

Prüfe auch die bisherigen Spaltendefinitionen: Datentypen, NULL-Eigenschaften, Standardwerte sowie gegebenenfalls Zeichensatz und Kollation sollen nicht unbeabsichtigt verändert worden sein. Ein Unterschied bei der Tabellenoption ROW_FORMAT ist bei der beabsichtigten Umstellung erwartbar.

Die gezeigten SQL-Anweisungen ergänzen Spalten beziehungsweise ändern das Zeilenformat. Sie enthalten keine Anweisung zum Löschen von Beiträgen, Seiten oder SEO-Einstellungen. Das Backup und der anschließende Strukturvergleich bleiben trotzdem erforderlich.

Schreibvorgänge testen und neue Logs kontrollieren

Prüfe nach der Schemaänderung Website und Administrationszugang. Wiederhole außerdem einen kontrollierten Vorgang, der den ursprünglichen Fehler ausgelöst hatte. Falls beispielsweise ein Speichern oder Aktualisieren eines Indexable-Datensatzes betroffen war, muss genau dieser Ablauf erneut beobachtet werden.

Notiere den Beginn des Nachtests und beurteile neue Logeinträge ab diesem Zeitpunkt. Ein alter Eintrag wird durch die Reparatur nicht aus der Logdatei gelöscht. Umgekehrt ist ein leerer kurzer Logausschnitt ohne passenden Test kein Beweis für eine vollständige Reparatur.

Für Agenturen empfiehlt sich pro Site ein kleines Prüfprotokoll: Yoast-Version, Datenbankversion, Präfix, Tabellenformat vorher und nachher, Spaltendefinitionen, Migrationskennung, ausgeführte Änderung und Ergebnis des Schreibtests.