Backend, Wartung und Diagnose im SEO CMS

Ein CMS für viele Websites lebt davon, dass sich der Alltag ohne FTP und ohne Kommandozeile erledigen lässt und dass die Pflege nach einem Update nicht in Handarbeit ausartet. Diese Seite behandelt das Backend, die Wartung aus dem Backend, das Aufräumen, die Diagnose und die Einstellungen. Wie Inhalte als Datei statt im Backend gepflegt werden, steht getrennt unter Redaktionsablauf mit Seed-Dateien.

Das Backend im Alltag

Im Backend pflegst du Verzeichniseinträge, Beiträge, Lexikoneinträge, Autorenprofile, statische Seiten, die Bestenliste und alle Einstellungen. Neu bauen lässt sich von dort aus mit einem Klick, der Fortschritt erscheint Zeile für Zeile. Seit Fassung 1.0.145 gibt es eine Funktion, die einen Begriff in allen redaktionellen Texten der Datenbank ersetzt, etwa nach einer Umbenennung. Technische Spalten wie Schlüssel und Adressen nimmt sie dabei aus. Die Versionsnummer steht in der Kopfzeile des Backends, damit erkennbar ist, ob eine Installation hinterherhinkt.

Die Anmeldung prüft Passwörter gegen einen bcrypt-Hash. PHP erzeugt bei diesem Verfahren für jedes Passwort automatisch ein zufälliges Salz ^[1]. Das CMS arbeitet mit dem Kostenfaktor 12 und rechnet ältere Hashes bei der nächsten Anmeldung neu. Nach fünf Fehlversuchen von derselben IP-Adresse sperrt es die Anmeldung für 15 Minuten. Mehr zur Absicherung steht unter Sicherheit und Datenschutz.

Einstellungen mit Erklärung je Feld

Alles, was je Website verschieden ist, steht in den Einstellungen: Name, Claim, Farbe, Adresspfade, Vokabular, Betreiberdaten für die strukturierten Daten, Rahmentexte der llms.txt, der Indexierungsschalter. Die Konfigurationsdatei eines Mandanten enthält dagegen nur Technik, also Datenbankzugang und Verzeichnis. Für eine Textänderung muss niemand mehr an eine Datei.

Die Einstellungen sind nach Themen gegliedert, und jedes Feld hat einen Typ und einen Hinweis, was der Wert bewirkt. Beim Indexierungsschalter steht zum Beispiel direkt daneben, dass er noindex, robots.txt und llms.txt gemeinsam steuert. Bleibt ein Feld leer, greift ein Rückfallwert aus dem Programmcode. Eine leere Einstellung führt deshalb nie zu einer leeren Stelle auf der Seite. Nach unserer Erfahrung zeigt sich der Nutzen, sobald mehrere Projekte laufen: Eine lange Liste von Schlüsseln ohne Erläuterung versteht nach einigen Monaten niemand mehr.

Auch Erweiterungen schaltest du in den Einstellungen ein, unter Erweiterungen. Danach legt die Datenbankprüfung ihre Tabellen an, und der nächste Build erzeugt ihre Seiten. Die Erweiterung Personen zum Beispiel lässt beim Abschalten ihre Tabellen stehen. Die Daten gehen also nicht verloren und sind beim Wiedereinschalten wieder da. Wer sie wirklich loswerden will, entfernt die Tabellen von Hand.

Wartung aus dem Backend

Die Wartungsseite führt der Reihe nach über jeden Mandanten und erledigt drei Schritte: Einstellungen mit der Seed-Datei abgleichen, bauen, aufräumen. Abgleich und Aufräumen laufen zunächst im Trockenlauf. Sie zeigen an, was sich ändern würde, und schreiben erst, wenn du das ausdrücklich freigibst. Jeder Schritt läuft in einem eigenen PHP-Prozess. Für Installationen ohne Kommandozeilenzugang ist das der Weg, alle Projekte in einem Durchgang zu aktualisieren.

Unter Wartung liegt auch "Datenbank prüfen". Nach einem Update legt dieser Schritt fehlende Spalten und Tabellen an, ebenfalls mit Trockenlauf und für alle Mandanten auf einmal. Bestehende Daten ändert und löscht er nicht, er lässt sich gefahrlos wiederholen. Eine eigene Seite "Nachziehen" zeigt, welche Schritte ein Update außerdem verlangt, etwa neue Zeilen in der .htaccess, und ob sie schon erledigt sind.

Aufräumen ohne Löschen auf Verdacht

Wird ein Adresspfad umbenannt, baut der Generator unter dem neuen Namen und lässt das alte Verzeichnis liegen. Für Suchmaschinen wäre das eine Dublette. Das Aufräumwerkzeug meldet solche Verzeichnisse, auf der Kommandozeile mit php cleanup.php, im Backend über die Wartung. Ohne ausdrücklichen Schalter löscht es nichts. Unter dem Ausgabeverzeichnis können auch übernommene Altbestände liegen, und ein Löschbefehl auf Verdacht wäre schlimmer als ein Hinweis. Einzelne .html-Dateien, die ein Build nicht mehr geschrieben hat, entfernt der Build selbst. Das steht unter Statischer Build und Auslieferung.

Ein zweites Werkzeug vergleicht die Einstellungen in der Datenbank mit denen in der Seed-Datei. Beim Bauen trägt das CMS nur fehlende Einstellungen nach, damit redaktionelle Änderungen erhalten bleiben. Korrigierst du im Seed einen Wert, der in der Datenbank schon steht, zeigt dir der Vergleich die Abweichung, und du entscheidest, ob er übernommen wird.

Diagnose und Prüfwerkzeuge

Scheitert eine Einrichtung, ist die erste Frage meist, ob es am Pfad, an der Datei oder am Inhalt der Konfiguration liegt. Dafür gibt es ein eigenständiges Diagnoseskript für das Setup-Token. Es bestätigt nur, ob ein übergebenes Token stimmt, und verrät über das hinterlegte nichts, auch keine Länge und keine Anfangszeichen. Es ist bewusst ohne Anmeldung erreichbar, weil es gerade dann gebraucht wird, wenn sonst nichts funktioniert. Nach Gebrauch löschst du die Datei vom Server.

Für die fertige Ausgabe liegen Prüfskripte bei. Eines prüft die Gliederung (genau eine H1, keine übersprungenen Ebenen), Alternativtexte, Beschriftungen und Kontraste. Ein zweites geht das JSON-LD aller Seiten durch und meldet, was Suchmaschinen beanstanden würden. Ein drittes findet interne Verweise auf Seiten, die es nicht gibt. Wie sich das auf die Zugänglichkeit auswirkt, beschreibt die Seite Suche und Barrierefreiheit. Den Hintergrund zu Prüfungen dieser Art erklärt der Glossarbegriff strukturierte Daten.

Du willst wissen, wie viel Pflege ein Mandantenbetrieb im Monat wirklich macht? Sprechen wir in der gratis Sprechstunde darüber, 30 Minuten je Person und ohne Anmeldung.

1. Organisation password_hash. PHP Documentation Group. 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.