KantSites/ENTWICKLUNGSPLAN.md

Eigenes CMS – Entwicklungsplan

Stand: 11.09.2026. Status: Planung; noch keine CMS-Implementierung und kein Repository eingerichtet. Arbeitstitel: Kant CMS. Der Produktname ist noch offen.

Ziel

Ein selbst betreibbares CMS für Umuts Kundenwebsites. Schwerpunkt: ein visueller Editor mit dem vertrauten Bedienprinzip des Flatsome UX Builders, schnelle öffentliche Seiten, integriertes SEO, gut zugängliche Inhalte für Suchmaschinen und KI-Systeme, erweiterbare Templates und Plugins.

Der Editor wird eigenständig implementiert. Die konkrete Referenzoberfläche und die von Umut meistgenutzten Abläufe werden zu Beginn anhand bereitgestellter Screenshots oder einer zugänglichen Demo erfasst. Der Plan behauptet keine vollständige Flatsome-Kompatibilität.

Oberste Priorität: fünf Qualitätsbereiche ab Phase 0

Umut hat Leistung, Barrierefreiheit, Best Practices, SEO und agentisches Browsing ausdrücklich in den Vordergrund gestellt. Diese Anforderungen gelten für Architektur, jeden Block, jedes Template und jedes Plugin ab Beginn. Phase 5 bündelt zusätzliche Funktionen und die abschließende Überprüfung; Qualitätsarbeit darf nicht bis dahin aufgeschoben werden.

Ausgangswerte ausschließlich aus dem bereitgestellten mobilen PageSpeed-Screenshot für www.kant-it.de: Leistung 67, Barrierefreiheit 87, Best Practices 77, SEO 100, agentisches Browsing 2/3. Im Screenshot sind keine Felddaten vorhanden. Es wurde kein eigener Audit der bestehenden Website durchgeführt; Ursachen sind aus der Übersicht nicht ableitbar.

Bereich	Entwicklungs- und Abnahmeziel
Leistung	Auf repräsentativen öffentlichen Referenzseiten mindestens 95 mobil, 100 anstreben; Desktop ebenfalls mindestens 95. Feste Testbedingungen, Produktionsbuild und Median aus drei Läufen.
Barrierefreiheit	100 bei automatischen Lighthouse-Prüfungen plus manuelle Prüfung von Tastatur, Fokus, Dialogen, Formularen und Screenreader-Grundabläufen.
Best Practices	100 bei den anwendbaren automatischen Prüfungen; zusätzlich funktionierende Fehlerbehandlung und Sicherheitsprüfungen für den CMS-Kern.
SEO	100 bei automatischen Prüfungen indexierbarer Referenzseiten plus Prüfung von Canonicals, Sitemap, Weiterleitungen, strukturierten Daten und tatsächlicher HTML-Ausgabe.
Agentisches Browsing	Alle anwendbaren Prüfungen der eingesetzten Auditversion bestehen; zusätzlich reale Abläufe wie Navigation, Suche und Formularbedienung prüfen. Kein dauerhaft festgeschriebener Nenner von drei.

Diese Werte sind Projektziele, keine Garantie für jede spätere Kundenkonfiguration. Testversion, Geräte-/Netzprofil, Inhalte, Server und externe Dienste werden im Bericht erfasst. Die Auswahl umfasst Startseite, Inhaltsseite, Beitrag und Formularseite mit realistischen Bildern und Texten; keine leeren Demo-Seiten als Leistungsnachweis.

Core Web Vitals im Feld: LCP <= 2,5 s, INP <= 200 ms, CLS <= 0,1 am 75. Perzentil, mobil und Desktop getrennt. Fehlende Felddaten als unbekannt ausweisen. Lighthouse-Labortests messen INP nicht direkt; TBT getrennt berichten.

Konkrete Konsequenzen für den Editor: semantische HTML-Ausgabe, echte Links und Buttons, Formularlabels, sichtbarer Fokus, Kontrastprüfung, Kennzeichnung dekorativer Bilder, Bildabmessungen und automatische Bildoptimierung. Große Bilder und zusätzliche externe Skripte sichtbar machen. Headerbilder gezielt priorisieren; nachgelagerte Bilder bei Bedarf verzögert laden. Keine Editor-Bibliotheken in öffentliche Seiten übernehmen.

