Gestructureerde gegevens en entiteitsopbouw

Gestructureerde gegevens en entiteitsopbouw zetten goedgekeurde feiten op de site om in een machineleesbare laag. Het identificeert de personen, organisaties, producten, artikelen, vragen, stappen en navigatiepaden die daadwerkelijk bestaan, kent stabiele identificatoren toe en drukt toetsbare relaties uit. Het verzint nooit een tweede versie van de inhoud.

Fase: P13, Gestructureerde gegevens en entiteitsopbouw. Stadium: C — Bouw. Tijdsbox: 3–5 werkdagen voor een site met een klein aantal stabiele sjablonen; 1–2 weken voor een marktplaats, uitgever of e-commercecatalogus met meerdere contentsystemen. Eigenaar: de technische SEO-lead is verantwoordelijk, met engineering die sjablonen implementeert, contenteigenaren die zichtbare feiten bevestigen, en merk- of juridische eigenaren die canonieke entiteitsrecords goedkeuren.

Zoekmachines behandelen schema over het algemeen als één signaal naast paginainhoud, links, feeds en ander bewijs. AI-ophaalsystemen kunnen de gestructureerde laag steeds vaker behandelen als een directe bron van feiten en relaties. Een onjuiste prijs, auteur, organisatienaam of relatie kan daarom met vertrouwen worden geëxtraheerd omdat het expliciet lijkt. Markup verbetert de interpretatie; het kan een ongefundeerde bewering niet waar maken.

Waarom deze fase, en waarom hier

P13 verbruikt beslissingen die eerder in het proces zijn genomen. De topische kaart identificeert welke pagina eigenaar is van elke intentie en entiteit. De contentinventaris identificeert duplicaten en verouderde URL’s. Het productiesysteem stabiliseert velden zoals auteur, beoordelingsdatum, prijs, beschikbaarheid en FAQ-tekst. On-page-optimalisatie maakt die feiten zichtbaar, terwijl intern-koppelingswerk de hiërarchie en canonieke bestemmingen repareert. Pas daarna kan een schemasjabloon een stabiele pagina beschrijven in plaats van een bewegend doelwit coderen.

Het te vroeg uitvoeren van deze fase produceert technisch geldige fictie. Een ontwikkelaar kan elke redactionele pagina markeren als Article voordat het bedrijf beslist of de auteursregel een persoon, een team of de organisatie vertegenwoordigt. Een productsjabloon kan een aanbiedingsprijs tonen die de zichtbare pagina later vervangt door “neem contact op”. Breadcrumb-markup kan een oude hiërarchie behouden nadat de navigatie is gewijzigd. Elk object wordt geparset, maar vertelt machines iets anders dan wat mensen zien.

Het overslaan van de fase laat systemen meer afleiden dan nodig is. Ze kunnen de pagina nog steeds begrijpen, maar namen, relaties, datums, auteurschap en productfeiten blijven dubbelzinnig. Dat verzwakt entiteitsdesambiguatie : het proces van beslissen naar welke echte persoon, bedrijf, product of plaats een naam verwijst. Het bemoeilijkt ook toekomstig onderhoud omdat niemand eigenaar is van de identificatoren en bronvelden achter de markup.

De output is niet “schema toegevoegd”. Het is een geteste mapping van paginasjablonen naar gerechtvaardigde schematypen, een canoniek entiteitenregister, live validatiebewijs en een monitoringsregel. P14, off-page digitale PR en citaties, heeft dat contract nodig zodat externe profielen, berichtgeving en verwijzingen dezelfde namen en identificatoren versterken in plaats van nieuwe varianten te creëren.

Inputs en outputs

De dekkingsmatrix contracteert met implementatie; het entiteitenregister contracteert met de volgende fase. Validatiebewijs en monitoring houden beide actueel.

De checklist

Elk item hieronder bevat het werk, de reden, de methode, het hulpmiddel en een done-when-voorwaarde. Behoud die vijf velden als de checklist naar een ticketsysteem wordt verplaatst.

1. Inventariseer sjablonen en selecteer geschikte paginavoorbeelden

