Schema.org for AI-eksponering: Hvilke markups er vigtige nu

Schema.org for Kunstig Intelligens-eksponering: Hvilke markups er vigtige nu

Pr. 5. september 2026 hjælper strukturerede data stadig søgemaskiner med at forstå sider, forfattere, organisationer og fakta. Det er dog ikke en direkte rangeringsfaktor for svar fra kunstig intelligens.

Google oplyser, at sider ikke behøver speciel Schema.org-markup for at vises i AI Overviews eller AI-tilstand. En side skal primært være crawlbar, indekseret, berettiget til et søgeresultat-uddrag og understøttet af nyttigt indhold. Google siger også, at strukturerede data skal stemme overens med sidens synlige indhold. (developers.google.com)

Den bedste nuværende strategi er derfor:

1. Brug strukturerede data til at beskrive siden præcist.
2. Match markuppen til sidens sande formål.
3. Opbyg klare relationer mellem artikler, forfattere, organisationer og emner.
4. Skriv direkte, komplette svar i synlig HTML.
5. Mål kunstig intelligens-citater separat fra traditionelle rige resultater.

Konklusion

Den brede forskningskonklusion er vigtig: tilføjelse af generiske strukturerede data alene har ikke medført en konsekvent stigning i kunstig intelligens-citater. En kontrolleret Ahrefs-undersøgelse sporede 1.885 sider, der tilføjede JavaScript Object Notation for Linked Data, og sammenlignede dem med 4.000 kontrolsider. Den fandt ingen meningsfuld forbedring i Google AI-tilstand eller ChatGPT-citater. Google AI Overview-citater faldt en smule, men forskerne advarede om, at ændringen var lille og ikke klart kunne tilskrives markuppen. (ahrefs.com)

En separat preprint fra 2026 fandt, at generiske typer som Article, Organization, BreadcrumbList og WebPage ikke uafhængigt forudsagde kunstig intelligens-citater efter at have kontrolleret for søgerangering og domæneautoritet. Deres stærkeste fund var, at sider med konkrete, attributrige data, såsom priser, bedømmelser og specifikationer, klarede sig bedre end sider med kun generiske sidemærker. Dette fund fokuserede primært på produkt- og anmeldelsessider, så det bør ikke behandles som bevis for, at nogen af typerne i denne artikel skaber en citationsfordel. (aixiv.science)

Hvad strukturerede data kan og ikke kan gøre

Strukturerede data er en maskinlæsbar beskrivelse af en side. De kan fortælle en søgemaskine:

• Hvilken type side det er
• Hvem der har skrevet den
• Hvilken organisation der har udgivet den
• Hvilket spørgsmål den besvarer
• Hvilken dato den blev udgivet eller opdateret
• Hvilken person, virksomhed, term eller datasæt siden beskriver

Google siger, at strukturerede data kan hjælpe deres systemer med at forstå sideindhold og gøre sider kvalificerede til rigere søgefunktioner. De siger også, at Google Søg kan bruge andre Schema.org-egenskaber til forståelse, selv når disse egenskaber ikke udløser et synligt søgeresultat. (developers.google.com)

Strukturerede data garanterer ikke:

• En højere organisk rangering
• En kunstig intelligens-citation
• Et rich result
• Et videnspanel
• Inkludering i et kunstig intelligens-svar
• Brug af den nøjagtige tekst i markuppen

Bing giver lignende vejledning. Deres nuværende webmastervejledning siger, at strukturerede data kan understøtte en klarere forankring, men det garanterer ikke synlighed eller citationstrafik. Bing råder også udgivere til at gøre fakta og definitioner eksplicitte i det synlige sideindhold. (bing.com)

Den vigtigste forskningsbegrænsning

Kunstig intelligens-svarpaneler viser normalt kildesiden, ikke den Schema.org-type, der måtte have været til stede på siden. Google offentliggør ikke en rapport, der f.eks. siger, at en side blev citeret, fordi den brugte Article i stedet for WebPage.

Dette skaber tre forskellige spørgsmål:

1. Blev siden citeret?
2. Indeholdt siden strukturerede data?
3. Forårsagede de strukturerede data citationen?

De fleste studier kan kun besvare de første to. De kan ikke bevise den tredje.

Det er derfor, en side med FAQPage-markup ofte kan vises i kunstig intelligens-svar, uden at markuppen er årsagen. Siden kan have stærkt indhold, en høj søgerangering, mange links eller et kendt brand.

Audit efter skematype

1. Article

Hvad den gør

Article beskriver en artikel, nyhedshistorie, blogindlæg eller lignende redaktionel side. Google understøtter Article, NewsArticle og BlogPosting som artikeltyper. Google angiver ikke obligatoriske egenskaber for artikel-markup, men anbefaler at tilføje de egenskaber, der gælder for siden. (developers.google.com)

Egenskaber der betyder mest

Brug disse, når de er synlige og nøjagtige:

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

Google anbefaler at bruge en rigtig Person eller Organization som forfatter. De anbefaler også at holde datoer i strukturerede data i overensstemmelse med de synlige udgivelses- og opdateringsdatoer. (developers.google.com)

Kunstig intelligens-effekt

Bevisniveau: indirekte.

Article hjælper med at etablere sidetype, forfatterskab og aktualitet. Disse er nyttige signaler for søgesystemer, især på faktasider og redaktionelt indhold. Nuværende beviser viser dog ikke, at tilføjelse af Article alene øger kunstig intelligens-citater.

Artikel-tjekliste

• Siden er ægte en artikel.
• Overskriften matcher den synlige titel.
• Hver synlig forfatter er inkluderet.
• Hver forfatter har et separat Person- eller Organization-objekt.
• Forfatternavne indeholder kun navne, ikke jobtitler eller udgivernavne.
• Forfatteren linker til en rigtig profil eller forfatterside.
• Udgivelses- og opdateringsdatoer er synlige på siden.
• Datoer bruger den korrekte tidszone, når tid er inkluderet.
• Billedet repræsenterer artiklen.
• Udgiveren er identificeret konsekvent på tværs af siden.
• Artiklen er ikke markeret som en anden primær type, såsom HowTo, medmindre siden virkelig tjener begge formål.

2. WebPage

Hvad den gør

WebPage er en generel sidetype. Schema.org oplyser, at enhver webside implicit behandles som en WebPage, men en eksplicit erklæring kan hjælpe, når siden inkluderer egenskaber eller relationer på sideniveau. (schema.org)

Nyttige egenskaber inkluderer:

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

Kunstig intelligens-effekt

Bevisniveau: lavt og indirekte.

WebPage bruges bedst som det ydre sidelag i en forbundet graf. Den kan forbinde siden til dens hovedartikel, definition, datasæt, person eller organisation.

Den bør ikke behandles som en speciel kunstig intelligens-optimeringstype. En side, der kun indeholder et generisk WebPage-objekt, giver normalt mindre nyttig information end en side, der tydeligt identificerer sin hovedentitet.

Webside-tjekliste

• Brug et stabilt @id for siden.
• Brug den kanoniske URL som side-URL.
• Identificer sidens sande mainEntity.
• Link hovedentiteten tilbage til siden med mainEntityOfPage.
• Tilføj inLanguage, når kendt.
• Hold sidetitel og beskrivelse afstemt med synligt indhold.
• Brug ikke WebPage til at skjule, at siden i virkeligheden er en artikel, profil, datasæt eller spørgsmålsside.

3. QAPage

Hvad den gør

QAPage er til en side, der fokuserer på ét spørgsmål og dets svar. Google siger, at de bruger Question-strukturerede data fra sider markeret som QAPage, og der bør kun være én QAPage og ét hovedQuestion på siden. (developers.google.com)

Obligatoriske egenskaber

For nuværende Google spørgsmål-og-svar-kvalifikation:

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

Et spørgsmål uden svar er ikke kvalificeret til det rige resultat.

Vigtig indholdsregel