Agentisches Browsing und GEO getrennt behandeln: Bedienbarkeit durch Agenten ist etwas anderes als Auffindbarkeit/Zitierung in KI-Antworten. Laut aktueller Chrome-Dokumentation ist die Agentic-Browsing-Kategorie experimentell und prüft unter anderem maschinelle Bedienbarkeit, Stabilität, WebMCP und llms.txt. Die konkreten Auditdetails der Nutzerseite müssen vor Diagnose geöffnet werden. WebMCP-Unterstützung austauschbar und nur für sinnvolle Funktionen vorsehen; Autorisierung und serverseitige Validierung gelten auch für Agentenzugriffe. Eine maschinenlesbare Zusammenfassung darf nur öffentliche Inhalte enthalten. llms.txt ist dabei kein allgemeiner Google-SEO-Rankingfaktor und keine Voraussetzung für die Google-KI-Suche.

Qualitätsprüfungen werden mit der ersten öffentlich gerenderten Seite eingerichtet und nach Änderungen an Renderer, Templates und Plugins auf Regressionen geprüft. Ein Score von 100 ersetzt weder vollständige Barrierefreiheitsprüfung noch Sicherheitsprüfung oder Inhaltsqualität.

Arbeitsumgebung und Projektgedächtnis

Empfehlung: Umsetzung am Desktop in einem lokalen Git-Projekt mit Codex-Zugriff auf den Projektordner, Vorschau im Browser und reproduzierbarer Entwicklungsumgebung. Hier lassen sich Planung, Dateien und Prototypen vorbereiten; dieser Chat hat derzeit keinen Zugriff auf Umuts Desktop-Projekt.

AGENTS.md im Projektstamm enthält die dauerhaften Arbeitsregeln. Dieser Entwicklungsplan enthält Ziele, Reihenfolge und Abnahmekriterien. Bei Implementierungsbeginn werden docs/STATUS.md für den aktuellen Stand und docs/ARCHITECTURE.md für begründete Architekturentscheidungen angelegt. Alle Dokumente werden mit dem Code versioniert. Eine neue Sitzung muss auf dasselbe Projekt zugreifen können; Chat-Erinnerung ersetzt diese Dateien nicht.

Leitentscheidungen als Vorschlag

• Eine selbstständige Installation je Kundenwebsite für Version 1; zentrale Verwaltung später.
• Modularer Kern in einer Anwendung. Öffentliche Ausgabe und Editor haben getrennte Ressourcen.
• Serverseitig erzeugtes oder vorab gerendertes HTML; der eigentliche Seiteninhalt benötigt kein Browser-JavaScript.
• Seiten als versionierter, validierter Blockbaum mit stabilen IDs speichern. Keine Bindung der Inhalte an proprietäre Shortcodes.
• Vorschau und öffentliche Ausgabe nutzen dieselben Blockdefinitionen und möglichst denselben Renderer.
• Inhaltsstruktur, Layout und globale Designwerte sind getrennt. Ein Templatewechsel erhält die Inhalte; fehlende Blocktypen bekommen einen kontrollierten Fallback.
• Plugin- und Template-Verträge früh definieren; einen öffentlichen Marktplatz erst später planen.
• Framework, Datenbank und Hostingprofil werden in Phase 0 festgelegt. Authentifizierung, Migrationen und andere Standardfunktionen auf bewährte Bibliotheken stützen.

Phasen und Abnahme

0 – Anforderungen und technische Grundlage

• Eine konkrete Pilotwebsite wählen und deren Seitentypen, Formulare und Inhalte erfassen.
• Die wichtigsten UX-Builder-Abläufe dokumentieren: Elemente hinzufügen, verschachteln, verschieben, bearbeiten, responsive anpassen und wiederverwenden.
• Hostingziel klären: eigener Server mit Containern oder herkömmliches PHP-Webhosting. Danach den Stack auswählen und Entscheidung begründen.
• Git-Projekt, lokale Startanleitung, Formatierung, Build und minimale CI einrichten.
• Datenmodell für Website, Seite, Revision, Medien, Menü, Template und Block entwerfen.

Abnahme: Ein frischer Checkout startet nach dokumentierter Anleitung. Eine gespeicherte Beispielseite wird als HTML ausgegeben. Das Dokumentformat ist versioniert.

1 – Durchgängiger Editor-Prototyp

