Entity Architecture für Unternehmenswebsites

Zuerst reale Gegenstände statt Fachwörter sammeln

Notieren Sie Unternehmen, Marken, tatsächlich beteiligte Personen und verfügbare Leistungen. Beschreiben Sie, was jeweils gemeint ist und welche öffentliche Seite dafür zuständig sein soll. Eine Begriffskarte hilft, gleichnamige, aber unterschiedliche Dinge nicht unbemerkt zusammenzufassen.

Legen Sie den Geltungsbereich ausdrücklich fest. Nicht jede interne Abteilung oder jedes einzelne Keyword braucht einen eigenen öffentlichen Knoten. Die Struktur soll Verständnis erleichtern. Ein immer größerer Graph ohne fachlich begründete Beziehungen macht Unternehmensinformationen nicht automatisch verlässlicher.

Beziehungen in verständlichen Sätzen prüfen

Formulieren Sie die Verknüpfung zunächst ohne Code: Eine Organisation veröffentlicht einen Artikel, eine Person verantwortet einen Beitrag, eine Leistung wird von einem Unternehmen angeboten. Prüfen Sie, ob diese Sätze tatsächlich stimmen und öffentlich nachvollziehbar sind.

Ein gemeinsamer Name ist noch keine sichere Identität. Ebenso beweist eine thematische Nähe keine geschäftliche Beziehung. Vermeiden Sie künstliche Verbindungen zu bekannten Organisationen oder Personen, wenn es dafür keine belastbare Grundlage gibt. Die Architektur darf keine geliehene Autorität vortäuschen.

Seitenverantwortung und Kennungen festlegen

Ordnen Sie wesentlichen Gegenständen stabile Adressen oder eindeutige Kennungen zu. Eine zentrale Unternehmensseite kann die Organisation erklären; eine Leistungsseite beschreibt das konkrete Angebot. Verschiedene Darstellungen sollten dieselbe reale Einheit konsistent benennen, statt bei jedem Artikel einen abweichenden Hintergrund zu erzeugen.

Schema.org bietet dafür beispielsweise Organization, Person und Service. Die passenden Eigenschaften werden anhand der tatsächlich vorhandenen Informationen gewählt. Eine technische Typangabe ersetzt keine sichtbare Erklärung und macht eine unbestätigte Qualifikation oder Niederlassung nicht wahr.

Fiktives Beispiel einer kleinen Zuordnung

Ein Beratungsunternehmen trennt seine Organisation, eine benannte tatsächlich mitwirkende Autorin und ein konkretes Auditangebot. Artikel und Leistungsseite verweisen auf die jeweils passende Verantwortung. Eine allgemeine Themenkategorie wird nicht fälschlich als zweite Firma beschrieben.

Nach Änderungen Konsistenz und Nutzen prüfen

Wenn Angebote umbenannt oder Verantwortlichkeiten geändert werden, werden abhängige Seiten und Daten überprüft. Das Register sollte zeigen, wo eine Einheit beschrieben wird. Veraltete Beziehungen bleiben nicht deshalb korrekt, weil ihre Kennung technisch unverändert funktioniert.

Validierung prüft die Struktur, aber nicht jede inhaltliche Wahrheit. Eine fehlerfreie Ausgabe ist daher nur ein Teil der Abnahme. Die eigentliche Frage bleibt, ob Menschen Organisation, Angebot und Verantwortung besser verstehen. Ein garantierter Knowledge-Graph-Eintrag oder KI-Zitat lässt sich daraus nicht ableiten.

Ein Beziehungsregister vor dem technischen Graphen erstellen

Schreiben Sie reale Einheiten in eine Tabelle und benennen Sie für jede die zuständige öffentliche Seite. Beginnen Sie mit Organisation, wichtigen Angeboten und tatsächlich beteiligten Personen. Kategorien wie „SEO“ oder „Anleitungen“ sind häufig Themenordnungen und keine eigenständigen Unternehmen. Diese Unterscheidung verhindert, dass ein technischer Graph aus jeder Menübezeichnung eine vermeintliche reale Organisation macht.

Ergänzen Sie Beziehungen in Alltagssprache. „Diese Organisation bietet diese Leistung an“ lässt sich fachlich bestätigen. „Diese Person hat diesen Artikel geschrieben“ verlangt eine tatsächliche Beteiligung. Erst wenn die Sätze stimmen, wird entschieden, wie sie technisch beschrieben werden können. Das Register ist damit eine inhaltliche Grundlage und kein Wettbewerb um die größte Zahl an Verknüpfungen.

Stabile Identität von Seitenvarianten unterscheiden

Eine Organisation kann auf vielen Seiten erwähnt werden, bleibt aber dieselbe reale Einheit. Verwenden Sie deshalb konsistente Namen und eine nachvollziehbare zentrale Referenz. Bei strukturierten Daten können stabile Kennungen helfen, dieselbe Einheit innerhalb des Graphen wiederzuverwenden. Eine Kennung ist jedoch kein Nachweis der Identität; deren sachliche Grundlage muss bereits stimmen.

Fiktives Beispiel: Ein Beratungsunternehmen bietet ein Audit und eine laufende Betreuung an. Beide Leistungen gehören zum selben Anbieter, haben aber unterschiedliche Leistungsseiten und Umfänge. Ein Fachartikel erklärt eine Vorfrage und verweist passend zum Audit. Er wird nicht selbst als drittes Beratungsprodukt beschrieben. Die Redaktion wird nur dann einer Person zugeordnet, wenn diese Person den Beitrag tatsächlich verantwortet.

Prüfen Sie bei gleichnamigen Marken oder Personen besonders sorgfältig, welche Einheit gemeint ist. Ein Link zu einem bekannten Namen schafft keine legitime Zugehörigkeit. Auch eine fremde Qualifikation darf nicht durch eine technische Verknüpfung übertragen werden. Beschreiben Sie lieber wenige belegbare Beziehungen vollständig, statt zahlreiche ungesicherte Bezüge zu ergänzen.

Eine inhaltliche und technische Abnahme verbinden

Lassen Sie zuerst die sichtbaren Seiten ohne Code lesen: Sind Anbieter, Angebot und Verantwortung erkennbar? Danach wird geprüft, ob die strukturierten Angaben dasselbe beschreiben. Passen Typen und Eigenschaften zur Realität? Verweisen Kennungen auf die beabsichtigte Einheit? Ein technisch zulässiger Wert kann inhaltlich trotzdem falsch sein, wenn etwa eine Redaktion als erfundene Person dargestellt wird.

Bei einer Umbenennung oder einem Rollenwechsel prüfen Sie alle betroffenen Beschreibungen. Eine alte Kennung muss nicht zwingend geändert werden, wenn dieselbe reale Einheit weiterbesteht; die Beschreibung muss aber aktuell passen. Veränderte Identität und veränderte Darstellung sind verschiedene Fälle. Dokumentieren Sie die Entscheidung, damit später keine unabsichtlichen Doppelungen entstehen.

Beurteilen Sie das Ergebnis anhand besserer Orientierung: Leser können Leistungen zuordnen und die verantwortliche Stelle verstehen. Ein Validator bestätigt keine garantierte Aufnahme in einen Wissensgraphen und keine künftige Zitierung in KI-Antworten. Solche Darstellungen werden gesondert beobachtet, statt als zugesicherte Folge der technischen Struktur verkauft zu werden.

Häufige Fragen.