Schema.org for AI-fremvisning: Hvilke markeringer betyr noe nå

Schema.org for fremvisning av kunstig intelligens: Hvilke markeringer betyr noe nå

Per 5. september 2026 hjelper strukturert data fortsatt søkemotorer med å forstå sider, forfattere, organisasjoner og fakta. Det er imidlertid ikke en direkte rangeringsbryter for svar fra kunstig intelligens.

Google uttaler at sider ikke trenger spesiell Schema.org-oppmerking for å vises i AI-oversikter eller AI-modus. En side må hovedsakelig være gjennomsøkbar, indeksert, kvalifisert for et søkesnutt, og støttes av nyttig innhold. Google sier også at strukturert data skal samsvare med det synlige sideinnholdet. (developers.google.com)

Den beste nåværende strategien er derfor:

1. Bruk strukturert data for å beskrive siden nøyaktig.
2. La oppmerkingen samsvare med sidens egentlige formål.
3. Bygg klare relasjoner mellom artikler, forfattere, organisasjoner og emner.
4. Skriv direkte, fullstendige svar i synlig HTML.
5. Mål sitater fra kunstig intelligens separat fra tradisjonelle rike resultater.

Oppsummering

Det brede forskningsresultatet er viktig: å legge til generisk strukturert data alene har ikke produsert en konsekvent økning i sitater fra kunstig intelligens. En kontrollert Ahrefs-studie sporet 1885 sider som la til JavaScript Object Notation for Linked Data og sammenlignet dem med 4000 kontrollsider. Den fant ingen meningsfull forbedring i Google AI-modus eller ChatGPT-sitater. Google AI-oversikt-sitater falt litt, men forskerne advarte om at endringen var liten og ikke tydelig kunne skyldes oppmerkingen. (ahrefs.com)

En separat forhåndsutgivelse fra 2026 fant at generiske typer som Article, Organization, BreadcrumbList og WebPage ikke uavhengig predikerte sitater fra kunstig intelligens etter å ha kontrollert for søkerangering og domeneautoritet. Det sterkeste funnet var at sider med konkrete, attributtrike data, som priser, vurderinger og spesifikasjoner, presterte bedre enn sider med bare generiske sideetiketter. Dette funnet fokuserte hovedsakelig på produkt- og anmeldelsessider, så det bør ikke behandles som bevis på at noen av typene i denne artikkelen skaper en sitatfordel. (aixiv.science)

Hva strukturert data kan og ikke kan gjøre

Strukturert data er en maskinlesbar beskrivelse av en side. Den kan fortelle en søkemotor:

• Hva slags side det er
• Hvem som skrev den
• Hvilken organisasjon som publiserte den
• Hvilket spørsmål den svarer på
• Når den ble publisert eller oppdatert
• Hvilken person, bedrift, begrep eller datasett siden beskriver

Google sier at strukturert data kan hjelpe systemene deres med å forstå sideinnhold og gjøre sider kvalifiserte for rikere søkefunksjoner. De sier også at Google Søk kan bruke andre Schema.org-egenskaper for forståelse, selv når disse egenskapene ikke utløser et synlig søkeresultat. (developers.google.com)

Strukturert data garanterer ikke:

• En høyere organisk rangering
• Et sitat fra kunstig intelligens
• Et rikt resultat
• Et kunnskapspanel
• Inkludering i et svar fra kunstig intelligens
• Bruk av den nøyaktige teksten i oppmerkingen

Bing gir lignende veiledning. Deres nåværende webmasterveiledning sier at strukturert data kan støtte klarere forankring, men det garanterer ikke synlighet eller sitattrafikk. Bing råder også utgivere til å gjøre fakta og definisjoner eksplisitte i det synlige sideinnholdet. (bing.com)

Den viktigste forskningsbegrensningen

Svarpaneler for kunstig intelligens viser vanligvis kildesiden, ikke Schema.org-typen som kan ha vært til stede på den siden. Google publiserer ikke en rapport som for eksempel sier at en side ble sitert fordi den brukte Article i stedet for WebPage.

Dette skaper tre forskjellige spørsmål:

1. Ble siden sitert?
2. Inneholdt siden strukturert data?
3. Forårsaket strukturert data sitatet?

