System-Fallstudie · Unter zwei Schul-Websites gebaut
KayJays und Kiakademie arbeiteten mit gegensätzlichen Publishing-Modellen und kamen beim selben Fehler an: Kursinformationen wurden in Seiten geschrieben, statt als Daten gepflegt. Ich habe das WordPress-System unter beiden Projekten entworfen, damit eine Quelle Menschen, Crawler und Antwortmaschinen versorgt.
Das Problem
Beide Schulen hatten einen für Menschen lesbaren Stundenplan. Keine hatte eine verlässliche Quelle für Kursdaten, die Website, Suchmaschinen und spätere Publishing-Oberflächen gemeinsam nutzen konnten.
Der gesamte Stundenplan liegt in der selbst gehosteten PHP-Anwendung Kursorganizer und wird über Advanced iFrame eingebettet. Die Inhalte fehlen im Seiten-HTML und in strukturierten Daten: für Menschen vorhanden, für Crawler und Antwortmaschinen unsichtbar.
Das spiegelverkehrte Problem: 26 manuell gepflegte Stundenplan-Einträge, deren Kurscodes nicht mehr mit den zugrunde liegenden Datensätzen übereinstimmten. Kursinformationen lebten im Seitentext statt in einem wiederverwendbaren Datenmodell.
STUDIO CLASSES & SCHEDULE · DAS FEHLMUSTER
Bei Kiakademie liegt der Stundenplan in einer eingebetteten Anwendung. Bei KayJays wurden Kursinformationen von Hand in Seiten geschrieben. Das Plugin ersetzt beide Muster durch verbundene Datensätze und eigenes Markup.
<div> <iframe src="kursorganizer…"> </iframe> </div> <!-- keine Kursnamen --> <!-- keine Zeiten --> <!-- keine Lehrkräfte --> <!-- keine strukturierten Daten -->
<section aria-label="Stundenplan">
<div>Montag</div>
<span>17:00</span>
<a>Hip-Hop für Kids</a>
<a>Jessy</a>
</section>
<script type="application/ld+json">
{ "@type": "Course" }
</script>Die These
„Lehrkräfte, Kurse und Stundenplan-Informationen sollten nur im Plugin eingetragen werden. Sie sollten niemals manuell auf der Website geschrieben werden.“
Vier verbundene Datentypen—Kurse, Stunden, Trainer:innen und Standorte—speisen Stundenplan, Kursseiten, Trainer:innen-Seiten und Schema aus derselben Quelle. Genau diese gemeinsame Quelle verhindert Abweichungen.
Die Publishing-Schicht unterstützt WordPress-Blöcke und Shortcodes. Avada-Builder-Seiten können keine Blöcke aufnehmen; deshalb war die Kompatibilität mit dem bestehenden Seitensystem Teil der Architektur und kein später Kompromiss.
STUDIO CLASSES & SCHEDULE · DER MECHANISMUS
Vier Datentypen werden einmal gepflegt. Jede öffentliche und interne Oberfläche wird bei der Anfrage daraus erzeugt—deshalb können Stundenplan, Kursseite und strukturierte Daten nicht auseinanderlaufen.
STUDIO CLASSES & SCHEDULE · VERBUNDENES PUBLISHING
Diese Regel gilt für Kurse, Stunden, Trainer:innen und Standorte. Jeder Datensatz ist eine Quelle für mehrere Ausgaben—nicht nur ein Eintrag im Backend. Welche Ausgaben aktiv sind, richtet sich nach der jeweiligen Schule.
Kurskarten · Kursseite · Filter · Course-JSON-LD
Wochenplan · Verfügbarkeit · Anmeldung · CourseInstance
Team-Raster · Profil · verlinkte Namen · Person/instructor
Stundenplan · Kursfakten · Standort-Verweise · Place/PostalAddress
Das Prinzip darunter ist bei allen vier Datentypen dasselbe.
Porträt, Rolle und Profiltext kommen aus Putris Lehrkraft-Datensatz. Die Kursliste darunter kommt aus ihrer aktuellen Zuordnung—es gibt keine zweite Liste, die jemand synchron halten muss.
Öffentliche Darstellungsformen
Eine Schule kann dieselben Stundendatensätze als ausführliche Liste oder kompaktes Wochenraster veröffentlichen. Die Nutzung verändert sich; die Quelle für Kurs, Lehrkraft, Zeit und Verfügbarkeit bleibt dieselbe.
Verfügbarkeit, passende Termine und Anmeldung stehen direkt bei der Stunde, die Besucher:innen gewählt haben.
Dieselben Datensätze werden zu einer kompakten Wochenansicht für Besucher:innen, die zuerst überblicken und vergleichen möchten.
Maschinenlesbares Ergebnis
Ein Stundenplan, der zuvor in einem iFrame oder handgeschriebenem Seitentext lag, wird zu eigenem HTML plus strukturierten Daten auf der Domain der Schule. Daraus wird kein Leistungswert abgeleitet; das Ergebnis ist ein technisch lesbares Publishing-System.
STUDIO CLASSES & SCHEDULE · DIE AUSGABE
Jeder strukturierte Fakt wird zum Zeitpunkt der Anfrage aus den Datensätzen erzeugt und kann deshalb nicht vom sichtbaren Stundenplan abweichen. Beschreibende Texte bleiben bewusst redaktionell verfasst.
{
"@context": "https://schema.org",
"@type": "Course",
"name": "Hip-Hop",
"provider": { "@type": "Organization" },
"hasCourseInstance": [{
"@type": "CourseInstance",
"courseMode": "Onsite",
"courseSchedule": {
"@type": "Schedule",
"startTime": "17:00",
"repeatFrequency": "P1W",
"scheduleTimezone": "Europe/Berlin",
"byDay": "https://schema.org/Monday"
},
"instructor": {
"@type": "Person",
"name": "Jessy"
}
}]
}Ein Knoten pro wöchentlicher Stunde, direkt aus den zugehörigen Datensätzen.
Stundenplan und Schema lesen dasselbe Wochentagsfeld.
Eine benannte Stadt-Zeitzone statt eines fehleranfälligen UTC-Offsets.
Ein Person-Knoten mit dem Profil der Lehrkraft; auch Co-Teaching bleibt abbildbar.
Interface-Studien
Dies sind Gestaltungsstudien aus dem Umsetzungsprozess, keine Screenshots live eingesetzter Kundensysteme. Gemeinsam zeigen sie, wie dieselben Datensätze fokussierte Ansichten für Betreiber:innen, Lehrkräfte und Website-Besucher:innen versorgen.
Verfügbarkeit, Vertretungen, Ausfälle und direkte Änderungen bleiben in dem Kontext, in dem die Studioleitung entscheidet.
Felder folgen den Fragen der Betreiber:innen und zeigen direkt, auf welchen Oberflächen ihr Wert erscheint.
Eingegebene Informationen und aus Unterrichtsbeziehungen berechnete Werte bleiben klar unterscheidbar.
Eine auf den Moment zwischen zwei Stunden zugeschnittene Ansicht statt einer verkleinerten Desktop-Tabelle.
Namen, Profile und Stile stammen aus denselben Beziehungen, die auch den Stundenplan speisen.
Prozess und Governance
Rund ein Dutzend schriftliche Spezifikationen definierten Datensätze, Beziehungen, Publishing-Verhalten und Grenzen vor dem Code.
Jede Spezifikation erhält eine adversariale Planprüfung—auf der Version, die als Nächstes umgesetzt wird, nicht auf einer bereits überholten Fassung.
Eine Prüfung des Spezifikationspakets durch ein zweites Modell ergab acht Hinweise. Sechs waren echte Defekte und wurden vor der weiteren Umsetzung behoben.
Die Plugin-Seite der Website ist die Quelle der Wahrheit. Diese Regel deckte einen Log-Eintrag über einen Upload auf, der nie angekommen war.
Scope-Disziplin
Bewusst zurückgestellt. Distribution ist nicht das nächste Problem, das gelöst werden muss.
Aufgeschoben, bis eine Klasse tatsächlich voll ist und der Bedarf entsteht.
Nur Darstellungsparität. Die Buchung bleibt in dem System, das die Schule bereits nutzt.
Grenze der Belege
In Entwicklung, läuft auf Staging, zwei zugesagte Schulen. Noch ist nichts live; deshalb beansprucht diese Seite keine Auswirkungen auf Traffic, Rankings, Buchungen oder Conversions.
Der Beleg liegt in der Diagnose, der gemeinsamen Datenarchitektur, der maschinenlesbaren Ausgabe, der Prüfdisziplin und den Entscheidungen, die den Build innerhalb seines echten Umfangs hielten.