Wat: maak een lijst van elk sjabloon binnen bereik en kies representatieve live-URL’s, inclusief varianten met ontbrekende optionele velden. Waarom: één ideaal voorbeeld kan conditionele fouten niet blootleggen, zoals een product zonder beoordelingen, een artikel zonder genoemde auteur, of een categorie zonder breadcrumb-bovenliggende. Hoe: groepeer URL’s op weergavesjabloon en contentbron, selecteer vervolgens minstens één complete, één minimale en één randgeval-URL per sjabloon. Hulpmiddel: de paginainventaris, crawler-export, CMS-model en browser. Done when: 100% van de sjablonen binnen bereik hebben minstens drie voorbeelden, of alle live-URL’s wanneer een sjabloon minder dan drie heeft.

2. Kies alleen schematypen die hun plek verdienen

Wat: wijs typen toe op basis van de zichtbare taak van de pagina. Waarom: extra typen vergroten het oppervlak voor tegenstrijdigheden zonder recht te geven op een resultaat. Hoe: gebruik het smalste accurate type en documenteer waarom elk object bestaat:

• Artikelschema of BlogPosting hoort bij redactionele content met een zichtbare kop, auteur of uitgever en publicatiecontext. Gebruik de bredere Article wanneer een smaller subtype misleidend zou zijn.
• FAQ-schema hoort alleen waar gebruikers de volledige vragen en antwoorden zien. Semantische waarde en speciale zoekweergavegeschiktheid zijn gescheiden.
• HowTo hoort bij een zichtbare geordende procedure. Drie marketingvoordelen zijn geen how-to.
• Productschema hoort bij een specifiek product of variant. Aanbiedingen, valuta, beschikbaarheid, beoordelingen en reviews moeten overeenkomen met de pagina.
• Organisatieschema hoort bij de canonieke organisatierepresentatie en kan elders worden gerefereerd via stabiele @id.
• Person hoort bij een canoniek profiel met voldoende zichtbare informatie om de persoon te identificeren. Een kale auteursregel rechtvaardigt geen credentials.
• BreadcrumbList-schema moet een hiërarchie weerspiegelen die gebruikers kunnen begrijpen, geen kunstmatig trefwoordpad.

Hulpmiddel: de dekkingsmatrix, zichtbare pagina’s, schema.org-vocabulaire en de huidige geschiktheidsdocumentatie van het zoekplatform. Done when: elk geselecteerd type heeft een rechtvaardiging van één zin, een zichtbare bron en een expliciete uitsluitingsregel voor pagina’s waar het niet mag worden weergegeven.

3. Bouw het canonieke entiteitenregister

Wat: maak één onderhouden record voor elke belangrijke organisatie, persoon, productfamilie en locatie. Waarom: consistente identificatoren laten verschillende pagina’s naar hetzelfde verwijzen; inconsistente namen laten machines beslissen of “AmICited”, “Am I Cited” en een juridische bedrijfsnaam één entiteit of meerdere zijn. Hoe: noteer de voorkeursnaam voor publiek, juridische naam waar relevant, alias, canonieke pagina, entiteitstype, stabiele @id, eigenaar en gezaghebbende sameAs-verwijzingen. Een sameAs-waarde beweert identiteit, niet topische relevantie, dus moet alleen verwijzen naar een record of officieel profiel dat dezelfde entiteit vertegenwoordigt.

Eén canonieke pagina is eigenaar van de volledige definitie van elke entiteit; andere pagina’s verwijzen naar de @id in plaats van concurrenten te creëren. De canonieke URL van een pagina identificeert de voorkeurspagina voor indexering, terwijl @id het beschreven ding identificeert. De entiteit kan bijvoorbeeld https://example.com/about/#organization zijn terwijl de pagina https://example.com/about/ blijft.

Hulpmiddel: entiteitenregister, CMS-records, juridische of HR-brongegevens, officiële profielen en gezaghebbende openbare registers. Done when: 100% van de materiële entiteiten die in markup worden gebruikt, hebben één voorkeursnaam, één canonieke pagina of goedgekeurde uitzondering, één stabiele @id, een eigenaar en geen onopgelost identiteitsconflict.

