segert.net segertblog

Zur Sichtbarkeit von Fachwissen, Kompetenzen und Marke in KI-Systemen

2026-06-05T17:35:00+00:00

Unternehmen verfügen häufig über deutlich mehr Fachwissen, Erfahrungen und Kompetenzen, als digital sichtbar werden. Während Suchmaschinen und KI-Systeme bestimmte Produkte, Marken oder Unternehmensnamen oft zuverlässig erkennen, bleiben die eigentlichen Stärken und fachlichen Besonderheiten eines Unternehmens häufig unsichtbar. Dadurch entsteht eine Lücke zwischen dem vorhandenen Wissen eines Unternehmens und der digitalen Wahrnehmung seiner Kompetenzen. Dieser Beitrag zeigt, wie Unternehmen ihre aktuelle Sichtbarkeit analysieren, welche Themen künftig stärker mit ihnen verbunden werden sollten und warum die Website dabei zunehmend die Rolle eines digitalen Wissensraums übernimmt.

Die Art, wie Menschen Informationen suchen, verändert sich grundlegend. Neben klassischen Suchmaschinen spielen KI-Systeme wie ChatGPT, Gemini oder Perplexity eine immer größere Rolle. Nutzer erhalten nicht mehr nur Listen von Suchergebnissen, sondern direkte Antworten, Empfehlungen und Einordnungen. Für Unternehmen entsteht daraus eine neue Herausforderung: Sichtbar sind oft Produkte, Marken oder einzelne Leistungen – deutlich seltener jedoch die Kompetenzen und Erfahrungen, die dahinterstehen.

Wenn Angebote sichtbar sind, aber Expertise nicht

Viele Unternehmen werden über ihre Produkte, Dienstleistungen oder Leistungen gefunden. Wesentlich seltener werden sie über die Erfahrungen, das Fachwissen und die Spezialisierungen wahrgenommen, die diese Angebote erst möglich machen.

Gerade bei spezialisierten Unternehmen zeigt sich häufig ein typisches Muster: Sichtbar sind die Angebote, unsichtbar bleibt die Expertise dahinter. Suchmaschinen und KI-Systeme erkennen Produktnamen, Leistungsbeschreibungen oder technische Merkmale oft zuverlässig. Die Erfahrungen, Methoden, Spezialisierungen und fachlichen Besonderheiten, die ein Unternehmen von anderen Anbietern unterscheiden, werden dagegen deutlich seltener sichtbar.

Vom Fachwissen zur digitalen Wahrnehmung

Meine Arbeit beginnt mit einer Analyse des vorhandenen Wissens, der bestehenden Inhalte und der aktuellen Sichtbarkeit. Dabei geht es nicht nur um die Frage, welche Informationen bereits vorhanden sind, sondern auch darum, welche Themen, Kompetenzen und Erfahrungen heute tatsächlich mit dem Unternehmen verbunden werden.

Ebenso wichtig ist die Frage, welche Wahrnehmung künftig entstehen soll. Für welche Themen soll das Unternehmen stehen? Welche Kompetenzen sollen stärker sichtbar werden? Und welche Erfahrungen oder Spezialisierungen unterscheiden es von anderen Anbietern?

Für diesen Zusammenhang verwende ich den Begriff des digitalen Wissensraums. Gemeint ist eine Website, die nicht nur Informationen veröffentlicht, sondern Fachwissen strukturiert, Zusammenhänge sichtbar macht und Kompetenzen nachvollziehbar vermittelt. So entsteht ein konsistentes Bild für Kunden, Suchmaschinen und KI-Systeme.

Leitfragen

Welche Themen verbinden Suchmaschinen und KI-Systeme bereits mit dem Unternehmen?
Welche Kompetenzen werden heute sichtbar?
Wo bestehen Wahrnehmungs- und Sichtbarkeitslücken?
Für welche Themen soll das Unternehmen künftig stärker wahrgenommen werden?
Welche Erfahrungen und Spezialisierungen unterscheiden es von anderen Anbietern?
Welche Themen sind für Kunden und Märkte besonders relevant?

Von der Analyse zur Umsetzung

Die Antworten auf diese Fragen fallen je nach Unternehmen sehr unterschiedlich aus. Entscheidend sind Branche, Zielgruppen, vorhandene Inhalte, fachliche Schwerpunkte und die strategischen Ziele des Unternehmens.

Wie daraus ein digitaler Wissensraum entstehen kann und welche Rolle dabei Fachartikel, FAQ-Bereiche, thematische Wissensstrukturen, interne Verlinkungen und strukturierte Daten spielen, beschreibe ich im Beitrag KI-Sichtbarkeit und GEO: Die Website als Wissensraum. Dort finden Sie konkrete Praxisbeispiele und typische Ansätze, mit denen Unternehmen ihr vorhandenes Fachwissen für Menschen, Suchmaschinen und KI-Systeme besser nutzbar machen können.

Seit 1997 entwickle ich Websites, Inhalte und digitale Informationsstrukturen für Unternehmen unterschiedlichster Branchen. Darüber hinaus arbeite ich seit rund drei Jahren produktiv mit KI-Systemen in den Bereichen Recherche, Textentwicklung, Programmierung, Wissensaufbereitung, Analyse und Content-Strategie.

Wenn Sie herausfinden möchten, welche Themen, Kompetenzen und Erfahrungen heute bereits mit Ihrem Unternehmen verbunden werden und welche Potenziale noch ungenutzt sind, freue ich mich über Ihre Nachricht an ki@segert.net.

Zur Vertiefung beachten Sie auch meine strukturierte und wachsende FAQ: KI-Sichtbarkeit für Unternehmen

Relevante Grundlagen- und Praxis-Artikel

KI-Sichtbarkeit und GEO: Die Website als Wissensraum

2026-05-20T12:38:00+00:00

Seit geraumer Zeit beschäftige ich mich intensiv mit der Frage, wie KI-Systeme wie ChatGPT, Perplexity oder Google AI die Suche im Internet verändern. Dabei wird immer deutlicher, dass viele Websites strukturell nur unzureichend darauf vorbereitet sind. Dieser Artikel beschäftigt sich deshalb nicht mit KI-Hype oder schnellen SEO-Tricks, sondern mit der Frage, wie Websites verständlicher, strukturierter und langfristig sinnvoller als Wissensräume aufgebaut werden können — für Menschen, Suchmaschinen und zunehmend auch für KI-Systeme.

1. Warum sich Suche gerade verändert

Immer häufiger werden heute nicht mehr nur einzelne Suchbegriffe eingegeben, sondern vollständige Fragen gestellt.

Zum Beispiel:

Was mache ich zuerst bei einer Abmahnung wegen Datenschutz?
Wie funktioniert Kurzzeitpflege und welche Rolle spielt der Pflegegrad?
Was kann ich tun, wenn mein Arbeitgeber keine Abfindung zahlen will?
Welche Lautsprecher passen zu kleinen Räumen?
Was ist eine berufliche Wiedereingliederung mit Bildungsgutschein?
Wer bietet besonders kompakte Bohreinheiten für industrielle Anwendungen an?

Mit solchen Fragen verändert sich auch die Erwartung an Websites. Gesucht werden nicht mehr nur Anbieter oder Produkte, sondern Orientierung, Einordnung und verständliche Informationen.

Gerade deshalb wird zunehmend wichtig, wie logisch, konsistent und technisch nachvollziehbar Inhalte aufgebaut sind.

2. Die Website als Wissensraum

Ich verwende bewusst den Begriff „Wissensraum“, weil moderne Websites aus meiner Sicht zunehmend mehr sein müssen als reine digitale Broschüren oder lose Sammlungen einzelner Unterseiten.

Meine erste Begegnung mit diesem Gedanken hatte ich bereits Mitte der 1990er-Jahre, als ich begann, mich intensiver mit dem World Wide Web zu beschäftigen. Damals war Tim Berners-Lee, der Erfinder des Webs, für viele von uns eine prägende Figur. Seine ursprüngliche Vision ging weit über das Veröffentlichen einzelner Dokumente hinaus: Das Web sollte ein offener, vernetzter Informations- und Wissensraum sein, in dem Inhalte miteinander in Beziehung stehen und Wissen über Verknüpfungen erschlossen werden kann.

Bereits in seinen frühen Konzepten beschrieb Berners-Lee das World Wide Web als einen universellen „Information Space“, also einen gemeinsamen Raum für Wissen, Informationen und Zusammenhänge. Genau dieser Gedanke gewinnt heute im Zeitalter von Suchmaschinen, Wissensgraphen und KI-Systemen erneut an Bedeutung. Webseiten werden zunehmend nicht mehr nur gelesen, sondern als strukturierte Wissensquellen interpretiert und in größere Zusammenhänge eingeordnet.

Viele Websites enthalten bereits relevantes (Fach-)Wissen:

Häufige Kundenfragen: Konkrete Fragen aus Beratungsgesprächen oder Supportanfragen, die systematisch beantwortet und miteinander verknüpft werden.
Technische Problemlösungen: Praxisnahe Erklärungen zu typischen Fehlerquellen, Anwendungen, Sonderfällen oder technischen Zusammenhängen.
Erfahrungswissen aus Projekten: Erkenntnisse, die aus jahrelanger praktischer Arbeit, realen Kundenprojekten und konkreten Anforderungen entstanden sind.
Fachliche Entscheidungsgrundlagen: Inhalte, die Kunden helfen, technische, rechtliche oder organisatorische Entscheidungen besser einzuordnen.
Prozess- und Ablaufwissen: Verständliche Beschreibungen typischer Abläufe, Arbeitsschritte oder Verfahren innerhalb eines Fachgebiets oder Unternehmens.

Häufig liegen diese Informationen jedoch verstreut, sprachlich unnötig kompliziert oder thematisch unscharf vor. Dadurch entstehen oft unübersichtliche Informationsbereiche mit wenig klaren thematischen Zusammenhängen. Ein sinnvoll aufgebauter Wissensraum versucht deshalb:

Informationen logisch gliedern: Inhalte so strukturieren, dass Themen nachvollziehbar aufgebaut sind und Nutzer wie KI-Systeme Zusammenhänge leichter erkennen können.
Themen klar voneinander trennen: Unterschiedliche Fachbereiche, Leistungen oder Fragestellungen sauber voneinander abgrenzen, statt viele Inhalte unsortiert auf einer Seite zu vermischen.
Inhalte sinnvoll zu hierarchisieren: Oberthemen, Unterthemen und Detailinformationen in eine verständliche Reihenfolge bringen.
Wichtige Begriffe verständlich erklären: Fachbegriffe nicht einfach voraussetzen, sondern ihre Bedeutung nachvollziehbar erläutern und in den richtigen Kontext einordnen.
Zusammenhänge sichtbar machen: Verwandte Inhalte durch sinnvolle interne Verlinkungen, weiterführende Fachartikel oder ergänzende Informationen miteinander vernetzen.

3. KI-Sichtbarkeit: Was damit realistisch gemeint ist

Ich verwende den Begriff „KI-Sichtbarkeit“ bewusst vorsichtig. Niemand kann seriös garantieren, dass eine Website künftig in ChatGPT, Perplexity oder Google AI Overviews prominent erscheint. Wer solche Garantien verkauft, arbeitet unseriös.

Was man jedoch sehr wohl tun kann:

Inhalte verständlicher strukturieren
reale Nutzerfragen nachvollziehbar beantworten
Themenbereiche logisch aufbauen
interne Verknüpfungen verbessern
strukturierte Daten sinnvoll einsetzen
semantisch sauberes HTML verwenden
Barrierefreiheit verbessern
Lesbarkeit und Orientierung erhöhen

All das verbessert nicht automatisch Rankings oder KI-Erwähnungen. Es verbessert jedoch die technische und inhaltliche Ausgangslage erheblich — für Nutzer, Suchmaschinen und zunehmend auch für KI-Systeme.

4. Drei Praxisbeispiele

1. Pflegebereich

Viele Pflege- oder Seniorenheim-Websites enthalten bereits Informationen zu Pflegeleistungen, Betreuung, Pflegegraden, Kurzzeitpflege oder organisatorischen Abläufen. Gleichzeitig wirken viele dieser Inhalte für Angehörige oder Interessenten schwer überschaubar.

Oft werden innerhalb einzelner Texte sehr unterschiedliche Themen vermischt. Dazu gehören etwa Pflegeleitbild, Betreuung, Pflegeprozess, Dokumentation, Qualitätsmanagement, Ansprechpartner oder organisatorische Informationen auf derselben Seite oder sogar im selben Absatz.

Dadurch entstehen oft zu allgemeine Texte, bei denen unklar bleibt, worum es konkret geht.

Ein sinnvoll strukturierter Wissensbereich könnte solche Themen deshalb deutlicher voneinander trennen:

Pflegeleitbild
Wie versteht die Einrichtung gute Pflege und Betreuung?

Pflegeplanung und Betreuung
Wie wird der individuelle Pflegebedarf erfasst und dokumentiert?

Kurzzeitpflege und Pflegegrade
Welche Leistungen gibt es und welche Unterschiede bestehen?

Wichtige Begriffe verständlich erklärt
Was bedeuten Fachbegriffe wie „SIS“ oder „strukturierte Informationssammlung“?

So entstehen keine künstlichen „KI-Texte“, sondern verständlichere und klarer strukturierte Informationsbereiche.

2. Kanzleien und juristische Dienstleistungen

Nicht wenige Kanzlei-Websites besitzen bereits Fachartikel, Urteile, Hinweise zu Gesetzesänderungen oder Informationen zu einzelnen Rechtsgebieten.

Gerade bei mehreren Fachbereichen entsteht dabei jedoch oft ein Nebeneinander einzelner Informationen. Typische Fragen, konkrete Alltagssituationen oder thematische Zusammenhänge werden dabei nicht immer klar strukturiert aufgegriffen.

Ein sinnvoll aufgebauter Wissensraum könnte stattdessen typische Nutzerfragen stärker in den Mittelpunkt stellen:

Arbeitsrecht
Was passiert nach einer Kündigung?
Wann lohnt sich eine Kündigungsschutzklage?
Was sollte ich nach einer Abmahnung tun?

Erbrecht
Wann entsteht ein Pflichtteilsanspruch?
Was passiert ohne Testament?

Mietrecht
Wann darf die Miete erhöht werden?
Welche Rechte habe ich bei Wohnungsmängeln?

Dadurch entstehen langfristig klar gegliederte Wissensbereiche mit nachvollziehbaren Beziehungen zwischen Fachgebieten, konkreten Problemen und typischen Nutzerfragen.

3. Technische Hersteller

Gerade technische Anbieter besitzen häufig Fachwissen zu technischen Grundlagen, Anwendungsszenarien, technischen Daten oder Testberichten. Dieses Wissen verteilt sich jedoch oft über viele Unterseiten, ältere Inhalte oder Dokumente.

Ein gutes Beispiel dafür sind spezialisierte HiFi- oder Audiotechnik-Websites. Dort existieren oft Inhalte zu technischen Grundlagen, besonderen Entwicklungsansätzen, historischen Hintergründen, technischen Daten oder Testberichten. Gleichzeitig bleibt dieses Wissen für Außenstehende häufig schwer erfassbar, weil Informationen über viele Unterseiten verteilt sind und konkrete Fragen kaum auffindbar beantwortet werden.

So entsteht eine Website mit großem Fachwissen, die jedoch nur begrenzt Orientierung bietet. Ein sinnvoll strukturierter Wissensraum könnte hier beispielsweise unterscheiden zwischen:

Grundlagen und Technologie
Wie funktioniert eine bestimmte Lautsprechertechnologie überhaupt?
Was unterscheidet sie von klassischen Systemen?
Warum spielt beispielsweise das Impulsverhalten eine wichtige Rolle?

Produkte und Einsatzbereiche
Welche Lautsprecher eignen sich für kleine Räume?
Welche Verstärker passen zu welchem System?
Welche Unterschiede bestehen zwischen einzelnen Modellen?

Historie und Entwicklerwissen
Wie entstand die Technologie ursprünglich?
Welche technischen Probleme sollten gelöst werden?
Welche Entwicklungsphilosophie steckt dahinter?

Verwandte Inhalte und weiterführende Informationen
FAQ-Bereiche, technische Artikel, Testberichte, Anwendungserklärungen oder Informationen zu passenden Verstärkern könnten logisch miteinander verknüpft werden, statt isoliert nebeneinander zu stehen.

5. Warum die technische Struktur für KI-Sichtbarkeit wichtig ist

