Redaktionsablauf mit Seed-Dateien im SEO CMS

Viele Websites entstehen heute in Wellen: Ein Grundbestand geht online, weitere Seiten folgen, Texte werden überarbeitet und geprüft. Das SEO CMS ist für diesen Ablauf gebaut. Inhalte lassen sich im Backend schreiben, aber auch als Datei vorbereiten, versionieren und nachliefern. Diese Seite behandelt Seed-Dateien, den CSV-Import, den Entwurfsstatus und die Prüfdaten. Den Begriff erklärt das Lexikon unter Seed-Datei.

Inhalte als Seed-Datei

Eine Seed-Datei ist eine PHP-Datei, die ein Array zurückgibt: Einstellungen, statische Seiten, Themenseiten, Beiträge, Lexikon, Autoren, Verzeichnis und Bestenliste. Große Bestände lassen sich auf Teildateien aufteilen, etwa mehrere Dateien für Beiträge. Bei der ersten Einrichtung spielt das CMS alles ein. Bei jedem weiteren Build legt es nur Datensätze an, die es noch nicht gibt. Der Abgleich läuft über den Slug. Steht ein Slug schon in der Datenbank, passiert nichts.

Das ist der Kern des Ablaufs: Seed-Datei ergänzen, hochladen, bauen. Neue Inhalte kommen dazu, und wer im Backend an einem Text gearbeitet hat, verliert nichts. Seed-Dateien gehören in eine Versionsverwaltung. Dann ist nachvollziehbar, wann welcher Text hinzugekommen ist, und eine Installation lässt sich jederzeit mit demselben Stand neu aufsetzen. Mehr dazu im Beitrag Inhalte als Datei pflegen.

Korrekturen aus dem Seed nachziehen

Die Vorsicht hat eine Kehrseite. Korrigierst du in der Seed-Datei einen Text, den es in der Datenbank schon gibt, kommt die Korrektur beim normalen Build nie an. Dafür gibt es zwei Werkzeuge. Das eine spielt gezielt einzelne Datensätze aus dem Seed neu ein und überschreibt dabei, was in der Datenbank steht, nach Bereichen getrennt und auf Wunsch für einen einzigen Slug. Seit Fassung 1.0.150 gilt das auch für Autoren. Ohne Bereichsangabe zeigt es nur an, was abweicht. Das andere vergleicht die Einstellungen und übernimmt Abweichungen erst auf ausdrücklichen Befehl. Es ist auf der Seite Backend, Wartung und Diagnose beschrieben.

Bestände per CSV einspielen

Für Ortsseiten, Beiträge und Verzeichniseinträge gibt es einen CSV-Import im Backend. Er ist für Bestände gedacht, die in einer Tabellenkalkulation vorbereitet werden oder aus einem Altsystem kommen. Das Trennzeichen erkennt er selbst (Semikolon, Komma oder Tabulator) und das Byte-Order-Mark aus Excel entfernt er. Die Reihenfolge der Spalten ist egal, es zählt die Kopfzeile, und unbekannte Spalten überspringt er, statt abzubrechen. Auch hier ist der Slug der Schlüssel: Vorhandene Zeilen werden aktualisiert, neue angelegt.

Vor jedem Import läuft ein Probelauf, der anzeigt, was passieren würde. Erst danach schreibst du. Für die Lesedauer von Beiträgen musst du keine Spalte pflegen, das CMS berechnet sie beim Import. Im Backend lädst du außerdem eine leere Vorlage mit den passenden Spalten herunter oder exportierst den vorhandenen Bestand. Der Export taugt als Sicherung außerhalb der Datenbank und für eine Massenänderung in der Tabelle, die danach als Import zurückkommt.

Dieser Verbund entsteht selbst nach dem beschriebenen Ablauf. Die Texte werden als Dateien geschrieben, gegengelesen und in Wellen eingespielt, Weiterleitungen und Einstellungen liegen ebenfalls als Dateien vor. Eine Seite, die noch geprüft wird, bleibt bis zur Freigabe außerhalb der Seed-Datei oder im Entwurf. Ein halbfertiger Text gelangt so nicht auf die Website.

Entwurf, Freigabe und Sichtbarkeit

Jeder Inhaltstyp kennt einen Status. Beiträge, Lexikoneinträge und Autorenprofile sind Entwurf, bis sie freigegeben werden. Eingesandte Verzeichniseinträge warten auf Prüfung. Themen- und Ortsseiten haben einen eigenen Sichtbarkeitsschalter, der beim Anlegen aus ist. Entwürfe baut das CMS nicht. Sie erscheinen nicht in Übersichten, nicht in der Sitemap, nicht im Feed und nicht in der Suche.

Ein veröffentlichter Beitrag mit einem Datum in der Zukunft erscheint erst mit dem ersten Build nach diesem Datum. So lässt sich eine Reihe vorbereiten und gestaffelt freigeben. Für die ganze Website gilt außerdem der Indexierungsschalter: Solange er aus ist, steht jede Seite auf noindex. Das steht unter Indexierung, Sitemap und robots.txt.

Prüf- und Änderungsdaten

Veröffentlichungs- und Änderungsdatum stehen in den strukturierten Daten, in den OpenGraph-Angaben, im Feed und in der Sitemap. Die Zeitzone ist auf Europe/Berlin gesetzt und lässt sich je Mandant in den Einstellungen ändern. Ohne gesetzte Zeitzone würde PHP mit UTC rechnen, die Uhrzeit stünde also im Sommer zwei Stunden, im Winter eine Stunde daneben. Google empfiehlt, bei Datumsangaben die richtige Zeitzone mit Sommerzeit anzugeben, und verlangt, dass die Daten die Veröffentlichung oder Aktualisierung der Seite beschreiben ^[1].

Lexikoneinträge und statische Seiten tragen zusätzlich ein Prüfdatum. Es sagt, wann der Inhalt zuletzt fachlich durchgesehen wurde. Ein geändertes Komma zählt dabei nicht. Seit Fassung 1.0.153 nimmt die Sitemap bei statischen Seiten das Prüfdatum vor der Änderungszeit, im Lexikon gilt das ebenso. Ein Build allein ändert kein Datum. So bleibt das Änderungsdatum eine Aussage über den Inhalt, und Suchmaschinen haben einen Grund, es ernst zu nehmen. Warum Daten beim Umzug erhalten bleiben sollten, beschreibt der Beitrag Veröffentlichungsdatum beim Umzug erhalten.

Wie sich ein Arbeitsablauf mit Seed-Dateien in einer kleinen Redaktion einrichten lässt, sprechen wir gern in der gratis Sprechstunde durch. Bring mit, wie du heute Texte schreibst und freigibst.

1. Organisation Veröffentlichungsdatum in der Google Suche beeinflussen. Google Search Central. Stand laufend. abgerufen am 31.10.2026

Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.