De fleste studier kan bare svare på de to første. De kan ikke bevise det tredje.

Det er derfor en side med FAQPage-oppmerking ofte kan vises i svar fra kunstig intelligens uten at oppmerkingen er årsaken. Siden kan ha sterkt innhold, en høy søkerangering, mange lenker eller et velkjent merke.

Revisjon etter skjematype

1. Article

Hva den gjør

Article beskriver en artikkel, nyhetssak, blogginnlegg eller lignende redaksjonell side. Google støtter Article, NewsArticle og BlogPosting som artikkeltyper. Google lister ikke opp nødvendige egenskaper for artikkeloppmerking, men anbefaler å legge til de egenskapene som gjelder for siden. (developers.google.com)

Egenskaper som betyr mest

Bruk disse når de er synlige og nøyaktige:

• headline
• author
• author.name
• author.url eller author.sameAs
• datePublished
• dateModified
• image
• publisher
• mainEntityOfPage
• about
• inLanguage

Google anbefaler å bruke en ekte Person eller Organization som forfatter. De anbefaler også å holde datoer i strukturert data konsistente med de synlige publiserings- og oppdateringsdatoene. (developers.google.com)

Effekt på kunstig intelligens

Bevisnivå: indirekte.

Article bidrar til å etablere sidetype, forfatterskap og aktualitet. Dette er nyttige signaler for søkesystemer, spesielt på faktasider og redaksjonelt innhold. Nåværende bevis viser imidlertid ikke at å legge til Article alene øker sitater fra kunstig intelligens.

Artikkelsjekkliste

• Siden er genuint en artikkel.
• Overskriften samsvarer med den synlige tittelen.
• Hver synlige forfatter er inkludert.
• Hver forfatter har et separat Person- eller Organization-objekt.
• Forfatternavn inneholder kun navn, ikke stillingstitler eller utgivernavn.
• Forfatteren lenker til en ekte profil- eller forfatterside.
• Publisering- og oppdateringsdatoer er synlige på siden.
• Datoer bruker riktig tidssone når klokkeslett er inkludert.
• Bildet representerer artikkelen.
• Utgiveren er konsekvent identifisert på tvers av nettstedet.
• Artikkelen er ikke merket som en annen primær type, for eksempel HowTo, med mindre siden virkelig tjener begge formål.

2. WebPage

Hva den gjør

WebPage er en generell sidetype. Schema.org uttaler at hver nettside implisitt behandles som en WebPage, men en eksplisitt erklæring kan hjelpe når siden inneholder egenskaper eller relasjoner på sidenivå. (schema.org)

Nyttige egenskaper inkluderer:

• url
• name
• description
• inLanguage
• dateModified
• breadcrumb
• mainEntity
• about
• isPartOf
• primaryImageOfPage

Effekt på kunstig intelligens

Bevisnivå: lavt og indirekte.

WebPage brukes best som det ytre sidelaget i en tilkoblet graf. Den kan koble siden til dens hovedartikkel, definisjon, datasett, person eller organisasjon.

Den bør ikke behandles som en spesiell optimaliseringstype for kunstig intelligens. En side som kun inneholder et generisk WebPage-objekt, gir vanligvis mindre nyttig informasjon enn en side som tydelig identifiserer sin hovedentitet.

WebPage-sjekkliste

• Bruk én stabil @id for siden.
• Bruk den kanoniske URL-en som side-URL.
• Identifiser sidens sanne mainEntity.
• Koble hovedentiteten tilbake til siden med mainEntityOfPage.
• Legg til inLanguage når kjent.
• Hold sidens navn og beskrivelse i samsvar med synlig innhold.
• Ikke bruk WebPage for å skjule det faktum at siden egentlig er en artikkel, profil, datasett eller spørsmålsside.

3. QAPage

Hva den gjør

QAPage er for en side fokusert på ett spørsmål og dets svar. Google sier at den bruker Question-strukturert data fra sider merket som QAPage, og det skal bare være én QAPage og ett hovedQuestion på siden. (developers.google.com)

Obligatoriske egenskaper

For nåværende Google spørsmål-og-svar-kvalifisering:

• QAPage.mainEntity
• Et nestet Question
• Question.answerCount
• Enten acceptedAnswer eller suggestedAnswer
• Answer.text

Et spørsmål uten svar er ikke kvalifisert for det rike resultatet.

Viktig innholdsregel

Ikke bruk QAPage for:

• En vanlig side med ofte stilte spørsmål (FAQ)
• Et blogginnlegg som svarer på et spørsmål
• En veiledningsartikkel (how-to)
• En produktside som inneholder mange spørsmål
• Et redaksjonelt svar skrevet kun av nettstedseieren

Google sier at brukere må kunne sende inn svar for en normal QAPage. Gyldige eksempler inkluderer et forumspørsmål eller en støtteside der brukere kan gi svar. (developers.google.com)

Effekt på kunstig intelligens

Bevisnivå: middels semantisk samsvar, ingen bevist kausal økning.

En ekte spørsmål-og-svar-side er naturlig nok lett for et gjenfinningssystem å forstå. Imidlertid er det ingen sterke offentlige studier som beviser at QAPage-oppmerking i seg selv øker sitater fra kunstig intelligens.

QAPage-sjekkliste

• Siden fokuserer på ett spørsmål.
• Brukere kan sende inn svar, med mindre siden kvalifiserer for en spesiell utdanningsspørsmål-og-svar-opplevelse.
• Hele spørsmålet er synlig.
• Hele svarteksten er synlig.
• answerCount samsvarer med det faktiske antallet svar.
• Aksepterte og foreslåtte svar er merket korrekt.
• Kommentarer er merket som kommentarer, ikke svar.
• Siden er ikke bare en redaksjonell side med ofte stilte spørsmål.
• Siden inneholder ikke flere urelaterte spørsmål.

QAPage-eksempel

html

Bruk dette mønsteret kun når siden virkelig støtter en spørsmål-og-svar-interaksjon.

4. HowTo

Hva den gjør

HowTo beskriver trinnvise instruksjoner. Google støttet en gang How-to rike resultater, men avviklet denne søkefunksjonen i september 2023. Google sa at How-to-resultater ikke lenger ville vises på datamaskin og allerede var fjernet fra mobilsøk. (developers.google.com)

Effekt på kunstig intelligens

Bevisnivå: lavt for Google.

De synlige trinnene kan fortsatt hjelpe brukere og gjenfinningssystemer. En klar veiledning med overskrifter, nummererte trinn, verktøy, tid og advarsler er lettere å lese og sitere. Men nåværende bevis viser ikke at HowTo-oppmerking skaper en spesiell fordel i Google AI-oversikter eller AI-modus.

Anbefaling

Bruk HowTo kun når:

• Siden genuint lærer bort en oppgave.
• Trinnene er synlige i sideinnholdet.
• En annen søkemotor, plattform eller internt system drar nytte av oppmerkingen.
• Teamet ditt kan vedlikeholde den uten å skape motstridende data.

For Google Søk, prioriter sterke HTML-overskrifter, nummererte lister, klare instruksjoner og nyttige bilder eller video.

Veiledningssjekkliste

• Siden lærer bort en ekte oppgave.
• Resultatet av oppgaven er klart.
• Hvert trinn er synlig og komplett.
• Trinnavn samsvarer med de synlige overskriftene.
• Verktøy og forsyninger er ekte og synlige.
• Tidsestimater er nøyaktige.
• Sikkerhetsadvarsler er inkludert der det er nødvendig.
• Den første delen gir et kort svar eller utfall.
• Siden er ikke avhengig av oppmerking for å gi instruksjonene.

5. ClaimReview

Hva den gjør

ClaimReview ble designet for faktasjekkinnhold. Google utfaset ClaimReview-støtte i Søk som en del av sin innsats i 2025 for å forenkle søkeresultatene. Typen ble fjernet fra Search Console-rapporteringen og Rich Results Test. (developers.google.com)

Effekt på kunstig intelligens

Bevisnivå: ingen nåværende Google-fordel.

En faktabekreftelse av høy kvalitet kan fortsatt siteres fordi den tydelig angir:

• Påstanden
• Vurderingen
• Bevisene
• Datoen
• Den faktabekreftende organisasjonen
• Begrunnelsen bak konklusjonen

