Warum gute Websites weniger Inhalte brauchen, aber bessere
Ein Website Content-Modell macht aus unübersichtlichen Leistungstexten klar definierte Entitäten, Felder und Beziehungen. Der Leitfaden zeigt, wie KMU strukturierte Inhalte prüfen, mehrsprachig pflegen und kontrolliert für Website, Google-Dienste und API ausgeben.

Ein Website Content-Modell beschreibt, welche Inhaltsobjekte existieren, welche Felder diese Objekte besitzen, wie sie miteinander verbunden sind und nach welchen Regeln Inhalte geprüft werden. Für Dein KMU bedeutet das: Aus einem schwer wiederverwendbaren Leistungstext entstehen strukturierte Inhalte, die Du fachlich prüfen, übersetzen und kontrolliert für die Website, Google-Dienste oder eine API bereitstellen kannst.

In meinen Website-Projekten mit kleinen und inhabergeführten Betrieben sehe ich häufig denselben Ausgangspunkt: Die Leistungen sind fachlich klar, aber über Fließtexte, PDFs, E-Mails, Angebotsvorlagen und einzelne Unterseiten verteilt. Sobald sich eine Bezeichnung, Telefonnummer oder Verfügbarkeit ändert, beginnt die Suche nach allen Stellen, an denen dieselbe Angabe vorkommt.

Ein gutes Content-Modell speichert eine Information nicht dort, wo sie angezeigt wird, sondern dort, wo sie fachlich verantwortet und zuverlässig gepflegt werden kann.

Vom Leistungstext zum Website Content-Modell

Für das durchgängige Beispiel nehmen wir einen Südtiroler Handwerksbetrieb, der individuelle Innenausbauten anbietet. Auf der bisherigen Website steht folgender Absatz:

„Wir planen und realisieren individuelle Innenausbauten für Privatpersonen, Hotels und Gastronomiebetriebe in ganz Südtirol. Beratung ist auf Deutsch und Italienisch möglich. Der Preis richtet sich nach Umfang, Material und Montageaufwand. Für eine Anfrage kannst Du uns anrufen oder das Kontaktformular verwenden.“

Der Absatz ist für Menschen verständlich. Für die Content-Modellierung hat der Absatz jedoch einen Nachteil: Leistungsname, Zielgruppen, Gebiet, Sprachen, Preislogik und Kontaktwege sind miteinander vermischt. Möchtest Du später nur italienisch verfügbare Leistungen anzeigen oder Leistungen für Hotels an eine andere Anwendung übergeben, muss der Text zuerst interpretiert werden.

Deshalb zerlegen wir den Leistungskatalog in fachlich erkennbare Objekte. Eine solche Entität ist ein eindeutig beschreibbares Inhaltsobjekt mit einer eigenen Identität.

  • Leistung: etwa „Individueller Innenausbau“
  • Zielgruppe: etwa Privatpersonen, Hotellerie oder Gastronomie
  • Standort oder Leistungsgebiet: etwa Südtirol, Bozen oder Meran
  • Ansprechpartner: die fachlich zuständige Person
  • Kontaktweg: Telefon, E-Mail oder Anfrageformular
  • Branche: etwa Tourismus, Gastronomie oder privates Wohnen
  • Referenz: ein abgeschlossenes Projekt, das die Leistung belegt
  • Frage und Antwort: eine häufige Frage zur Leistung

Die sichtbare Leistungsseite ist damit nicht mehr das eigentliche Datenobjekt. Die Seite ist eine Ausgabe, die Informationen aus mehreren Entitäten zusammenführt. Das Website Content-Modell beschreibt die zugrunde liegenden Inhalte; der Seitenaufbau bestimmt deren sichtbare Darstellung.

Felder im Website Content-Modell: die Entität Leistung

Ein brauchbares Feldschema enthält nicht nur Feldnamen. Für jedes Feld solltest Du Zweck, Datentyp, Pflichtstatus, erlaubte Werte und mindestens eine Validierungsregel festhalten. Jede Regel braucht einen betrieblichen Grund: Sie soll Fehler verhindern, Verantwortlichkeiten klären oder eine spätere Nutzung ermöglichen.

