Strukturierte Daten und Entity Building

Strukturierte Daten und Entity Building wandeln genehmigte On-Site-Fakten in eine maschinenlesbare Ebene. Es identifiziert die Personen, Organisationen, Produkte, Artikel, Fragen, Schritte und Navigationspfade, die tatsächlich existieren, weist stabile Identifikatoren zu und drückt testbare Beziehungen aus. Es erfindet nie eine zweite Version des Inhalts.

Phase: P13, Strukturierte Daten und Entity Building. Stufe: C – Aufbau. Zeitrahmen: 3–5 Arbeitstage für eine Website mit einer kleinen Anzahl stabiler Vorlagen; 1–2 Wochen für einen Marktplatz, Publisher oder E-Commerce-Katalog mit mehreren Contentsystemen. Verantwortlich: der technische SEO-Leiter ist rechenschaftspflichtig, wobei die Entwicklung die Vorlagen implementiert, die Content-Verantwortlichen die sichtbaren Fakten bestätigen und die Marken- oder Rechtsverantwortlichen die kanonischen Entitätseinträge genehmigen.

Suchmaschinen behandeln Schema in der Regel als ein Signal neben Seiteninhalten, Links, Feeds und anderen Belegen. KI-Retrieval-Systeme können die strukturierte Ebene zunehmend als direkte Quelle für Fakten und Beziehungen behandeln. Ein falscher Preis, Autor, Organisationsname oder eine falsche Beziehung kann daher mit hoher Sicherheit extrahiert werden, weil sie explizit erscheint. Markup verbessert die Interpretation; es kann eine unbelegte Behauptung nicht wahr machen.

Warum diese Phase, und warum hier

P13 nutzt Entscheidungen, die früher im Prozess getroffen wurden. Die thematische Karte (Topical Map) identifiziert, welche Seite für welche Absicht und Entität zuständig ist. Das Content-Inventar identifiziert Dubletten und Legacy-URLs. Das Produktionssystem stabilisiert Felder wie Autor, Prüfdatum, Preis, Verfügbarkeit und FAQ-Text. Die On-Page-Optimierung macht diese Fakten sichtbar, während die Arbeit an der internen Verlinkung die Hierarchie und kanonische Ziele korrigiert. Erst dann kann eine Schema-Vorlage eine stabile Seite beschreiben, anstatt ein bewegliches Ziel zu kodieren.

Ein zu frühes Durchführen dieser Phase produziert technisch valide Fiktion. Ein Entwickler könnte jede Redaktionsseite als Article auszeichnen, bevor das Unternehmen entscheidet, ob die Autorenzeile eine Person, ein Team oder die Organisation repräsentiert. Eine Produktvorlage könnte einen Angebotspreis ausweisen, den die sichtbare Seite später durch „Kontaktieren Sie uns" ersetzt. Breadcrumb-Markup könnte eine alte Hierarchie beibehalten, nachdem die Navigation geändert wurde. Jedes Objekt wird geparst, doch jedes sagt Maschinen etwas anderes, als Menschen sehen.

Das Auslassen der Phase zwingt Systeme dazu, mehr zu interpretieren als nötig. Sie mögen die Seite trotzdem verstehen, aber Namen, Beziehungen, Daten, Autorschaft und Produktfakten bleiben mehrdeutig. Das schwächt die Entity-Disambiguierung , also den Prozess, zu entscheiden, auf welche reale Person, welches Unternehmen, welches Produkt oder welchen Ort sich ein Name bezieht. Es erschwert auch die zukünftige Wartung, da niemand die Identifikatoren und Quellfelder hinter dem Markup besitzt.

Das Ergebnis ist nicht „Schema hinzugefügt". Es ist eine getestete Zuordnung von Seitenvorlagen zu begründeten Schema-Typen, ein kanonisches Entitätsregister, Live-Validierungsnachweise und eine Überwachungsregel. P14, Off-Page Digital PR und Zitationen, benötigt diesen Vertrag, damit externe Profile, Berichterstattung und Referenzen dieselben Namen und Identifikatoren verstärken, anstatt neue Varianten zu schaffen.