In der praktischen Arbeit zeigt sich immer wieder, dass eine sinnvolle Inhaltsstruktur langfristig nur funktioniert, wenn auch die technische Grundlage dafür sauber aufgebaut ist. Moderne CMS-Systeme sollten deshalb nicht nur Seitenlayouts verwalten, sondern Inhalte flexibel strukturieren, logisch miteinander verknüpfen und technisch sauber ausgeben können.

Gerade im Zusammenhang mit KI-Systemen werden dabei strukturierte Daten zunehmend wichtiger. Gemeint sind zusätzliche Informationen im Quellcode einer Website, häufig auf Basis von JSON-LD, mit denen Inhalte technisch genauer beschrieben werden können.

So lässt sich klarer auszeichnen, ob es sich um einen Fachartikel, eine FAQ, eine Person, ein Unternehmen, ein Produkt oder eine konkrete Frage mit Antwort handelt. Suchmaschinen und KI-Systeme können Inhalte dadurch häufig besser einordnen und Zusammenhänge leichter erkennen.

Entscheidend ist dabei jedoch, dass solche strukturierten Daten nicht manuell doppelt gepflegt werden müssen. Sinnvoll wird das erst dann, wenn sich diese Informationen automatisch aus bereits vorhandenen Inhalten generieren lassen. Genau deshalb spielt die Wahl des passenden Content-Management-Systems eine zentrale Rolle.

Flexible CMS-Systeme wie ExpressionEngine besitzen aus meiner Sicht entscheidende Vorteile. Inhalte lassen sich damit frei modellieren und unabhängig vom eigentlichen Layout strukturieren. Dadurch können differenzierte Inhaltsstrukturen mit eigenen Feldern, Beziehungen, Kategorien und thematischen Verknüpfungen aufgebaut werden, statt Inhalte nur starr in klassische Seitenstrukturen zu pressen.

Hinzu kommen leistungsfähige Feldtypen, mit denen sich komplexere Inhaltsbereiche sauber organisieren lassen, etwa FAQ-Strukturen, technische Daten, mehrsprachige Inhalte oder wiederverwendbare Inhaltselemente. Gleichzeitig bleibt die technische Ausgabe vollständig kontrollierbar — von semantischem HTML über interne Verlinkungen bis hin zur automatisierten Ausgabe strukturierter Daten.

Gerade bei größeren oder inhaltlich anspruchsvolleren Websites entsteht dadurch eine konsistentere und langfristig besser pflegbare Inhaltsstruktur.

Relevante Artikel

Quellen und weiterführende Informationen

Google Einführung strukturierte Daten
https://developers.google.com/...
Schema.org Documentation
https://schema.org/docs/docume...
W3C – Semantische Seitenstruktur
https://www.w3.org/WAI/tutoria...
Mozilla Developer Network – Semantic HTML
https://developer.mozilla.org/...
Search Engine Journal – Generative Engine Optimization (GEO)
https://www.searchenginejourna...

Über Ralph Segert

Ich beschäftige mich seit den frühen Jahren des Webs mit Websites, digitalen Inhalten und Informationsstrukturen. Seit 1997 entwickle und betreue ich Internetauftritte für Unternehmen, Organisationen und Selbstständige aus unterschiedlichen Branchen.

In dieser Zeit sind nicht nur zahlreiche Websites entstanden, sondern auch Fachartikel, Blogbeiträge, Produkttexte, Dokumentationen und digitale Wissensbereiche. Dabei ging es immer um dieselbe Frage: Wie lassen sich Informationen so strukturieren, dass Menschen sie finden, verstehen und nutzen können?

Heute verbindet sich diese langjährige Praxiserfahrung mit den neuen Anforderungen von Suchmaschinen und KI-Systemen. Mein Schwerpunkt liegt auf der Analyse von Themenfeldern, Wissensstrukturen und digitaler Sichtbarkeit – immer mit dem Blick eines Praktikers, der Websites, Inhalte und digitale Projekte seit vielen Jahren begleitet und selbst umsetzt.

Konzeptionelles und individuelles Webdesign ohne Page Builder wie Elementor, DIVI und Co

2024-10-10T07:48:00+00:00

Der Beitrag erklärt, warum konzeptionelles und individuell entwickeltes Webdesign auch in Zeiten von Page Buildern wie Elementor oder DIVI wichtig bleibt. Im Mittelpunkt stehen nicht nur Gestaltung und Technik, sondern vor allem semantische Inhaltsstrukturen, Barrierefreiheit, langfristige Wartbarkeit und die zunehmende Bedeutung der KI-Sichtbarkeit. — Überarbeitete Fassung (Juni 2026): Der Beitrag wurde grundlegend aktualisiert und um die Themen semantische Inhaltsstrukturen, Wartbarkeit, Barrierefreiheit und KI-Sichtbarkeit ergänzt.

Als Webdesigner begegne ich seit vielen Jahren Projekten, bei denen für „individuelles Webdesign“ erhebliche Summen berechnet wurden, obwohl die Umsetzung im Kern auf WordPress, Page Buildern und angepassten Standardvorlagen basierte. Daran ist zunächst nichts auszusetzen. Page Builder haben ihre Berechtigung und ermöglichen vielen Unternehmen einen vergleichsweise schnellen und kostengünstigen Einstieg ins Web.

Für jemanden wie mich, der seit über 27 Jahren Websites konzipiert, gestaltet und entwickelt, ergibt sich daraus jedoch eine besondere Situation: Mit rein vorlagenbasierten Lösungen kann und möchte ich weder preislich noch zeitlich konkurrieren.

Dieser Beitrag richtet sich deshalb an Auftraggeber, die verstehen möchten, wo die Stärken von Page Buildern liegen, wo ihre Grenzen beginnen und warum konzeptionell entwickelte Websites einen anderen Anspruch verfolgen.

Gutes Webdesign ist mehr als Gestaltung

Gutes Webdesign ist weit mehr als die Gestaltung einzelner Seiten. Es verbindet Design, Benutzerführung, technische Qualität, Performance, Barrierefreiheit und langfristige Wartbarkeit zu einem Gesamtkonzept.

Während früher häufig ein Grafikprogramm und ein Code-Editor ausreichten, bestimmen heute zunehmend visuelle Baukastensysteme den Markt. Werkzeuge wie Elementor, DIVI oder ähnliche Systeme ermöglichen auch weniger erfahrenen Anwendern ansprechende Ergebnisse und haben die Qualität vieler Websites zweifellos verbessert.

Gerade bei kleineren Projekten oder begrenzten Budgets können solche Lösungen sinnvoll sein. Dennoch stellt sich die Frage, welche Auswirkungen diese Entwicklung auf Individualität, technische Qualität und Zukunftsfähigkeit von Websites hat.

Die Vorteile von Page Buildern

Page Builder bieten eine komfortable visuelle Oberfläche, über die sich Layouts ohne Programmierkenntnisse erstellen und verändern lassen.

Zu den wichtigsten Vorteilen gehören:

schnelle Umsetzung vieler Standardanforderungen
große Auswahl vorgefertigter Layouts und Komponenten
einfache Anpassung von Farben, Typografie und Abständen
vergleichsweise geringe Einstiegskosten
kurze Entwicklungszeiten bei kleineren Projekten

Für viele Unternehmen sind diese Vorteile absolut nachvollziehbar und wirtschaftlich sinnvoll.

Die Grenzen von Page Buildern

Die Stärken von Page Buildern sind zugleich häufig ihre größten Schwächen. Viele Systeme erzeugen umfangreichen und teilweise redundanten Code. Dies kann sich negativ auf Performance, Wartbarkeit und technische Qualität auswirken.

Hinzu kommt, dass die vermeintliche Gestaltungsfreiheit oft innerhalb eines vorgegebenen Rahmens stattfindet. Individuelle Anforderungen lassen sich zwar häufig umsetzen, erfordern aber zusätzliche Erweiterungen, individuelle Anpassungen oder technische Umwege.

Auch die langfristige Abhängigkeit vom jeweiligen System sollte nicht unterschätzt werden. Inhalte, Layout und Funktionen sind oft eng miteinander verknüpft. Ein späterer Wechsel kann daher erheblichen Aufwand verursachen.

Darüber hinaus führt die weite Verbreitung standardisierter Systeme zwangsläufig zu einer zunehmenden Vereinheitlichung vieler Websites. Navigationen, Inhaltsstrukturen und Interaktionsmuster ähneln sich häufig so stark, dass echte Wiedererkennbarkeit verloren geht.

Die Freiheit konzeptionellen Webdesigns

Konzeptionelles Webdesign beginnt nicht mit einem Layout, sondern mit Fragen.

Wie informieren sich die Nutzer?
Welche Ziele verfolgt das Unternehmen?
Welche Inhalte stehen im Mittelpunkt?
Wie können Informationen verständlich strukturiert werden?

Erst aus diesen Überlegungen entstehen Gestaltung, Benutzerführung und technische Architektur. Das Design folgt dabei nicht den Möglichkeiten eines Systems, sondern den Anforderungen des Projekts. Benutzerfreundlichkeit, Barrierefreiheit und technische Qualität werden nicht nachträglich ergänzt, sondern von Beginn an berücksichtigt.

Das Ergebnis ist keine Sammlung einzelner Seiten, sondern ein durchdachtes Gesamtsystem.

Warum individuelle Entwicklung langfristig Vorteile bietet

Eine individuell entwickelte Website bietet häufig Vorteile, die erst im Laufe der Zeit sichtbar werden:

höherer Wiedererkennungswert
bessere Differenzierung gegenüber Wettbewerbern
gezielte Benutzerführung
flexible Erweiterbarkeit
bessere technische Kontrolle
höhere Performance
geringere Abhängigkeit von Drittanbietern
bessere Voraussetzungen für Barrierefreiheit
langfristig stabilere Inhaltsstrukturen

Insbesondere bei komplexeren Projekten spielt auch die Wahl des Content-Management-Systems eine wichtige Rolle. Systeme wie ExpressionEngine ermöglichen beispielsweise eine sehr präzise Modellierung von Inhalten und Strukturen, ohne dabei Gestaltung und Inhalt unnötig miteinander zu vermischen.

SEO, Barrierefreiheit und KI-Sichtbarkeit

In den vergangenen Jahren wurde häufig über Suchmaschinenoptimierung gesprochen. Heute kommt ein weiterer Faktor hinzu: die Sichtbarkeit in KI-Systemen. Suchmaschinen, KI-Assistenten und intelligente Suchsysteme bewerten Inhalte zunehmend nicht nur anhand einzelner Schlüsselwörter. Immer wichtiger werden Zusammenhänge, semantische Strukturen und die Verständlichkeit von Informationen.

Eine Website profitiert deshalb von:

klaren Überschriftenhierarchien
sauber strukturierten Inhalten
semantischem HTML
nachvollziehbaren Inhaltsbeziehungen
konsistenten Datenstrukturen
einer verständlichen Informationsarchitektur

Diese Faktoren verbessern nicht nur die Auffindbarkeit in Suchmaschinen. Sie erleichtern auch die barrierefreie Nutzung und schaffen bessere Voraussetzungen dafür, dass KI-Systeme Inhalte korrekt erfassen und einordnen können.

Struktur schlägt Gestaltung

Rückblickend haben sich viele Unternehmen möglicherweise selbst unnötige Hürden geschaffen. Denn heute wird oft erheblicher Aufwand investiert, um nachträglich jene semantischen Strukturen, Inhaltsbeziehungen und Wartungsvorteile zu erreichen, die bei einer konzeptionell entwickelten Website von Anfang an vorgesehen werden können.

Die entscheidende Frage lautet deshalb nicht mehr nur, wie eine Website aussieht. Immer wichtiger wird, wie verständlich, strukturiert und langfristig nutzbar ihre Inhalte aufgebaut sind.

Überwiegt der Preisnachteil?

Eine individuell entwickelte Website verursacht in der Regel höhere Anfangskosten als eine auf Vorlagen basierende Lösung. Die Betrachtung sollte jedoch nicht beim ersten Angebot enden. Entscheidend sind die Gesamtkosten über mehrere Jahre hinweg.

Wer langfristig denkt, profitiert häufig von:

geringeren Anpassungskosten
besserer Skalierbarkeit
höherer technischer Kontrolle
weniger Systemabhängigkeiten
stabileren Inhaltsstrukturen
nachhaltigerer Weiterentwicklung

Die höhere Anfangsinvestition steht somit einer Lösung gegenüber, die oft über viele Jahre hinweg tragfähig bleibt.

Fazit

Page Builder sind sinnvolle Werkzeuge und haben ihren festen Platz im modernen Webdesign. Für viele kleinere Projekte sind sie eine wirtschaftliche und praktikable Lösung.

Wer jedoch Wert auf Individualität, technische Qualität, langfristige Wartbarkeit, Barrierefreiheit und eine zukunftsfähige Inhaltsstruktur legt, sollte auch den konzeptionellen Ansatz in Betracht ziehen.

Denn nachhaltiges Webdesign entsteht nicht allein durch Gestaltung. Es entsteht durch das Zusammenspiel von Konzept, Struktur, Technik und Inhalt.

Mit ExpressionEngine effektiv und pflegeleicht strukturierte Daten entwickeln

2026-07-06T07:47:00+00:00

Strukturierte Daten entfalten ihren größten Nutzen, wenn sie die Informationsarchitektur einer Website widerspiegeln. Dieser Praxisbericht zeigt anhand einer Website für ein Seniorenheim, wie mit ExpressionEngine eine durchgängige JSON-LD-Strategie entwickelt wurde. Ausgangspunkt ist die Startseite. Sie beschreibt nicht nur die Einrichtung, sondern bildet gleichzeitig die semantische Grundlage für sämtliche Themenbereiche und Fachartikel.

Die Startseite als Ausgangspunkt der gesamten JSON-LD-Architektur

Im Rahmen eines Kundenprojekts entstand eine neue Website für ein Seniorenheim. Die Inhalte wurden bewusst nicht als lose Einzelseiten aufgebaut, sondern in klar voneinander abgegrenzte Wissensbereiche gegliedert. Dazu gehören unter anderem:

Pflege und Betreuung
Wohnen und Leben
Qualität und Transparenz
Kosten und Finanzierung
Essen auf Rädern
Jobs und Ehrenamt

Jeder dieser Bereiche besitzt eine eigene Übersichtsseite sowie mehrere Artikel. Ergänzt wird die Website durch aktuelle Meldungen, Termine und Videointerviews. Schon während der Konzeption wurde deutlich, dass eine einzige JSON-LD-Struktur diesem Aufbau nicht gerecht werden würde. Die einzelnen Seitentypen erfüllen unterschiedliche Aufgaben und benötigen deshalb auch unterschiedliche strukturierte Daten. Es entstanden drei Ebenen.

Die Startseite beschreibt die Einrichtung und bildet den Einstieg in die gesamte Website.
Die Themenübersichten erschließen jeweils einen kompletten Informationsbereich.
Die Artikel beantworten eine konkrete Fragestellung.

Diese Unterscheidung bildet die Grundlage der gesamten JSON-LD-Struktur.

Warum die Entwicklung mit der Startseite beginnt

Die Entwicklung beginnt bewusst mit der Startseite. Sie beschreibt nicht nur das Seniorenheim, sondern führt gleichzeitig in die wichtigsten Inhalte der Website ein. Besucher finden hier den Einstieg in die zentralen Wissensbereiche, aktuelle Meldungen, zusätzliche Angebote und Videointerviews.

Diese Inhalte erfüllen unterschiedliche Aufgaben. Die wichtigsten Informationen führen in die einzelnen Wissensbereiche. Aktuelle Meldungen zeigen neue Entwicklungen. Angebote verweisen auf eigenständige Leistungsbereiche. Videos ergänzen die Website um einen weiteren Inhaltstyp.

Die Startseite bildet damit bereits die Informationsarchitektur der gesamten Website ab. Genau diese Struktur sollte sich auch in den strukturierten Daten widerspiegeln. Erst auf dieser Grundlage entstehen anschließend die JSON-LD-Ausgaben für Themenübersichten und Fachartikel.

Die erste Überlegung

Der erste Schritt bestand darin, das Seniorenheim selbst eindeutig zu beschreiben. Dafür fiel die Wahl bewusst auf den Schema.org-Typ NursingHome. Dadurch wird nicht nur eine Website beschrieben, sondern die Einrichtung als eigenständige Entität.

Zu dieser Beschreibung gehören unter anderem:

Name der Einrichtung
Logo
Anschrift
Telefonnummer
E-Mail-Adresse

Diese Informationen bilden den gemeinsamen Kern der gesamten JSON-LD-Architektur.

Anschließend wird die Website selbst als WebSite beschrieben und direkt mit dem Seniorenheim verknüpft. Dadurch entstehen zwei klar voneinander getrennte, aber miteinander verbundene Ebenen.