Eindeutige ID

  • Feldname: leistungs_id
  • Zweck: Die eindeutige ID verbindet dieselbe Leistung zuverlässig mit Übersetzungen, Referenzen, Kontaktwegen und externen Systemen.
  • Datentyp: Zeichenfolge
  • Pflichtfeld: Ja
  • Validierungsregel: Die ID muss eindeutig, unveränderlich und frei von Leerzeichen sein, zum Beispiel „leistung-innenausbau-001“.
  • Betrieblicher Nutzen: Eine spätere Namensänderung unterbricht keine Beziehungen und keine API-Verknüpfung.

Leistungsname

  • Feldname: name
  • Zweck: Eindeutige und verständliche Bezeichnung der Leistung.
  • Datentyp: übersetzbare Zeichenfolge
  • Pflichtfeld: Ja, je veröffentlichter Sprache
  • Validierungsregel: Der Name darf nicht leer sein, sollte nicht mit einer anderen Leistung identisch sein und bleibt beispielsweise auf 80 Zeichen begrenzt.
  • Betrieblicher Nutzen: Kurze Namen funktionieren in Navigation, Suche, Auswahlfeldern und mobilen Ansichten.

Kurzbeschreibung

  • Feldname: kurzbeschreibung
  • Zweck: Erklärt in ein bis zwei Sätzen, was angeboten wird.
  • Datentyp: übersetzbarer Text
  • Pflichtfeld: Ja
  • Validierungsregel: Mindest- und Maximallänge festlegen, zum Beispiel 80 bis 240 Zeichen; Telefonnummern und Preise gehören in eigene Felder.
  • Betrieblicher Nutzen: Dieselbe Kurzfassung kann in Übersichten, der internen Website-Suche und ausgewählten Schnittstellen verwendet werden.

Nutzen

  • Feldname: nutzen
  • Zweck: Beschreibt das konkrete Ergebnis für den Auftraggeber.
  • Datentyp: Liste übersetzbarer Textbausteine
  • Pflichtfeld: Mindestens ein Eintrag
  • Validierungsregel: Jeder Eintrag enthält genau einen Nutzen und bleibt unter einer festgelegten Zeichenlänge.
  • Betrieblicher Nutzen: Einzelne Nutzenargumente lassen sich je nach Zielgruppe auswählen, ohne den gesamten Text neu zu schreiben.

Zielgruppen und Branchen

  • Feldnamen: zielgruppen_ids und branchen_ids
  • Zweck: Ordnen eine Leistung den passenden Zielgruppen und Branchen zu.
  • Datentyp: Liste von Beziehungen zu anderen Entitäten
  • Pflichtfeld: Mindestens eine Zielgruppe; die Branche ist je nach Betrieb optional.
  • Validierungsregel: Es dürfen nur vorhandene und freigegebene IDs gewählt werden.
  • Betrieblicher Nutzen: Die Zielgruppe „Hotellerie“ wird einmal gepflegt und kann mit mehreren Leistungen verbunden werden.

Preislogik

  • Feldname: preislogik
  • Zweck: Beschreibt, wie ein Preis grundsätzlich zustande kommt.
  • Datentyp: Auswahlwert
  • Pflichtfeld: Ja, wenn Preise oder Preisangaben kommuniziert werden
  • Erlaubte Werte: Festpreis, Ab-Preis, nach Aufwand, individuelles Angebot oder auf Anfrage
  • Validierungsregel: Freitext ist nicht erlaubt; ergänzende Hinweise kommen in ein separates Textfeld.
  • Betrieblicher Nutzen: Preisangaben bleiben vergleichbar und widersprechen sich nicht zwischen Übersichts- und Detailseiten.

Verfügbarkeit und Leistungsgebiet

  • Feldnamen: verfügbarkeit und standort_ids
  • Zweck: Legt fest, ob und wo die Leistung angeboten wird.
  • Datentyp: definierter Status plus Beziehungen zu Standorten oder Gebieten
  • Pflichtfeld: Ja
  • Erlaubte Statuswerte: verfügbar, eingeschränkt verfügbar, vorübergehend nicht verfügbar oder eingestellt
  • Validierungsregel: Bei eingeschränkter Verfügbarkeit muss ein Hinweis oder ein Zeitraum hinterlegt sein.
  • Betrieblicher Nutzen: Nicht verfügbare Leistungen können kontrolliert ausgeblendet werden, ohne sie endgültig zu löschen.