Eingaben und Ausgaben

Die Abdeckungsmatrix bildet den Vertrag mit der Implementierung; das Entitätsregister bildet den Vertrag mit der nächsten Phase. Validierungsnachweise und Überwachung halten beide aktuell.

Die Checkliste

Jeder Punkt unten umfasst die Arbeit, ihren Grund, die Methode, das Werkzeug und eine Erledigt-Bedingung. Diese fünf Felder sollten erhalten bleiben, wenn die Checkliste in ein Ticketsystem übertragen wird.

1. Vorlagen inventarisieren und geeignete Seitenproben auswählen

Was: Listen Sie jede relevante Vorlage auf und wählen Sie repräsentative Live-URLs, einschließlich Varianten mit fehlenden optionalen Feldern. Warum: Ein einziges ideales Beispiel kann keine konditionalen Fehler aufdecken, wie ein Produkt ohne Bewertungen, einen Artikel ohne benannten Autor oder eine Kategorie ohne Breadcrumb-Elternelement. Wie: Gruppieren Sie URLs nach Rendering-Vorlage und Content-Quelle, wählen Sie dann mindestens eine vollständige, eine minimale und eine Grenzfall-URL pro Vorlage. Werkzeug: Das Seiteninventar, Crawler-Export, CMS-Modell und Browser. Erledigt wenn: 100% der relevanten Vorlagen mindestens drei Proben haben, oder alle Live-URLs, wenn eine Vorlage weniger als drei hat.

2. Nur Schema-Typen auswählen, die ihren Platz verdienen

Was: Weisen Sie Typen entsprechend der sichtbaren Aufgabe der Seite zu. Warum: Zusätzliche Typen vergrößern die Angriffsfläche für Widersprüche, ohne Anspruch auf ein Ergebnis zu schaffen. Wie: Verwenden Sie den engsten zutreffenden Typ und dokumentieren Sie, warum jedes Objekt existiert:

• Article-Schema oder BlogPosting gehört auf redaktionelle Inhalte mit einer sichtbaren Überschrift, einem Autor oder Herausgeber und einem Publikationskontext. Verwenden Sie das breitere Article, wenn ein engerer Subtyp irreführend wäre.
• FAQ-Schema gehört nur dorthin, wo Benutzer die vollständigen Fragen und Antworten sehen. Semantischer Wert und besondere Suchpräsentations-Berechtigung sind getrennt zu betrachten.
• HowTo gehört auf eine sichtbare geordnete Anleitung. Drei Marketing-Vorteile sind kein HowTo.
• Product-Schema gehört zu einem bestimmten Produkt oder einer Variante. Angebote, Währung, Verfügbarkeit, Bewertungen und Rezensionen müssen mit der Seite übereinstimmen.
• Organization-Schema gehört auf die kanonische Organisationsdarstellung und kann von anderen Stellen über eine stabile @id referenziert werden.
• Person gehört auf ein kanonisches Profil mit genügend sichtbaren Informationen, um die Person zu identifizieren. Eine bloße Autorenzeile rechtfertigt keine Referenzen.
• BreadcrumbList-Schema muss eine Hierarchie widerspiegeln, die Benutzer verstehen können, keinen künstlichen Keyword-Pfad.

Werkzeug: Die Abdeckungsmatrix, sichtbare Seiten, schema.org-Vokabular und die aktuelle Berechtigungsdokumentation der Suchplattform. Erledigt wenn: Jeder ausgewählte Typ eine einzeilige Begründung, eine sichtbare Quelle und eine explizite Ausschlussregel für Seiten hat, auf denen er nicht gerendert werden darf.

3. Das kanonische Entitätsregister aufbauen

