Strukturierte Daten bei CMS-Updates kontrollieren

Die betroffenen Ausgabeschichten identifizieren

Ein CMS-Update kann Kernsystem, Theme, SEO-Erweiterung oder eine selbst ergänzte Vorlage betreffen. Schreiben Sie auf, welche dieser Komponenten die strukturierten Daten tatsächlich erzeugt. Ein Feld im Redaktionsformular muss nicht die einzige Quelle sein. Gerade nach Erweiterungswechseln können alte und neue Ausgaben nebeneinander bestehen bleiben.

Ordnen Sie die Zuständigkeiten zu: Wer bestätigt die fachlichen Angaben, wer prüft die technische Ausgabe, und wer entscheidet über die Veröffentlichung? Ohne diese Trennung wird ein Parserfehler leicht an die Redaktion weitergereicht, während ein falscher Autorenname als rein technisches Problem liegenbleibt. Beides braucht eine Bearbeitung, aber nicht denselben Bearbeiter.

Repräsentative Seiten vor dem Update sichern

Wählen Sie eine kleine, begründete Stichprobe Ihrer Seitentypen: einen normalen Artikel, eine Seite mit geändertem Datum, ein Autorenprofil und gegebenenfalls ein Angebot. Ergänzen Sie bekannte Sonderfälle. Die Auswahl folgt Ihren tatsächlichen Templates; sie muss nicht möglichst viele URLs enthalten, um umfangreich auszusehen.

Sichern Sie für jede ausgewählte URL sichtbaren Hauptinhalt und ausgegebene strukturierte Daten. Notieren Sie den Komponentenstand und bekannte offene Befunde. Wenn schon vor dem Update ein Fehler vorhanden war, sollte er nachher nicht fälschlich als neu verursacht gelten. Eine Sicherung ohne nachvollziehbare URL und Zeitpunkt ist für einen Vergleich kaum brauchbar.

Eine passende ergänzende Entscheidungshilfe bietet Article-Markup für redaktionelle Inhalte.

Fachliche und technische Differenzen getrennt erfassen

Benutzen Sie einen Vergleich, der Änderungen auf ihre Bedeutung zurückführt. Eine veränderte Reihenfolge von JSON-Eigenschaften ist nicht automatisch ein inhaltlicher Fehler. Eine andere Autorenidentität, ein neues Preisangebot oder ein unpassendes Datum ist dagegen fachlich relevant.

Ordnen Sie jede Differenz einer Entscheidung zu: erwartete Änderung, zu korrigierender Fehler oder noch ungeklärter Befund. Ein pauschales „alles grün“ hilft wenig, wenn die Prüfliste nur die Syntax und keine tatsächlichen Inhalte erfasst.

Die Vorschau unter realistischen Bedingungen testen

Prüfen Sie die Vorschau mit der für die spätere öffentliche Seite vorgesehenen Konfiguration. Ein deaktiviertes Plugin oder andere Beispieldaten können Fehler verdecken. Halten Sie die Vorschau gleichzeitig aus der unbeabsichtigten öffentlichen Nutzung heraus. Zugangsschutz und Indexierungssteuerung sind unterschiedliche Aufgaben und sollten bewusst eingerichtet werden.

Nutzen Sie geeignete Tests für die jeweils unterstützten Datenarten. Vergleichen Sie deren Ergebnis mit dem fachlichen Register. Ein gültiges Article-Objekt kann noch immer einen falschen Autor enthalten. Umgekehrt bedeutet eine nicht unterstützte besondere Suchfunktion nicht zwangsläufig, dass jede beschreibende Schema-Angabe unverständlich wäre. Dokumentieren Sie den konkreten Prüfgegenstand und die Grenze des verwendeten Werkzeugs.

Fiktives Beispiel: ein Theme ergänzt einen zweiten Artikelblock

Eine Redaktion hat Article-Daten über eine Erweiterung gepflegt. Nach einem Theme-Update erzeugt das Theme zusätzlich einen eigenen Artikelblock mit einem allgemeinen Organisationsnamen und dem aktuellen Tagesdatum. Der technische Test kann beide Blöcke lesen, die Angaben widersprechen sich aber in der Bedeutung.

Das Team bestimmt eine führende Ausgabeschicht und entfernt die unbeabsichtigte Doppelbeschreibung in der Vorschau. Danach prüft es normale Artikel und Sonderfälle erneut. Nach dem Einspielen wird dieselbe Stichprobe öffentlich abgerufen. Das Beispiel zeigt eine mögliche Fehlerklasse und behauptet keinen tatsächlich auf dieser Website aufgetretenen CMS-Fehler.

Eine Freigabe mit klarer Fehlergrenze treffen

Legen Sie vor der Veröffentlichung fest, welche Befunde ein Update stoppen. Dazu können unlesbare Daten, falsche Identitäten oder frei erfundene Angebotsangaben gehören. Eine harmlose technische Umformatierung muss dagegen nicht denselben Rückweg auslösen. Entscheidend ist die Auswirkung auf die veröffentlichte Aussage und die nachvollziehbare Verarbeitung.

Halten Sie fest, welche Komponente bei einem Rückschritt wiederhergestellt werden kann und welche zwischenzeitlichen Inhaltsänderungen davon betroffen wären. Ein kompletter Datenbankrücksprung kann neue redaktionelle Arbeit verlieren. Ein begrenzter Template-Rollback kann geeigneter sein, wenn nur die Ausgabe betroffen ist. Der passende Umfang muss zum tatsächlichen System und zur vorhandenen Sicherung passen.

Öffentlich nachprüfen und den Prüfsatz weiterpflegen

Ein bestandener Vorschautest beendet die Prüfung nicht. Rufen Sie die veröffentlichten URLs auf und vergleichen Sie die tatsächliche Ausgabe mit der freigegebenen Sollfassung. Caches, abweichende Umgebungen oder ausgelassene Dateien können Unterschiede verursachen. Dokumentieren Sie, welcher Stand tatsächlich öffentlich erreichbar ist.

Ergänzen Sie einen neu entdeckten Sonderfall im Prüfsatz, damit er beim nächsten Update berücksichtigt wird. Wiederholen Sie nicht wahllos alle Tests, wenn die Veröffentlichung bereits eindeutig bestätigt ist. Ein gepflegter Satz relevanter Seiten und eine klare Zuständigkeit machen die Kontrolle langfristig belastbarer als eine sehr lange, aber ungezielte Liste von Werkzeugmeldungen.

Die übergreifenden Grundlagen vertieft der Leitfaden Strukturierte Daten testen und Fehler beheben.

Häufige Fragen.