Sprachen

  • Feldname: verfügbare_sprachen
  • Zweck: Hält fest, in welchen Sprachen Beratung oder Durchführung möglich ist.
  • Datentyp: Liste standardisierter Sprachcodes, zum Beispiel de und it
  • Pflichtfeld: Ja
  • Validierungsregel: Nur definierte Sprachwerte verwenden; Beratungssprache und Sprache des Website-Textes nicht vermischen.
  • Betrieblicher Nutzen: Ein italienischer Beschreibungstext behauptet nicht automatisch, dass die Leistung auch auf Italienisch erbracht wird.

Kontaktweg und Aktualität

  • Feldnamen: kontaktweg_ids, aktualisiert_am und freigabestatus
  • Zweck: Verknüpft die Leistung mit gültigen Kontaktmöglichkeiten und dokumentiert ihren redaktionellen Zustand.
  • Datentyp: Beziehungen, Datum und Auswahlwert
  • Pflichtfeld: Ja
  • Erlaubte Freigabewerte: Entwurf, fachlich geprüft, redaktionell geprüft, freigegeben oder archiviert
  • Validierungsregel: Eine Veröffentlichung ist nur mit mindestens einem aktiven Kontaktweg und einer abgeschlossenen Freigabe zulässig.
  • Betrieblicher Nutzen: Besucher erhalten keine veraltete Telefonnummer, und unfertige Übersetzungen gehen nicht versehentlich online.

Beziehungen im Website Content-Modell richtig anlegen

Eine Beziehung verbindet zwei Entitäten über ihre IDs. Die Leistung „Individueller Innenausbau“ kann beispielsweise mit den Zielgruppen „Privatpersonen“, „Hotellerie“ und „Gastronomie“ verbunden sein. Dieselbe Leistung kann außerdem mehreren Standorten, Referenzen, Ansprechpartnern und häufigen Fragen zugeordnet werden.

Der Vorteil zeigt sich bei einer Änderung: Scheidet ein Ansprechpartner aus, änderst Du die Person oder die Verknüpfung einmal. Du musst nicht jede Leistungsseite durchsuchen. Dasselbe gilt für Telefonnummern, Leistungsgebiete, Branchenbezeichnungen und Kontaktformulare.

In über 20 Jahren Arbeit an Websites und digitalen Systemen habe ich gelernt: Der häufigste Modellierungsfehler ist nicht ein vergessenes Feld. Häufiger entsteht eine Struktur, die nur die aktuelle Website abbildet. Ein erweiterbares Modell berücksichtigt auch zusätzliche Kanäle, Mehrsprachigkeit, fachliche Zuständigkeiten und technische Übergaben.

Modelliere die fachlichen Inhalte und ihre Beziehungen, nicht nur den Aufbau der aktuellen Website.

Vorher und nachher: ein Leistungstext als Datensatz

Der ursprüngliche Absatz wird nun in einzelne Angaben zerlegt:

  • Leistungsname: Individueller Innenausbau
  • Kurzbeschreibung: Planung, Fertigung und Montage individueller Innenausbauten für private und gewerbliche Räume.
  • Nutzen: passgenaue Raumlösung, abgestimmte Materialwahl, ein verantwortlicher Kontaktweg
  • Zielgruppen: Privatpersonen, Hotellerie, Gastronomie
  • Preislogik: individuelles Angebot
  • Verfügbarkeit: verfügbar
  • Leistungsgebiet: Südtirol
  • Beratungssprachen: Deutsch und Italienisch
  • Kontaktwege: Telefon und Anfrageformular
  • Aktualisierungsdatum: 2026-03-15
  • Freigabestatus: freigegeben

Eine mögliche JSON-Ausgabe über eine API kann daraus so aussehen:

{
  "id": "leistung-innenausbau-001",
  "name": {
    "de": "Individueller Innenausbau",
    "it": "Arredamento d'interni su misura"
  },
  "kurzbeschreibung": {
    "de": "Planung, Fertigung und Montage individueller Innenausbauten für private und gewerbliche Räume.",
    "it": "Progettazione, produzione e montaggio di arredamenti su misura per spazi privati e commerciali."
  },
  "nutzen": {
    "de": [
      "Passgenaue Raumlösung",
      "Abgestimmte Materialwahl",
      "Ein verantwortlicher Kontaktweg"
    ]
  },
  "zielgruppen_ids": [
    "zielgruppe-privat",
    "zielgruppe-hotellerie",
    "zielgruppe-gastronomie"
  ],
  "preislogik": "individuelles_angebot",
  "verfuegbarkeit": "verfuegbar",
  "standort_ids": [
    "gebiet-suedtirol"
  ],
  "beratungssprachen": [
    "de",
    "it"
  ],
  "kontaktweg_ids": [
    "kontakt-telefon-zentrale",
    "kontakt-formular-projektanfrage"
  ],
  "aktualisiert_am": "2026-03-15",
  "freigabestatus": {
    "de": "freigegeben",
    "it": "freigegeben"
  }
}

Das JSON ist nicht das Content-Modell selbst. JSON ist eine technische Darstellung eines Datensatzes, der nach dem Modell erfasst wurde. Das Modell legt fest, welche Felder erlaubt sind, welche Beziehungen gelten und wann der Datensatz veröffentlicht werden darf.

Das Website Content-Modell als zentrale Inhaltsbasis

Wenn derselbe freigegebene Datensatz mehrere Kanäle versorgt, entsteht eine Single Source of Truth für Dein KMU. Das bedeutet nicht, dass jeder Kanal jedes Feld unverändert übernimmt. Die zentrale Inhaltsbasis liefert verlässliche Ausgangsdaten; kanalspezifische Regeln bestimmen Auswahl, Format und Freigabe.

Ausgabe auf der Website

Die Leistungsseite kann Leistungsname, Beschreibung, Nutzen, Referenzen, häufige Fragen und Kontaktweg kombinieren. Eine Übersichtsseite verwendet dagegen vielleicht nur Name, Kurzbeschreibung und Bild. Beide Seiten greifen auf dieselbe Leistung zurück, statt getrennte Kopien zu führen.

Strukturierte Daten auf der Website

Für maschinenlesbare Leistungsdaten kannst Du Dich an den offiziell beschriebenen Eigenschaften und erwarteten Typen von Schema.org für den Typ Service orientieren. Dort sind unter anderem Eigenschaften wie serviceType, provider, areaServed und availableChannel dokumentiert.

Eine technisch korrekte Schema.org-Auszeichnung garantiert jedoch keine Darstellung in einem Google-Produkt und keine bessere Platzierung. Strukturierte Inhalte und ihre Auszeichnung können Systemen dabei helfen, Bedeutung und Beziehungen einzuordnen. Welche strukturierten Daten für Dein KMU zuerst sinnvoll sind, erläutere ich im Beitrag über Prioritäten bei strukturierten Website-Daten.

Google-Unternehmensprofil und Google-Schnittstellen

Unternehmensdaten auf der eigenen Website, strukturierte Website-Daten und Angaben im Google-Unternehmensprofil sind drei unterschiedliche Ebenen. Eine Leistung in Deinem Content-Modell wird nicht automatisch und vollständig in das Google-Unternehmensprofil übertragen.

Google dokumentiert für seine Business Profile APIs getrennte Funktionsbereiche, beispielsweise für Unternehmensinformationen, Attribute, Kategorien, Medien, Beiträge, Bewertungen oder branchenspezifische Daten. Welche Angaben verwaltet werden können, hängt von der jeweiligen Schnittstelle, den Profilberechtigungen, der Unternehmenskategorie und den aktuellen Vorgaben ab. Maßgeblich bleibt die offizielle Dokumentation der Google Business Profile APIs.

In der Praxis brauchst Du deshalb ein Kanal-Mapping. Das Kanal-Mapping legt fest, welches interne Feld zu welchem erlaubten Google-Feld passt, wer die Übertragung freigibt und was passiert, wenn der Zielkanal eine Angabe nicht unterstützt.