Was: Erstellen Sie einen gepflegten Eintrag für jede wichtige Organisation, Person, Produktfamilie und jeden Standort. Warum: Konsistente Identifikatoren erlauben es verschiedenen Seiten, sich auf dieselbe Sache zu beziehen; inkonsistente Namen zwingen Maschinen zu entscheiden, ob „AmICited", „Am I Cited" und ein rechtlicher Firmenname eine Entität oder mehrere sind. Wie: Erfassen Sie den bevorzugten öffentlichen Namen, den rechtlichen Namen (sofern relevant), Aliase, die kanonische Seite, den Entitätstyp, die stabile @id, den Eigentümer und autoritative sameAs-Referenzen. Ein sameAs-Wert behauptet Identität, nicht thematische Relevanz, und sollte daher nur auf einen Eintrag oder ein offizielles Profil verweisen, das dieselbe Entität repräsentiert.

Eine kanonische Seite besitzt die vollständige Definition jeder Entität; andere Seiten referenzieren deren @id, anstatt Konkurrenten zu schaffen. Die kanonische URL einer Seite identifiziert die bevorzugte Seite für die Indexierung, während @id die beschriebene Sache identifiziert. Zum Beispiel kann die Entität https://example.com/about/#organization sein, während die Seite https://example.com/about/ bleibt.

Werkzeug: Entitätsregister, CMS-Einträge, rechtliche oder HR-Quelldaten, offizielle Profile und autoritative öffentliche Aufzeichnungen. Erledigt wenn: 100% der wesentlichen Entitäten, die im Markup verwendet werden, einen bevorzugten Namen, eine kanonische Seite oder genehmigte Ausnahme, eine stabile @id, einen Eigentümer und keinen ungelösten Identitätskonflikt haben.

4. Eigenschaften sichtbaren Quellfeldern zuordnen

Was: Verbinden Sie jede Schema-Eigenschaft mit dem Feld, das den sichtbaren Fakt rendert. Warum: Manuelle Duplizierung erzeugt Abweichungen; derselbe Preis oder Autor, zweimal gespeichert, wird irgendwann nicht mehr übereinstimmen. Wie: Ordnen Sie headline dem sichtbaren Titel zu, author dem veröffentlichten Autoreneintrag, dateModified einem sinnvollen sichtbaren Aktualisierungsdatum, Angebotsfelder der kundenorientierten Commerce-Quelle, FAQ-Objekte den gerenderten Antworten und Breadcrumb-Positionen der tatsächlichen Hierarchie. Befüllen Sie keine Eigenschaft nur weil sie in einem Plugin verfügbar ist, wenn ihre Quelle versteckt, veraltet oder semantisch anders ist.

Werkzeug: CMS-Schema, Vorlagencode, Commerce-Feed, Content-API und Feldzuordnung. Erledigt wenn: Jede wesentliche Eigenschaft eine benannte Quelle, Transformationsregel, Fallback-Verhalten und einen Eigentümer hat; null wesentliche Werte werden unabhängig in Markup und sichtbarem Inhalt gepflegt.

5. Einen verbundenen JSON-LD-Graphen implementieren

Was: Rendern Sie die genehmigten Objekte und verbinden Sie sie mit stabilen Identifikatoren. Warum: Nicht verbundene Blöcke können dieselbe Organisation oder denselben Autor als separate Dinge beschreiben, während stabile Referenzen Beziehungen klar ausdrücken. Wie: Verwenden Sie JSON-LD (JavaScript Object Notation for Linked Data), es sei denn, die bestehende Plattform erfordert ein anderes unterstütztes Format. Verwenden Sie @id-Referenzen für Herausgeber, Autor, Produktmarke und primäre Entität, anstatt partielle Definitionen zu wiederholen. Halten Sie die Ausgabe wo möglich serverlesbar und maskieren Sie benutzergesteuerte Zeichenketten sicher.

Das Ergebnis ist ein kleiner Knowledge Graph auf Seitenebene: Entitäten und ihre Beziehungen. Fügen Sie Fakten ein, die sie auf dieser Seite identifizieren oder qualifizieren, nicht jede verfügbare Eigenschaft.