Die Einrichtung beschreibt den realen Ort.
Die Website beschreibt den digitalen Auftritt.

Diese Informationen werden anschließend auf allen weiteren Seiten wiederverwendet und bilden den gemeinsamen Kontext für sämtliche Themenübersichten und Themenartikel. Dadurch müssen die grundlegenden Angaben zum Unternehmen nicht bei jeder JSON-LD-Ausgabe erneut definiert werden.

Der erste JSON-LD-Block

Der erste Schritt der Umsetzung besteht deshalb ausschließlich aus der Beschreibung der Einrichtung und der Website.

Der eigentliche Zweck dieser Struktur

Das Seniorenheim wird als eigenständige Entität beschrieben und direkt mit der Website verknüpft. Diese grundlegenden Informationen stehen anschließend allen weiteren JSON-LD-Ausgaben als gemeinsamer Kontext zur Verfügung und müssen nicht auf jeder Seite erneut definiert werden.

Damit war die technische Grundlage geschaffen. Eine Frage blieb jedoch offen: Reicht es aus, auf der Startseite nur die Einrichtung und die Website zu beschreiben? Nein. Die Startseite ist zugleich der Einstieg in die wichtigsten Themenbereiche der Website. Deshalb entstand ein zweiter JSON-LD-Block, der die Startseite zusätzlich als CollectionPage mit mehreren ItemList beschreibt. Genau darum geht es in der Folge.

Die Startseite als CollectionPage mit Grid-Feldern: Warum die Startseite mehr leisten muss

Von NursingHome zur CollectionPage

Mit NursingHome und WebSite waren die grundlegenden Informationen beschrieben. Es fehlte jedoch noch die eigentliche Funktion der Startseite. Sie erschließt die wichtigsten Wissensbereiche, Angebote, aktuellen Meldungen und Videos. Deshalb wurde sie zusätzlich als CollectionPage mit mehreren ItemList modelliert.

Der Aufbau in ExpressionEngine

Die Startseite wird in ExpressionEngine über den Channel startseite gepflegt. Die einzelnen Bereiche der Startseite sind dabei eigene Einträge innerhalb dieses Channels (siehe dazu meinen Praxisbericht: Eine flexible und pflegeleichte Startseite mit ExpressionEngine). Für die wiederholbaren Inhalte werden Grid-Felder verwendet. Das ist entscheidend, weil dieselben Inhalte dadurch sowohl im sichtbaren HTML als auch im JSON-LD wiederverwendet werden können. Die wichtigsten Felder sind:

slider für die Bühnenbilder

cards für Kacheln, Links, Bilder und Videos

cards:thema für den Titel der Kachel

cards:link für die Zielseite

cards:file für Bild oder Video

cards:alttext für Alternativtexte

cards:bildtext_fuer_screenreader für zugänglichere Videobeschreibungen.

Damit wird die Startseite nicht doppelt gepflegt. Die Inhalte liegen einmal im CMS und werden an verschiedenen Stellen ausgegeben.

Das sichtbare Template der Startseite

{preload_replace:channels="startseite"}
{layout="DRY/_header-footer"}

{exp:channel:entries channel="startseite" url_title="pflege-mit-herz" limit="1"}

  
    {slider}
      
    {/slider}
  
  
    {title}
    Jetzt bewerben
  

{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="wichtige-informationen" limit="1"}

  {title}
  
    {cards}
      
        
        {cards:thema}
      
    {/cards}
  

{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="angebote" limit="1"}

  {title}
  
    {cards}
      
        
        {cards:thema}
      
    {/cards}
  

{/exp:channel:entries}

  Aktuelles
  
    {exp:channel:entries channel="aktuelles" dynamic="no" limit="2" orderby="date" sort="desc"}
      
        {if teaserbild}
          
        {/if}
        {title}
      
    {/exp:channel:entries}
  

{exp:channel:entries channel="startseite" url_title="videos" limit="1"}

  {title}
  
    {cards}
      
        
          
        
      
    {/cards}
  

{/exp:channel:entries}

Aus dem sichtbaren Aufbau wird JSON-LD

Der entscheidende Punkt ist nun: Die strukturierte Ausgabe folgt exakt dem sichtbaren Aufbau der Startseite. Die Kacheln im Bereich „Die wichtigsten Informationen im Überblick“ werden als ItemList ausgegeben. Dasselbe gilt für Angebote, aktuelle Meldungen und Videos. Die Inhalte kommen dabei nicht aus einem zweiten System, sondern aus denselben ExpressionEngine-Feldern. So entsteht eine saubere Verbindung zwischen redaktioneller Pflege, sichtbarem Frontend und strukturierter Datenausgabe.

Der JSON-LD-Code für die Startseite

{if segment_1 == ""}

{/if}

Warum diese Lösung sauber ist

Die Startseite wird nicht künstlich mit strukturierten Daten angereichert. Sie wird so beschrieben, wie sie tatsächlich aufgebaut ist. Die sichtbaren Kachelbereiche werden zu ItemList. Die einzelnen Kacheln werden zu ListItem. Die Videos werden nicht wie normale Links behandelt, sondern als VideoObject ausgegeben. Aktuelle Meldungen kommen direkt aus dem Channel aktuelles.

Dadurch entsteht kein zusätzliches Pflegeproblem. Die Redakteure pflegen weiterhin die Startseite in ExpressionEngine. Die JSON-LD-Ausgabe nutzt dieselben Inhalte und übersetzt sie in eine maschinenlesbare Struktur. Auch hier zeigt sich die Stärke von ExpressionEngine. Grid-Felder, Channel-Einträge und Templates greifen sauber ineinander. Inhalte werden einmal gepflegt und können trotzdem an mehreren Stellen sinnvoll ausgegeben werden. Die Startseite wird damit nicht nur visuell zum Einstieg in die Website. Sie wird auch semantisch zum Einstieg in den gesamten Informationsbereich. Genau daran schließen im nächsten Schritt die Themenübersichten an.

Themenübersichten mit CollectionPage und ItemList: Von mehreren Templates zu einer zentralen Lösung

Nachdem die Startseite die semantische Grundlage der Website geschaffen hatte, ging es an die Themenübersichten. Für jeden Wissensbereich sollte eine eigene CollectionPage mit den dazugehörigen Fachartikeln ausgegeben werden.Der erste Lösungsansatz lag nahe: Für jeden Hauptbereich einen eigenen JSON-LD-Block anzulegen. Technisch wäre das problemlos möglich gewesen. Praktisch hätte dies jedoch bedeutet, dass nahezu derselbe Code siebenmal im Template vorhanden gewesen wäre. Unterschieden hätten sich im Wesentlichen nur zwei Angaben:

der Channel
Name und Beschreibung des jeweiligen Themenbereichs

Alle übrigen Bestandteile wären identisch geblieben. Gerade solche Redundanzen führen im Laufe eines Projekts häufig zu Problemen. Wird später eine Eigenschaft ergänzt oder geändert, muss dieselbe Anpassung an mehreren Stellen vorgenommen werden. Mit jeder Erweiterung steigt die Gefahr, dass einzelne Templates unübersichtlich werden. Mein Ziel war deshalb von Anfang Eine JSON-LD-Struktur, die alle Themenbereiche verarbeitet.

Der entscheidende Perspektivwechsel

Zunächst stand die Frage im Mittelpunkt, welcher Channel jeweils geladen werden muss. Im Laufe der Entwicklung wurde jedoch deutlich, dass dies gar nicht die eigentliche Aufgabe ist. Entscheidend ist vielmehr, in welchem Bereich der Website sich der Besucher gerade befindet. Die URL liefert diese Information bereits.

/pflege/info/pflegeberatung

Daraus ergeben sich unmittelbar die wichtigsten Informationen:

pflege
info
pflegeberatung

Nicht der Channel bestimmt also den Kontext der Seite, sondern die URL. Diese kleine Veränderung der Denkweise machte es möglich, sämtliche Themenübersichten mit nur einem einzigen Template abzubilden.

Die URL übernimmt das Routing

Bevor ExpressionEngine den passenden Channel laden kann, wird zunächst geprüft, ob sich die aktuelle Seite überhaupt innerhalb eines der vorgesehenen Hauptbereiche befindet.Erst wenn diese Voraussetzung erfüllt ist, übernimmt segment_1 automatisch den richtigen Channel. Dadurch reagiert das Template ausschließlich auf die gewünschten Themenübersichten und bleibt gleichzeitig flexibel für alle Bereiche. Der Einstieg sieht deshalb folgendermaßen aus.

{if segment_2 == "info"}
{if segment_1 == "pflege"
OR segment_1 == "qualitaet"
OR segment_1 == "wohnen"
OR segment_1 == "essen"
OR segment_1 == "kosten"
OR segment_1 == "jobs"
OR segment_1 == "ueberuns"}

Der eigentliche Channel muss anschließend nicht mehr fest hinterlegt werden.

channel="{segment_1}"

Damit genügt ein einziges Template für sämtliche Wissensbereiche.

Der vollständige Template-Code

{if segment_2 == "info"}
{if segment_1 == "pflege"
OR segment_1 == "qualitaet"
OR segment_1 == "wohnen"
OR segment_1 == "essen"
OR segment_1 == "kosten"
OR segment_1 == "jobs"
OR segment_1 == "ueberuns"}

{/if}
{/if}

Warum die CollectionPage eine Beschreibung erhält

Nachdem die technische Umsetzung funktionierte, stellte sich eine weitere Frage: Reichen Titel und URL aus, um einen Themenbereich sinnvoll zu beschreiben? Formal wäre das ausreichend gewesen. Inhaltlich blieb jedoch viel Potenzial ungenutzt.

Deshalb erhielt nicht nur jedes Listenelement eine Beschreibung über das vorhandene Teaser-Feld. Auch die CollectionPage selbst bekam eine eigene description. Dadurch beschreiben die strukturierten Daten nicht mehr nur eine Sammlung von Links, sondern den gesamten Themenbereich und seine inhaltliche Ausrichtung.

Der zusätzliche Pflegeaufwand war gleich null. Alle Informationen waren bereits im CMS eingepflegt und mussten lediglich an der passenden Stelle erneut ausgegeben werden.

In der Folge wird dieses Prinzip auf die einzelnen Artikel übertragen. Auch dort entsteht mit derselben Template-Strategie eine zentrale JSON-LD-Ausgabe – ohne redundanten Code.

Die gleiche Strategie für alle Artikel

Nachdem die Themenübersichten umgesetzt waren, wurde derselbe Gedanke auf die einzelnen Fachartikel übertragen. Auch hier sollte möglichst wenig redundanter Template-Code entstehen.Die Lösung folgt deshalb demselben Prinzip wie zuvor. Zunächst wird geprüft, ob sich die aktuelle Seite in einem der vorgesehenen Hauptbereiche befindet. Anschließend übernimmt ExpressionEngine automatisch den passenden Channel. Der eigentliche Fachartikel wird danach über das zweite URL-Segment geladen. Dadurch entsteht auch für sämtliche Fachartikel nur ein einziges zentrales Template. Neue Bereiche lassen sich später problemlos ergänzen, ohne zusätzlichen JSON-LD-Code anlegen zu müssen.

Der vollständige Template-Code

{if segment_2 != "info" AND segment_2 != ""}
{if segment_1 == "pflege"
OR segment_1 == "qualitaet"
OR segment_1 == "wohnen"
OR segment_1 == "essen"
OR segment_1 == "kosten"
OR segment_1 == "jobs"
OR segment_1 == "ueberuns"}
{exp:channel:entries
    channel="{segment_1}"
    url_title="{segment_2}"
    limit="1"
    require_entry="yes"
    track_views="one"
    dynamic="no"
}

{/exp:channel:entries}
{/if}
{/if}

Vorhandene Inhalte intelligent wiederverwenden

Auch bei den Fachartikeln wurde bewusst auf doppelte Pflege verzichtet. Existiert eine SEO-Beschreibung, wird sie für die JSON-LD-Ausgabe verwendet. Ist keine vorhanden, greift das Template automatisch auf den vorhandenen Teaser zurück.

{if seo_description},
"description":"{seo_description:attr_safe}"
{if:elseif teaser},
"description":"{teaser:attr_safe}"
{/if}

Dadurch erhält jeder Fachartikel eine aussagekräftige Beschreibung, ohne dass zusätzliche Inhalte geschrieben oder gepflegt werden müssen. Dasselbe Prinzip wurde bereits bei den Themenübersichten genutzt. Ein Inhalt wird einmal im CMS gepflegt und anschließend an unterschiedlichen Stellen wiederverwendet – auf der Website ebenso wie innerhalb der strukturierten Daten. Genau dadurch bleibt die Pflege einfach und die Ausgabe konsistent.

Fazit

Dieses Projekt hat einmal mehr gezeigt, dass gute strukturierte Daten nicht mit JSON-LD beginnen, sondern mit einer durchdachten Informationsarchitektur. Erst wenn Inhalte, URL-Struktur und Templates sauber zusammenspielen, lassen sich strukturierte Daten nachhaltig und wartungsfreundlich entwickeln.Genau hier spielt ExpressionEngine seine größten Stärken aus. Die konsequente Trennung von Inhalten, Templates und Logik ermöglicht es, vorhandene Informationen mehrfach zu nutzen, redundanten Code zu vermeiden und eine Lösung zu schaffen, die sich auch Jahre später problemlos erweitern lässt.

Entity SEO und Topical Authority oder warum Wissen mehr ist als Content

2026-06-17T14:13:00+00:00

Entity SEO und Topical Authority stehen für den Versuch von Suchmaschinen und KI-Systemen, Themen, Begriffe und Zusammenhänge besser zu verstehen. Der Artikel erklärt die Konzepte, hinterfragt verbreitete SEO-Versprechen und zeigt, warum langfristige Sichtbarkeit vor allem dort entsteht, wo fachliches Wissen strukturiert und nachvollziehbar vermittelt wird.

Entity SEO und Topical Authority

Wer sich heute mit Suchmaschinenoptimierung oder KI-Sichtbarkeit beschäftigt, stößt schnell auf Begriffe wie Entity SEO und Topical Authority. Beide klingen technisch, modern und ein wenig nach Geheimwissen. Genau deshalb eignen sie sich gut für große Versprechen.

Manchmal wirkt es fast so, als müsse man nur die richtigen Begriffe verwenden und schon stehe die Website ein gutes Stück näher an der digitalen Erleuchtung. Schön wäre es. 🙂

Ganz so einfach ist es nicht. Die Begriffe sind aber nicht leer. Sie beschreiben reale Veränderungen in der Art, wie Suchmaschinen Inhalte verstehen. Google bewertet Websites längst nicht mehr nur danach, ob ein bestimmtes Wort oft genug auf einer Seite vorkommt. Die Suche versucht Zusammenhänge zu erkennen, Themen einzuordnen und Begriffe in Beziehung zueinander zu setzen.

Was bedeutet Entity SEO?

Entity SEO hängt eng mit dem Google Knowledge Graph zusammen. Google stellte den Knowledge Graph 2012 unter dem Gedanken „things, not strings“ vor. Gemeint war damit: Die Suche sollte nicht nur Zeichenketten erkennen, sondern Dinge, Personen, Orte, Unternehmen oder Begriffe als eigenständige Einheiten verstehen.

Eine solche Einheit nennt man Entity. Eine Entity kann eine Person sein, ein Unternehmen, ein Ort, ein Produkt, eine Organisation oder ein Ereignis. Wichtig ist, dass diese Einheit eindeutig identifizierbar ist und in Beziehung zu anderen Dingen steht. Ein einfaches Beispiel ist das Wort „Jaguar“. Ohne Kontext ist unklar, ob das Tier, die Automarke oder etwas anderes gemeint ist. Erst durch den Zusammenhang wird erkennbar, welche Bedeutung passt.

Hier setzt Entity SEO an. Inhalte sollten so klar aufgebaut sein, dass Suchmaschinen erkennen können, über welche Dinge gesprochen wird und wie diese Dinge miteinander verbunden sind. Wenn eine Website über eine Person, ein Unternehmen, ein Produkt oder ein Fachthema spricht, sollte sie das nicht beliebig tun. Begriffe müssen konsistent verwendet werden. Beziehungen sollten nachvollziehbar sein. Strukturierte Daten können helfen, bestimmte Informationen technisch klarer auszuzeichnen. Interne Verlinkungen können Zusammenhänge sichtbar machen.

Was bedeutet Topical Authority?

Topical Authority bedeutet wörtlich etwa: thematische Autorität. Es ist kein offizieller Google-Begriff, beschreibt aber eine Beobachtung vieler SEO-Fachleute: Suchmaschinen bewerten nicht nur einzelne Seiten, sondern auch den thematischen Zusammenhang einer Website.