Ausgabe über eine eigene API

Eine API kann freigegebene Leistungen als JSON für eine App, einen Shop, einen zweiten Webauftritt oder ein internes Angebotssystem bereitstellen. Eine API-first geplante Lösung trennt fachliche Inhalte von der sichtbaren Oberfläche. Die API sollte nur benötigte und freigegebene Felder ausgeben, nicht ungeprüft den gesamten internen Datensatz.

Das Website Content-Modell in acht Schritten umsetzen

1. Bestehende Inhalte inventarisieren

Sammle Leistungsseiten, PDFs, Preislisten, Angebotsbausteine, Profilangaben, Kontaktinformationen und Übersetzungen. Markiere Dubletten, Widersprüche und Inhalte ohne erkennbare verantwortliche Person.

2. Entitäten bestimmen

Identifiziere wiederkehrende Objekte wie Leistung, Standort, Person, Zielgruppe, Branche, Referenz und Kontaktweg. Prüfe bei jedem Objekt, ob es eine eigene Identität besitzt und mehrfach verwendet werden kann.

3. Felder definieren

Lege pro Entität fest, welche Angaben gebraucht werden. Trenne Inhalte, die unterschiedlich geprüft, übersetzt, gefiltert oder ausgegeben werden müssen.

4. Beziehungen festlegen

Dokumentiere, welche Entitäten miteinander verbunden werden dürfen. Definiere auch die Anzahl: Eine Leistung hat beispielsweise mindestens einen Kontaktweg, kann aber mehrere Zielgruppen und Referenzen besitzen.

5. Regeln dokumentieren

Bestimme für jedes Feld Datentyp, Pflichtstatus, erlaubte Werte und Validierungsregel. Erkläre zusätzlich, welchen Fehler die Regel verhindert. Ohne nachvollziehbaren betrieblichen Zweck werden Regeln im Alltag häufig umgangen.

6. Beispieldaten erfassen

Teste das Modell nicht nur mit einer einfachen Leistung. Erfasse mindestens eine mehrsprachige Leistung, ein individuelles Angebot und eine vorübergehend nicht verfügbare Leistung. Solche Grenzfälle zeigen früh, ob das Modell tragfähig ist.

7. Redaktionell und fachlich prüfen

Die fachliche Prüfung beantwortet: Ist die Aussage korrekt? Die redaktionelle Prüfung beantwortet: Ist die Aussage verständlich, konsistent und in der jeweiligen Sprache passend? Erst danach folgt die redaktionelle Freigabe.

8. Technisch ausspielen und kontrollieren

Gib freigegebene Daten an Website-Komponenten, strukturierte Datenauszeichnungen oder eine API weiter. Prüfe anschließend die tatsächliche Ausgabe und nicht nur die Eingabemaske.

Mehrsprachigkeit im Website Content-Modell

Bei Südtiroler KMU ist Mehrsprachigkeit keine nachträgliche Übersetzungsaufgabe. Sprachneutrale Daten und übersetzbare Inhalte müssen im Modell getrennt werden.

  • Sprachneutral: eindeutige ID, Preislogik, Verfügbarkeit, Standortbeziehung und Aktualisierungsdatum
  • Übersetzbar: Leistungsname, Kurzbeschreibung, Nutzen, Hinweise und häufige Fragen
  • Je Sprache freizugeben: Textqualität, Terminologie, URL, Seitentitel und redaktioneller Status
  • Nicht gleichzusetzen: Sprache des Inhalts und Sprache, in der eine Beratung oder Leistung verfügbar ist

So kann die deutsche Fassung bereits freigegeben sein, während die italienische Fassung noch geprüft wird. Die Website zeigt dadurch keine halbfertige Übersetzung. Für die Such- und URL-Planung findest Du ergänzend meinen Leitfaden zur SEO-Struktur mehrsprachiger Websites.

Rollen und Übergaben klar festlegen