Disse fordelene kommer hovedsakelig fra innholdet i seg selv, ikke fra den avviklede Google-søkefunksjonen.

Anbefaling

For en faktaside:

1. Bruk Article eller NewsArticle når siden er redaksjonell.
2. Angi tydelig påstanden i synlig tekst.
3. Sitér primær bevis.
4. Identifiser forfatteren og den kontrollerende organisasjonen.
5. Legg til publisering- og vurderingsdatoer.
6. Bruk ClaimReview bare hvis en annen plattform eller et datasystem spesifikt krever det.

Ikke legg til ClaimReview bare fordi du forventer at Google-svar fra kunstig intelligens vil foretrekke det.

6. FAQPage

Hva den gjør

FAQPage beskriver en side som inneholder spørsmål og offisielle svar. Google sluttet å vise FAQ rike resultater i Søk fra og med 7. mai 2026, og fjernet den relaterte dokumentasjonen i juni 2026. (developers.google.com)

Effekt på kunstig intelligens

Bevisnivå: svakt og blandet.

En 90-dagers leverandørstudie la til FAQPage-oppmerking på 120 sider. Den fant ingen pålitelig forbedring i ChatGPT-, Gemini- eller Google AI-oversiktsitater. Perplexity viste en liten økning, men studien selv sa at resultatet var plattformspesifikt og ikke beviste årsakssammenheng. (authorityradar.com)

En annen studie av 615 allerede siterte sider fant at FAQ-oppmerking dukket opp oftere på tungt siterte sider. Dette forholdet forsvant etter å ha kontrollert for gjentatte sider fra de samme utgiverne. Forskerne konkluderte med at bevisene ikke etablerte en effekt fra oppmerkingen i seg selv. (getintel.ai)

Anbefaling

Bruk ofte stilte spørsmål når de forbedrer siden for leserne. Ikke legg til store blokker med generiske spørsmål bare for å målrette svar fra kunstig intelligens.

Hvis du beholder FAQPage-oppmerking for en annen søkemotor eller innholdssystem:

• Gjør hvert spørsmål synlig.
• Gjør hvert svar komplett.
• Hold oppmerkingen identisk med siden.
• Ikke gjenta samme spørsmål i flere skjema-blokker.
• Ikke forvent et Google FAQ rikt resultat.

FAQPage-eksempel for ikke-Google-forbrukere

html

Dette er en semantisk beskrivelse, ikke et løfte om en Google-søkefunksjon.

7. Organization

Hva den gjør

Organization hjelper Google med å forstå og disambiguere et selskap, en ideell organisasjon, en utgiver, en skole eller en annen organisasjon. Google sier at organisasjonsoppmerking kan påvirke visuelle elementer som logoen som vises i Søk og noe informasjon i kunnskapspaneler. Det er ingen obligatoriske egenskaper i Googles nåværende organisasjonsveiledning. (developers.google.com)

Anbefalte egenskaper

Bruk egenskapene som er sanne og synlige:

• name
• alternateName
• url
• logo
• sameAs
• description
• telephone
• email
• address
• identifier
• foundingDate
• parentOrganization

Effekt på kunstig intelligens

Bevisnivå: indirekte, men nyttig.

Organization kan koble til:

• Utgiveren til en artikkel
• Selskapet til dets produkter eller tjenester
• Merkevaren til dets offisielle profiler
• Organisasjonen til en kjent webidentitet

Dette er nyttig for enhetsdisambiguering. Det beviser ikke at et system for kunstig intelligens vil sitere siden.

Organisasjons-sjekkliste

• Plasser hele organisasjonsobjektet på hjemmesiden eller organisasjonssiden.
• Bruk en stabil @id, for eksempel https://www.example.com/#organization.
• Bruk det nøyaktige offentlige organisasjonsnavnet.
• Lenk til ekte offisielle profiler med sameAs.
• Bruk riktig underkategori for organisasjonen når det er hensiktsmessig.
• Bruk en ekte logo som representerer organisasjonen.
• Hold kontaktinformasjonen oppdatert.
• Referer til organisasjonen fra artikler i stedet for å gjenskape motstridende versjoner på hver side.