Werkzeug: Template-Engine, Source-Code-Review, Browserquelle und ein JSON-Parser. Erledigt wenn: Alle ausgewählten Proben parsbare Objekte ausgeben, jede interne @id zu einer Definition oder beabsichtigten Referenz aufgelöst wird, optionale Felder bei Fehlen sauber verschwinden und keine Vorlage leere oder Platzhalterwerte ausgibt.

6. Sichtbarkeitsparitäts-Prüfung durchführen

Was: Vergleichen Sie jede wesentliche im Markup enthaltene Tatsache mit dem, was ein Benutzer auf derselben URL sehen kann. Warum: Strukturierte Daten sind eine explizite Behauptung, kein Versteck für Inhalte. Suchsysteme können irreführendes Markup ignorieren, die Berechtigung entziehen oder manuelle Maßnahmen ergreifen; KI-Systeme können den falschen Wert als autoritativ wiederholen. Wie: Vergleichen Sie die gerenderte Seite und den extrahierten Graphen nebeneinander. Prüfen Sie Namen, Autorschaft, Referenzen, Daten, Preise, Verfügbarkeit, Währung, Bewertungen, Anzahl der Rezensionen, Fragen, Antworten, Schritte und Breadcrumb-Beschriftungen.

Werkzeug: Gerenderte Seite, extrahiertes JSON-LD, CMS-Vorschau und Commerce-Quelle. Erledigt wenn: 100% der wesentlichen Eigenschaften in Bedeutung, Einheiten, Umfang und Aktualität mit den sichtbaren Inhalten übereinstimmen – über die vollständigen, minimalen und Grenzfall-Proben hinweg.

7. Syntax, Berechtigung, Kanonik und Live-Interpretation validieren

Was: Testen Sie den generierten Graphen auf vier Ebenen. Warum: Valides JSON kann die falsche Eigenschaft verwenden; valides Schema kann die Anforderungen einer Suchfunktion nicht erfüllen; eine korrekte Seite kann trotzdem nicht indexiert sein; und Google kann eine andere Kanonische auswählen. Wie: Parsen Sie zuerst das JSON. Zweitens validieren Sie das Vokabular und die typspezifischen Anforderungen. Drittens prüfen Sie die Rich-Results- und erkannte-Element-Beurteilungen der Live-URL. Viertens bestätigen Sie den Indexstatus und die ausgewählte Kanonische. Trennen Sie Fehler von Warnungen und trennen Sie Berechtigung von tatsächlicher Anzeige.

Werkzeug: Schema-Validator, das relevante Testtool der Suchplattform und AmICited URL Inspection. Erledigt wenn: Es null Syntaxfehler, null ungültige oder nicht unterstützte erforderliche Eigenschaften, null ungelöste Rich-Result-Fehler auf berechtigten Vorlagen gibt, jede Warnung einen Eigentümer oder dokumentierten Grund der Nichtanwendbarkeit hat und die geprüfte Live-URL unter der beabsichtigten Kanonischen indexiert ist.

8. Regressionsüberwachung und Änderungsverantwortung einrichten

Was: Automatisieren Sie Prüfungen und definieren Sie Ereignisse, die eine erneute Validierung erzwingen. Warum: Schema verfällt stillschweigend, wenn ein CMS-Feld umbenannt, eine Komponente ausgeblendet, eine Preisquelle geändert wird oder ein JavaScript-Deployment das Einfügen des Graphen stoppt. Wie: Führen Sie Vorlagen-Fixtures in Release-Tests aus, crawlen Sie repräsentative Live-URLs, vergleichen Sie erkannte Typen und Fehlerzahlen mit der Baseline und abonnieren Sie Berichte der Suchplattform. Lösen Sie eine gezielte Überprüfung nach Änderungen an Vorlagen, Navigation, Autorschaft, Organisationsidentität, Katalogfeldern, kanonischen Regeln oder sichtbaren FAQ- und Schrittkomponenten aus.