Brug ikke QAPage til:

• En normal ofte stillede spørgsmål-side
• Et blogindlæg, der besvarer et spørgsmål
• En "sådan gør du"-artikel
• En produktside, der indeholder mange spørgsmål
• Et redaktionelt svar skrevet kun af webstedsejeren

Google siger, at brugere skal kunne indsende svar til en normal QAPage. Gyldige eksempler inkluderer et forumspørgsmål eller en supportside, hvor brugere kan give svar. (developers.google.com)

Kunstig intelligens-effekt

Bevisniveau: medium semantisk match, ingen bevist kausal forbedring.

En rigtig spørgsmål-og-svar-side er naturligvis let for et genfindingssystem at forstå. Der er dog ingen stærk offentlig undersøgelse, der beviser, at QAPage-markup i sig selv øger kunstig intelligens-citater.

QAPage-tjekliste

• Siden fokuserer på ét spørgsmål.
• Brugere kan indsende svar, medmindre siden kvalificerer sig til en særlig uddannelsesrelateret spørgsmål-og-svar-oplevelse.
• Det fulde spørgsmål er synligt.
• Den fulde svartekst er synlig.
• answerCount matcher det faktiske antal svar.
• Accepterede og foreslåede svar er korrekt mærket.
• Kommentarer er markeret som kommentarer, ikke svar.
• Siden er ikke blot en redaktionel ofte stillede spørgsmål-side.
• Siden indeholder ikke flere urelaterede spørgsmål.

QAPage-eksempel

html

Brug kun dette mønster, når siden virkelig understøtter en spørgsmål-og-svar-interaktion.

4. HowTo

Hvad den gør

HowTo beskriver trin-for-trin-instruktioner. Google understøttede engang "Sådan gør du"-rige resultater, men udfasede denne søgefunktion i september 2023. Google sagde, at "Sådan gør du"-resultater ikke længere ville vises på desktop og allerede var fjernet fra mobil søgning. (developers.google.com)

Kunstig intelligens-effekt

Bevisniveau: lavt for Google.

De synlige trin kan stadig hjælpe brugere og genfindingssystemer. En klar vejledning med overskrifter, nummererede trin, værktøjer, tid og advarsler er lettere at læse og citere. Men nuværende beviser viser ikke, at HowTo-markup skaber en særlig fordel i Google AI Overviews eller AI-tilstand.

Anbefaling

Brug kun HowTo, når:

• Siden virkelig lærer en opgave.
• Trinnene er synlige i sideindholdet.
• En anden søgemaskine, platform eller et internt system drager fordel af markuppen.
• Dit team kan vedligeholde det uden at skabe modstridende data.

For Google Søg skal du prioritere stærke HTML-overskrifter, nummererede lister, klare instruktioner og nyttige billeder eller videoer.

Vejlednings-tjekliste

• Siden lærer en rigtig opgave.
• Resultatet af opgaven er klart.
• Hvert trin er synligt og komplet.
• Trinnavne matcher de synlige overskrifter.
• Værktøjer og forsyninger er ægte og synlige.
• Tidsestimater er nøjagtige.
• Sikkerhedsadvarsler er inkluderet, hvor det er nødvendigt.
• Den første sektion giver et kort svar eller resultat.
• Siden er ikke afhængig af markup for at give instruktionerne.

5. ClaimReview

Hvad den gør

ClaimReview blev designet til faktatjek-indhold. Google udfasede Claim Review-understøttelsen i Søg som en del af deres indsats i 2025 for at forenkle søgeresultaterne. Typen blev fjernet fra Search Console-rapportering og Rich Results Test. (developers.google.com)

Kunstig intelligens-effekt

Bevisniveau: ingen nuværende Google-fordel.

Et faktatjek af høj kvalitet kan stadig citeres, fordi det tydeligt angiver:

• Påstanden
• Bedømmelsen
• Beviset
• Datoen
• Den faktatjekkende organisation
• Begrundelsen bag konklusionen