4. Koppel eigenschappen aan zichtbare bronvelden

Wat: verbind elke schema-eigenschap met het veld dat het zichtbare feit weergeeft. Waarom: handmatige duplicatie veroorzaakt drift; dezelfde prijs of auteur die twee keer is opgeslagen, zal uiteindelijk tegenstrijdig zijn. Hoe: koppel headline aan de zichtbare titel, author aan het gepubliceerde auteursregelrecord, dateModified aan een betekenisvolle zichtbare updatedatum, aanbiedingsvelden aan de klantgerichte commercebron, FAQ-objecten aan weergegeven antwoorden en breadcrumb-posities aan de werkelijke hiërarchie. Vul geen eigenschap in omdat deze beschikbaar is in een plugin, als de bron verborgen, verouderd of semantisch verschillend is.

Hulpmiddel: CMS-schema, sjablooncode, commercefeed, content-API en veldenkaart. Done when: elke materiële eigenschap heeft één genoemde bron, transformatieregel, terugvalgedrag en eigenaar; nul materiële waarden worden onafhankelijk onderhouden in markup en zichtbare content.

5. Implementeer een verbonden JSON-LD-grafiek

Wat: render de goedgekeurde objecten en verbind ze met stabiele identificatoren. Waarom: niet-verbonden blokken kunnen dezelfde organisatie of auteur beschrijven als afzonderlijke dingen, terwijl stabiele verwijzingen relaties duidelijk uitdrukken. Hoe: gebruik JSON-LD — JavaScript Object Notation for Linked Data — tenzij het bestaande platform een ander ondersteund formaat vereist. Gebruik @id-verwijzingen voor uitgever, auteur, productmerk en primaire entiteit in plaats van gedeeltelijke definities te herhalen. Houd de output waar mogelijk server-leesbaar en escape gebruikersgestuurde strings veilig.

Het resultaat is een kleine knowledge graph op paginaniveau: entiteiten en hun relaties. Neem feiten op die ze op deze pagina identificeren of kwalificeren, niet elke beschikbare eigenschap.

Hulpmiddel: sjabloonengine, source control-review, browsertbron en een JSON-parser. Done when: alle geselecteerde voorbeelden leveren parseerbare objecten, elke interne @id verwijst naar één definitie of beoogde verwijzing, optionele velden verdwijnen netjes wanneer afwezig, en geen sjabloon geeft lege of plaatsvervangende waarden.

6. Voer een zichtbare-contentpariteitsbeoordeling uit

Wat: vergelijk elk materieel opgemaakt feit met wat een gebruiker op dezelfde URL kan zien. Waarom: gestructureerde gegevens zijn een expliciete bewering, geen verstop plek voor content. Zoeksystemen kunnen misleidende markup negeren, geschiktheid verwijderen of handmatige actiebeleid toepassen; AI-systemen kunnen de verkeerde waarde herhalen alsof deze gezaghebbend is. Hoe: vergelijk de weergegeven pagina en geëxtraheerde grafiek naast elkaar. Controleer namen, auteurschap, credentials, datums, prijzen, beschikbaarheid, valuta, beoordelingen, aantallen reviews, vragen, antwoorden, stappen en breadcrumb-labels.

Hulpmiddel: weergegeven pagina, geëxtraheerde JSON-LD, CMS-voorbeeld en commercebron. Done when: 100% van de materiële eigenschappen komen overeen met zichtbare content in betekenis, eenheden, scope en actualiteit voor de complete, minimale en randgeval-voorbeelden.

7. Valideer syntaxis, geschiktheid, canonicalen en live interpretatie

Wat: test de gegenereerde grafiek op vier niveaus. Waarom: geldige JSON kan de verkeerde eigenschap gebruiken; geldig schema kan niet voldoen aan de vereisten van een zoekfunctie; een correcte pagina kan nog steeds niet-geïndexeerd zijn; en Google kan een andere canonieke kiezen. Hoe: parseer eerst de JSON. Valideer vervolgens het vocabulaire en type-specifieke vereisten. Inspecteer ten derde de rich-results en gedetecteerde-item-oordelen van de live URL. Bevestig ten vierde de indexstatus en de geselecteerde canonieke. Scheid fouten van waarschuwingen, en scheid geschiktheid van werkelijke weergave.