8. Person

Hva den gjør

Person identifiserer en person som skriver, anmelder, eier, administrerer eller vises på en side. Den er vanligvis mest nyttig når den er koblet til:

• Article.author
• QAPage spørsmål- eller svarforfatter
• ProfilePage.mainEntity
• Organization.employee
• Review.author

Googles profilveiledning sier at en profilside må fokusere på én person eller organisasjon. ProfilePage-objektet krever en mainEntity, og denne entiteten må være en Person eller Organization. Personen eller organisasjonen må ha et name, eller et alternateName når ingen navn er tilgjengelig. (developers.google.com)

Anbefalte egenskaper

• name
• url
• sameAs
• image
• description
• jobTitle
• worksFor
• knowsAbout
• affiliation
• identifier

Effekt på kunstig intelligens

Bevisnivå: indirekte.

Person-oppmerking kan bidra til å koble en forfatters navn til:

• En biografi
• En jobb eller rolle
• En organisasjon
• Publisert artikler
• Eksterne profiler
• Ekspertiseområder

Bruk den til å tydeliggjøre identitet, ikke til å hevde ekspertise som siden ikke støtter.

Person-sjekkliste

• Bruk Person kun for en ekte person.
• Bruk Organization for et selskap eller en publikasjon.
• Koble personen til en synlig forfatterside.
• Bruk sameAs kun for nøyaktige, offisielle profiler.
• Hold stillingstitler og kvalifikasjoner oppdatert.
• Legg til alle synlige forfattere, ikke bare hovedforfatteren.
• Bruk samme person-@id på tvers av artikler og profilsider.

Matrise for obligatoriske egenskaper

Googles generelle veiledning favoriserer komplette og nøyaktige data fremfor store mengder ufullstendig oppmerking. Den advarer også om at strukturert data må representere synlig innhold, og at korrekt oppmerking fortsatt ikke garanterer et rikt resultat. (developers.google.com)

Sjekklister for implementering av brukstilfeller

Faktasider

Beste kombinasjon:

• WebPage
• Article eller NewsArticle
• Person
• Organization
• Valgfritt ClaimReview kun for en annen støttet forbruker

Sjekkliste:

• Angi hovedfaktum nær toppen av siden.
• Navngi kilden til faktumet.
• Lenk til primær bevis.
• Inkluder publiseringsdato og dato for siste gjennomgang.
• Identifiser forfatteren og anmelderen.
• Skill fakta fra meninger.
• Bruk Article når siden er redaksjonell.
• Ikke bruk ClaimReview som en nåværende Google Søk-taktikk.

Definisjonssider

Beste kombinasjon:

• WebPage
• DefinedTerm
• Valgfritt Article hvis siden er en lang redaksjonell forklaring
• Organization eller Person når en ekspert eller utgiver er ansvarlig

Schema.org definerer Dataset som et organ av strukturert informasjon og støtter relasjoner som includedInDataCatalog og distribution. (schema.org)

Sjekkliste:

• Gi definisjonen i første avsnitt.
• Bruk ett klart begrep som hovedentitet.
• Legg til alternative navn kun når de er reelle.
• Lenk til en pålitelig ekstern definisjon når det er hensiktsmessig.
• Forklar begrepet i et enkelt språk.
• Bruk eksempler og grenser.
• Unngå å merke en liste med urelaterte termer som én DefinedTerm.

Veiledninger

Beste kombinasjon:

• WebPage
• HowTo kun når en annen forbruker trenger det
• Article når veiledningen også er en redaksjonell artikkel
• Person og Organization for forfatterskap

Sjekkliste:

• Angi resultatet før trinnene.
• Bruk nummererte synlige overskrifter.
• Hold hvert trinn fokusert på én handling.
• Inkluder verktøy, forsyninger, tid og advarsler der det er nødvendig.
• Legg til bilder eller video når de hjelper.
• Ikke gjem trinnene kun i JSON-LD.
• Ikke forvent How-to rike resultater i Google Søk.

Datakataloger

Beste kombinasjon:

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.org definerer Dataset som en samling strukturert informasjon og støtter relasjoner som includedInDataCatalog og distribution. (schema.org)