Disse fordele kommer primært fra selve indholdet, ikke fra den udfasede Google-søgefunktion.

Anbefaling

For en faktaside:

1. Brug Article eller NewsArticle, når siden er redaktionel.
2. Angiv tydeligt påstanden i synlig tekst.
3. Citer primære beviser.
4. Identificer forfatteren og den gennemgående organisation.
5. Tilføj udgivelses- og gennemgangsdatoer.
6. Brug ClaimReview kun hvis en anden platform eller et datasystem specifikt kræver det.

Tilføj ikke ClaimReview kun fordi du forventer, at Googles kunstige intelligens-svar foretrækker det.

6. FAQPage

Hvad den gør

FAQPage beskriver en side, der indeholder spørgsmål og officielle svar. Google stoppede med at vise FAQ rich result i Søg startende 7. maj 2026, og fjernede den relaterede dokumentation i juni 2026. (developers.google.com)

Kunstig intelligens-effekt

Bevisniveau: svagt og blandet.

Et 90-dages leverandørstudie tilføjede FAQPage-markup til 120 sider. Det fandt ingen pålidelig forbedring i ChatGPT-, Gemini- eller Google AI Overview-citater. Perplexity viste en lille stigning, men selve studiet sagde, at resultatet var platformspecifikt og ikke beviste kausalitet. (authorityradar.com)

Et andet studie af 615 allerede citerede sider fandt, at FAQ-markup optrådte oftere på stærkt citerede sider. Denne relation forsvandt efter kontrol for gentagne sider fra de samme udgivere. Forskerne konkluderede, at beviserne ikke etablerede en effekt fra selve markuppen. (getintel.ai)

Anbefaling

Brug ofte stillede spørgsmål, når de forbedrer siden for læserne. Tilføj ikke store blokke af generiske spørgsmål blot for at målrette kunstig intelligens-svar.

Hvis du beholder FAQPage-markup for en anden søgemaskine eller indholdssystem:

• Gør hvert spørgsmål synligt.
• Gør hvert svar komplet.
• Hold markuppen identisk med siden.
• Gentag ikke det samme spørgsmål i flere schema-blokke.
• Forvent ikke et Google FAQ rich result.

FAQPage-eksempel for ikke-Google-forbrugere

html

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

7. Organization

Hvad den gør

Organization hjælper Google med at forstå og disambiguere en virksomhed, nonprofitorganisation, udgiver, skole eller anden organisation. Google siger, at organisation-markup kan påvirke visuelle elementer såsom logoet vist i Søg og visse videnspanelinformationer. Der er ingen obligatoriske egenskaber i Googles nuværende organisationsguide. (developers.google.com)

Anbefalede egenskaber

Brug de egenskaber, der er sande og synlige:

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

Kunstig intelligens-effekt

Bevisniveau: indirekte, men nyttigt.

Organization kan forbinde:

• Udgiveren til en artikel
• Virksomheden til dens produkter eller tjenester
• Brandet til dets officielle profiler
• Organisationen til en kendt webidentitet

Dette er nyttigt for disambiguering af entiteter. Det beviser ikke, at et kunstig intelligens-system vil citere siden.

Organisation-tjekliste

• Placer det fulde organisationsobjekt på hjemmesiden eller organisationssiden.
• Brug et stabilt @id, f.eks. https://www.example.com/#organization.
• Brug det nøjagtige offentlige organisationsnavn.
• Link til reelle officielle profiler med sameAs.
• Brug den korrekte organisationstype, når det er relevant.
• Brug et ægte logo, der repræsenterer organisationen.
• Hold kontaktoplysninger ajour.
• Referer til organisationen fra artikler i stedet for at genskabe modstridende versioner på hver side.

8. Person

Hvad den gør

Person identificerer en person, der skriver, anmelder, ejer, administrerer eller optræder på en side. Den er normalt mest nyttig, når den er forbundet til:

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

Googles profilvejledning siger, at en profilside skal fokusere på én person eller organisation. ProfilePage-objektet kræver en mainEntity, og denne entitet skal være en Person eller Organization. Personen eller organisationen skal have et name eller et alternateName, når intet navn er tilgængeligt. (developers.google.com)