Hulpmiddel: schemavalidator, het relevante testplatform van het zoekplatform en AmICited URL-inspectie. Done when: er zijn nul syntaxisfouten, nul ongeldige of niet-ondersteunde vereiste eigenschappen, nul onopgeloste rich-result fouten op geschikte sjablonen, elke waarschuwing heeft een eigenaar of gedocumenteerde reden van niet-toepasbaarheid, en de geïnspecteerde live URL is geïndexeerd onder de beoogde canonieke.

8. Stel regressiemonitoring en wijzigingseigenaarschap in

Wat: automatiseer controles en definieer gebeurtenissen die herevaluatie afdwingen. Waarom: schema rot stil wanneer een CMS-veld wordt hernoemd, een component wordt verborgen, een prijsbron verandert, of een JavaScript-implementatie stopt met het injecteren van de grafiek. Hoe: voer sjabloonfixtures uit in releasetests, crawld representatieve live-URL’s, vergelijk gedetecteerde typen en fouttellingen met de basislijn, en abonneer u op rapporten van het zoekplatform. Activeer een gerichte beoordeling na wijzigingen aan sjablonen, navigatie, auteurschap, organisatie-identiteit, catalogusvelden, canonieke regels of zichtbare FAQ- en stapcomponenten.

Hulpmiddel: geautomatiseerde tests, geplande crawler, implementatielogboek, URL-inspectie en een beheerde issue-wachtrij. Done when: elk kritiek sjabloon wordt gecontroleerd vóór publicatie en minstens wekelijks in productie, fouten creëren een toegewezen melding binnen één werkdag, en het entiteitenregister heeft een driemaandelijkse beoordelingsdatum.

Hulpmiddelen in AmICited

AmICited ondersteunt twee verschillende delen van de workflow. Ze mogen niet worden samengevoegd tot één score, omdat bereikbaarheid en interpretatie van gestructureerde gegevens verschillende vragen beantwoorden.

Open AI-toegankelijkheid op https://app.amicited.com/accessibility om te verifiëren dat AI-agents de paginastructuur die de markup moet beschrijven kunnen bereiken en extraheren. Een perfecte grafiek is irrelevant als een crawler een uitdagingspagina, een client-gerenderde shell of geblokkeerde toegang krijgt. Gebruik deze controle op dezelfde representatieve URL’s en user-agent-omstandigheden als gebruikt voor het schema-voorbeeld.

Open URL-inspectie op https://app.amicited.com/reports/google-search/url-inspection voor het live Google-oordeel. Inspecteer de beoogde canonieke, indexstatus, rich-results-oordeel en gedetecteerde schema.org-knooppunten. Beoordeel object-, fout- en waarschuwingstotalen in plaats van “markup gedetecteerd” als een goedkeuring te behandelen. Ververs na een implementatie wanneer een gecached resultaat het nieuwe sjabloon niet zou vertegenwoordigen.

Noteer beide rapport-URL’s, de geïnspecteerde pagina, tijd, resultaat en screenshot, zodat de volgende beoordelaar de controle kan reproduceren.

Beslisregels

Cijfers maken van “schemakwaliteit” een publicatiebeslissing. Deze drempels meten implementatie-integriteit, niet beloofde rankings, rich results of citaties.

Slagen garandeert geen rich result of AI-citatie; deze drempels bepalen nauwkeurigheid en onderhoud, niet selectie.

Opleverbaar

Draag één versiebeheerd pakket over met vier artefacten: de dekkingsmatrix, het entiteitenregister, het validatielogboek en de monitoringsspecificatie. Een spreadsheet, database of repositorybestand is acceptabel als de velden exporteerbaar zijn en eigenaren ze kunnen bijwerken zonder de methode te reconstrueren.

SCHEMA DEKKINGSMATRIX
Sjabloon | Voorbeeld-URL's | Opgenomen typen | Uitgesloten typen en reden
Eigenschap | Zichtbaar bronveld | Terugval | Implementatie-eigenaar