Ein Content-Modell bleibt nur dann verlässlich, wenn für jede wichtige Entscheidung eine verantwortliche Person benannt ist. Gerade in kleinen Teams sollten die Rollen einfach und eindeutig sein.

  • Geschäftsführung oder fachlich verantwortliche Person: bestätigt Leistungsumfang, Preislogik, Verfügbarkeit und fachliche Richtigkeit.
  • Redaktion: verantwortet Verständlichkeit, Terminologie, Zeichenlängen und konsistente Übersetzungen.
  • Entwicklung: setzt Datenstruktur, Validierung, Berechtigungen, Schnittstellen und technische Ausgaben um.
  • Benannte Freigabeperson: entscheidet, wann ein Datensatz veröffentlicht wird, und überwacht die Aktualität.

Bei Berger+Team sprechen die Menschen, die modellieren, texten oder entwickeln, direkt mit dem Auftraggeber. Diese direkte Abstimmung ist bei einem Content-Modell wichtig: Ein technisch korrektes Feld hilft im Betrieb nur, wenn klar ist, wer den Inhalt pflegt und warum das Feld benötigt wird.

Typische Fehlmodellierungen

  • Ein Sammelfeld für die gesamte Leistung: Zielgruppe, Preis und Kontaktweg bleiben im Fließtext verborgen und können nicht einzeln geprüft werden.
  • Freitext für Preislogiken: „auf Anfrage“, „Preis nach Anfrage“ und „individuelles Angebot“ werden zu drei schwer vergleichbaren Varianten.
  • Fehlende IDs: Beziehungen beruhen auf sichtbaren Namen und brechen bei einer Umbenennung.
  • Vermischte Sprachen: Deutsche und italienische Inhalte landen im selben Textfeld oder besitzen keinen eigenen Freigabestatus.
  • Seiten statt Entitäten: Jede Unterseite speichert eigene Kopien von Ansprechpartnern, Standorten und Kontaktangaben.
  • Technische Pflichtfelder ohne betrieblichen Zweck: Mitarbeitende tragen Platzhalter ein, nur um speichern zu können.
  • Keine Zuständigkeit: Das Aktualisierungsdatum existiert, aber niemand ist für die nächste Prüfung verantwortlich.
  • Direkte Kanalübernahme ohne Mapping: Interne Hinweise oder ungeeignete Feldwerte werden ungeprüft an externe Systeme übergeben.

Prüfliste für Dein Website Content-Modell

Datenqualität und Struktur

  • Sind alle Pflichtfelder ausgefüllt?
  • Entspricht jeder Wert dem vorgesehenen Datentyp?
  • Werden Mindest- und Maximallängen eingehalten?
  • Besitzt jede Leistung eine eindeutige ID?
  • Gibt es doppelte Leistungen oder unterschiedliche Schreibweisen derselben Leistung?
  • Sind alle Beziehungen gültig und mit vorhandenen Entitäten verknüpft?

Freigabe und Ausspielung

  • Stimmen Kontaktinformationen auf Leistungs-, Standort- und Unternehmensebene überein?
  • Sind Preislogik und Verfügbarkeit noch aktuell?
  • Sind notwendige Übersetzungen vorhanden und je Sprache freigegeben?
  • Sind eingestellte Leistungen archiviert, statt unkontrolliert gelöscht zu werden?
  • Ist dokumentiert, welche Felder an Website, Google-Dienste und API ausgegeben werden dürfen?
  • Gibt es für jede veröffentlichte Leistung ein Prüf- oder Aktualisierungsdatum?

Das Website Content-Modell in 90 Tagen einführen

Tag 1 bis 30: Modell und Pilot

Wähle drei bis fünf typische Leistungen aus. Inventarisiere die vorhandenen Inhalte, definiere Entitäten, Felder und Beziehungen und erfasse echte Beispieldaten. Der Pilot sollte bewusst einen anspruchsvolleren Fall enthalten, etwa mehrere Zielgruppen oder zwei Sprachen.

Tag 31 bis 60: Redaktion und Technik

Prüfe die Feldnamen mit den Menschen, die später Inhalte pflegen. Setze Pflichtfelder, Auswahlwerte, Übersetzungsstatus und Freigaben im verwendeten System um. Erstelle danach eine erste Website-Ausgabe und eine kontrollierte JSON-Antwort.

Tag 61 bis 90: Ausspielung und Erweiterung