Anbefalede egenskaber

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

Kunstig intelligens-effekt

Bevisniveau: indirekte.

Person-markup kan hjælpe med at forbinde en forfatters navn til:

• En biografi
• Et job eller en rolle
• En organisation
• Udgivne artikler
• Eksterne profiler
• Ekspertiseområder

Brug det til at gøre identiteten klar, ikke til at hævde ekspertise, som siden ikke understøtter.

Person-tjekliste

• Brug Person kun for en rigtig person.
• Brug Organization for en virksomhed eller publikation.
• Link personen til en synlig forfatterside.
• Brug sameAs kun for nøjagtige, officielle profiler.
• Hold jobtitler og legitimationsoplysninger ajour.
• Tilføj alle synlige forfattere, ikke kun hovedforfatteren.
• Brug det samme person @id på tværs af artikler og profilsider.

Obligatorisk egenskabsmatrix

Googles generelle vejledning foretrækker komplette og nøjagtige data frem for store mængder ufuldstændig markup. Den advarer også om, at strukturerede data skal repræsentere synligt indhold, og at korrekt markup stadig ikke garanterer et rich result. (developers.google.com)

Tjeklister for implementering af brugsscenarier

Faktasider

Bedste kombination:

• WebPage
• Article eller NewsArticle
• Person
• Organization
• Valgfri ClaimReview kun for en anden understøttet forbruger

Tjekliste:

• Angiv hovedfaktummet nær toppen af siden.
• Navngiv kilden til faktummet.
• Link til primære beviser.
• Inkluder udgivelsesdato og seneste gennemgangsdato.
• Identificer forfatteren og anmelderen.
• Adskil fakta fra meninger.
• Brug Article, når siden er redaktionel.
• Brug ikke ClaimReview som en nuværende Google Søg-taktik.

Definitionssider

Bedste kombination:

• WebPage
• DefinedTerm
• Valgfri Article, hvis siden er en lang redaktionel forklaring
• Organization eller Person, når en ekspert eller udgiver er ansvarlig

DefinedTerm er beregnet til et ord, en sætning, en kode eller et koncept med en formel definition. Dens hovedegenskaber inkluderer name, description, termCode, inDefinedTermSet og sameAs. (schema.org)

Tjekliste:

• Giv definitionen i første afsnit.
• Brug et klart udtryk som hovedentitet.
• Tilføj alternative navne kun når de er reelle.
• Link til en pålidelig ekstern definition, når det er relevant.
• Forklar udtrykket i et almindeligt sprog.
• Brug eksempler og afgrænsninger.
• Undgå at markere en liste over urelaterede udtryk som én DefinedTerm.

Vejledninger

Bedste kombination:

• WebPage
• HowTo kun når en anden forbruger har brug for det
• Article, når vejledningen også er en redaktionel artikel
• Person og Organization for forfatterskab

Tjekliste:

• Angiv resultatet før trinnene.
• Brug nummererede synlige overskrifter.
• Hold hvert trin fokuseret på én handling.
• Inkluder værktøjer, forsyninger, tid og advarsler, hvor det er nødvendigt.
• Tilføj billeder eller videoer, når de hjælper.
• Skjul ikke trinnene kun i JSON-LD.
• Forvent ikke "Sådan gør du"-rige resultater i Google Søg.

Datakataloger

Bedste kombination:

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.org definerer Dataset som en samling af struktureret information og understøtter relationer som includedInDataCatalog og distribution. (schema.org)

Google præciserede i slutningen af 2025, at Dataset-strukturerede data bruges af Datasæt Søg og ikke er en generel Google Søg-resultatfunktion. Det bør derfor behandles som et datagenfindings- og interoperabilitetslag, ikke en genvej til kunstig intelligens-citater. (developers.google.com)

Tjekliste:

• Giv hvert datasæt en stabil identifikator.
• Angiv emnet og omfanget.
• Inkluder udgiveren eller skaberen.
• Tilføj datointervallet, som dataene dækker.
• Angiv geografisk dækning, når det er relevant.
• Beskriv licenser og adgangsbetingelser.
• Tilføj hver downloadbar fil som en DataDownload.
• Inkluder filformat og download-URL.
• Hold katalogmetadata synkroniseret med de faktiske filer.
• Dokumenter opdateringsfrekvens og seneste opdateringsdato.

JSON-LD eksempel: faktaside

Dette eksempel forbinder siden, artiklen, forfatteren, udgiveren og emnet. Erstat hver værdi med information, der vises på den rigtige side.

html

JSON-LD eksempel: definitionsside

html

Definitionen skal også vises som normal sidetekst. Placer ikke definitionen udelukkende i de strukturerede data.

JSON-LD eksempel: vejledning

Da Googles "Sådan gør du"-rige resultat er udfaset, skal dette behandles som valgfri markup for andre systemer. Den synlige side bør stadig indeholde de fulde instruktioner.

html

JSON-LD eksempel: datakatalog

html

Almindelige faldgruber ved implementering

Uoverensstemmende schema

Den mest alvorlige fejl er at markere indhold, som brugere ikke kan se. Google siger, at strukturerede data skal være en sand repræsentation af siden, og vildledende eller skjult indhold kan gøre en side ukvalificeret til rich results. (developers.google.com)

Almindelige eksempler:

• Markere en artikel som en HowTo, når den ikke indeholder rigtige trin
• Markere en virksomhed som forfatter, når artiklen blev skrevet af en person
• Tilføje FAQ-svar, der ikke vises på siden
• Bruge en fremtidig udgivelsesdato
• Markere et generelt blogindlæg som QAPage
• Tilføje ClaimReview til en meningsartikel

Korte/Mangelfulde svar

Strukturerede data kan ikke fylde en tom side.

Et kort, vagt svar inde i Answer.text eller acceptedAnswer skaber ikke en stærk kilde. Det synlige indhold bør:

• Besvare spørgsmålet direkte
• Forklare vigtige begrænsninger og undtagelser
• Navngive kilder
• Inkludere datoer, eksempler eller målinger, hvor det er nyttigt
• Stå alene, når det kopieres ud af kontekst

Googles kunstig intelligens-vejledning siger, at der ikke er nogen ideel sidelængde og intet behov for at opdele indhold i små stykker for kunstig intelligens-systemer. Det bedre mål er nyttigt, komplet, menneskecentreret indhold. (developers.google.com)

Duplikerede entiteter

Undgå at udgive flere modstridende versioner af den samme organisation, forfatter eller side.

Svag implementering:

• Ét Organization-objekt med ét navn på hjemmesiden
• Et andet objekt med et andet navn på hver artikel
• Et tredje objekt uden @id på forfattersiden

Bedre implementering:

• Giv organisationen ét stabilt @id
• Giv hver forfatter ét stabilt @id
• Referer til disse objekter fra artikler, profiler og spørgsmålssider
• Hold navn, logo, URL og eksterne identitetslinks konsistente

Duplikerede spørgsmål

Gentag ikke det samme spørgsmål i:

• FAQPage
• QAPage
• Artikel-markup
• Flere synlige sideafsnit
• Flere JSON-LD-blokke

Brug den skematype, der matcher sidens hovedformål. Et enkelt, klart svar er bedre end flere overlappende markup-blokke.

Ukorrekte datoer

Google bruger flere kilder til at estimere udgivelses- og opdateringsdatoer. De anbefaler, at synlige datoer og strukturerede datoer stemmer overens, og de advarer mod at bruge fremtidige datoer eller datoer relateret til begivenheder, der diskuteres i artiklen, snarere end datoer relateret til selve siden. (developers.google.com)

Overforbrug af sameAs

Et sameAs-link skal identificere den samme virkelige person eller organisation. Link ikke til:

• En urelateret social profil
• En søgeresultatside
• En generisk katalogfortegnelse
• En side med en anden stavemåde eller identitet
• En profil, som organisationen ikke kontrollerer

Kun JavaScript-markup

Google kan behandle strukturerede data, der er tilføjet til den gengivne side, men en JavaScript-only implementering kan være sværere for andre crawlere og revisionsværktøjer at registrere. En server-renderet JSON-LD-blok er normalt lettere at teste og vedligeholde. (developers.google.com)

En praktisk testplan

For at måle, om markup har en inkrementel effekt, skal du bruge en kontrolleret test i stedet for at stole på et par manuelle søgninger.

Før ændringen

Registrer:

• Målforespørgsler
• Nuværende organisk rangering
• Om et kunstig intelligens-svar vises
• Hvilke sider der citeres
• Citationsposition, når tilgængelig
• Søgetrafik
• Konverteringer
• Nuværende strukturerede data
• Indholdsændringer foretaget i testperioden

Under testen

• Tilføj én større markup-ændring ad gangen.
• Hold indhold, interne links, titler og backlinks stabile.
• Brug lignende kontrolsider, der ikke modtager ændringen.
• Registrer den nøjagtige udgivelsesdato for ændringen.
• Vent længe nok til crawling og genbehandling.

Ahrefs brugte matchede kontroller og en før-og-efter difference-in-differences metode. Deres tilgang er en nyttig model for organisationer, der ønsker at teste strukturerede data i stedet for at antage, at en korrelation beviser kausalitet. (ahrefs.com)

Efter ændringen

Spor:

• Google Search Console præstationsdata for kunstig intelligens
• Google AI Overview-citater
• Google AI-tilstand-citater
• Bing Webmaster Tools kunstig intelligens-citater
• ChatGPT-, Gemini- eller Perplexity-citater, når det er relevant
• Organiske rangeringer
• Søgeklik
• Assisterede konverteringer

Google rapporterer kunstig intelligens-søgetrafik via Search Console-præstationsrapportering. Bings rapportering af kunstig intelligens-præstation viser citerede sider og "grounding"-forespørgsler, men den viser ikke, hvorfor en side blev valgt, eller hvor vigtig den var inden for et svar. (developers.google.com)

Anbefalet implementeringsrækkefølge

For de fleste udgivere er den bedste rækkefølge:

1. Ret synligt indhold først.
2. Gør crawling og indeksering pålidelig.
3. Implementer Article for rigtige redaktionelle sider.
4. Forbind forfattere med Person og profilsider.
5. Forbind udgivere med Organization.
6. Brug WebPage som et rent grafisk lag på sideniveau.
7. Brug QAPage kun til ægte fællesskabsspørgsmål.
8. Brug DefinedTerm til ordlister og definitionssider.
9. Brug Dataset og DataCatalog til dataressourcer.
10. Behandl FAQPage, HowTo og ClaimReview som sekundær eller ikke-Google-markup, da deres Google-søgefunktioner er blevet fjernet eller udfaset.

Konklusion

Den stærkeste nuværende lektion er enkel: Schema.org-markup hjælper maskiner med at forstå indhold, men det er ikke en garanteret vej til kunstig intelligens-svar.

Den mest holdbare implementering er ikke en stor samling af skematyper. Det er en lille, nøjagtig entitetsgraf:

• Article beskriver den redaktionelle side.
• Person identificerer forfatteren.
• Organization identificerer udgiveren.
• WebPage forbinder siden med dens hovedentitet.
• QAPage beskriver et ægte brugerspørgsmål og dets svar.
• DefinedTerm præciserer en definition.
• Dataset og DataCatalog beskriver strukturerede dataressourcer.

Brug strukturerede data, hvor de tilføjer klar mening. Brug dem ikke til at forklæde tyndt indhold, duplikere synlig tekst eller efterligne en søgefunktion, som Google ikke længere understøtter. For kunstig intelligens-eksponering forbliver det mest værdifulde arbejde klare svar, stærk evidens, nøjagtige entiteter, aktuel information og indhold, der kan stå alene.