Google klargjorde sent i 2025 at Dataset strukturert data brukes av Dataset Search og ikke er en generell søkeresultatfunksjon for Google Søk. Den bør derfor behandles som et datagjenfinning- og interoperabilitetslag, ikke en snarvei til sitater fra kunstig intelligens. (developers.google.com)

Sjekkliste:

• Gi hvert datasett en stabil identifikator.
• Angi emne og omfang.
• Inkluder utgiver eller skaper.
• Legg til datoperioden som dekkes av dataene.
• Angi geografisk dekning når relevant.
• Beskriv lisenser og tilgangsbetingelser.
• Legg til hver nedlastbare fil som en DataDownload.
• Inkluder filformat og nedlastings-URL.
• Hold katalogmetadata synkronisert med de faktiske filene.
• Dokumenter oppdateringsfrekvens og dato for siste oppdatering.

JSON-LD-eksempel: faktaside

Dette eksempelet kobler siden, artikkelen, forfatteren, utgiveren og emnet. Erstatt hver verdi med informasjon som vises på den virkelige siden.

html

JSON-LD-eksempel: definisjonsside

html

Definisjonen må også vises som normal sideteekst. Ikke plasser definisjonen kun i den strukturerte dataen.

JSON-LD-eksempel: veiledning

Fordi Googles How-to rike resultat er avviklet, behandle dette som valgfri oppmerking for andre systemer. Den synlige siden skal fortsatt inneholde de fullstendige instruksjonene.

html

JSON-LD-eksempel: datakatalog

html

Vanlige implementeringsfeller

Manglende samsvar i skjema

Den mest alvorlige feilen er å merke innhold som brukere ikke kan se. Google sier at strukturert data må være en sann representasjon av siden, og misvisende eller skjult innhold kan gjøre en side ukvalifisert for rike resultater. (developers.google.com)

Vanlige eksempler:

• Merke en artikkel som HowTo når den ikke inneholder virkelige trinn
• Merke et selskap som forfatter når artikkelen ble skrevet av en person
• Legge til FAQ-svar som ikke vises på siden
• Bruke en fremtidig publiseringsdato
• Merke et generelt blogginnlegg som QAPage
• Legge til ClaimReview i en meningsartikkel

Tynne svar

Strukturert data kan ikke fylle en tom side.

Et kort, vagt svar i Answer.text eller acceptedAnswer skaper ikke en sterk kilde. Det synlige innholdet bør:

• Svare direkte på spørsmålet
• Forklare viktige begrensninger og unntak
• Navngi kilder
• Inkludere datoer, eksempler eller målinger der det er nyttig
• Stå på egne ben når det kopieres ut av kontekst

Googles veiledning for kunstig intelligens sier at det ikke er noen ideell sidelengde og ingen grunn til å bryte innholdet i små biter for AI-systemer. Det bedre målet er nyttig, komplett, menneske-først-innhold. (developers.google.com)

Duplikate entiteter

Unngå å publisere flere motstridende versjoner av samme organisasjon, forfatter eller side.

Dårlig implementering:

• Ett Organization-objekt med ett navn på hjemmesiden
• Et annet objekt med et annet navn på hver artikkel
• Et tredje objekt uten @id på forfattersiden

Bedre implementering:

• Gi organisasjonen én stabil @id
• Gi hver forfatter én stabil @id
• Referer til disse objektene fra artikler, profiler og spørsmålssider
• Hold navn, logo, URL og eksterne identitetslenker konsistente

Duplikate spørsmål

Ikke gjenta samme spørsmål i:

• FAQPage
• QAPage
• Artikkeloppmerking
• Flere synlige sideseksjoner
• Flere JSON-LD-blokker

Bruk skjematypen som samsvarer med sidens hovedformål. Et enkelt, klart svar er bedre enn flere overlappende oppmerkingsblokker.

Feil datoer

Google bruker flere kilder for å estimere publiserings- og oppdateringsdatoer. De anbefaler at synlige datoer og strukturerte datoer stemmer overens, og de advarer mot å bruke fremtidige datoer eller datoer relatert til hendelser diskutert i artikkelen snarere enn datoer relatert til selve siden. (developers.google.com)

Overdreven bruk av sameAs