Werkzeug: Automatisierte Tests, geplanter Crawler, Deployment-Log, URL Inspection und eine verwaltete Issue-Queue. Erledigt wenn: Jede kritische Vorlage vor der Veröffentlichung und mindestens wöchentlich in der Produktion geprüft wird, Fehler innerhalb eines Werktags einen zugewiesenen Alarm erzeugen und das Entitätsregister ein vierteljährliches Überprüfungsdatum hat.

Tools in AmICited

AmICited unterstützt zwei verschiedene Teile des Workflows. Sie sollten nicht zu einer einzigen Bewertung zusammengefasst werden, da Erreichbarkeit und strukturierte Dateninterpretation unterschiedliche Fragen beantworten.

Öffnen Sie AI Accessibility unter https://app.amicited.com/accessibility , um zu überprüfen, ob KI-Agenten die Seitenstruktur erreichen und extrahieren können, die das Markup beschreiben soll. Ein perfekter Graph ist irrelevant, wenn ein Crawler auf eine Challenge-Seite, eine clientseitig gerenderte Hülle oder blockierten Zugriff stößt. Verwenden Sie diese Prüfung auf denselben repräsentativen URLs und User-Agent-Bedingungen wie für die Schema-Stichprobe.

Öffnen Sie URL Inspection unter https://app.amicited.com/reports/google-search/url-inspection für das Live-Google-Urteil. Prüfen Sie die beabsichtigte Kanonische, den Indexstatus, die Rich-Results-Beurteilung und die erkannten schema.org-Knoten. Überprüfen Sie die Gesamtzahlen der Objekte, Fehler und Warnungen, anstatt „Markup erkannt" als Bestehen zu werten. Aktualisieren Sie nach einem Deployment, wenn ein zwischengespeichertes Ergebnis die neue Vorlage nicht repräsentieren würde.

Halten Sie beide Berichts-URLs, die geprüfte Seite, Zeitpunkt, Ergebnis und Screenshot fest, damit der nächste Prüfer die Überprüfung reproduzieren kann.

Entscheidungsregeln

Zahlen machen aus „Schema-Qualität" eine Release-Entscheidung. Diese Schwellenwerte messen die Integrität der Implementierung, nicht versprochene Rankings, Rich Results oder Zitationen.

Das Bestehen garantiert kein Rich Result oder keine KI-Zitation; diese Schwellenwerte regeln Genauigkeit und Wartung, nicht die Auswahl.

Liefergegenstand

Übergeben Sie ein versioniertes Paket mit vier Artefakten: der Abdeckungsmatrix, dem Entitätsregister, dem Validierungsprotokoll und der Überwachungsspezifikation. Eine Tabellenkalkulation, Datenbank oder Repository-Datei ist akzeptabel, wenn die Felder exportierbar sind und Eigentümer sie aktualisieren können, ohne die Methode neu zu konstruieren.

SCHEMA-ABDECKUNGSMATRIX
Vorlage | Beispiel-URLs | Enthaltene Typen | Ausgeschlossene Typen und Grund
Eigenschaft | Sichtbares Quellfeld | Fallback | Implementierungseigentümer

ENTITÄTSREGISTER
Entitätstyp | Bevorzugter Name | Rechtlicher Name | Aliase
Kanonische Seite | Stabile @id | sameAs-Referenzen | Eintragseigentümer | Prüfdatum

VALIDIERUNGSPROTOKOLL
URL | Vorlage | Prüfzeitpunkt | Deployte Version
Parse-Ergebnis | Erkannte Typen | Fehler | Warnungen | Sichtbarkeitsparität
Indexstatus | Google-Kanonische | Rich-Results-Beurteilung | Nachweislinks

ÜBERWACHUNGSSPEZIFIKATION
Vorlage | Fixture-URLs | Prüfhäufigkeit | Alarmbedingung
Eigentümer | Reaktionszeit | Letzte Prüfung | Nächste Entitätsprüfung