Teste Links, Beziehungen, Sprachversionen, strukturierte Website-Daten und vorgesehene Schnittstellen. Korrigiere das Modell anhand der tatsächlichen Nutzung und erweitere anschließend den gesamten Leistungskatalog. Ein geprüfter Pilot vor der vollständigen Migration reduziert die Nacharbeit.

Fragen und Antworten zum Website Content-Modell

Was ist der Unterschied zwischen Content-Modell und Seitenaufbau?

Das Content-Modell beschreibt Entitäten, Felder, Beziehungen und Regeln. Der Seitenaufbau entscheidet, welche Inhalte an welcher Stelle sichtbar werden. Aus einem Modell können deshalb mehrere Seitenarten und weitere Ausgaben entstehen.

Welche Inhalte eignen sich für eigene Felder?

Ein Inhalt braucht meist ein eigenes Feld, wenn Du ihn separat prüfen, filtern, übersetzen, aktualisieren oder ausgeben möchtest. Telefonnummer, Preislogik und Verfügbarkeit sollten beispielsweise nicht in einer allgemeinen Beschreibung versteckt werden.

Wie granular sollten Felder sein?

Felder sollten so fein sein, wie es für Pflege, Prüfung und Ausgabe nötig ist. Wenn zwei Angaben immer gemeinsam geändert und verwendet werden, kann ein Feld genügen. Brauchen die Angaben unterschiedliche Regeln oder Verantwortliche, solltest Du sie trennen.

Wer pflegt das Content-Modell?

Das Modell entsteht gemeinsam aus fachlicher, redaktioneller und technischer Sicht. Im laufenden Betrieb pflegen benannte Verantwortliche die Inhalte. Änderungen an Struktur, Datentypen oder Beziehungen werden kontrolliert durch die zuständige Entwicklung umgesetzt.

Kann WordPress strukturierte Inhalte verwalten?

Ja, WordPress kann Entitäten beispielsweise über eigene Inhaltstypen, Felder und Taxonomien abbilden. Entscheidend ist, dass das fachliche Modell unabhängig von einzelnen Seitenvorlagen dokumentiert ist und die Daten sauber exportiert werden können.

Was passiert, wenn sich eine Leistung ändert?

Ändert sich nur ein Feldwert, wird der Datensatz aktualisiert, geprüft und erneut freigegeben. Ändert sich die fachliche Struktur, sollte zuerst das Modell versioniert und geprüft werden, bevor bestehende Datensätze oder Schnittstellen angepasst werden.

Wie werden Übersetzungen modelliert?

Sprachneutrale Werte bleiben einmalig gespeichert, während übersetzbare Felder je Sprache eigene Inhalte und einen eigenen Freigabestatus erhalten. Dadurch kannst Du Deutsch und Italienisch getrennt redaktionell prüfen, ohne IDs, Beziehungen oder Preislogiken doppelt zu pflegen.

Muss jeder Inhalt über eine API ausgegeben werden?

Nein. Eine API sollte nur Inhalte bereitstellen, die für den jeweiligen Anwendungsfall erforderlich und freigegeben sind. Interne Notizen, Entwürfe, personenbezogene Angaben und technische Verwaltungsfelder bleiben geschützt.

Nutzen eines gepflegten Content-Modells

Ein Website Content-Modell ist kein Projekt nur für große Unternehmen. Für ein KMU schafft die Content-Modellierung klare Zuständigkeiten, weniger Doppelpflege, konsistente Übersetzungen und kontrollierbare Übergaben.

Beginne mit drei bis fünf Leistungen, modelliere sie vollständig und prüfe den Weg von der fachlichen Aussage bis zur sichtbaren Ausgabe. Wenn Du Deine Website und den Leistungskatalog auf diese Weise aufbauen möchtest, verbinden wir bei Website-Strategie und Entwicklung die fachliche Struktur mit Redaktion, Gestaltung und technischer Umsetzung.

Quellen

  1. Schema.org: Service, abgerufen über schema.org.
  2. Google for Developers: Google Business Profile APIs – Frequently Asked Questions, abgerufen über developers.google.com.
Florian Berger
Bloggerei.de