Slik splittes entiteten din — og hva det koster
Fant to konkurrerende Person-schema på eget domene, uten felles @id. Slik ser entitetssplitting ut, hva det koster i AI-søk, og hvordan du retter det.
Kort svar: Entitetssplitting er når to eller flere konkurrerende versjoner av samme enhet — for eksempel en person eller en bedrift — finnes side om side i strukturert data eller innhold på nettet, uten en felles identifikator som binder dem sammen. Søkemotorer og språkmodeller kan da ikke avgjøre hvilken versjon som er den korrekte, og enheten mister autoritet i stedet for å bygge den.
Funnet på eget domene
Jeg gikk gjennom det strukturerte dataet (SchemaSchema er maskinlesbar merking som forteller søkemotorer og språkmodeller hva innholdet på en side faktisk er. Det skaper ikke autoritet i seg selv, men gjør eksisterende innhold lettere å tolke riktig.Se i ordlisten) på kristerross.no og fant nettopp dette problemet i egen skog. Domenet publiserer to forskjellige Person-objekter for samme person, med to forskjellige jobTitle-verdier — én sier «AI SEO og Growth Strategist», den andre «Vekstmarkedsfører». Den ene versjonen mangler i tillegg et stabilt @id. Uten det feltet finnes det ingen teknisk måte å fortelle Google eller en språkmodell at de to objektene faktisk beskriver samme person.
Konsekvensen er ikke kosmetisk. Når to schema-objekter med ulik jobbtittel begge er koblet til samme navn, må det som leser dataene velge — eller la være å velge, og i praksis behandle det som to svakere signaler i stedet for ett sterkt. Det er nøyaktig det motsatte av hva strukturert data skal gjøre.
Hvorfor @id er limet som holder entiteten sammen
@id er JSON-LD sin måte å si «dette er samme ting, uansett hvor det dukker opp» på. Uten et konsistent @id ser hver forekomst av en Person eller Organization ut som et helt nytt, ukjent objekt for maskinen som leser det. Det spiller ingen rolle om navnet er stavet likt — uten @id er koblingen implisitt, og implisitte koblinger er nøyaktig det språkmodeller er dårligst til å anta riktig.
Et stabilt @id gjør tre ting samtidig: det lar samme EntitetEn entitet er en identifiserbar ting — en person, et selskap, et produkt eller et sted — som søkemotorer og språkmodeller kan knytte fakta til. Konsistent navn, kontaktinfo og profiler på tvers av kilder er det som gjør entiteten entydig.Se i ordlisten refereres til fra flere sider på domenet ditt, det lar eksterne kilder (en artikkel, en profil, et sitat) peke tilbake på nøyaktig samme entitet via sameAs, og det gir en søkemotor eller modell ett sted å samle alt den vet om deg i stedet for flere spredte, delvis motstridende fragmenter.
Hva splittelsen koster deg i praksis
Tre konkrete kostnader følger av en splittet entitet:
- Utvannet autoritet. Signaler som skulle styrket én entitet, fordeles i stedet på to. Hver av dem ser svakere ut enn de ville gjort samlet.
- Feil ved SiteringEn sitering er når en AI-tjeneste oppgir kilden bak et svar, som regel med lenke. Sitering er noe annet enn omtale: du kan bli nevnt uten å bli lenket til, og lenket til uten å bli nevnt ved navn.Se i ordlisten. Når en AI-modell skal beskrive hvem du er eller hva du gjør, har den to motstridende kilder å velge mellom. I beste fall velger den én og ignorerer den andre. I verste fall blander den elementer fra begge og produserer en beskrivelse som ikke stemmer med noen av dem.
- Svekket knowledge-graph-tilstedeværelse. Google og de store språkmodellene bygger interne representasjoner av entiteter over tid. En splittet entitet gir et svakere, mer usikkert utgangspunkt for den representasjonen enn én konsistent entitet ville gjort — selv om den totale mengden innhold er identisk.
Slik retter du en splittet entitet
Rettelsen er konseptuelt enkel, men krever disiplin på tvers av hele domenet:
- Velg én kanonisk versjon. Bestem hvilken
jobTitle, beskrivelse og bilde som er riktig, og bruk kun den — overalt. - Gi entiteten ett fast
@id. Typisk en URL-anker på hovedsiden for personen eller organisasjonen, for eksempelhttps://dittdomene.no/om-meg/#person. Bruk nøyaktig samme streng hver eneste gang entiteten refereres. - Fjern eller oppdater den utdaterte versjonen. Ikke la den gamle bli liggende «for sikkerhets skyld» — det er selve problemet.
- Koble entiteten sammen med
sameAs. Pek til eksterne profiler (LinkedIn, forfatterside hos en publikasjon, en relevant Wikipedia-artikkel) som konsekvent beskriver samme person med samme detaljer. - Verifiser mot rendret HTML, ikke mot CMS-et. Mange publiseringsverktøy bekrefter at en skrive-operasjon lyktes uten å bekrefte at endringen faktisk kom med i den ferdig genererte siden. Sjekk alltid den live siden.
Denne typen entitetsarbeid henger direkte sammen med schema mer generelt — hvilke typer som faktisk påvirker hvordan AI-søk oppfatter deg, og hvilke som ignoreres. Se en bredere innføring i hvorfor entiteter og struktur er blitt grunnlaget for synlighet i AI-søk i den komplette guiden til AI SEO / AEO / GEO / LLMO.
Ofte stilte spørsmål
Hva er entitetssplitting?
Entitetssplitting er når to eller flere konkurrerende versjoner av samme person eller organisasjon eksisterer i strukturert data uten en felles identifikator (@id) som binder dem sammen, slik at søkemotorer og AI-modeller ikke kan slå dem sammen til én entitet.
Hvordan finner jeg ut om min egen entitet er splittet?
Se gjennom JSON-LD-blokkene (Person- og Organization-typer) på tvers av domenets sider. Sjekk om jobTitle, beskrivelse og navn er identisk hvert sted, og om alle forekomstene deler nøyaktig samme @id-streng.
Holder det å bare fjerne den ene versjonen?
Det løser splittelsen, men bare hvis den gjenværende versjonen har et stabilt @id og konsistent innhold. Å fjerne én versjon uten å sette opp @id riktig på den andre løser ikke det underliggende problemet.
Er dette bare et problem for kjente personer eller store merkevarer?
Nei. Effekten er størst for nettopp mindre kjente entiteter — de har færre eksterne signaler i utgangspunktet til å kompensere for en intern selvmotsigelse.
Takk — dette hjelper meg med å gjøre artikkelen bedre.
Ordforklaringer
Begrepene som brukes i denne artikkelen.
- AEO
- AEO (Answer Engine Optimization) er arbeidet med å gjøre innhold lett å finne, forstå og sitere for AI-drevne svartjenester. Der SEO avgjør om du rangerer i en lenkeliste, avgjør AEO om du blir kilden svaret bygges på.
- GEO
- GEO (Generative Engine Optimization) er optimalisering rettet mot generative søkemotorer som ChatGPT, Perplexity og Google AI Overviews. Begrepet brukes i praksis om det samme arbeidet som AEO.
- LLMO
- LLMO (Large Language Model Optimization) er enda et navn på arbeidet med å bli synlig i språkmodeller. AEO, GEO og LLMO beskriver i praksis samme jobb, med ulik innfallsvinkel i navnet.
- Entitet
- En entitet er en identifiserbar ting — en person, et selskap, et produkt eller et sted — som søkemotorer og språkmodeller kan knytte fakta til. Konsistent navn, kontaktinfo og profiler på tvers av kilder er det som gjør entiteten entydig.
- Sitering
- En sitering er når en AI-tjeneste oppgir kilden bak et svar, som regel med lenke. Sitering er noe annet enn omtale: du kan bli nevnt uten å bli lenket til, og lenket til uten å bli nevnt ved navn.
- Schema
- Schema er maskinlesbar merking som forteller søkemotorer og språkmodeller hva innholdet på en side faktisk er. Det skaper ikke autoritet i seg selv, men gjør eksisterende innhold lettere å tolke riktig.
Få det jeg lærer om AI-søk
Egne tester og analyser av hvordan språkmodellene velger kilder. Ingen fast frekvens — jeg sender når jeg faktisk har noe å si.