• Oberfläche mit Elementbibliothek/Strukturbaum, Live-Vorschau und Eigenschaftenpanel.
• Sektionen, Zeilen, Spalten, Überschrift, Text, Bild und Button.
• Auswahl in Vorschau und Strukturbaum synchronisieren.
• Drag-and-drop, Duplizieren, Löschen und alternative Bedienung per Tastatur/Schaltflächen.
• Grundlegende Farben, Abstände, Breiten und Schriftwerte bearbeiten.
• Undo/Redo; Speichern und erneutes Laden desselben Blockbaums.
• Eine bearbeitete Seite über die öffentliche Route ausgeben.

Abnahme: Eine Beispielseite visuell erstellen, Elemente umordnen, Änderungen rückgängig machen, speichern und nach Neuladen unverändert bearbeiten. Die öffentliche HTML-Ausgabe entspricht der Vorschau.

2 – Editor für tägliche Arbeit

• Desktop-, Tablet- und Mobilvorschau mit klarer Vererbung und gezielten Überschreibungen.
• Inline-Textbearbeitung, Mediathek, Bildausschnitt, Alt-Texte und responsive Bilder.
• Weitere Blöcke: Karten, Galerie, Akkordeon, Tabs, Icon/Text und Kontaktformular.
• Globale Farben/Schriften, Header/Footer, wiederverwendbare Sektionen.
• Kopierte Sektionen und global verknüpfte Sektionen unterscheiden.
• Autosave mit sichtbarem Speicherstatus, Fehlerbehandlung und Schutz vor veralteten Schreibständen.
• Lokales Undo/Redo von dauerhaft gespeicherten Revisionen trennen.

Abnahme: Die Pilotwebsite lässt sich ohne Code im Editor pflegen. Mobile Änderungen verhalten sich vorhersehbar. Gleichzeitige Bearbeitung überschreibt keine neueren Inhalte unbemerkt.

3 – CMS-Kern und Veröffentlichung

• Anmeldung, Rollen, serverseitige Berechtigungen, sichere Sitzungen und Uploadvalidierung.
• Seiten, Blogbeiträge, Menüs, Medien und Unternehmens-/Kontaktdaten verwalten.
• Entwürfe, Vorschau, Revisionen, Publizieren und Zurücksetzen.
• Entwurf und veröffentlichte Revision getrennt halten; Cache bei Veröffentlichung gezielt erneuern.
• Formulare mit serverseitiger Validierung, Spam-Schutz, Versandstatus und Fehlerbehandlung.
• Datenmodell für Sprachen von Beginn an berücksichtigen; Übersetzungsoberfläche ergänzen.

Abnahme: Unveröffentlichte Inhalte bleiben privat; Rollen werden serverseitig durchgesetzt. Wiederherstellung einer Revision und Formularversand funktionieren.

4 – Templates und Plugins

• Templatepaket mit Manifest, Versionsanforderungen, Designwerten, Blockvarianten und Seitenvorlagen.
• Zwei eigene Templates auf denselben Inhalten erproben.
• Plugins registrieren Blöcke, Einstellungen, Hooks und bei Bedarf Datenmigrationen über dokumentierte APIs.
• Abhängigkeiten und inkompatible Versionen erkennen; Ressourcen nur dort laden, wo sie gebraucht werden.
• Fehlende oder deaktivierte Erweiterungen dürfen Inhalte nicht löschen.
• Ein Beispielplugin als Referenz implementieren.
• Serverseitige Plugins in Version 1 als vertrauenswürdigen Installationscode behandeln; keine Sandbox versprechen, solange keine echte Isolation implementiert ist.

Abnahme: Templatewechsel erhält die Inhalte. Beispielplugin lässt sich aktivieren, aktualisieren und deaktivieren; fehlende Pluginblöcke werden kontrolliert dargestellt.

5 – Geschwindigkeit, SEO und KI-Zugänglichkeit