En sameAs-lenke skal identifisere samme virkelige person eller organisasjon. Ikke lenk til:

• En urelatert sosial profil
• En søkeresultatside
• En generisk katalogoppføring
• En side med en annen stavemåte eller identitet
• En profil som organisasjonen ikke kontrollerer

Kun JavaScript-oppmerking

Google kan behandle strukturert data lagt til den gjengitte siden, men en JavaScript-basert implementering kan være vanskeligere for andre indekseringsroboter og revisjonsverktøy å oppdage. En servergjengitt JSON-LD-blokk er vanligvis enklere å teste og vedlikeholde. (developers.google.com)

En praktisk testplan

For å måle om oppmerking har en inkrementell effekt, bruk en kontrollert test i stedet for å stole på noen få manuelle søk.

Før endringen

Registrer:

• Målspørringer
• Nåværende organisk rangering
• Om et AI-svar vises
• Hvilke sider som siteres
• Sitats posisjon når tilgjengelig
• Søketrafikk
• Konverteringer
• Nåværende strukturert data
• Innholdsendringer gjort i testperioden

Under testen

• Legg til én stor oppmerkingsendring om gangen.
• Hold innhold, interne lenker, titler og tilbakekoblinger stabile.
• Bruk lignende kontrollsider som ikke mottar endringen.
• Registrer den nøyaktige publiseringsdatoen for endringen.
• Vent lenge nok til gjennomsøking og ny behandling.

Ahrefs brukte matchede kontroller og en differanse-i-differanser-method før og etter. Deres tilnærming er en nyttig modell for organisasjoner som ønsker å teste strukturert data i stedet for å anta at en korrelasjon beviser årsakssammenheng. (ahrefs.com)

Etter endringen

Spor:

• Google Search Console AI-ytelsesdata
• Google AI-oversiktsitater
• Google AI-modus sitater
• Bing Webmaster Tools AI-sitater
• ChatGPT, Gemini eller Perplexity sitater når relevant
• Organiske rangeringer
• Søkeklikk
• Assisterte konverteringer

Google rapporterer AI-søketrafikk gjennom Search Console-ytelsesrapportering. Bings AI-ytelsesrapportering viser siterte sider og forankringsspørsmål, men den viser ikke hvorfor en side ble valgt eller hvor viktig den var i et svar. (developers.google.com)

Anbefalt implementeringsrekkefølge

For de fleste utgivere er den beste rekkefølgen:

1. Fiks synlig innhold først.
2. Gjør gjennomsøking og indeksering pålitelig.
3. Implementer Article for ekte redaksjonelle sider.
4. Koble forfattere med Person og profilsider.
5. Koble utgivere med Organization.
6. Bruk WebPage som et rent grafisk lag på sidenivå.
7. Bruk QAPage kun for ekte fellesskapsspørsmål.
8. Bruk DefinedTerm for ordliste- og definisjonssider.
9. Bruk Dataset og DataCatalog for dataressurser.
10. Behandle FAQPage, HowTo og ClaimReview som sekundær eller ikke-Google-oppmerking fordi deres Google-søkefunksjoner er fjernet eller avviklet.

Konklusjon

Den sterkeste nåværende lærdommen er enkel: Schema.org-oppmerking hjelper maskiner med å forstå innhold, men det er ikke en garantert vei inn i AI-svar.

Den mest holdbare implementeringen er ikke en stor samling av skjematyper. Det er en liten, nøyaktig enhetsgraf:

• Article beskriver den redaksjonelle siden.
• Person identifiserer forfatteren.
• Organization identifiserer utgiveren.
• WebPage kobler siden til dens hovedentitet.
• QAPage beskriver et ekte brukerspørsmål og dets svar.
• DefinedTerm klargjør en definisjon.
• Dataset og DataCatalog beskriver strukturerte dataressurser.

Bruk strukturert data der det gir klar mening. Ikke bruk det til å maskere tynt innhold, duplisere synlig tekst eller imitere en søkefunksjon som Google ikke lenger støtter. For AI-fremvisning forblir det høyest verdsatte arbeidet klare svar, sterke bevis, nøyaktige entiteter, oppdatert informasjon og innhold som kan stå på egne ben.