Das SEO CMS ist ein statischer Seitengenerator mit Backend. Redaktion und Einstellungen leben in einer Datenbank je Mandant, ausgeliefert werden aber fertige HTML-Dateien. Beim Aufruf einer Seite fragt also kein PHP-Skript die Datenbank ab. Diese Seite behandelt den statischen Build, statische Seiten, gemeinsame Dateien und die Fehlerseiten. Ob statische Auslieferung zu deinem Vorhaben passt, wägt der Beitrag Statisch oder dynamisch ab.
Ein Lauf, alle Seiten
Ein Build schreibt sämtliche Seiten eines Mandanten neu: Startseite, Verzeichnis und Bestenliste, Themen- und Ortsseiten, Blog, Lexikon, Autorenprofile und die statischen Seiten. Dazu entstehen die Dateien, die Suchmaschinen und andere Programme lesen: sitemap.xml, robots.txt, der RSS-Feed, die llms.txt, das Web-App-Manifest und der Suchindex für die Suche im Browser. Erweiterungen hängen sich in denselben Lauf ein und schreiben ihre Seiten mit.
Gestartet wird der Build im Backend oder auf der Kommandozeile, für einen Mandanten (php build.php seo-cms) oder für alle (php build.php --all). Bei --all läuft jeder Mandant in einem eigenen PHP-Prozess, weil sich die Konstanten eines Mandanten je Prozess nur einmal setzen lassen. Am Ende steht eine Zusammenfassung, welche Mandanten fehlgeschlagen sind. Wer den Build als geplante Aufgabe laufen lässt, sieht einen Fehler in der Mitte also nicht erst, wenn jemand die Seite aufruft.
Eine Sperrdatei verhindert, dass zwei Läufe gleichzeitig in dasselbe Verzeichnis schreiben. Der Fortschritt erscheint Zeile für Zeile, ein Abbruch fällt damit sofort auf. Seit Fassung 1.0.147 baut auch das Backend in einem eigenen PHP-Prozess, damit ein großer Mandant nicht an der Zeitgrenze des Webservers hängen bleibt.
Was nach dem Build übrig bleibt
Der Generator schreibt bei jedem Lauf jede Seite neu. Was danach im Ausgabeverzeichnis eine ältere Änderungszeit trägt, wurde nicht mehr erzeugt. Solche .html-Dateien entfernt der Build am Ende selbst, etwa die Seiten eines abgeschalteten Moduls oder eines umbenannten Pfads. Sonst blieben sie über ihre alte Adresse erreichbar, ohne Verlinkung und ohne Sitemap-Eintrag. Bilder, JSON-Dateien und alles andere fasst diese Prüfung nicht an. Für ganze Verzeichnisse, die zu keiner Einstellung mehr gehören, gibt es das Aufräumwerkzeug, das zunächst nur anzeigt. Es ist auf der Seite Backend, Wartung und Diagnose beschrieben.
Fragen zu deiner Website?
Ruf an, stell deine Frage in der gratis Sprechstunde oder vereinbare ein Erstgespräch.
Statische Seiten je Domain
Impressum, Datenschutzerklärung, Kontakt, "Über uns" und weitere Einzelseiten liegen als Datensätze in der Datenbank des Mandanten und werden im Backend gepflegt. Jede Domain hat ihre eigenen Rechtstexte, niemand muss dafür per FTP an eine Vorlage. Der Seitentyp in den strukturierten Daten richtet sich nach dem Slug: Aus "ueber" wird eine AboutPage, aus "kontakt" eine ContactPage. Seit Fassung 1.0.143 können statische Seiten einen Fragenblock tragen und ins Menü aufgenommen werden. Die Sitemap übernimmt alle statischen Seiten aus der Datenbank, nur die Fehlerseiten nicht.
Gemeinsame Dateien für alle Mandanten
Stylesheets, Skripte, Schriften und Symbole liegen einmal unter shared/ und werden von allen Mandanten genutzt. Liegt im Verzeichnis eines Mandanten eine Datei mit demselben Namen, hat sie Vorrang. So bekommt jede Website ihr eigenes Favicon, ihre Vorschaubilder und ihr Manifest, ohne dass für den Rest eine zweite Kopie nötig ist. Die Regel dafür steht in der .htaccess und greift auch vor dem ersten Build. Deshalb lädt das Backend seine Stylesheets auch dann, wenn ein Mandant noch gar keine Seiten hat.
Der Vorteil ist zugleich der Punkt, an dem du aufpassen musst: Eine Änderung an einem gemeinsamen Stylesheet wirkt auf jedes Projekt gleichzeitig. Wer das Design für einen einzelnen Mandanten ändern will, legt die Datei in dessen Verzeichnis ab.
Fehlerseiten mit Rückfall
Die Seiten für 403, 404 und 500 sind gewöhnliche Inhaltsseiten. Du pflegst sie im Backend und kannst darauf Hinweise geben, die zum Projekt passen. Sie tragen immer "noindex, nofollow" und fehlen in der Sitemap. Die .htaccess bindet sie als lokale Pfade ein. Apache leitet dabei intern weiter, und der Browser erhält den ursprünglichen Fehlercode [1].
Wichtig ist der Rückfall: Solange ein Mandant noch nicht gebaut wurde, gibt es seine 404-Seite nicht. Ohne Vorkehrung würde Apache die Fehlerseite suchen, sie nicht finden und sich im Kreis drehen, bis er mit einem Serverfehler abbricht. Für diesen Fall liegt eine schlichte Hinweisseite im Wurzelverzeichnis, die die .htaccess ausliefert, solange die eigene Fehlerseite fehlt. Ist die Erweiterung Weiterleitungen aktiv, prüft der 404-Weg vorher noch, ob für die Adresse eine Umleitung hinterlegt ist. Das steht auf der Seite Adressen, Weiterleitungen und Zertifikate.
Warum statische Auslieferung
Eine fertige HTML-Datei auszuliefern ist für den Webserver die einfachste Aufgabe. Es gibt keine Datenbankabfrage je Aufruf und keinen Seitencache, der veralten könnte. Das entlastet den Webserver gerade dann, wenn viele Websites auf einer Installation laufen. Die Ladezeit hängt danach vor allem an Bildern, Schriften und Skripten. Wie das mit den Core Web Vitals zusammenhängt, steht im Beitrag Core Web Vitals, die Grundbegriffe im Glossar unter Core Web Vitals.
Der Preis: Eine Änderung im Backend ist erst nach dem nächsten Build sichtbar. In der Praxis ist das ein Klick im Backend, und weil der Lauf alle Übersichten, die Sitemap und den Feed neu schreibt, kann keine davon auf einem älteren Stand stehen bleiben.
Ob ein Build bei dir per geplanter Aufgabe laufen sollte oder von Hand reicht, hängt an deinem Redaktionsrhythmus. Darüber sprechen wir in der gratis Sprechstunde, an jedem ersten Samstag im Monat um 18 Uhr.
- Organisation Apache Core Features: ErrorDocument. The Apache Software Foundation. Stand Apache HTTP Server 2.4. abgerufen am 31.10.2026
Häufige Fragen
Brauche ich für den Build Node.js oder ein anderes Bauwerkzeug?
Nein. Der Build ist PHP und läuft auf demselben Webspace wie das Backend. Er wird im Backend oder mit php build.php auf der Kommandozeile gestartet.
Kann der Build nachts automatisch laufen?
Ja. php build.php --all lässt sich als geplante Aufgabe einrichten, etwa in Plesk. Am Ende meldet der Lauf, welche Mandanten fehlgeschlagen sind.
Was passiert mit Seiten, die ich im Backend lösche?
Der nächste Build schreibt sie nicht mehr, und die alte .html-Datei entfernt er am Ende des Laufs. Soll die alte Adresse weiterführen, legst du eine Weiterleitung an.
Kann ich das Design für nur einen Mandanten ändern?
Ja. Eine Datei im Verzeichnis des Mandanten hat Vorrang vor der gemeinsamen Datei unter shared/.
Warum sehe ich vor dem ersten Build eine schlichte Hinweisseite?
Das ist der Rückfall für Fehlerseiten. Er verhindert, dass der Webserver eine fehlende 404-Seite im Kreis sucht und mit einem Serverfehler abbricht.
Fragen zu deiner Website?
Ruf an, stell deine Frage in der gratis Sprechstunde oder vereinbare ein Erstgespräch.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.