• Seitentitel, Beschreibungen, Canonicals, Indexierungssteuerung, Sitemap, robots.txt, Weiterleitungen und passende HTTP-Statuscodes.
• Strukturierte Daten aus konsistenten sichtbaren Inhalten erzeugen, z. B. Unternehmens-, Artikel- und Breadcrumb-Daten.
• Unternehmensdaten, Leistungen, Standorte, Autoren, Quellen und Aktualisierungen sinnvoll modellieren.
• Cachekonzept, Bildgrößen, moderne Bildformate, lokale Schriften und kleine Ressourcenpakete prüfen.
• Messziele auf repräsentativen Seiten: LCP <= 2,5 s, CLS <= 0,1, INP <= 200 ms bei realer Nutzung als Zielwerte; Laborwerte getrennt dokumentieren. Hosting und Inhalte beeinflussen die Ergebnisse.
• Redaktionelle KI optional und anbieteraustauschbar: Vorschläge für Texte, Übersetzungen und Metadaten mit Vorschau vor Übernahme.
• KI-Dateien wie llms.txt allenfalls optional; keine garantierte Aufnahme, Zitierung oder Rankingverbesserung versprechen.

Abnahme: Wichtige Inhalte sind im initialen HTML vorhanden. SEO-Felder, Weiterleitungen, Cacheinvalidierung und strukturierte Daten sind überprüft. Messbedingungen und verbleibende Engpässe sind dokumentiert.

6 – WordPress-Migration und Pilotbetrieb

• Export/Import für Seiten, Beiträge, Medien, Slugs und relevante SEO-Daten erstellen.
• Flatsome-Layouts separat behandeln: tatsächlich vorhandene Shortcodes inventarisieren und unterstützte Typen auf eigene Blöcke abbilden. Unbekannte Inhalte im Importbericht ausweisen und erhalten.
• URLs, Medienreferenzen, interne Links und Weiterleitungen vor/nach Umzug vergleichen.
• Staging aufsetzen; Backups einschließlich Wiederherstellung erproben.
• Updateverfahren mit passenden Datenbankmigrationen und Rückfallstrategie dokumentieren. Ein Code-Rollback allein genügt nach inkompatiblen Datenbankänderungen nicht.
• Pilot veröffentlichen, sobald Inhalt, Funktion und Betrieb überprüft sind und der konkrete Livegang beauftragt ist.

Abnahme: Eine echte Kundenwebsite ist vollständig geprüft migriert. Ein Rückweg zur bisherigen Website ist vorbereitet; Backup und Wiederherstellung sind nachgewiesen.

7 – Ausbau nach dem Pilot

• Zentrale Verwaltung mehrerer Installationen, überwachte Updates, Backups und Gesundheitsstatus.
• Vorlagen für Branchen, erweiterte dynamische Inhalte und Integrationen.
• Shop, Buchungen, öffentliche Pluginverteilung und Mehrmandantenbetrieb anhand tatsächlichen Bedarfs separat planen.

Arbeitsablauf pro Entwicklungsschritt

1. AGENTS.md, diesen Plan und den aktuellen STATUS lesen; Repositoryzustand prüfen.
2. Den nächsten kleinen, prüfbaren Abschnitt wählen und Abnahme benennen.
3. Umsetzung einschließlich benötigter Fehler- und Leerzustände fertigstellen.
4. Passende Prüfungen ausführen: Dokument-Roundtrip und Undo/Redo für den Editor; Berechtigungen für Serverfunktionen; Migrationstests bei Schemaänderungen; visuelle Prüfung für Layoutarbeit.
5. Betroffene Architekturentscheidung, Status, bekannte Fehler und nächsten konkreten Schritt aktualisieren.
6. Ergebnis und tatsächlich ausgeführte Prüfungen knapp berichten. Keine ungetesteten Funktionen als fertig markieren.

Nächster konkreter Schritt

Phase 0 beginnen: Pilotwebsite und Hostingprofil erfassen, UX-Builder-Referenz ansehen, Stackentscheidung dokumentieren und Projektgerüst erstellen. Anschließend Phase 1 als erstes vorzeigbares Ergebnis umsetzen.

Quellen zur Einordnung

• Projektanweisungen mit AGENTS.md: https://developers.openai.com/codex/guides/agents-md
• Google zu JavaScript und HTML-Ausgabe: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
• Google zu KI-Suche und SEO: https://developers.google.com/search/docs/appearance/ai-features
• Lighthouse-Barrierefreiheit und Grenzen automatischer Scores: https://developer.chrome.com/docs/lighthouse/accessibility/scoring
• Agentisches Browsing: https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring
• Labor- und Felddaten: https://web.dev/articles/vitals

Die Phasen sind ein Arbeitsvorschlag. Die Implementierung ist noch nicht begonnen; Termine und Aufwand werden nach dem ersten durchgängigen Prototyp eingeschätzt.