Die Übergabe ist angenommen, wenn die Entwicklung die Vorlagenregel hinter jedem Live-Objekt identifizieren kann, der Content die sichtbare Quelle hinter jedem wesentlichen Wert identifizieren kann und der Eigentümer der nächsten Phase den kanonischen Entitätseintrag identifizieren kann, ohne den Code öffnen zu müssen.

Was schiefgeht

Ein Plugin zeichnet alles aus. Die Startseite wird zu einem Article, Kategoriekarten werden zu Produkten und jedes Akkordeon wird zu einem FAQ. Korrigieren Sie die Abdeckungsmatrix; die Konfiguration folgt dem Seitenzweck.

Markup und sichtbarer Inhalt verwenden unterschiedliche Datenbanken. Das Angebot sagt „auf Lager", nachdem die Seite „nicht verfügbar" anzeigt. Generieren Sie beide Darstellungen aus demselben Feld und testen Sie die Aktualisierungslatenz.

Jede Seite definiert die Organisation neu. Namen, Logos und Profile driften auseinander. Definieren Sie sie einmal mit einer stabilen @id und referenzieren Sie sie dann.

sameAs wird zu einem Link-Dump. Erwähnungen und ähnlich benannte Unternehmen werden als identisch behauptet. Behalten Sie nur autoritative Einträge und kontrollierte Profile für dieselbe Entität.

FAQ- oder HowTo-Markup versteckt die Antwort. Wenn Benutzer nur einen Teaser oder einen gesperrten Schritt sehen, rendern Sie den vollständigen markierten Inhalt oder entfernen Sie die Eigenschaften.

Die Validierung endet bei einem Generator. Die Live-Vorlage kann Objekte duplizieren, JSON falsch escapen oder bei Crawlern fehlschlagen. Validieren Sie die deployte Seite und ihre Index-Interpretation.

Warnungen werden pauschal als bestanden oder ignoriert gewertet. Triagieren Sie jede nach Konsequenz, dokumentieren Sie die Entscheidung und überprüfen Sie sie erneut, wenn sich Anforderungen oder Vorlagen ändern.

Schema bekommt Anerkennung für Ergebnisse, die es nicht garantieren kann. Verfolgen Sie Gültigkeit getrennt von Suchdarstellung, Traffic, KI-Zitationen und Konversionen.

Nächste Phase

P14 ist Off-Page Digital PR und Zitationen. Es benötigt das Entitätsregister, nicht nur Code. Coverage, Profile, Partnerschaften und Verzeichnisse sollten den genehmigten Namen, das kanonische Ziel und die Beziehungssprache verwenden; andernfalls kann externe Evidenz die falsche Identität stärken.

Der P13-Eigentümer übergibt:

• den genehmigten bevorzugten Namen, Aliase, die kanonische Seite und den stabilen Identifikator für jede Entität im Kampagnenumfang;
• die autoritativen Einträge, die bereits mit sameAs verbunden sind, einschließlich aller Lücken, die nicht ohne Verifizierung gefüllt werden sollten;
• die Seiten- und Schema-Typen, die jede Entität beschreiben, damit Outreach-Behauptungen mit den On-Site-Fakten übereinstimmen;
• ungelöste Konflikte, wie einen rechtlichen Namen, der von der öffentlichen Marke abweicht, oder zwei Experten mit ähnlichen Namen;
• den Überwachungseigentümer, der Identitätsänderungen überprüfen muss, die durch neue Profile, Rebrandings, Akquisitionen oder Autorenwechsel entstehen.

Die nächste Phase kann beginnen, wenn ein externer Publisher die korrekte Entität nur anhand dieses Pakets identifizieren und verlinken könnte. Sie wartet, solange Eigentümerschaft, Benennung oder Identität umstritten bleiben.

FAQ

Häufig gestellte Fragen