Eine Website, die ein Thema umfassend, verständlich und fachlich fundiert behandelt, kann glaubwürdiger wirken als eine Website mit einzelnen, isolierten Artikeln. Eine Website über Photovoltaik sollte nicht nur einen Artikel über Solarmodule enthalten. Sie sollte auch Speicher, Förderungen, Wirtschaftlichkeit und typische Fragen aus der Praxis behandeln.

Je besser ein Themenfeld erschlossen ist, desto eher entsteht der Eindruck: Hier kennt sich jemand aus. Das gilt für Menschen. Es gilt auch für Suchmaschinen und noch mehr für KI-Systeme, die einordnen müssen, ob eine Website nur einzelne Inhalte veröffentlicht oder ob dahinter ein fachlicher Zusammenhang steht.

Wenn aus Konzepten Rezepte werden

Entity SEO und Topical Authority werden häufig als fortgeschrittene SEO-Strategien vermarktet. Die Begriffe klingen modern, technisch und wissenschaftlich. Das macht sie attraktiv für Präsentationen, Beratungsangebote und neue SEO-Rezepte.

Problematisch wird es dort, wo aus einem Erklärungsmodell eine Erfolgsformel wird. Eine Website wird nicht automatisch zur Autorität, weil ihre Inhalte sauber strukturiert sind. Struktur kann Wissen sichtbar machen. Sie kann Wissen aber nicht ersetzen. Eine Kanzlei wird nicht zur anerkannten Quelle für Arbeitsrecht, Familienrecht und Erbrecht, weil sie zu jedem Thema zwanzig KI-generierte Artikel veröffentlicht. Interessant wird es dort, wo Erfahrungen aus Mandaten sichtbar werden, typische Fallkonstellationen erklärt werden und erkennbar wird, welche Fragen Mandanten tatsächlich beschäftigen.

Fachliche Autorität entsteht nicht durch die Anzahl der Texte. Sie entsteht dort, wo Wissen, Erfahrung und Kontext zusammenkommen.

Wissen ist mehr als Content

Content lässt sich produzieren. Wissen aber entsteht aus Erfahrung, Beobachtung und Nachdenken.

Viele Unternehmen verfügen über einen großen Erfahrungsschatz, ohne ihn vollständig sichtbar zu machen. Das Wissen steckt in Projekten, Kundenanfragen, Problemlösungen und jahrelanger Praxis. Die eigentliche Herausforderung besteht oft nicht darin, neue Inhalte zu erfinden, sondern dieses Wissen freizulegen und greifbar zu machen.

Bei der Konzeption größerer Websites geht es deshalb zunächst darum, vorhandenes Wissen sichtbar zu machen und daraus die Fragen abzuleiten, die Kunden, Interessenten oder Mitarbeitende tatsächlich beschäftigen. Bei der Analyse von Inhalten, Gesprächen und wiederkehrenden Kundenfragen wird oft deutlich, dass wichtige Zusammenhänge auf der Website noch fehlen. Einzelne Themen bleiben isoliert, Hintergrundinformationen werden vorausgesetzt oder häufig gestellte Fragen sind bislang gar nicht dokumentiert.

Die Texte entstehen erst am Ende dieses Prozesses. Deshalb greift die Vorstellung zu kurz, man müsse für mehr Sichtbarkeit vor allem mehr Content produzieren. Texte können Wissen vermitteln. Aber wo Wissen fehlt, hilft auch der beste Text nicht.

Was durch KI und moderne Suchsysteme neu geworden ist

Viele Dinge, die heute unter Begriffen wie Entity SEO oder Topical Authority diskutiert werden, gehören seit Jahren zu guten Websites. Klare Begriffe, verständliche Strukturen, sinnvolle Verlinkungen und die systematische Aufbereitung von Wissen waren schon lange wichtig.

Neu ist nicht die Grundidee. Neu ist, dass Suchmaschinen und KI-Systeme solche Strukturen heute besser erkennen und einordnen können. Sie betrachten Inhalte nicht mehr nur als einzelne Seiten oder Keywords, sondern stärker im Zusammenhang eines Themenfeldes. Dadurch gewinnt die Qualität des gesamten Wissensraums an Bedeutung.

KI kann dabei helfen, vorhandenes Wissen schneller zu strukturieren, zu recherchieren und aufzubereiten. Die eigentliche Herausforderung bleibt jedoch dieselbe: Welches Wissen soll überhaupt sichtbar gemacht werden?

KI-Sichtbarkeit als strategische Aufgabe

Für Unternehmen verschiebt sich damit die Perspektive. Die entscheidende Frage lautet nicht mehr nur, wie Inhalte produziert werden, sondern welches Wissen sichtbar werden soll und wie dieses Wissen langfristig zugänglich gemacht werden kann.

Das ist aufwendiger als die Produktion einzelner Inhalte. Dafür entsteht etwas, das über einzelne Kampagnen oder kurzfristige Reichweite hinausgeht. Ein gut aufgebauter Wissensraum kann über Jahre wachsen, Vertrauen schaffen und sowohl Menschen als auch Such- und KI-Systemen helfen, die fachliche Position eines Unternehmens besser einzuordnen.

Fazit

Entity SEO und Topical Authority sind keine Abkürzungen zu mehr Sichtbarkeit. Sichtbar werden zunehmend Unternehmen, die ihr Wissen verständlich strukturieren und zugänglich machen. Die eigentliche Herausforderung bleibt dabei erstaunlich altmodisch: Man muss etwas zu sagen haben.

Passende Artikel zum Thema

Warum ich bei moderner CSS-Typografie kaum noch line-height benutze

2026-06-11T10:21:00+00:00

Moderne CSS-Techniken verändern nicht nur die Gestaltung von Schriftgrößen, sondern zunehmend auch den gesamten typografischen Workflow. In diesem Erfahrungsbericht beschreibe ich, warum ich bei aktuellen Projekten immer häufiger auf feste line-height-Werte verzichte und stattdessen konsequent mit clamp() arbeite. Dabei geht es nicht nur um flexible Schriftgrößen, sondern auch um dynamische Abstände zwischen Überschriften, Texten und Bildern.

Als CSS-Coder beobachtet man natürlich ständig, wie sich CSS weiterentwickelt. Manche Techniken tauchen irgendwann auf, werden zunächst eher vorsichtig eingesetzt und entwickeln sich dann langsam zum Webstandard. Und irgendwann kommt der Punkt, an dem man den eigenen Workflow anpassen muss. Das macht man eher ungern, behaupte mal mit Blick auf das Gewohnheitstier Mensch. ;) Schließlich hat man sich über Jahre bestimmte Arbeitsweisen angewöhnt. Aber genau das gehört zur Arbeit mit CSS dazu:

Ich prüfe immer mal wieder während der Arbeit, ob alte Routinen noch sinnvoll sind. Und wenn mir etwas sinnvoll und effizient erscheint, setze ich es gleich um, auch wenn die Arbeit dadurch zuerst etwas länger dauert. Eine dieser Techniken ist für mich clamp().

Schriftgrößen mit `clamp()`

Vor einiger Zeit habe ich, wie viele andere auch, clamp() für dynamische Schriftgrößen entdeckt. Die Technik ist mittlerweile etabliert und gehört längst zum Werkzeugkasten moderner CSS-Entwicklung. Ob sie allerdings bereits konsequent eingesetzt wird, steht auf einem anderen Blatt.

Ein Beispiel:

.inhalt h2 {
  font-family: var(--semibold);
  font-size: clamp(1.4rem, 2.6vw, 2.2rem);
}

Die Schriftgröße hat damit einen unteren Wert, einen flexiblen Zwischenwert und einen oberen Wert. Auf dem Smartphone bleibt die Überschrift kompakt. Auf größeren Displays wächst sie mit, ohne irgendwann zu groß zu werden. Das allein ist schon sehr hilfreich.

Warum ich immer seltener `line-height` setze

Interessant wurde es für mich aber erst später. Ich habe gemerkt: Wenn ich Schriftgrößen konsequent mit clamp() aufbaue, brauche ich in vielen Fällen gar keine eigene line-height mehr. Früher hätte ich vielleicht geschrieben:

.inhalt h2 {
  font-size: clamp(1.4rem, 2.6vw, 2.2rem);
  line-height: 1.25;
}

Heute lasse ich die Zeilenhöhe bei vielen Elementen bewusst weg (allein die Betrachtung des obigen Codes gibt mir das Gefühl, dass sich altes und neues Coding hier beißen).

.inhalt h2 {
  font-family: var(--semibold);
  font-size: clamp(1.4rem, 2.6vw, 2.2rem);
}

Nach meinen Tests passen moderne Browser die Zeilenhöhe sehr gut an die jeweilige Schriftgröße an. Gerade wenn die Schriftgröße dynamisch wächst oder schrumpft, wirkt das oft harmonischer, als wenn ich zusätzlich feste Werte erzwinge. Für mich ist das bei komplexeren Layouts eine echte Arbeitserleichterung.

Auch Abstände lassen sich dynamisch gestalten

Der nächste Schritt ist dann naheliegend: Wenn clamp() bei Schriftgrößen funktioniert, warum nicht auch bei Abständen? Zum Beispiel beim Abstand unter einer Überschrift:

.inhalt h2 {
  margin: clamp(0.75rem, 1vw, 1rem) 0
          clamp(0.45rem, 0.7vw, 0.75rem) 0;
  font-family: var(--semibold);
  font-size: clamp(1.4rem, 2.6vw, 2.2rem);
}

Oder bei einer H3:

.inhalt h3 {
  margin: clamp(1.5rem, 2.5vw, 1.8rem) 0
          clamp(0.8rem, 1vw, 1.2rem) 0;
  font-family: var(--regular);
  font-size: clamp(1.3rem, 2vw, 1.8rem);
}

Auch Bildabstände lassen sich so flexibler steuern:

.inhalt img {
  width: 100%;
  height: auto;
  margin: clamp(1.2rem, 2.5vw, 2.5rem) 0;
}

Dadurch entstehen auf Smartphones nicht zu große Abstände, während das Layout auf größeren Displays trotzdem luftig bleiben kann.

Das Austarieren bleibt wichtig

Natürlich ersetzt keine saubere typografische Arbeit. Die Werte müssen austariert werden. Man muss auf dem Smartphone testen, auf dem Tablet prüfen, am Desktop vergleichen und dann wieder nachjustieren. Das ist ein Geduldsspiel. Aber das CSS wird dadurch robuster, weil ich weniger Sonderregeln schreiben muss.


Weniger Media Queries, weniger Pflegeaufwand
Meine These ist inzwischen: Wer clamp() konsequent für Schriftgrößen, Überschriftenabstände, Absatzabstände und Bildabstände einsetzt, spart sich einen großen Teil typografischer Media Queries. Gerade bei komplexeren Websites mit vielen unterschiedlichen Inhaltstypen reduziert das den Wartungsaufwand doch erheblich. Statt an mehreren Breakpoints immer wieder Schriftgrößen, Abstände und Zeilenhöhen nachzubessern, definiert man flexible Wertebereiche. Innerhalb dieser Bereiche kann sich das Layout selbst anpassen. 
Für mich ist das inzwischen einer der wichtigsten Vorteile moderner CSS-Typografie: weniger starre Vorgaben, weniger Sonderregeln und deutlich weniger Nacharbeit.



Praxisbericht: Eine flexible und pflegeleichte Startseite mit ExpressionEngine
2026-06-04T14:45:00+00:00
Für ein aktuelles Kundenprojekt sollte eine bereits gestaltete und in HTML und CSS umgesetzte Startseite in ExpressionEngine integriert werden. Im Mittelpunkt stand dabei die Frage, wie sich unterschiedliche Inhaltsbereiche mit möglichst wenig Feldern und ohne zusätzliche Entscheidungen für die Redaktion abbilden lassen. Der Artikel zeigt, warum ich mich für feste Bereiche, Grid-Felder und eine einfache CMS-Struktur entschieden habe und welche Alternativen dabei verworfen wurden. Der Praxisbericht verdeutlicht außerdem, warum weniger Felder und klare Strukturen oft sinnvoller sind als zusätzliche Steuerungsmöglichkeiten für die Redaktion.
 
    Der Aufbau der Startseite


    Die Startseite besteht aus vier Bereichen. Ganz oben steht ein großer Bildbereich mit mehreren Bildern, einer Überschrift und einem Call-to-Action-Button. Dieser Bereich soll auf wichtige Themen aufmerksam machen und kann später flexibel angepasst werden.



    Darunter folgen die wichtigsten Informationen. Kleine Teaser verweisen auf häufig gesuchte Inhalte. Anschließend kommen die Hauptbereiche der Website. Hier führen größere Bildteaser zu den wichtigsten Seiten. Den Abschluss bilden zwei Videos.


    Für Besucher wirkt dieser Aufbau selbstverständlich. Hinter den Kulissen musste dafür jedoch eine Struktur entstehen, die unterschiedliche Layouts unterstützt und gleichzeitig einfach zu pflegen bleibt.


    


    Die erste Idee: Alles über Grid-Felder


    Grid-Felder nutze ich in ExpressionEngine sehr häufig. Sie eignen sich gut für Inhalte, die immer dieselbe Struktur besitzen.In diesem Projekt bestand ein typisches Element aus:


    Bild
    Überschrift
    Link
    Alternativtext


    Für den oberen Bildbereich und die Informationskacheln war das eine gute Lösung. Neue Inhalte lassen sich hinzufügen, bearbeiten oder in der Reihenfolge verändern, ohne dass dafür das Template angepasst werden muss. Schnell zeigte sich jedoch, dass Grid-Felder allein nicht ausreichen. Die eigentliche Frage war eine andere:


    Wie lassen sich unterschiedliche Layouts innerhalb eines einzigen Channels abbilden, ohne dass der Kunde zusätzliche Einstellungen vornehmen muss?


    Denn die Anforderungen waren sehr unterschiedlich. Der Bildbereich benötigt mehrere Bilder und einen Button. Die Informationskacheln verwenden ein anderes Layout als die Hauptbereiche der Website. Die Videos benötigen wiederum eine eigene Ausgabe. Die Inhalte ähneln sich teilweise. Die Darstellung unterscheidet sich jedoch deutlich.



    Alle Bereiche der Startseite sollten aus demselben Channel stammen. Die Inhalte sollten dort als einzelne Einträge angelegt werden. Gleichzeitig musste die Pflege für den Kunden möglichst einfach bleiben. Damit stellte sich eine zentrale Frage: Wie lässt sich die Seitenstruktur steuern, ohne zusätzliche Komplexität ins CMS zu bringen?


    Kategorien oder zusätzliche Steuerfelder?


    Eine Möglichkeit war, die unterschiedlichen Bereiche über Kategorien zu steuern. Kategorien wie „Slider“, „Informationen“, „Hauptbereiche“ oder „Videos“ hätten dem Template sagen können, welcher Bereich gerade ausgegeben wird. Technisch wäre das möglich gewesen. Für mich fühlte es sich aber nicht richtig an. Kategorien hätten hier nicht Inhalte sortiert, sondern das Layout gesteuert.


    Eine weitere Möglichkeit wäre ein zusätzliches Auswahlfeld gewesen:


Layouttyp
○ Slider
○ Informationskachel
○ Hauptbereich
○ Video

    
Auch das wäre technisch sauber gewesen. Für den Kunden wäre es aber eine weitere Entscheidung im CMS. Und genau solche zusätzlichen Entscheidungen wollte ich vermeiden. Je weniger der Kunde konfigurieren muss, desto besser.


    Die einfache Lösung – wie so oft über Umwege


    Deshalb entschied ich mich für einen pragmatischen Ansatz. Die Struktur der Startseite wird über feste Einträge innerhalb desselben Channels definiert. Jeder Bereich besitzt seinen eigenen Eintrag: Slider, wichtige Informationen, Hauptbereiche und Videos. Im Template erfolgt die Zuordnung anschließend über den URL-Title. Interessanterweise war das am Ende sogar die einfachste Lösung. Der Kunde muss keine Kategorien auswählen, keine Layouttypen verstehen und keine technischen Entscheidungen treffen. Die Inhalte landen automatisch an der richtigen Stelle.


    Die Grid-Felder bleiben trotzdem erhalten. Sie übernehmen genau dort ihre Aufgabe, wo sie ihre Stärke ausspielen können: innerhalb der einzelnen Bereiche. Dadurch entsteht eine klare Trennung. Die Seitenstruktur ist fest definiert. Die Inhalte innerhalb der Bereiche bleiben flexibel. Während der Umsetzung ließ sich sogar noch ein Feld einsparen. Die Überschrift eines Bereichs ist bereits der Beitragstitel. Warum also dieselbe Information zweimal speichern? Für Bereiche wie „Die wichtigsten Informationen“, „Hauptbereiche“ oder „Videos“ reicht der Titel des jeweiligen Eintrags vollkommen aus.


    Eine Kleinigkeit vielleicht. Bei komplexeren Inhaltsstrukturen sind es aber oft genau solche Überlegungen, die am Ende den Unterschied machen. Wo kann ein Feld entfallen? Welche Information existiert bereits? Und wie lässt sich die Pflege vereinfachen, ohne die Möglichkeiten für den Kunden einzuschränken?


    Und ich muss zugeben: Je länger ich mich mit den verschiedenen Möglichkeiten beschäftigt habe, desto besser gefiel mir dieser Ansatz. Weniger Felder. Weniger Möglichkeiten für Fehler. Weniger Erklärungsbedarf.


    Wie so oft führte der Weg über mehrere Überlegungen und verworfene Ansätze. Am Ende blieb die einfachste Lösung übrig.


    Template-Code: Ein bewusster Kompromiss


    Natürlich hatte diese Lösung auch einen kleinen Nachteil. Im Template entsteht dadurch etwas mehr Code, als mir normalerweise lieb ist. Einige Strukturen wiederholen sich und auch die einzelnen Bereichsausgaben ähneln sich teilweise. Wer streng nach dem DRY-Prinzip („Don't Repeat Yourself“) arbeitet, würde hier versuchen, weitere Abstraktionen einzubauen.


{exp:channel:entries channel="startseite" url_title="slider" limit="1"}

  
    {slider}
      
    {/slider}
  
  
    {title}
    Jetzt bewerben
  

{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="wichtige-informationen" limit="1"}

  {title}
  
    {cards}
      
        
        {cards:thema}
      
    {/cards}
  

{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="hauptbereiche" limit="1"}

  {title}
  
    {cards}
      
        
        {cards:thema}
      
    {/cards}
  

{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="videos" limit="1"}

  {title}
  
    {cards}
      
        
          
        
      
    {/cards}
  

{/exp:channel:entries}


    
Wie bereits erläutert, haben die Bereiche aber unterschiedliche Layouts. Das lässt sich nicht wegdiskutieren und auch nicht einfach wegcoden. Der obere Bildbereich, die kleinen Informationskacheln, die großen Hauptbereiche und die Videos brauchen jeweils eine eigene Ausgabe.


    Natürlich könnte man versuchen, diese Unterschiede über Bedingungen im Template abzufangen. Dann würde weniger Code doppelt erscheinen. Dafür entstünde an anderer Stelle mehr Logik. Die Alternative wären zusätzliche Steuerfelder, Kategorien oder verschachtelte Conditions gewesen. Das Template wäre vielleicht etwas kompakter geworden. Gleichzeitig hätte die Komplexität  in der Template-Logik zugenommen.


    Da das gesamte Template doch recht schlank geblieben ist, erschien mir dieser Kompromiss sinnvoll.  In diesem Fall war mir eine einfache Pflege wichtiger als ein theoretisch perfektes Template.


    Eine Struktur, die nachvollziehbar bleibt


    Gerade der Bereich „Hauptbereiche der Website“ zeigt den Vorteil gut. Auf der Website erscheinen mehrere große Teaser. Im CMS ist es ein einziger Startseiten-Eintrag mit einem Grid-Feld.


    Der Kunde kann Teaser ergänzen, Texte ändern oder Links austauschen, ohne die Grundstruktur der Seite zu berühren. Für Entwickler bleibt die Lösung ebenfalls gut nachvollziehbar. Die Startseite besteht aus festen Bereichen. Wiederkehrende Inhalte liegen in Grid-Feldern. 


    Die Lösung ist vielleicht nicht in jedem Detail perfekt nach dem DRY-Prinzip aufgebaut. Dafür lässt sie sich schnell erfassen und verstehen. Und genau das ist bei Projekten, die über Jahre gepflegt und weiterentwickelt werden, oft wichtiger als einige eingesparten Zeilen Code.



    Einen Nachteil möchte ich nicht verschweigen


    So zufrieden ich mit der Lösung bin, einen kleinen Nachteil bringt sie mit sich. Die ersten Bereiche der Startseite sind fest im Template definiert. Wenn später ein weiterer Bereich hinzukommen soll, stellt sich also sofort die Frage: Wo soll er erscheinen und welches Layout soll er bekommen?


    Genau das lässt sich nicht allein technisch entscheiden. Soll der neue Bereich oberhalb der Videos stehen? Unterhalb der Videos? Soll er kleine Kacheln verwenden oder große Teaser wie die Hauptbereiche? Solche Fragen gehören zur Seitenstruktur und sollten mit dem Kunden abgestimmt werden.


    Trotzdem lässt sich das Template gut vorbereiten. Eine elegante Möglichkeit ist ein zusätzlicher channel:entries-Tag, der alle Einträge aus dem Startseiten-Channel ausgibt, aber die festen Systembereiche über den URL-Title ausschließt. Der Kunde könnte dann später einen weiteren Bereich mit Cards anlegen. Dieser Bereich würde automatisch ausgegeben, ohne dass die bestehenden Bereiche verändert werden müssen.


{exp:channel:entries channel="startseite" url_title="not slider|wichtige-informationen|hauptbereiche|videos"}

  {title}
  
    {cards}
      
        
        {cards:thema}
      
    {/cards}
  

{/exp:channel:entries}


    
In diesem Beispiel würde der zusätzliche Bereich dasselbe Layout wie die großen Hauptbereiche verwenden. Das wäre für weitere Teaser naheliegend und hält die Gestaltung ruhig. Wo dieser Template-Block steht, entscheidet dann die Position auf der Startseite. Ich würde ihn wahrscheinlich oberhalb der Videos einfügen. Genau das wäre aber eine Frage, die man im konkreten Fall mit dem Kunden bespricht.


    Eine weitere Frage wäre die Sortierung. Die vier festen Bereiche sind im Template bewusst fest angeordnet. Ihre Reihenfolge wird also nicht über das CMS gesteuert, sondern über das Template. Für zusätzliche Bereiche könnte man mit Veröffentlichungsdatum, Entry-Reihenfolge oder einer anderen Steuerung arbeiten.


    Noch flexibler wäre eine Lösung über ein Relationships-Feld. Dann könnten Bereiche gezielt ausgewählt und per Drag-and-Drop sortiert werden. Das klingt komfortabel, bringt aber wieder mehr Struktur, mehr Felder und mehr Aufwand mit sich. An einem bestimmten Punkt wird eine Lösung für den Kunden nur scheinbar einfacher. Technisch wächst im Hintergrund die Komplexität.


    Für dieses Projekt erschien mir der vorbereitete Zusatzbereich als sinnvoller Kompromiss. Die feste Struktur bleibt erhalten. Der Kunde bekommt trotzdem eine Erweiterungsmöglichkeit. 



    Fazit


    Bei solchen Projekten setze ich die Prioritäten nicht erst während der Entwicklung, sondern bereits davor. Eine dieser Prioritäten ist die spätere Pflege. Der Kunde soll Inhalte möglichst einfach ändern können. Er soll verstehen, was er tut. Und er soll nicht für jede Kleinigkeit den Entwickler anrufen müssen.


    Das bedeutet nicht, dass jede technische Möglichkeit ausgeschöpft werden muss. Es bedeutet auch nicht, dass jede denkbare Funktion ihren Weg ins CMS finden sollte. Entscheidend ist, ob sie dem Kunden tatsächlich einen Mehrwert bietet. Genau das gehört zu meinem Selbstverständnis als Entwickler.


    Der eine oder andere würde darüber vermutlich den Kopf schütteln (ich habe das auch schon erlebt). Schließlich macht man sich damit ein Stück weit selbst überflüssig. Ich sehe das anders. Wenn ein Kunde seine Website möglichst selbstständig pflegen kann und die Struktur auch Jahre später noch verständlich bleibt, dann ist das für mich ein gutes Ergebnis – und Ausdruck von Fairness gegenüber dem Kunden.



    Weiterführende Artikel


    10 Vorteile des CMS ExpressionEngine für Kunden, Designer und Webentwickler
    Zwei starke ExpressionEngine-Features: Relationships-Felder und der Fluid-Feldertyp
    Interview: Zwischen ExpressionEngine, KI und E-Commerce



Die llms.txt als ein Spiegel der eigenen Informationsarchitektur oder als neues Werkzeug für mehr KI-Sichtbarkeit?
2026-06-03T10:59:00+00:00
Die llms.txt wird häufig als neues Werkzeug für KI-Sichtbarkeit diskutiert. Doch ihr eigentlicher Wert könnte an anderer Stelle liegen. Wer die wichtigsten Inhalte einer Website in einer llms.txt zusammenfassen möchte, muss sich zwangsläufig mit Struktur, Prioritäten und Zusammenhängen beschäftigen. Der Artikel ordnet die Idee ein und betrachtet die llms.txt weniger als technische Maßnahme, sondern als Spiegel eines digitalen Wissensraums.
 Wer sich aktuell mit KI-Sichtbarkeit beschäftigt, stolpert früher oder später über einen neuen Begriff: llms.txt. Manche sehen darin bereits das neue robots.txt. Andere behaupten sogar, ohne eine llms.txt-Datei werde man künftig von ChatGPT, Gemini oder Perplexity kaum noch gefunden.Wie so oft liegt die Wahrheit vermutlich irgendwo dazwischen. Die Idee hinter llms.txt ist interessant. Die Erwartungen, die derzeit damit verbunden werden, erscheinen mir aber teilweise überzogen.
Was ist eine llms.txt überhaupt?
Die Abkürzung steht für Large Language Models. Gemeint sind Sprachmodelle wie ChatGPT, Claude, Gemini oder andere KI-Systeme. Die Grundidee stammt von dem KI-Forscher und Unternehmer Jeremy Howard. Er veröffentlichte im September 2024 den Vorschlag, Websites um eine zusätzliche Datei namens llms.txt zu erweitern. Ziel war es, Sprachmodellen einen einfacheren Zugang zu den wichtigsten Inhalten einer Website zu ermöglichen.Der Gedanke dahinter ist nachvollziehbar. Websites werden für Menschen gebaut. Sie enthalten Navigationen, Menüs, Sidebars, JavaScript, Werbung, Footer und viele andere Elemente, die für Besucher sinnvoll sind. Für ein Sprachmodell sind diese Bestandteile oft eher Ballast. Eine llms.txt soll deshalb eine Art kompaktes Inhaltsverzeichnis bereitstellen. Nicht für Menschen, sondern für Maschinen.
Wie sieht eine llms.txt aus?
Eine llms.txt ist keine XML-Datei und kein kompliziertes Datenformat. Sie besteht in der Regel aus einfachem Markdown und liegt direkt im Hauptverzeichnis einer Website. Ein stark vereinfachtes Beispiel könnte so aussehen:

# Segert.net

Webentwicklung, semantische Websites und KI-Sichtbarkeit.

## Wichtige Themen

- KI-Sichtbarkeit
- Websites als Wissensräume
- Strukturierte Daten
- ExpressionEngine
- Semantisches Webdesign

## Zentrale Inhalte

- https://segert.net/segertblog/thema/ki-sichtbarkeit
- https://segert.net/segertblog/ki-sichtbarkeit-strukturierte-daten-website-als-wissensraum
- https://segert.net/segertblog/wie-ich-eine-klassische-faq-semantisch-mit-expressionengine-und-json-ld-erweitert-habe
- https://segert.net/segertblog/thema/expressionengine

## Hinweise

Diese Website beschäftigt sich mit langfristig gepflegten Inhalten, technischer Klarheit und der Frage, wie Websites für Menschen, Suchmaschinen und KI-Systeme verständlicher werden.


Das Prinzip erinnert ein wenig an eine Mischung aus Sitemap, Inhaltsverzeichnis und Abstract. Die Website sagt damit gewissermaßen: „Wenn du mich verstehen möchtest, beginne bitte hier.“
Ist llms.txt ein offizieller Standard?
Nein. Und genau hier beginnt die erste wichtige Einordnung. Viele Beiträge sprechen inzwischen von einem neuen Standard für KI-Systeme. Tatsächlich handelt es sich bislang um einen Vorschlag aus der Community. Weder das W3C noch andere offizielle Standardisierungsgremien haben llms.txt verabschiedet. Man könnte sagen: llms.txt ist eher eine Idee mit wachsender Verbreitung als ein verbindlicher Webstandard. Das bedeutet nicht, dass die Idee schlecht ist. Es bedeutet nur, dass niemand garantieren kann, ob und wie KI-Systeme diese Datei tatsächlich nutzen.
Warum wird das Thema plötzlich so stark gehypt?
Dafür gibt es mehrere Gründe. Erstens verändert sich die Suche zur Zeit grundlegend. Immer mehr Nutzer stellen Fragen direkt an ChatGPT, Gemini oder Perplexity. Dadurch entsteht verständlicherweise die Sorge, wie Unternehmen und Fachseiten in diesen neuen Systemen sichtbar bleiben können. Zweitens suchen viele Agenturen und Tool-Anbieter nach technischen Lösungen für ein sehr komplexes Problem. Eine Datei ist leicht erklärt, leicht verkauft und deutlich einfacher zu vermarkten als Themen wie Informationsarchitektur, semantische Zusammenhänge oder hochwertige Fachinhalte. Drittens erinnert die Idee an bekannte Konzepte wie robots.txt oder sitemap.xml. Das macht sie sofort verständlich. Wer seit Jahren Websites betreibt, denkt vielleicht etwas schnell: „Ah, das ist also die robots.txt für KI.“ Genau dieser Vergleich wird nicht selten gezogen. Tatsächlich erfüllt die Datei aber eine andere Aufgabe. Sie steuert keine Zugriffe, sondern soll Inhalte priorisieren und erklären.
Das eigentliche Problem
Wenn man manche Diskussionen verfolgt, entsteht schnell der Eindruck, eine llms.txt würde die KI-Sichtbarkeit einer Website entscheidend verbessern. Dafür gibt es bisher kaum belastbare Nachweise. Die entscheidende Frage lautet: Liest ChatGPT diese Datei überhaupt? Oder Gemini? Oder Perplexity? Die ehrliche Antwort lautet: Wir wissen es nicht mit Sicherheit. Öffentlich ist derzeit nicht nachvollziehbar, welche Rolle eine llms.txt bei den großen KI-Anbietern spielt oder spielen wird. Entsprechend gibt es bislang keine belastbaren Nachweise dafür, dass eine llms.txt zu einer besseren Sichtbarkeit in KI-Systemen führt. Genau deshalb bin ich vorsichtig, wenn ihre Wirkung so weitreichend behauptet wird.
Warum ich die Idee trotzdem interessant finde
Trotz aller Skepsis halte ich die Grundidee für sinnvoll. Allerdings aus einem anderen Grund. Eine gute llms.txt zwingt den Betreiber einer Website dazu, sich eine einfache Frage zu stellen: Welche Inhalte sind die wichtigsten? Viele Websites können diese Frage erstaunlich schwer beantworten. Wer dagegen einen echten Wissensraum aufgebaut hat, verfügt bereits über zentrale Themenbereiche, grundlegende Artikel, klare Orientierungspunkte und Inhalte, die sinnvoll aufeinander verweisen. In diesem Fall entsteht die llms.txt fast von selbst. Und genau darin liegt für mich ihr eigentlicher Wert. Nicht als magische SEO-Maßnahme, sondern als Spiegel der eigenen Informationsarchitektur.
Die eigentliche Frage liegt woanders
Die Diskussion um llms.txt zeigt noch etwas ganz anderes. Viele Betreiber suchen derzeit nach technischen Stellschrauben für KI-Sichtbarkeit. Dabei liegt die Herausforderung nicht in einer zusätzlichen Datei, sondern in der Frage, ob eine Website ihre Themen überhaupt klar strukturiert und verständlich vermittelt. Eine llms.txt macht aus einer ungeordneten Website keinen Wissensraum. Sie kann aber sichtbar machen, ob ein Wissensraum bereits vorhanden ist. Oder anders formuliert: Nicht die llms.txt macht einen Wissensraum sichtbar. Ein vorhandener Wissensraum macht eine llms.txt überhaupt erst sinnvoll.
Mein Fazit
Wer heute eine llms.txt anlegt, macht nichts falsch, wenn er es richtig macht. ;) Der Aufwand ist überschaubar und die Idee dahinter ist gut. Wer allerdings glaubt, dadurch automatisch in ChatGPT häufiger erwähnt oder in KI-Systemen besser sichtbar zu werden, sollte seine Erwartungen besser bremsen. Die wirklich wichtigen Fragen bleiben dieselben wie vor zehn oder zwanzig Jahren:
Ist eine Website verständlich aufgebaut?
Werden Themen umfassend behandelt?
Sind Inhalte sinnvoll miteinander verknüpft?
Entsteht strukturiertes, genuines Wissen?
Wenn diese Grundlagen fehlen, wird auch die schönste llms.txt daran wenig ändern. 
Relevante Artikel 
KI-Sichtbarkeit: Die Website als Wissensraum 
Warum Hypertext im Zeitalter von ChatGPT & Co. wieder interessanter wird
Semantische Erweiterung einer klassischen FAQ mit ExpressionEngine und JSON-LD
Weiterführende Informationen
llmstxt.org – Offizielle Projektseite
https://llmstxt.org
Answer.AI – Vorstellung des Vorschlags durch Jeremy Howard
https://www.answer.ai/posts/2024-09-03-llmstxt.html
Google Search Central – AI und Suchmaschinenoptimierung
https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
OpenAI Developers – Informationen zu OpenAI-Bots und robots.txt
https://platform.openai.com/docs/bots
Sistrix – Einordnung von llms.txt aus SEO-Sicht
https://www.sistrix.de/frag-sistrix/ai-grundlagen/llms-txt