ENTITEITENREGISTER
Entiteitstype | Voorkeursnaam | Juridische naam | Alias
Canonieke pagina | Stabiele @id | sameAs-verwijzingen | Recordeigenaar | Beoordelingsdatum

VALIDATIELOGBOEK
URL | Sjabloon | Testtijd | Geïmplementeerde versie
Parseerresultaat | Gedetecteerde typen | Fouten | Waarschuwingen | Zichtbaarheidspariteit
Indexstatus | Google-canonieke | Rich-results-oordeel | Bewijskoppelingen

MONITORINGSPECIFICATIE
Sjabloon | Fixture-URL's | Controlefrequentie | Alarmeringsconditie
Eigenaar | Reactietijd | Laatste geslaagde | Volgende entiteitsbeoordeling

De overdracht wordt geaccepteerd wanneer engineering de sjabloonregel achter elk live object kan identificeren, content de zichtbare bron achter elke materiële waarde kan identificeren, en de eigenaar van de volgende fase het canonieke entiteitenrecord kan identificeren zonder de code te openen.

Wat er misgaat

Een plugin markeert alles op. De homepage wordt een Article, categorielijsten worden producten en elke accordeon wordt een FAQ. Fix de dekkingsmatrix; configuratie volgt paginadoel.

Markup en zichtbare content gebruiken verschillende databases. De aanbieding zegt “op voorraad” nadat de pagina “niet beschikbaar” aangeeft. Genereer beide representaties uit hetzelfde veld en test updatelatentie.

Elke pagina herdefinieert de organisatie. Namen, logo’s en profielen raken uit elkaar. Definieer het één keer met een stabiele @id en verwijs er vervolgens naar.

sameAs wordt een linkdump. Vermeldingen en gelijknamige bedrijven worden beweerd als identiek. Houd alleen gezaghebbende records en gecontroleerde profielen voor dezelfde entiteit.

FAQ- of HowTo-markup verbergt het antwoord. Als gebruikers alleen een teaser of afgeschermde stap zien, render dan de volledige gemarkeerde inhoud of verwijder de eigenschappen.

Validatie stopt bij een generator. Het live sjabloon kan objecten dupliceren, JSON verkeerd escapen of falen voor crawlers. Valideer de geïmplementeerde pagina en de indexinterpretatie ervan.

Waarschuwingen worden in hun geheel genegeerd of afgewezen. Triageer elke waarschuwing op consequentie, leg de beslissing vast en bezoek deze opnieuw wanneer vereisten of sjablonen veranderen.

Schema krijgt krediet voor resultaten die het niet kan garanderen. Volg geldigheid apart bij van zoekweergave, verkeer, AI-citaties en conversies.

Volgende fase

P14 is off-page digitale PR en citaties. Het heeft het entiteitenregister nodig, niet alleen code. Berichtgeving, profielen, partnerschappen en mappen moeten de goedgekeurde naam, canonieke bestemming en relatietaal gebruiken; anders kan extern bewijs de verkeerde identiteit versterken.

De P13-eigenaar draagt over:

• de goedgekeurde voorkeursnaam, alias, canonieke pagina en stabiele identificator voor elke entiteit binnen campagnebereik;
• de gezaghebbende records die al zijn verbonden met sameAs, inclusief eventuele hiaten die niet mogen worden gevuld zonder verificatie;
• de pagina- en schematypen die elke entiteit beschrijven, zodat outreach-claims overeenkomen met feiten op de site;
• onopgeloste conflicten, zoals een juridische naam die afwijkt van het publieke merk of twee experts met vergelijkbare namen;
• de monitoringeigenaar die identiteitswijzigingen moet beoordelen die zijn ontstaan door nieuwe profielen, rebrandings, overnames of auteurswijzigingen.

De volgende fase kan beginnen wanneer een externe uitgever de juiste entiteit kan identificeren en linken met alleen dit pakket. Het wacht zolang eigendom, naamgeving of identiteit betwist blijft.

FAQ

Veelgestelde vragen