Ein Entity-Datenmodell bildet reale Unternehmensobjekte als eindeutig identifizierbare Datensätze mit Eigenschaften, Beziehungen und einer verbindlichen Quelle ab. Für Dein Unternehmen bedeutet das: Organisation, Marke, Person, Standort, Leistung, Produkt, Referenz und Kontaktweg werden nicht auf jeder Unterseite neu eingetragen, sondern einmal modelliert und anschließend konsistent verwendet.
Gerade bei einem Südtiroler KMU entstehen widersprüchliche Angaben selten aus Nachlässigkeit. In meiner Arbeit mit kleinen und mittleren Betrieben sehe ich häufiger ein anderes Problem: Auf der Website stehen andere Öffnungszeiten als im Google-Unternehmensprofil, eine Broschüre verwendet einen alten Markennamen und die italienische Sprachversion nennt einen Ansprechpartner, der nicht mehr zuständig ist. Inhalte sind vorhanden, aber Quellsystem und Verantwortlichkeit sind ungeklärt.
Ein sauberes Entity-Datenmodell reduziert diese Doppelpflege. Es schafft eine Single Source of Truth für zentrale Unternehmensdaten und liefert eine verlässliche Grundlage für Deine Website, Suchmaschinen, Übersetzungen, Schnittstellen und KI-Systeme.
Was ein Entity-Datenmodell für Dein Unternehmen leistet
Eine Entität ist ein eindeutig abgrenzbares Objekt, über das Dein Unternehmen Informationen verwaltet. Eine Organisation ist eine Entität. Ein Standort ist eine andere Entität. Auch eine konkrete Leistung, ein Produkt oder eine Referenz kann als eigenständige Entität behandelt werden.
Der entscheidende Unterschied zu einem gewöhnlichen Seitentext liegt in der Identität: Eine Entität behält ihre stabile ID, auch wenn sich Name, Beschreibung, URL oder Sprache ändern. Dadurch können verschiedene Systeme zuverlässig auf dasselbe Objekt verweisen.
Eine stabile ID beantwortet die Frage „Welches Objekt ist gemeint?“. Der kanonische Name beantwortet die Frage „Wie nennen wir dieses Objekt aktuell?“.
Ein brauchbarer Entitätsdatensatz enthält mindestens:
- Stabile ID: eine dauerhafte, eindeutige Kennung, die nicht von einem übersetzten Namen abhängt.
- Kanonischer Name: die verbindliche Hauptbezeichnung der Entität.
- Alternative Namen: frühere Namen, Kurzformen, Handelsnamen oder gebräuchliche Varianten.
- Eigenschaften: beispielsweise Adresse, Beschreibung, E-Mail-Adresse, Öffnungszeiten oder Leistungsgebiet.
- Beziehung: eine eindeutige Verbindung zu anderen Entitäten, etwa „Standort gehört zu Organisation“.
- Quellsystem: die führende Quelle, in der der betreffende Wert gepflegt wird.
- Sprache: die Kennzeichnung sprachabhängiger Werte, beispielsweise Deutsch oder Italienisch.
- Status: Entwurf, freigegeben, veraltet oder archiviert.
- Verantwortlichkeit: die Person oder Rolle, die Änderungen prüft und freigibt.
- Prüfdatum: der Zeitpunkt der letzten fachlichen Kontrolle.
Diese Struktur macht verstreute Entitätsdaten der Website zu steuerbarem Unternehmenswissen. Software kann die Ausgabe automatisieren. KI kann beim Prüfen, Übersetzen oder Erkennen von Abweichungen helfen. Keine Software ersetzt jedoch die unternehmerische Entscheidung, welche Quelle verbindlich ist und wer für die Datenqualität einsteht.
Die acht Kernentitäten im Entity-Datenmodell
1. Organisation
Die Organisation beschreibt die rechtliche oder wirtschaftliche Einheit hinter dem Betrieb. Zu den relevanten Feldern gehören der offizielle Name, die Rechtsform, Anschrift, Steuernummer oder Umsatzsteuer-ID, Gründungsinformation, zentrale Kontaktdaten und die verantwortliche Geschäftsführung.
Typische Beziehungen lauten:
- Organisation führt Marke.
- Organisation unterhält Standort.
- Organisation beschäftigt oder vertritt Person.
- Organisation bietet Leistung oder Produkt an.
- Organisation stellt Kontaktweg bereit.
2. Marke
Die Marke ist nicht automatisch mit der rechtlichen Organisation identisch. Ein Unternehmen kann mehrere Marken führen; umgekehrt kann eine Marke von mehreren Gesellschaften genutzt werden. Zentrale Felder sind der kanonische Name, alternative Schreibweisen, Positionierung, Logo, Tonalität, Markeninhaber und freigegebene Sprachvarianten.
Diese Trennung ist besonders bei Rebrandings wichtig. Ändert sich der Markenname, kann die Organisation unverändert bleiben. Eine fundierte Markenstrategie und Markenarchitektur schafft dafür die fachliche Grundlage.
3. Person
Eine Person kann Gründer, Geschäftsführerin, Ansprechpartner, Autorin, Projektleiter oder fachlich Verantwortlicher sein. Der Datensatz sollte Name, Rolle, Zuständigkeit, Profilbild, Kurzbiografie, Sprachen, zugehörige Organisation und freigegebene Kontaktwege enthalten.
Personenbezogene Daten brauchen klare Freigaben. Nicht jede interne Information gehört auf die Website oder in strukturierte Daten. Das Entity-Datenmodell sollte deshalb zwischen internen, geschützten und öffentlich ausspielbaren Eigenschaften unterscheiden.
4. Standort
Ein Standort benötigt eine eigene Identität, wenn Adresse, Öffnungszeiten, Telefonnummer, Leistungsangebot oder Zuständigkeit vom Hauptsitz abweichen. Relevante Felder sind Standortname, Adresse, Geokoordinaten, Zeitzone, Öffnungszeiten, erreichbare Sprachen und die zugehörige Organisation.
Die Beziehung muss eindeutig sein: „Standort Bozen gehört zu Organisation A“ und „Leistung Beratung ist am Standort Bozen verfügbar“. So verhindert das Entity-Datenmodell, dass Öffnungszeiten oder Telefonnummern versehentlich für alle Niederlassungen übernommen werden.
5. Leistung
Eine Leistung beschreibt eine klar definierte Tätigkeit oder ein Angebot, beispielsweise Markenstrategie, Webentwicklung oder Beratung. Sinnvolle Felder sind Name, Leistungsbeschreibung, Zielgruppe, Anbieter, Leistungsgebiet, verfügbare Sprache, verantwortliche Person und zugehörige Referenzen.
Eine Leistung ist mehr als eine Überschrift auf einer Seite. Derselbe Datensatz kann auf einer Leistungsseite, im Profil eines Standorts, in einer Referenz und in maschinenlesbaren Daten erscheinen. Wie Leistungsseiten mit passenden strukturierten Angaben verbunden werden, vertiefe ich im Beitrag über Service Schema und JSON-LD.
6. Produkt
Ein Produkt ist ein konkretes, wiedererkennbares Angebot mit eigener Identität. Dazu gehören beispielsweise eine Produktlinie, eine Softwarelösung oder ein physischer Artikel. Relevante Felder können Produktname, Hersteller, Marke, Beschreibung, Variante, Artikelnummer, Verfügbarkeit, Preislogik und Bezugsweg sein.
Leistung und Produkt sollten getrennt bleiben, selbst wenn beide gemeinsam verkauft werden. Eine Beratung ist eine Leistung. Eine standardisierte Softwareplattform ist ein Produkt. Die Beziehung kann beispielsweise lauten: „Leistung Implementierung unterstützt Produkt X“.
7. Referenz
Eine Referenz dokumentiert eine tatsächlich erbrachte Arbeit. Der Datensatz sollte Projektname, Auftraggeberfreigabe, Zeitraum, beteiligte Leistungen, verantwortliche Personen, Ausgangslage, Ergebnis und verwendbare Medien enthalten.
Die Referenz gewinnt durch Beziehungen an Aussagekraft. Die Website kann dadurch nicht nur ein Projektbild zeigen, sondern auch erklären, welche Organisation betreut wurde, welche Leistung erbracht wurde, welcher Standort beteiligt war und welche Person fachlich verantwortlich war.
8. Kontaktweg
Ein Kontaktweg ist eine konkrete Möglichkeit, mit Deinem Unternehmen in Verbindung zu treten: Telefonnummer, E-Mail-Adresse, Formular, Messenger, Supportkanal oder persönliche Ansprechstelle. Der Kontaktweg braucht einen Zweck, eine Zielgruppe, verfügbare Sprachen, erreichbare Zeiten, den zugehörigen Standort und eine zuständige Person oder Organisation.
Das Entity-Datenmodell kann dadurch unterscheiden, ob eine Telefonnummer für allgemeine Anfragen, Verkauf, Support oder einen bestimmten Standort gedacht ist. Ein Kontaktweg sollte nicht nur korrekt, sondern auch eindeutig einem Zweck zugeordnet sein.
Unternehmensentitäten in sieben Schritten modellieren
Schritt 1: Daten inventarisieren
Sammle zuerst alle Stellen, an denen Unternehmensdaten vorkommen: Website, Google-Unternehmensprofil, CRM, ERP, E-Mail-Signaturen, Preislisten, PDFs, Social-Media-Profile und interne Dokumente. Markiere Abweichungen, statt sofort eine vermeintlich richtige Version auszuwählen.
Die erste Bestandsaufnahme zeigt häufig, dass nicht zu wenig Information vorhanden ist. Meist existieren mehrere Varianten ohne erkennbare Rangordnung.
Schritt 2: Entitäten voneinander trennen
Prüfe für jeden Datensatz, welches reale Objekt beschrieben wird. Ein hilfreicher Test lautet: Kann sich dieses Objekt unabhängig von den anderen verändern?
- Kann der Standort umziehen, ohne dass die Organisation ihren Namen ändert? Dann ist der Standort eine eigene Entität.
- Kann eine Person ausscheiden, während die Leistung bestehen bleibt? Dann dürfen Person und Leistung nicht zu einem Datensatz verschmelzen.
- Kann die Marke umbenannt werden, während die rechtliche Gesellschaft gleich bleibt? Dann müssen Marke und Organisation getrennt sein.
Schritt 3: Stabile IDs vergeben
Verwende im Entity-Datenmodell IDs, die nicht von Namen, Sprachen oder aktuellen URLs abhängen. Ein internes Format kann beispielsweise so aussehen:
- org-0001 für die Organisation
- brand-0001 für die Marke
- place-0001 für den ersten Standort
- person-0001 für eine Person
- service-0001 für eine Leistung
Die ID „service-0001“ bleibt bestehen, wenn „Digitalberatung“ später in „Digitale Prozessberatung“ umbenannt wird. Eine sprechende URL darf sich ändern; die interne Identität sollte stabil bleiben.
Schritt 4: Beziehungen explizit modellieren
Speichere Beziehungen nicht nur in Beschreibungen. „Maria Huber leitet den Standort Meran“ sollte als strukturierte Beziehung zwischen person-0001 und place-0002 vorliegen. Relevante Beziehungsarten sind beispielsweise:
- gehört zu
- wird betrieben von
- wird angeboten von
- ist verfügbar an
- ist verantwortlich für
- verwendet Marke
- belegt Leistung
- ist Kontaktweg für
Schritt 5: Führende Quellen bestimmen
Nicht jedes Feld muss aus demselben System stammen. Rechtliche Firmendaten können aus der Verwaltung kommen, Produktpreise aus dem ERP und freigegebene Kurztexte aus dem Website-System. Entscheidend ist, dass jedes wichtige Feld genau ein führendes Quellsystem besitzt.
Die Website darf Daten darstellen, sollte aber nicht automatisch die Quelle für alle Angaben sein. Ein Quellsystem ist dort führend, wo Änderungen fachlich beschlossen und kontrolliert werden.
Schritt 6: Sprachlogik definieren
Eine mehrsprachige Website benötigt keine vollständige Kopie aller Datensätze. Teile die Eigenschaften im Entity-Datenmodell stattdessen in zwei Gruppen:
- Sprachneutrale Werte: stabile ID, Telefonnummer, Geokoordinaten, E-Mail-Adresse, Organisationsbeziehung und interne Artikelnummer.
- Sprachabhängige Werte: Name, Kurzbeschreibung, Leistungsbeschreibung, Funktionsbezeichnung, URL, Handlungsaufforderung und gegebenenfalls Hinweise zu Öffnungszeiten.
Eine Übersetzung darf nicht zu einer zweiten Entität werden. „Markenberatung“ und „Consulenza di marca“ sind zwei Sprachwerte derselben Leistung. Die Informationsarchitektur und die Suchintention müssen dennoch für jede Sprache separat geplant werden, wie ich im Leitfaden für mehrsprachige Website-SEO erläutere.
Schritt 7: Pflege und Freigabe regeln
Lege für jede Entitätsart eine fachlich verantwortliche Rolle fest. Die Geschäftsführung verantwortet möglicherweise Organisationsdaten, die Marketingleitung die Marke und die Standortleitung Öffnungszeiten sowie lokale Kontaktwege.
Ein klarer Pflegeprozess reicht für viele KMU:
- Eine Änderung wird beantragt.
- Die verantwortliche Person prüft die fachliche Richtigkeit.
- Sprachvarianten werden ergänzt oder aktualisiert.
- Der Datensatz wird freigegeben.
- Die Website und weitere Kanäle übernehmen den freigegebenen Stand.
- Änderung und Prüfdatum werden dokumentiert.
Entity-Datenmodell: Beispiel eines Südtiroler Betriebs
Das folgende vereinfachte Entity-Datenmodell zeigt einen fiktiven mehrsprachigen Handwerksbetrieb. Das Beispiel ist kein vollständiges Produktionsmodell, sondern ein Ausgangspunkt für die individuelle Modellierung.
Die zentralen Datensätze
- Organisation org-0001: Alpenwerk Holz GmbH, rechtlicher Sitz in Bozen.
- Marke brand-0001: Alpenwerk, geführt von org-0001.
- Standort place-0001: Werkstatt Bozen, gehört zu org-0001.
- Standort place-0002: Schauraum Meran, gehört zu org-0001.
- Person person-0001: Maria Huber, Geschäftsführerin und verantwortlich für Beratung.
- Leistung service-0001: Innenausbau nach Maß beziehungsweise „Arredamento su misura“, angeboten von org-0001.
- Produkt product-0001: Möbelserie Larix, angeboten unter brand-0001.
- Referenz reference-0001: Innenausbau Hotel Bergblick, belegt service-0001.
- Kontaktweg contact-0001: allgemeine E-Mail-Adresse für Deutsch und Italienisch.
- Kontaktweg contact-0002: Telefonnummer des Schauraums Meran während der lokalen Öffnungszeiten.
Ein Entity-Eintrag für die Leistung
{
"id": "service-0001",
"canonicalName": {
"de": "Innenausbau nach Maß",
"it": "Arredamento su misura"
},
"provider": "org-0001",
"availableAt": ["place-0001", "place-0002"],
"responsiblePerson": "person-0001",
"references": ["reference-0001"],
"sourceSystem": "company-content",
"status": "approved",
"reviewedAt": "2026-02-15"
}Der Datensatz trennt Identität, Sprache und Beziehung. Eine Korrektur der italienischen Bezeichnung verändert weder die stabile ID noch die Verknüpfung zur Organisation, zur Person oder zu den Standorten.
Welche Entität braucht eine eigene Seite?
Nicht jede Entität im Entity-Datenmodell muss eine öffentliche URL erhalten. Die Entscheidung richtet sich nach dem Nutzen für Menschen, Suchmaschinen und betriebliche Abläufe.
Eigene Seite
Eine eigene Seite ist sinnvoll, wenn die Entität eine eigenständige Suchintention, ausreichend Inhalt und einen klaren nächsten Schritt besitzt. Typische Kandidaten sind:
- Organisation oder Unternehmensprofil
- wichtige Marke
- Standort mit eigenen Öffnungszeiten und Leistungen
- zentrale Leistung
- erklärungsbedürftiges Produkt
- umfangreiche Referenz
- öffentlich relevante Fachperson
Wiederverwendbarer Inhaltsbaustein
Ein Inhaltsbaustein eignet sich für Informationen, die auf mehreren Seiten gebraucht werden. Dazu zählen Ansprechpartner, Öffnungszeiten, Kontaktdaten, kurze Leistungsbeschreibungen, Standortkarten und Markenhinweise.
Der Baustein enthält keine manuell gepflegte Kopie. Er greift auf denselben freigegebenen Entitätsdatensatz zu.
Nur strukturierter Datensatz
Manche Entitäten bleiben im Hintergrund. Ein technischer Kontaktweg, eine interne Zuständigkeit oder eine archivierte Namensvariante benötigt möglicherweise keine sichtbare Seite. Der Datensatz bleibt relevant, weil er Beziehungen, Freigaben und die Herkunft einer Information dokumentiert.
Vom Entity-Datenmodell zu JSON-LD und Schema.org
Das interne Entity-Datenmodell und JSON-LD erfüllen unterschiedliche Aufgaben. Das Entity-Datenmodell organisiert Dein Unternehmenswissen. JSON-LD ist ein Ausgabeformat, mit dem ausgewählte Informationen maschinenlesbar auf einer Website bereitgestellt werden können.
Schema.org stellt dafür Typen und Eigenschaften bereit. Eine interne Organisation kann beispielsweise als Organization, eine Person als Person, ein Standort als Place, eine Leistung als Service, ein Produkt als Product und ein Kontaktweg als ContactPoint ausgegeben werden. Welche Typen und Eigenschaften im konkreten Fall passen, muss anhand des vollständigen Datensatzes geprüft werden.
Die interne ID „org-0001“ kann dabei in eine eindeutige Web-ID übertragen werden. Das folgende verkürzte JSON-LD zeigt die Grundlogik:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.alpenwerk.example/#organization",
"name": "Alpenwerk Holz GmbH",
"brand": {
"@type": "Brand",
"@id": "https://www.alpenwerk.example/#brand",
"name": "Alpenwerk"
},
"location": [
{
"@id": "https://www.alpenwerk.example/standorte/bozen/#place"
},
{
"@id": "https://www.alpenwerk.example/standorte/meran/#place"
}
],
"contactPoint": {
"@type": "ContactPoint",
"@id": "https://www.alpenwerk.example/#contact-general",
"contactType": "customer service",
"availableLanguage": ["de", "it"]
}
},
{
"@type": "Service",
"@id": "https://www.alpenwerk.example/leistungen/innenausbau/#service",
"name": "Innenausbau nach Maß",
"provider": {
"@id": "https://www.alpenwerk.example/#organization"
}
}
]
}Die @id-Werte verbinden zusammengehörige Objekte, ohne alle Angaben an jeder Stelle zu wiederholen. Google beschreibt die Verknüpfung separat ausgezeichneter, zusammengehöriger Elemente auf derselben Seite über @id. Daraus ergibt sich keine pauschale Vorgabe für seitenübergreifend eindeutige IDs. Quelle: Google Search Central.
Für die eigene Architektur sind dauerhaft verwendete Web-IDs dennoch sinnvoll, wenn mehrere Seiten oder Systeme dieselbe Entität referenzieren. Diese Entscheidung folgt aus Deinem Entity-Datenmodell und nicht aus dem Versuch, ein Suchmaschinenformat nachzubauen.
Vorher und nachher: Was das Entity-Datenmodell verändert
Vorher: Angaben werden pro Seite gepflegt
- Die Firmenbezeichnung steht in mehreren Schreibweisen auf der Website.
- Öffnungszeiten werden in Footer, Kontaktseite und Standortseite separat geändert.
- Deutsch und Italienisch bestehen als weitgehend unabhängige Inhaltskopien.
- Eine ausgeschiedene Person bleibt in alten Referenzen als Ansprechpartner sichtbar.
- JSON-LD enthält andere Werte als der sichtbare Seiteninhalt.
- Es ist nicht festgelegt, welche Version verbindlich ist.
Nachher: Entitäten liefern die verbindlichen Werte
- Organisation und Marke besitzen jeweils eine stabile ID und einen kanonischen Namen.
- Jeder Standort verwaltet eigene Adresse, Öffnungszeiten und Kontaktwege.
- Sprachneutrale Werte werden einmal gepflegt; Texte erhalten kontrollierte Sprachvarianten.
- Leistungen sind mit Anbietern, Personen, Standorten und Referenzen verbunden.
- Seitenbausteine und JSON-LD greifen auf freigegebene Entitätsdaten zurück.
- Für jede Entitätsart sind Quellsystem und Verantwortlichkeit dokumentiert.
Aus meiner Erfahrung liegt der wichtigste Nutzen nicht in der technischen Struktur, sondern in klaren Abläufen: Eine Änderung wird einmal entschieden, einmal geprüft und anschließend konsistent ausgegeben.
Entity-Datenmodell: Checkliste für KMU
- Haben Organisation und Marke getrennte Datensätze, falls beide nicht identisch sind?
- Besitzt jede wichtige Entität eine stabile ID?
- Ist für jede Entität ein kanonischer Name festgelegt?
- Sind alternative und frühere Namen dokumentiert?
- Sind Personen, Standorte, Leistungen, Produkte und Referenzen miteinander verbunden?
- Ist für jedes zentrale Feld ein führendes Quellsystem definiert?
- Sind sprachneutrale und sprachabhängige Werte getrennt?
- Hat jeder Standort eigene Öffnungszeiten und Kontaktwege?
- Ist die Verantwortlichkeit für Anlage, Prüfung und Freigabe geregelt?
- Gibt es einen Status und ein letztes Prüfdatum?
- Stimmen sichtbarer Inhalt und maschinenlesbare Ausgabe überein?
- Werden archivierte Entitäten erhalten, statt ihre IDs für neue Objekte wiederzuverwenden?
Fragen und Antworten zum Entity-Datenmodell
Welches ID-Format eignet sich für ein KMU?
Ein einfaches, dauerhaftes Format wie org-0001, place-0001 oder eine kontrollierte UUID reicht häufig aus. Entscheidend ist, dass die ID eindeutig bleibt, nicht übersetzt wird und nach einer Namensänderung weiterbesteht.
Braucht jede Sprache eine eigene Entität?
Nein. „Markenberatung“ und „Consulenza di marca“ sind in der Regel sprachabhängige Bezeichnungen derselben Leistung. Beide Sprachwerte verweisen deshalb auf dieselbe stabile ID, während Texte, URLs und Metadaten pro Sprache gepflegt werden.
Was passiert bei einer Namensänderung?
Der neue kanonische Name ersetzt die bisherige Hauptbezeichnung, während die stabile ID unverändert bleibt. Den alten Namen solltest Du als alternative oder frühere Bezeichnung dokumentieren und betroffene URLs kontrolliert weiterleiten.
Benötigt jeder Standort einen eigenen Datensatz?
Ja, sobald sich Adresse, Öffnungszeiten, Kontaktweg, Leistung oder Zuständigkeit unterscheiden. Ein eigener Standortdatensatz verhindert, dass lokale Informationen versehentlich auf alle Niederlassungen übertragen werden.
Wer sollte für Entitätsdaten verantwortlich sein?
Die Verantwortung gehört zur fachlich zuständigen Rolle, nicht automatisch zur Person, die das Website-System bedient. Die Geschäftsführung kann Organisationsdaten freigeben, während Standortleitungen Öffnungszeiten und lokale Kontaktdaten verantworten.
Wie oft sollten Unternehmensentitäten geprüft werden?
Änderungsanfällige Daten wie Personen, Öffnungszeiten und Kontaktwege sollten nach jeder relevanten Änderung und zusätzlich in festen Intervallen geprüft werden. Für stabile Stammdaten ist eine dokumentierte jährliche Kontrolle ein praktikabler Richtwert, der an den Betrieb angepasst werden muss.
Ist ein Entity-Datenmodell dasselbe wie strukturierte Daten?
Nein. Das Entity-Datenmodell ist die interne Ordnung Deines Unternehmenswissens, während strukturierte Daten eine ausgewählte maschinenlesbare Ausgabe für die Website sind. Ein technisch korrektes JSON-LD-Markup kann ein unzureichendes internes Datenmodell nicht dauerhaft ausgleichen.
Braucht ein kleines Unternehmen dafür komplexe Software?
Nein. Ein kleines KMU kann mit einer kontrollierten Datenstruktur, eindeutigen IDs und klaren Zuständigkeiten beginnen. Software wird erst ausgewählt, wenn Entitäten, Quellen, Sprachen und Pflegeprozesse fachlich geklärt sind.
Zuerst das Entity-Datenmodell, dann die Automatisierung
Ein Entity-Datenmodell ist kein Selbstzweck. Das Modell soll Deinem Betrieb Zeit sparen, Fehler reduzieren und verlässliche Informationen für Menschen und Maschinen bereitstellen.
Beginne deshalb nicht mit JSON-LD, Plugins oder KI-Automatisierung. Beginne mit den realen Objekten Deines Unternehmens: Welche rechtliche Organisation steht hinter dem Betrieb? Welche Marke tritt nach außen auf? Welche Person verantwortet welche Leistung? Welcher Standort bietet was an? Welcher Kontaktweg ist für welchen Zweck vorgesehen?
Wenn diese Fragen verbindlich beantwortet sind, können wir im Rahmen unserer Website-Strategie und technischen Entwicklung daraus ein System aufbauen, das Inhalte zuverlässig verwaltet und wiederverwendet. Das unternehmerische Ergebnis sind weniger Doppelpflege, klarere Zuständigkeiten und konsistente Informationen für Kunden, Suchmaschinen und KI-Systeme.