Warum Hypertext im Zeitalter von ChatGPT & Co. wieder interessanter wird
2026-06-02T06:49:00+00:00
Lange bevor von KI-Sichtbarkeit die Rede war, gab es die Idee des Webs als vernetztem Wissensraum. Tim Berners-Lee nannte das einen „common information space“. Mit dem Aufstieg großer Sprachmodelle rücken Fragen nach Wissensstrukturen, Kontext und internen Verbindungen erneut in den Fokus. Warum das interessant ist – und weshalb man dabei trotzdem nicht in Hypertext-Romantik verfallen sollte.
 
    Wer heute die KI-Übersichten von Google oder die Antworten großer Sprachmodelle betrachtet, stößt häufig auf zusammengeführte Informationen, Begriffserklärungen und thematische Zusammenhänge. Das lenkt den Blick auf einige sehr alte Ideen des Webs. Interne Verlinkungen, thematische Verweise, Glossare, FAQ-Strukturen oder semantisch aufgebaute Inhaltsbereiche erscheinen dadurch in einem neuen Licht.


    Das ist insofern interessant, weil sich der Fokus vieler kommerzieller Websites in den vergangenen Jahren verschoben hat. Statt vernetzter Wissensräume entstanden häufig Seitenstrukturen, die vor allem auf einzelne Suchanfragen, Landingpages und Conversion-Ziele ausgerichtet waren. Zusammenhänge zwischen Inhalten blieben zwar vorhanden, wurden aber häufig stärker durch SEO- oder Navigationsziele geprägt als durch den ursprünglichen Gedanken eines inhaltlich vernetzten Webs.

    Dabei war genau diese Vernetzung ursprünglich eine Kernidee des Webs. Tim Berners-Lee, der Erfinder des World Wide Webs, beschrieb das Netz früh nicht einfach als Sammlung einzelner Dokumente, sondern als „common information space“ – also als gemeinsamen Informations- oder Wissensraum. Informationen sollten über Hyperlinks miteinander verbunden werden, damit Menschen Zusammenhänge entdecken, Wissen erweitern und sich frei zwischen Themen bewegen können. Hypertext bedeutete für ihn deshalb weit mehr als bloße Navigation. Die Idee dahinter war ein vernetzter Denk- und Wissensraum, in dem Beziehungen zwischen Informationen sichtbar werden.


    Auch frühe Hypertext-Theoretiker wie Ted Nelson dachten das Netz weniger als starres Archiv einzelner Seiten, sondern als dynamisches Geflecht miteinander verbundener Informationen. Interessant ist heute, dass genau diese frühen Vorstellungen durch moderne KI-Systeme plötzlich wieder aktueller wirken. Vielleicht nicht als technische Realität, wohl aber als neue Perspektive auf das Web und die Art, wie Wissen darin organisiert wird. Zumindest kann man darüber diskutieren, ob es so ist. ;)



    Trotzdem sollte man den Hypertext-Gedanken nicht überbewerten. Die Probleme waren immer bekannt. Zu viele Verlinkungen können Texte zerfasern. Leser verlieren den Fokus, springen permanent zwischen Seiten hin und her oder verlassen den eigentlichen Gedankengang (einmal abgesehen von der Frage, neues Browserfenster oder nicht ;). Gerade längere Texte leiden schnell darunter, wenn an jeder zweiten Stelle ein erklärender Link auftaucht.


    Deshalb ist die eigentliche Herausforderung nicht die maximale Verlinkung, sondern die sinnvolle Dosierung. Gute Wissensstrukturen müssen Orientierung schaffen, ohne den Lesefluss ständig zu unterbrechen. Genau deshalb experimentierten viele Websites schon Anfang der 2000er Jahre mit Mouse-Over-Erklärungen, Layern, Quickinfos oder ergänzenden Fenstern, um zusätzliche Informationen zugänglich zu machen, ohne den eigentlichen Textfluss komplett zu zerreißen.

Interessant ist heute vor allem, dass moderne Sprachmodelle Inhalte anders verarbeiten als klassische Suchmaschinen. Während Suchmaschinen lange vor allem Dokumente, Keywords und Verlinkungen analysierten, verarbeiten große Sprachmodelle Texte stärker als zusammenhängende Bedeutungskontexte. Aus menschlicher Sicht wirken sie dabei so, als würden sie Beziehungen, thematische Zusammenhänge und semantische Muster zwischen Informationen erfassen.


    Natürlich „verstehen“ auch Sprachmodelle Inhalte nicht im menschlichen Sinn. Sie erkennen jedoch Muster, semantische Beziehungen und thematische Nähe in einem Umfang, der vor wenigen Jahren noch kaum möglich schien. Für Websitebetreiber entsteht dadurch eine interessante Situation: Nicht nur einzelne Seiten werden relevant, sondern zunehmend auch die Art und Weise, wie Wissen innerhalb einer Website strukturiert, erklärt und miteinander verbunden wird.


    Es wäre sicher mehr als übertrieben zu behaupten, dass KI-Systeme nun die ursprüngliche Vision des Hypertexts erfüllen. Aber sie verschieben den Blick wieder stärker auf Zusammenhänge, Kontexte und Wissensstrukturen. Damit bekommen einige Grundideen des frühen Webs ein neues Gewicht – nicht als nostalgische Rückkehr, sondern weil moderne Sprachmodelle genau solche Beziehungen zwischen Informationen verarbeiten und in ihre Antworten einbeziehen können.

Relevante Artikel 
KI-Sichtbarkeit: Die Website als Wissensraum 
Semantische Erweiterung einer klassischen FAQ mit ExpressionEngine und JSON-LD

    Weiterführende Informationen


    Tim Berners-Lee: The World Wide Web – Frequently Asked Questions
https://www.w3.org/People/Berners-Lee/FAQ.html
    MDN Web Docs: Hypertext
https://developer.mozilla.org/de/docs/Glossary/Hypertext
    Wikipedia: Hypertext
https://de.wikipedia.org/wiki/Hypertext
    Wikipedia: Ted Nelson
https://de.wikipedia.org/wiki/Ted_Nelson



Semantische Erweiterung einer klassischen FAQ mit ExpressionEngine und JSON-LD
2026-05-26T13:31:00+00:00
Wie strukturiert man eine FAQ so, dass sie nicht nur für Besucher verständlicher wird, sondern auch für KI-Systeme und semantische Suche relevanter? In diesem Praxisartikel zeige ich Schritt für Schritt, wie aus einer klassischen Accordion-FAQ mit ExpressionEngine eine kleine semantische Wissensstruktur entstanden ist — inklusive JSON-LD, semantischen Beziehungen, direkten Abschnittslinks und der Arbeits-Erkenntnis, dass weniger strukturierte Daten oft sinnvoller sind als überbordende SEO-Taxonomien.
 Zuerst: Das ist kein „SEO-Tutorial“, sondern ein praktisches Beispiel dafür, wie semantische Wissensstrukturierung auch im kleinen Rahmen und von vorneherein aussehen kann. Konkret geht es um den Wissensbereich: Fragen und Antworten zu barrierefreien Websites und das BFSG ab 2025 (FAQ)

    Ausgangslage: Die FAQ war eigentlich schon gar nicht schlecht


    Die ursprüngliche FAQ bestand bereits aus einer vergleichsweise sauberen HTML-Struktur:


    Frage
    Antwort



    
Damit war die FAQ semantisch bereits deutlich besser aufgebaut als viele typische Accordion-Lösungen, die ausschließlich aus verschachtelten 
-Containern bestehen.


    Auch die einzelnen Fragen waren direkt per Anchor-Link ansprechbar:

    Dadurch konnten einzelne FAQ-Einträge direkt verlinkt werden:

Direktlink



    Allein das ist in vielen FAQ-Systemen noch erstaunlich selten. 

    Der nächste Schritt: strukturierte Daten für die FAQ


    Die eigentliche Überlegung begann mit der Frage:

    Wie lässt sich diese FAQ zusätzlich als strukturierte Wissensstruktur im JSON-LD abbilden?

    Die erste Erweiterung war vergleichsweise naheliegend:

"mainEntity":[
  {
    "@type":"Question",
    "name":"Was ist eine barrierefreie Website?",
    "acceptedAnswer":{
      "@type":"Answer",
      "text":"..."
    }
  }
]


    Damit wurde aus einer reinen HTML-FAQ zusätzlich eine maschinenlesbare Struktur.


    Interessant ist dabei vor allem die Frage, warum hier überhaupt mit @type gearbeitet wird und warum der Typ Question gewählt wurde.


    Genau das ist nämlich die eigentliche Idee hinter Schema.org und JSON-LD:

    Inhalte sollen nicht nur dargestellt, sondern auch semantisch beschrieben werden. Systeme wie Suchmaschinen oder KI-Anwendungen sollen verstehen können, was ein Inhalt überhaupt ist.


    Eine Überschrift ist zunächst nur Text.

    Eine Frage innerhalb von JSON-LD dagegen wird explizit als semantisches Objekt beschrieben:

"@type":"Question"


    
Damit wird für Maschinen klar:

    Dies ist keine gewöhnliche Textpassage, sondern eine Frage mit einer dazugehörigen Antwort.


    Ebenso beschreibt:

"@type":"Answer"


    die eigentliche Antwort als eigenes semantisches Objekt.


    Schema.org arbeitet also mit Typen, die reale Wissensobjekte modellieren:


    Question
    Answer
    Article
    Person
    Event
    Product


    und viele weitere.


    Die Auswahl dieser Typen ist entscheidend. Genau hier entstehen sinnvolle semantische Beziehungen — oder eben redundante Metadaten.


    Zunächst lag deshalb die Überlegung nahe, die gesamte Seite einfach als FAQPage auszuzeichnen. Diesen Typ gibt es in Schema.org tatsächlich.


    Für diesen Anwendungsfall erschien jedoch die Kombination aus:


    Question
    Answer
    Thing


    interessanter.


    Warum?


    Weil die Seite nicht nur aus einer FAQ besteht, sondern zugleich ein umfangreicher Fachartikel über digitale Barrierefreiheit ist.

    Die einzelnen FAQ-Einträge wurden deshalb nicht als isolierte FAQ-Seite verstanden, sondern als Wissenseinheiten innerhalb eines größeren Artikels.


    Genau an solchen Stellen zeigt sich, dass semantische Strukturierung nicht bedeutet, möglichst viele strukturierte Daten auszugeben. Entscheidend ist vielmehr die Frage:


    Welche Typen beschreiben den tatsächlichen Charakter der Inhalte möglichst präzise?


    Die nächste Frage: Reicht Frage und Antwort wirklich aus?


    An diesem Punkt wurde es interessant für mich.
    Denn technisch war die FAQ damit bereits korrekt ausgezeichnet. Trotzdem fehlte für mich zuerst intuitiv die eigentliche Wissensstruktur.
    Daraus ergab sich die Frage:
    Welche zusätzlichen Informationen wären semantisch sinnvoll?


    Die erste Idee: Kategorien


    Zunächst lag ein klassisches Kategorienfeld nahe.
    Zum Beispiel:


    Technik
    Gesetz
    Accessibility
    CMS


    Doch genau hier entstand das erste Problem:
    Die meisten Kategorien wiederholten lediglich Informationen, die ohnehin bereits in Frage und Antwort enthalten waren.


    Eine FAQ wie:


    „Was bedeutet WCAG 2.1?“


    trägt ihre thematische Einordnung bereits in sich.
    Zusätzliche Kategorien erzeugten deshalb kaum neue semantische Beziehungen.
    Die Struktur wurde komplexer, aber nicht intelligenter.
    Das Kategorienfeld wurde deshalb wieder verworfen.


    Die Arbeitserkenntnis: Verdichtung statt Schlagwortwolken


    Am Ende blieben zwei zusätzliche Felder übrig, die tatsächlich sinnvoll erschienen:


    
    1. FAQ-Abstract
    


    Das erste Feld war eine kurze semantische Verdichtung der eigentlichen Antwort. Aber nur aus dem Grund, weil die Antworten meistens recht lang sind. 
    
    Dieses Feld erfüllt mehrere Aufgaben gleichzeitig:


    schnellere Orientierung für Besucher
    semantische Verdichtung
    bessere maschinenlesbare Zusammenfassungen
    klarere Struktur innerhalb langer FAQ-Antworten


    Die Kurzantwort wurde dabei nicht nur im JSON-LD verwendet, sondern zusätzlich sichtbar oberhalb der eigentlichen Antwort eingebunden.


    Dadurch stimmen sichtbare Struktur und strukturierte Daten erstmals wirklich überein. Und schließlich dienen strukturierte Daten nicht dazu, komplette Fließtexte einfach in JSON-LD zu kopieren. Viel sinnvoller ist die Frage, ob Inhalte bereits redaktionell so aufgebaut sind, dass sich ihr Kern in kurzen, klaren und maschinenlesbaren Zusammenfassungen darstellen lässt. Genau daraus entstehen am Ende die wirklich interessanten Wissensstrukturen.

    Die zweite Erweiterung: verwandte Wissensobjekte


    Der zweite interessante Schritt war etwas schwieriger.

    Meine ursprüngliche Überlegung lautete:

    Welche verwandten Konzepte stehen eigentlich in inhaltlicher Beziehung zur jeweiligen FAQ-Antwort?


    Zum Beispiel:


    WCAG 2.1
    BITV
    WAI-ARIA


    Zunächst entstand die Versuchung, diese Begriffe einfach als keywords auszugeben.


    Aber damit war ich nicht zufrieden.

    Denn Keywords beschreiben eher Schlagwörter oder Suchbegriffe als tatsächliche fachliche Beziehungen.


    Somit ersetzte dann die eine Idee eine andere: Wenn eine FAQ das Barrierefreiheitsstärkungsgesetz behandelt, stehen bestimmte Begriffe nicht zufällig daneben, sondern in realer inhaltlicher Beziehung dazu.

    Das BFSG ist beispielsweise die deutsche Umsetzung des European Accessibility Act.
    Die technische Umsetzung digitaler Barrierefreiheit orientiert sich wiederum an Standards wie WCAG 2.1 oder EN 301 549.


    Zwischen diesen Begriffen bestehen also tatsächliche fachliche Zusammenhänge.


    Genau diese Beziehungen sollten sichtbar gemacht werden.


    Die bessere Lösung war deshalb schließlich:

"about":[
  {
    "@type":"Thing",
    "name":"WCAG 2.1"
  },
  {
    "@type":"Thing",
    "name":"BITV"
  }
]


    Dadurch entstanden erstmals echte Beziehungen zwischen einzelnen Wissensobjekten.


    Die FAQ bestand nun nicht mehr nur aus isolierten Fragen und Antworten, sondern begann, kleine fachliche Kontexte abzubilden.  Genau hier wurde aber auch deutlich, dass solche Strukturen nicht einfach automatisch entstehen.


    Denn die Auswahl verwandter Begriffe ist keine rein technische Aufgabe.

    Sie erfordert redaktionelle Entscheidungen.

    Nicht jeder Begriff passt automatisch zu jeder Frage.
    Und nicht jede mögliche Verbindung ist wirklich sinnvoll.


    Gerade an diesem Punkt zeigt sich, dass strukturierte Wissensmodelle nicht einfach durch möglichst viele Metadaten entstehen.
    Entscheidend ist vielmehr die Qualität der inhaltlichen Beziehungen.


    Natürlich können KI-Systeme dabei helfen, passende Konzepte oder angrenzende Themen vorzuschlagen.
    Trotzdem bleibt menschliche Prüfung wichtig.

    Denn nur durch echtes Mitdenken entsteht am Ende eine Struktur, die nicht bloß technisch korrekt ist, sondern auch fachlich nachvollziehbar.


    Die praktische Grenze: CMS-Struktur


    Spätestens an diesem Punkt zeigte sich ein typisches Problem der ernsthaften Inhaltsstrukturierung (semantischer Modellierung):
    Die Theorie ist einfacher als die CMS-Realität.

    Denn innerhalb eines FAQ-Gridfeldes ließ sich nicht ohne Weiteres ein weiteres Gridfeld verschachteln.


    Die pragmatische Lösung bestand deshalb darin, zwei feste Felder anzulegen:

faq_verwandt
faq_verwandt2

So konnten verwandte Wissensobjekte weiterhin sauber gepflegt und als einzelne Thing-Objekte im JSON-LD ausgegeben werden, ohne die bestehende FAQ-Struktur unnötig kompliziert zu machen.
Und wie diese erweiterte FAQ-Struktur schließlich direkt im CMS aussieht, zeigt der folgende Screenshot. Überforderung für Redakteure sollte hier nicht entstehen. ;)


    Ein oft übersehener Punkt: direkte Links auf einzelne FAQ-Einträge


    Besonders spannend wurde schließlich die Kombination aus:


    Anchor-Links
    Accordion-Struktur
    JSON-LD


    Denn jeder FAQ-Eintrag besitzt nun zusätzlich eine eigene URL:

"@type":"Question",
       "name":"{glossar:begriff}",
       "url":"{site_url}segertblog/{url_title}#{glossar:anker}",
       "acceptedAnswer":{
         "@type":"Answer",
         "text":"{glossar:faq_abstract}"

    
Dadurch entstehen direkt adressierbare Wissenseinheiten innerhalb einer einzelnen Seite.

    Das ist semantisch deutlich interessanter als klassische FAQ-Blöcke, die nur als geschlossener Gesamttext funktionieren. 
Praxis: Kommas, Schleifen und saubere Inhalte in ExpressionEngine
Je umfangreicher die JSON-LD-Struktur wurde, desto deutlicher zeigte sich, dass die eigentliche Herausforderung oft nicht in Schema.org selbst liegt. Die größeren Probleme entstehen meist an den Schnittstellen zwischen CMS, redaktionellen Inhalten und sauberem JSON.
Wer strukturierte Daten direkt aus ExpressionEngine erzeugt, stößt früher oder später auf typische Fragen:
Wie vermeidet man ungültiges JSON durch überflüssige Kommas?
Wie gibt man optionale Felder nur dann aus, wenn tatsächlich Inhalte vorhanden sind?
Wie verhindert man, dass HTML-Markup oder Sonderzeichen ungefiltert in strukturierte Daten gelangen?
Gerade diese scheinbaren Kleinigkeiten entscheiden am Ende darüber, ob strukturierte Daten robust, valide und langfristig wartbar bleiben.
Das Komma-Problem in wiederholenden Feldern
JSON ist an dieser Stelle kompromisslos. Bereits ein einziges überflüssiges Komma macht die gesamte Struktur ungültig.
Besonders schnell tritt dieses Problem bei wiederholenden Feldern auf, etwa bei FAQs, Glossaren oder Relationship-Feldern:
[
  {
    "name": "Erster Begriff"
  },
  {
    "name": "Zweiter Begriff"
  },
]
Das letzte Komma vor der schließenden Klammer führt bereits zu einem Fehler.
Viele Lösungen umgehen dieses Problem über zusätzliche Plugins oder komplizierte Hilfskonstruktionen. In ExpressionEngine lässt sich das jedoch direkt innerhalb der Schleife lösen:
{glossar}
{
  "@type":"Question",
  "name":"{glossar:begriff}"
}{if glossar:count < glossar:total_rows},{/if}
{/glossar}
Der entscheidende Teil ist:
{if glossar:count < glossar:total_rows},{/if}

Das Komma wird nur dann ausgegeben, wenn tatsächlich noch ein weiterer Datensatz folgt. Dadurch bleibt die JSON-Struktur unabhängig von der Anzahl der Einträge gültig.
Optionale Felder sauber ausgeben
Ein ähnliches Problem entsteht bei optionalen Informationen.
Nicht jede FAQ besitzt verwandte Themen. Nicht jede Frage benötigt zusätzliche semantische Beziehungen. Werden solche Felder dennoch pauschal ausgegeben, entstehen schnell leere Objekte oder unnötiger Ballast.
Deshalb werden zusätzliche Themen nur dann erzeugt, wenn tatsächlich Inhalte gepflegt wurden:
{if glossar:haupttopic}
{
  "@type":"Thing",
  "name":"{glossar:haupttopic}"
}
{/if}
Dasselbe Prinzip kommt später auch bei den verwandten Begriffen innerhalb des about-Arrays zum Einsatz.
Dadurch bleiben die strukturierten Daten kompakt und beschreiben nur Informationen, die tatsächlich vorhanden sind.
Saubere Inhalte statt HTML-Reste
Ein weiterer Punkt wird häufig übersehen: Viele Inhaltsfelder wurden ursprünglich für die normale Website-Ausgabe angelegt und enthalten daher HTML-Markup, Formatierungen oder Sonderzeichen.
Für strukturierte Daten sind solche Elemente meist unerwünscht.
Deshalb werden die Inhalte bereits bei der Ausgabe bereinigt:
"description":"{teaser:attr_safe}"
Bei umfangreicheren Rich-Text-Feldern kann zusätzlich ein Strippen von HTML-Tags sinnvoll sein, damit ausschließlich der eigentliche Textinhalt in den strukturierten Daten landet.
Der Grundgedanke dahinter ist einfach: Strukturierte Daten sollen Inhalte beschreiben, nicht deren Darstellung.
Das vollständige Praxisbeispiel
Die folgenden Template-Auszüge zeigen vereinfacht die finale Struktur der FAQ-Erweiterung. Der Artikel selbst wird als TechArticle beschrieben. Die einzelnen FAQ-Einträge erscheinen als eigenständige Wissenseinheiten und können zusätzlich mit verwandten Themen verknüpft werden.

An diesem Beispiel wird gut sichtbar, dass die eigentliche Schwierigkeit nicht darin besteht, JSON-LD auszugeben. Die Herausforderung liegt vielmehr darin, Inhalte so zu strukturieren, dass daraus sinnvolle semantische Beziehungen entstehen.
Die Fragen selbst werden als eigenständige Wissenseinheiten modelliert. Über die Anker-URLs sind sie direkt adressierbar. Über die Thing-Objekte entstehen fachliche Beziehungen zu verwandten Konzepten. Gleichzeitig sorgen die Schleifenlogik und die bedingten Ausgaben dafür, dass die erzeugten Daten valide und schlank bleiben.
Strukturierte Daten: Weniger ist oft mehr
Echte Wissensstrukturen entstehen nicht automatisch durch möglichst viele strukturierte Daten. Moderne Websites erzeugen oft große Mengen an Kategorien, Tags, Keywordfeldern und JSON-LD-Blöcken, ohne dass Inhalte dadurch wirklich verständlicher oder besser miteinander verbunden werden. Entscheidend ist vielmehr, ob zwischen Themen nachvollziehbare Beziehungen entstehen, Inhalte sinnvoll verdichtet werden und einzelne Wissensbereiche gezielt vertieft und miteinander verknüpft werden können.
Auch hier gilt zunächst: Weniger ist oft mehr. Für den Einstieg erwies sich eine kleinere, logischere Struktur als wesentlich sinnvoller — bestehend aus eigentlichen Fragen, kurzen Verdichtungen der Inhalte, nachvollziehbaren fachlichen Beziehungen, direkt verlinkbaren Wissenseinheiten und einer internen Verlinkung, die zusätzliche Kontexte zwischen den Themen herstellt.
Die praktischen Erfahrungen mit ExpressionEngine haben diese Einschätzung eher bestätigt. Die größten Fortschritte entstanden nicht durch immer neue Felder oder zusätzliche Metadaten, sondern durch die bewusste Auswahl weniger, aber sinnvoller Beziehungen und die saubere technische Umsetzung im Template.
Genau in dieser Verbindung aus Struktur, Orientierung und Vernetzung könnte ein wesentlicher Teil der zukünftigen Entwicklung moderner Wissens- und Informationsseiten liegen.
Was mir dabei auffällt: Der gute alte Hypertext bekommt anscheinend ein Stück seiner ursprünglichen Bedeutung zurück. Inhalte stehen nicht mehr nur isoliert nebeneinander, sondern werden wieder stärker über Beziehungen, Verweise und Kontexte miteinander verbunden. Auch darin könnte künftig ein wesentlicher Unterschied zwischen bloß veröffentlichten Informationen und tatsächlich verständlich strukturiertem Wissen liegen.
Ich bin auf jeden Fall und gerne dabei. 27 Jahre Erfahrung mit Webtexten, Navigation und Hypertext werden mir dabei sicher nicht im Wege stehen. ;)


Interview: Zwischen ExpressionEngine, KI und E-Commerce
2026-05-25T09:37:00+00:00
Wie entwickelt man seit über fünfzehn Jahren Add-ons für ExpressionEngine, ohne die Begeisterung dafür zu verlieren? Im Gespräch erzählt Rein de Vries von seinen ersten Modulen, der Entwicklung von Reinos Store zu einer ernstzunehmenden E-Commerce-Lösung und davon, warum direkte Zusammenarbeit mit Kunden für ihn so wichtig ist. Außerdem geht es um KI im Entwickleralltag, die Zukunft von ExpressionEngine und die Frage, warum technische Freiheit für viele Entwickler bis heute ein entscheidender Vorteil des CMS ist.
 
    Ralph: Ich freue mich sehr, heute dieses Gespräch mit dir zu führen – über ExpressionEngine, deine Add-ons und deine Arbeit als Entwickler. Wir haben ja vor Kurzem bei einem Projekt eng zusammengearbeitet, deshalb ist es besonders spannend, auch mal etwas persönlicher auf deinen Weg und deine Sichtweise zu schauen.


    Rein: Die Freude ist ganz meinerseits. Wir haben bei einem aktuellen Projekt tatsächlich eng zusammengearbeitet, bei dem wir das Reinos Store Modul zusammen mit einigen individuellen Erweiterungen für das Reinos Store Shipping Modul umgesetzt haben.


    Ralph: Wie bist du ursprünglich zu ExpressionEngine gekommen, und was macht das CMS für dich bis heute interessant?


    Rein: Das geht ziemlich weit zurück – kurz nach dem Release von ExpressionEngine 2. In der Firma, in der ich damals gearbeitet habe, waren wir auf der Suche nach einem neuen CMS. Nach einigen Recherchen stellte sich ExpressionEngine in praktisch allen Bereichen als die beste Lösung heraus.


    Es hat von Anfang an einfach Spaß gemacht, damit zu arbeiten. Nicht nur für unsere Kunden, sondern auch für uns Entwickler. Besonders begeistert hat uns damals das Template-System, weil es eine Freiheit ermöglicht hat, die wir vorher so nicht kannten.


    Ralph: Wie bist du dann zur Entwicklung von Add-ons gekommen, und was war dein erstes eigenes Add-on?


    Rein: Am Anfang brachte ExpressionEngine eigentlich schon fast alles mit, was wir brauchten. Aber wie bei jeder wachsenden Plattform fehlten irgendwann kleinere Funktionen. Zum Glück gab es damals Devot:ee – ein großartiges Verzeichnis für Drittanbieter-Module.


    Parallel dazu arbeitete ich noch nebenbei für eine andere Organisation und betreute eigene Kunden. Dadurch liefen immer mehr Projekte ebenfalls über ExpressionEngine. Sehr schnell brauchte ich dann für eine bestimmte Website eine Backup-Lösung, wollte aber vermeiden, zusätzliche Cronjobs auf dem Server einzurichten – wenn ich mich richtig erinnere, war das im damaligen Hosting sogar gar nicht möglich.


    Also habe ich voller Begeisterung mein erstes eigenes Add-on entwickelt: ein Modul, das automatisch Datenbank- und Dateibackups erstellt hat, sobald sich jemand ins CMS eingeloggt hat.


    Weil ich die Idee faszinierend fand, eigene Module verkaufen zu können, habe ich es direkt als kommerzielles Produkt entwickelt. Devot:ee machte das damals extrem einfach – Dokumentation, Produktseiten, alles war dort sauber organisiert.


    Ich erinnere mich noch genau an den Moment, als der erste Verkauf einging. Ich war völlig begeistert. Das Modul selbst gibt es heute schon lange nicht mehr. Inzwischen gibt es deutlich modernere und bessere Möglichkeiten für Backups. Aber damals existierte so eine Lösung eben noch nicht.


    Ralph: Du hast inzwischen eine ganze Reihe von Add-ons für ExpressionEngine entwickelt. Welches würdest du als das leistungsfähigste bezeichnen und welches als das erfolgreichste?


    Rein: Ich denke, meine Maps Suite war sowohl das erfolgreichste als auch eines der leistungsfähigsten Add-ons, die ich entwickelt habe. Ich habe relativ kurz nach Login Backup damit angefangen, also sprechen wir von ungefähr fünfzehn Jahren.


    Leider ist die Nachfrage nach solchen Kartenlösungen im Laufe der Jahre etwas zurückgegangen. Das finde ich schade, weil es nach wie vor ein unglaublich vielseitiges und spannendes Produkt ist. Trotzdem kann ich mich nicht beklagen – auch wenn die Nachfrage geringer geworden ist, gibt es immer noch einen stabilen Bedarf dafür.


    Daneben ist auch mein Store-Modul ein extrem leistungsfähiges Produkt. Ich positioniere es bewusst als leichtgewichtige und zugängliche E-Commerce-Basis, die sich über Erweiterungen flexibel ausbauen lässt. Dadurch eignet es sich für sehr viele unterschiedliche Online-Shops.


    Ralph: Anders gefragt: Welche deiner Add-ons sind deine persönlichen Favoriten, und was kann man damit konkret bauen?


    Rein: Meine persönlichen Favoriten sind definitiv die Maps Suite und das Store-Modul.


    Die Maps Suite vor allem wegen der enormen Bandbreite an Möglichkeiten. Mit relativ einfachen ExpressionEngine-Tags kann man damit unglaublich viel umsetzen. Wenn man sich die Beispiele auf der Demo-Website von Reinos anschaut, sieht man schnell, wie viele unterschiedliche Anwendungen damit möglich sind.


    Außerdem gibt es eine vollständige Integration ins Control Panel über einen eigenen Fieldtype. Dadurch können Nutzer Marker, Linien und andere Kartenelemente direkt visuell im CMS platzieren.
    

    "Kunden sind für mich unglaublich wertvoll, weil sie oft Entwicklungen anstoßen"
    

    Das Store-Modul gehört ebenfalls zu meinen Favoriten, weil die Arbeit daran sehr erfüllend ist. Damit können Website-Betreiber tatsächlich Umsatz generieren – das macht die Auswirkungen der eigenen Arbeit sehr greifbar. Ich kann inzwischen auch mit gutem Gewissen sagen, dass sich das Store-Modul zu einer ausgereiften E-Commerce-Lösung entwickelt hat, die sowohl kleinere Shops als auch größere und anspruchsvollere Projekte bedient.
    

        Ralph: Bei unserem letzten Projekt mit Store und Store Shipping habe ich deinen Support als sehr direkt und lösungsorientiert erlebt – besonders die Art, wie konkrete Anforderungen schnell gemeinsam zu neuen Features wurden. Wie siehst du diese Arbeitsweise selbst? Und was steht aktuell auf der Roadmap deiner Shop-Add-ons? Außerdem: Wie wird die Lösung insgesamt angenommen, und für welche Projekte eignet sich Store deiner Meinung nach besonders im Vergleich zu größeren E-Commerce-Systemen?
    

        Rein: Ja, wir haben bei einigen Themen sehr direkt zusammengearbeitet – und genau so arbeite ich am liebsten.
    

    Kunden sind für mich unglaublich wertvoll, weil sie oft Entwicklungen anstoßen, auf die ich alleine gar nicht unbedingt gekommen wäre. Sie nutzen das Produkt im echten Alltag und entdecken dadurch Probleme, Engstellen oder Möglichkeiten, die ich selbst vielleicht nicht sofort sehe. Deshalb entwickle ich Vorschläge, die allgemein sinnvoll erscheinen, häufig direkt weiter.
    

    Im Vergleich zu größeren E-Commerce-Lösungen wie CartThrob war Reinos Store ursprünglich eher auf kleinere Shopbetreiber ausgerichtet. Das zeigt sich auch im Preis und in der niedrigeren Einstiegshürde.
    

    Durch die vielen Weiterentwicklungen konkurriert das Store-Modul inzwischen aber deutlich stärker mit den großen E-Commerce-Add-ons. Über das ständig wachsende Erweiterungs-System deckt es mittlerweile viele Anforderungen größerer Shops ab.
    

    Zum Beispiel:
    

        Das Store Shipping Modul ergänzt komplexe Versandlogiken und verschiedene Versandarten.
        Das Tax Modul erweitert die Steuerverwaltung erheblich, inklusive vollständiger MOSS-Unterstützung innerhalb der EU.
        Mit dem Discount Modul lassen sich Rabattregeln pro Produkt, Warenkorb oder Benutzer definieren.
        Und sehr bald wird es außerdem eine direkte Unterstützung für MyParcel geben.
    

    Aktuell stehen drei größere Punkte auf der Roadmap: Kreditkartenzahlungen direkt auf der Website, Unterstützung für Abonnements, und die Möglichkeit, Bestellpositionen direkt innerhalb einer Bestellung zu bearbeiten.
    

        Ralph: Was würdest du dir für die Zukunft von ExpressionEngine wünschen? Gibt es Entwicklungen der letzten Jahre, die du kritisch siehst – etwa das Lizenzmodell – oder ist das für dich kein großes Thema? Und wo siehst du generell Verbesserungspotenzial?
    

        Rein: Die Entwicklung von ExpressionEngine in den letzten Jahren war eigentlich sehr positiv. Die Plattform ist enorm gereift und deutlich ausgereifter als früher.
    

    ExpressionEngine: "Die Plattform ist enorm gereift"
    

    Das Lizenzmodell halte ich persönlich für notwendig, damit die Weiterentwicklung gesund und nachhaltig finanziert werden kann. Das Gleiche gilt für kommerzielle Module. Ich glaube sogar, dass genau diese Struktur Qualität, Kontinuität und vernünftigen Support sichert – sowohl für ExpressionEngine selbst als auch für Drittentwickler.
    

        Ralph: Wie sieht dein Entwickleralltag aktuell aus? Und wie nimmst du die Situation für Entwickler in den Niederlanden wahr – sowohl was die Community als auch die wirtschaftlichen Bedingungen betrifft? Gibt es mehr Preisdruck oder stärkere Konkurrenz, oder ist die Lage insgesamt stabil?
    

        Rein: Die Arbeit an den Modulen ist nicht jeden Tag eine Vollzeitbeschäftigung, aber es gibt durchaus Phasen, in denen die Entwicklung eines bestimmten Features den kompletten Arbeitstag einnimmt.
    

    Ich nutze ExpressionEngine außerdem auch für eigene Projekte. Wenn ich dabei Funktionen entdecke, die auch für andere Nutzer interessant wären, integriere ich diese Verbesserungen oft direkt in die Module. Das kostet natürlich Zeit, weil ein Modul sauber geplant, durchdacht, getestet und dokumentiert werden muss.
    

    Zusätzlich nimmt auch der Kundensupport einen beträchtlichen Teil meiner Zeit ein.
    

    Was mir immer häufiger auffällt: KI-generierte Antworten liegen oft sehr selbstbewusst daneben. Menschen melden sich regelmäßig mit Lösungsvorschlägen oder Code, die schlicht nicht existieren, aber von KI-Systemen überzeugend dargestellt wurden. Diese Fehlinformationen wieder geradezurücken kostet leider ebenfalls einiges an Zeit.
    

    In den vergangenen Jahren habe ich außerdem beobachtet, dass die Popularität von ExpressionEngine etwas zurückgegangen ist. Das finde ich schade, denn technisch ist es nach wie vor eine sehr starke Plattform. Viele entscheiden sich heute eher für Baukasten-ähnliche Systeme im Stil von WordPress.
    

    Mit dem Aufkommen von KI, die die Produktivität massiv steigert, bin ich selbst gespannt, wie sich ExpressionEngine langfristig entwickeln wird. ExpressionEngine ist ein technisch orientiertes CMS und setzt ein gewisses Verständnis voraus. Ich sehe hier großes Potenzial in stärker vorbereiteten Templates, Channels und Feldstrukturen, damit Nutzer deutlich schneller starten können.
    

    Außerdem war ExpressionEngine immer ein bisschen ein Geheimtipp. Ich denke schon, dass sich die Sichtbarkeit der Plattform künftig verbessern sollte.
    

        Ralph: Was sind die fünf wichtigsten Werkzeuge in deinem Arbeitsalltag – und warum gerade diese? Hat sich dein Werkzeugkasten über die Jahre stark verändert, etwa durch neue Technologien oder veränderte Anforderungen?
    

        Rein: Meine fünf täglichen Essentials wären:
    

        Visual Studio Code – für die komplette Entwicklungsarbeit.
        KI-Tools – mein Junior-Assistent für viele tägliche Aufgaben.
        Gitea – meine selbstgehostete GitHub-Alternative für Versionsverwaltung.
        MacBook – einfach der beste Laptop, mit dem ich in den letzten fünfzehn Jahren gearbeitet habe.
        Kaffee – weil jeder produktive Tag mit einer richtig guten Tasse Kaffee beginnt.
    

    Und ja: KI-Tools wie Copilot gehören inzwischen definitiv ebenfalls dazu.
    

        Ralph: Danke für die spannenden Antworten und dass Du Dir die Zeit genommen hast.


    
Über Rein de Vries
Rein de Vries ist ein engagierter Webentwickler mit über 20 Jahren Erfahrung in der Entwicklung digitaler Lösungen, die auf seiner Website reinos.nl zu finden sind. Er hegt eine ausgeprägte Leidenschaft für Innovationen, verfolgt aufmerksam die neuesten technologischen Entwicklungen und engagiert sich aktiv in Projekten im Bereich der nachhaltigen Energie. Außerhalb seiner beruflichen Tätigkeit trägt er seine Liebe zur Technik in die Lüfte – als begeisterter FPV-Drohnenpilot. Rein ist 40 Jahre alt, glücklich verheiratet und stolzer Vater zweier Kinder.


Wie ich arbeite – und was eine Website langfristig tragfähig macht
2026-03-03T09:54:00+00:00
Wenn ich ein Website-Projekt übernehme, das in der Zukunft wachsen soll, baue ich keine digitale Visitenkarte, die zwei Jahre gut aussieht und dann an ihre technischen Grenzen stößt.  Eine Website ist für mich nicht nur eine hippe Selbstdarstellung, sondern immer auch eine Art Infrastruktur, die wachsenden Anforderungen gerecht werden muss. Und eine funktionierende Infrastruktur erkennt man daran, dass sie zuverlässig arbeitet, auch ohne Web-Spezialisten und über Jahre hinweg.

Natürlich spielt Gestaltung eine Rolle. Typografie, Bildsprache, Struktur, Klarheit – all das ist wichtig. Aber Design ist für mich nicht Dekoration, sondern Ausdruck einer durchdachten Architektur. Eine Website muss nicht nur gut aussehen, sie muss stabil bleiben, erweiterbar sein und sich an neue Anforderungen anpassen lassen. 
    Langfristigkeit ist kein Zufall


    Einige meiner ältesten Kunden arbeiten seit über zwanzig Jahren mit mir zusammen. Ihre Websites haben in dieser Zeit mehrere Redesigns erlebt, strukturelle Erweiterungen, inhaltliche Neuausrichtungen und technische Updates. Systeme wurden modernisiert und weiterentwickelt, einmal sogar vollständig von WordPress auf ExpressionEngine umgestellt – ohne nennenswerte Ausfälle, ohne Chaos, ohne „Jetzt müssen wir alles neu machen“-Momente. Das ist kein Zufall. Das ist das Ergebnis vorausschauender Entscheidungen.


    Ein Beispiel: Bereits 2011 hat sich ein Kunde bewusst für ExpressionEngine entschieden – und damals schon für eine responsive Umsetzung. Das war zu einer Zeit, als „responsive“ noch kein selbstverständlicher Standard war. Die technische Grundlage wurde so aufgebaut, dass Inhalte klar von Layout und Struktur getrennt sind. Genau das macht heute den Unterschied. Beim aktuellen Redesign konnte das komplette Erscheinungsbild neu gedacht und technisch modernisiert werden, ohne dass Inhalte gefährdet oder mühsam übertragen werden mussten. Texte, Bilder und Strukturen blieben stabil, während das Layout vollständig erneuert wurde. Das ist der Vorteil einer sauber angelegten CMS-Architektur: Man kann weiterentwickeln, ohne das Fundament zu beschädigen.
    


    Qualität entsteht vor der Veröffentlichung


    Ich denke Projekte nicht bis zur Veröffentlichung, sondern weiter. Ich frage mich schon beim ersten Entwurf: Ist das updatefähig? Ist das strukturell sauber? Kann man Inhalte erweitern, ohne dass alles auseinanderfällt? Was passiert in fünf Jahren? In zehn?


    Diese Fragen stellt man sich nicht, wenn man nur auf die Oberfläche schaut. Aber genau dort entscheidet sich Qualität. Eine Website ist kein einmaliges Ereignis. Sie ist ein System, das wachsen und sich verändern muss. Wer das am Anfang nicht berücksichtigt, zahlt später doppelt.


    Struktur statt Baukasten


    Heute kann man Websites sehr schnell erstellen. Themes, Page Builder, fertige Vorlagen – technisch ist vieles möglich. Das ist nicht grundsätzlich falsch. Für manche Projekte ist das ausreichend.


    Ich arbeite bewusst anders. Ich baue keine Klicklösung, sondern eine strukturierte Grundlage. Ich achte auf sauberes Markup, klare Inhaltslogik und eine technische Basis, die langfristig stabil bleibt. Suchmaschinenoptimierung ist dabei kein nachträgliches Plugin, sondern Teil der Struktur. Inhalte werden so angelegt, dass sie logisch eingebettet sind und nicht zufällig das Layout beeinflussen.


    Der Unterschied zeigt sich selten am ersten Tag. Er zeigt sich nach Jahren.


    Verantwortung endet nicht mit dem Launch


    Ein Projekt ist für mich nicht abgeschlossen, wenn es online geht. Ich bleibe ansprechbar. Ich beobachte Entwicklungen, prüfe Updates, korrigiere Kleinigkeiten, bevor sie zu größeren Problemen werden. Manchmal passe ich Dinge an, ohne dass daraus ein neues Projekt entsteht. Nicht, weil ich großzügig sein möchte, sondern weil ich Verantwortung ernst nehme.


    Zuverlässigkeit bedeutet für mich, dass man sich auf Absprachen verlassen kann. Dass Systeme stabil laufen. Dass Entscheidungen nicht kurzfristig beeindrucken, sondern langfristig tragen. Gewissenhaftigkeit heißt, auch unsichtbare Details ernst zu nehmen – gerade die, die später entscheidend werden.


    Erfahrung als Entscheidungsqualität


    Nach über zwanzig Jahren im Web arbeite ich heute schneller als früher. Nicht weil ich oberflächlicher arbeite, sondern weil ich Entscheidungen sicherer treffe. Ich weiß, welche Lösungen sich bewähren und welche nur kurzfristig modern wirken. Ich erkenne strukturelle Schwächen frühzeitig. Das spart Zeit – und es vermeidet spätere Kosten.


    Ich arbeite in Personalunion. Konzeption, Gestaltung, technische Umsetzung und Systemarchitektur greifen ineinander. Es gibt keine Übergaben zwischen Abteilungen, keine Missverständnisse durch interne Abstimmungen. Verantwortung ist klar. Entscheidungen sind konsistent.


    Für wen ich arbeite


    Ich arbeite gern mit Menschen, die verstehen, dass eine Website mehr ist als eine Oberfläche. Mit Unternehmen, die Wert auf Stabilität, Struktur und langfristige Perspektive legen. Mit Auftraggebern, die nicht nur „online sein“ möchten, sondern digital verlässlich aufgestellt sein wollen.


    Wenn es um kurzfristige Effekte geht, gibt es viele Anbieter. Wenn es um eine tragfähige, durchdachte Grundlage geht, sprechen wir vermutlich dieselbe Sprache.


    Fazit


    Eine gute Website erkennt man nicht nur am Design. Man erkennt sie daran, wie ruhig sie läuft. Wie flexibel sie sich weiterentwickeln lässt. Wie problemlos sie Updates übersteht. Und daran, dass man auch nach Jahren nicht bei null anfangen muss.


    Redesign einer 13 Jahre alten Website mit ExpressionEngine


    Vor dem Redesign: responsive Website zwischen 2012 und 2025 für Thomas Paul Zahntechnik, Berlin


    



    Nach dem Redesign 2026. Kein Text und kein Bild musste geändert oder angepasst werden. Die Template-Struktur im CMS blieb unbebrührt, ebenso die Navigation.

segert.net segertblog

Zur Sichtbarkeit von Fachwissen, Kompetenzen und Marke in KI-Systemen

Wenn Angebote sichtbar sind, aber Expertise nicht

Vom Fachwissen zur digitalen Wahrnehmung

Leitfragen

Von der Analyse zur Umsetzung

Relevante Grundlagen- und Praxis-Artikel

KI-Sichtbarkeit und GEO: Die Website als Wissensraum

1. Warum sich Suche gerade verändert

2. Die Website als Wissensraum

3. KI-Sichtbarkeit: Was damit realistisch gemeint ist

4. Drei Praxisbeispiele

5. Warum die technische Struktur für KI-Sichtbarkeit wichtig ist

Relevante Artikel

Quellen und weiterführende Informationen

Über Ralph Segert

Konzeptionelles und individuelles Webdesign ohne Page Builder wie Elementor, DIVI und Co

Gutes Webdesign ist mehr als Gestaltung

Die Vorteile von Page Buildern

Die Grenzen von Page Buildern

Die Freiheit konzeptionellen Webdesigns

Warum individuelle Entwicklung langfristig Vorteile bietet

SEO, Barrierefreiheit und KI-Sichtbarkeit

Struktur schlägt Gestaltung

Überwiegt der Preisnachteil?

Fazit

Mit ExpressionEngine effektiv und pflegeleicht strukturierte Daten entwickeln

Die Startseite als Ausgangspunkt der gesamten JSON-LD-Architektur

Warum die Entwicklung mit der Startseite beginnt

Die erste Überlegung

Der erste JSON-LD-Block

Der eigentliche Zweck dieser Struktur

Die Startseite als CollectionPage mit Grid-Feldern: Warum die Startseite mehr leisten muss

Der Aufbau in ExpressionEngine

Das sichtbare Template der Startseite

{title}

{title}

{cards:thema}

{title}

Aktuelles

{title}

Aus dem sichtbaren Aufbau wird JSON-LD

Der JSON-LD-Code für die Startseite

Warum diese Lösung sauber ist

Themenübersichten mit CollectionPage und ItemList: Von mehreren Templates zu einer zentralen Lösung

Der entscheidende Perspektivwechsel

Die URL übernimmt das Routing

Der vollständige Template-Code

Warum die CollectionPage eine Beschreibung erhält

Die gleiche Strategie für alle Artikel

Der vollständige Template-Code

Vorhandene Inhalte intelligent wiederverwenden

Fazit

Verwandte Artikel

Entity SEO und Topical Authority oder warum Wissen mehr ist als Content

Entity SEO und Topical Authority

Was bedeutet Entity SEO?

Was bedeutet Topical Authority?

Wenn aus Konzepten Rezepte werden

Wissen ist mehr als Content

Was durch KI und moderne Suchsysteme neu geworden ist

KI-Sichtbarkeit als strategische Aufgabe

Fazit

Passende Artikel zum Thema

Warum ich bei moderner CSS-Typografie kaum noch line-height benutze

Schriftgrößen mit clamp()

Warum ich immer seltener line-height setze

Auch Abstände lassen sich dynamisch gestalten

Das Austarieren bleibt wichtig

Weniger Media Queries, weniger Pflegeaufwand

Praxisbericht: Eine flexible und pflegeleichte Startseite mit ExpressionEngine

Der Aufbau der Startseite

Die erste Idee: Alles über Grid-Felder

Kategorien oder zusätzliche Steuerfelder?

Die einfache Lösung – wie so oft über Umwege

Template-Code: Ein bewusster Kompromiss

{title}

{title}

{cards:thema}

{title}

Schriftgrößen mit `clamp()`

Warum ich immer seltener `line-height` setze