Schema.org för AI-visning: Vilka markeringar är viktiga nu

Schema.org för AI-visning: Vilka markeringar är viktiga nu

Från och med den 5 september 2026 hjälper strukturerad data fortfarande sökmotorer att förstå sidor, författare, organisationer och fakta. Det är dock ingen direkt rankningsfaktor för svar från artificiell intelligens.

Google uppger att sidor inte behöver särskild Schema.org-markup för att visas i AI-översikter eller AI-läge. En sida måste huvudsakligen vara genomsökbar, indexerad, kvalificerad för en sökutdrag och stödd av användbart innehåll. Google säger också att strukturerad data ska matcha det synliga sidinnehållet. (developers.google.com)

Den bästa nuvarande strategin är därför:

1. Använd strukturerad data för att beskriva sidan korrekt.
2. Matcha markupen med sidans verkliga syfte.
3. Skapa tydliga relationer mellan artiklar, författare, organisationer och ämnen.
4. Skriv direkta, kompletta svar i synlig HTML.
5. Mät citat från artificiell intelligens separat från traditionella rika resultat.

Sammanfattande bedömning

Den breda forskningsresultatet är viktigt: att lägga till generisk strukturerad data ensam har inte lett till en konsekvent ökning av AI-citat. En kontrollerad Ahrefs-studie spårade 1 885 sidor som lade till JavaScript Object Notation for Linked Data och jämförde dem med 4 000 kontrollsidor. Den fann ingen meningsfull förbättring i Google AI-läge eller ChatGPT-citat. Google AI Overview-citat minskade något, men forskarna varnade för att förändringen var liten och inte tydligt kunde skyllas på markupen. (ahrefs.com)

En separat förpublicering från 2026 fann att generiska typer som Article, Organization, BreadcrumbList och WebPage inte oberoende förutsade AI-citat efter att ha kontrollerat för sökposition och domänauktoritet. Dess starkaste fynd var att sidor med konkreta, attributrika data, såsom priser, betyg och specifikationer, presterade bättre än sidor med endast generiska sidetiketter. Detta fynd fokuserade främst på produkt- och recensionssidor, så det bör inte behandlas som bevis för att någon av typerna i denna artikel skapar en citation-fördel. (aixiv.science)

Vad strukturerad data kan och inte kan göra

Strukturerad data är en maskinläsbar beskrivning av en sida. Den kan berätta för en sökmotor:

• Vilken typ av sida det är
• Vem som skrev den
• Vilken organisation som publicerade den
• Vilken fråga den besvarar
• Vilket datum den publicerades eller uppdaterades
• Vilken person, företag, term eller datamängd sidan beskriver

Google säger att strukturerad data kan hjälpa dess system att förstå sidinnehåll och göra sidor kvalificerade för rikare sökfunktioner. Det sägs också att Google Sök kan använda andra Schema.org-egenskaper för förståelse, även när dessa egenskaper inte utlöser ett synligt sökresultat. (developers.google.com)

Strukturerad data garanterar inte:

• En högre organisk rankning
• Ett AI-citat
• Ett rikt resultat
• En kunskapspanel
• Inkludering i ett AI-svar
• Användning av exakt text i markupen

Bing ger liknande vägledning. Dess nuvarande webbansvarig-vägledning säger att strukturerad data kan stödja tydligare förankring, men den garanterar inte synlighet eller citationstrafik. Bing råder också utgivare att göra fakta och definitioner explicita i det synliga sidinnehållet. (bing.com)

Den huvudsakliga forskningsbegränsningen

AI-svarspaneler visar vanligtvis källsidan, inte den Schema.org-typ som kan ha funnits på den sidan. Google publicerar ingen rapport som till exempel säger att en sida citerades för att den använde Article istället för WebPage.

Detta skapar tre olika frågor:

1. Citerades sidan?
2. Innehöll sidan strukturerad data?
3. Orsakade den strukturerade datan citatet?

De flesta studier kan bara svara på de två första. De kan inte bevisa den tredje.

Det är därför en sida med FAQPage-markup ofta kan visas i AI-svar utan att markupen är anledningen. Sidan kan ha starkt innehåll, en hög sökrankning, många länkar eller ett välkänt varumärke.

Granskning per schematyp

1. Article

Vad den gör

Article beskriver en artikel, nyhetsartikel, blogginlägg eller liknande redaktionell sida. Google stöder Article, NewsArticle och BlogPosting som artikeltyper. Google listar inte obligatoriska egenskaper för artikelmarkup, men rekommenderar att man lägger till de egenskaper som gäller för sidan. (developers.google.com)

Viktigaste egenskaper

Använd dessa när de är synliga och korrekta:

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

Google rekommenderar att man använder en riktig Person eller Organization som författare. De rekommenderar också att datum i strukturerad data är konsekventa med de synliga publicerings- och uppdateringsdatumen. (developers.google.com)

Effekt på artificiell intelligens

Bevisnivå: indirekt.

Article hjälper till att fastställa sidtyp, författarskap och aktualitet. Dessa är användbara signaler för söksystem, särskilt på faktasidor och redaktionellt innehåll. Aktuella bevis visar dock inte att enbart tillägg av Article ökar AI-citat.

Checklista för artikel

• Sidan är genuint en artikel.
• Rubriken matchar den synliga titeln.
• Varje synlig författare är inkluderad.
• Varje författare har ett separat Person- eller Organization-objekt.
• Författarnamn innehåller endast namn, inte jobbtitlar eller utgivar-namn.
• Författaren länkar till en riktig profil- eller författarsida.
• Publicerings- och uppdateringsdatum är synliga på sidan.
• Datum använder korrekt tidszon när tid inkluderas.
• Bilden representerar artikeln.
• Utgivaren identifieras konsekvent över hela webbplatsen.
• Artikeln är inte markerad som en annan primär typ, som HowTo, såvida sidan verkligen tjänar båda syftena.

2. WebPage

Vad den gör

WebPage är en allmän sidtyp. Schema.org anger att varje webbsida implicit behandlas som en WebPage, men en explicit deklaration kan hjälpa när sidan inkluderar egenskaper eller relationer på sidnivå. (schema.org)

Användbara egenskaper inkluderar:

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

Effekt på artificiell intelligens

Bevisnivå: låg och indirekt.

WebPage används bäst som det yttre sidlagret i en ansluten graf. Den kan ansluta sidan till dess huvudsakliga artikel, definition, datamängd, person eller organisation.

Den bör inte behandlas som en speciell AI-optimeringstyp. En sida som endast innehåller ett generiskt WebPage-objekt ger vanligtvis mindre användbar information än en sida som tydligt identifierar sin huvudentitet.

Checklista för WebPage

• Använd ett stabilt @id för sidan.
• Använd den kanoniska URL:en som sidans URL.
• Identifiera sidans verkliga mainEntity.
• Länka huvudentiteten tillbaka till sidan med mainEntityOfPage.
• Lägg till inLanguage när det är känt.
• Håll sidans namn och beskrivning i linje med synligt innehåll.
• Använd inte WebPage för att dölja det faktum att sidan egentligen är en artikel, profil, datamängd eller frågesida.

3. QAPage

Vad den gör

QAPage är för en sida fokuserad på en fråga och dess svar. Google säger att de använder strukturerad data för Question från sidor markerade som QAPage, och det bör endast finnas en QAPage och en huvudsaklig Question på sidan. (developers.google.com)

Obligatoriska egenskaper

För aktuell Google-kvalificering för frågor och svar:

• QAPage.mainEntity
• En nästlad Question
• Question.answerCount
• Antingen acceptedAnswer eller suggestedAnswer
• Answer.text

En fråga utan svar är inte kvalificerad för det rika resultatet.

Viktig innehållsregel

Använd inte QAPage för:

• En vanlig sida med vanliga frågor
• Ett blogginlägg som besvarar en fråga
• En ”hur man gör”-artikel
• En produktsida som innehåller många frågor
• Ett redaktionellt svar skrivet endast av webbplatsägaren

Google säger att användare måste kunna skicka in svar för en vanlig QAPage. Giltiga exempel inkluderar en forumfråga eller en supportsida där användare kan ge svar. (developers.google.com)

Effekt på artificiell intelligens

Bevisnivå: medelhög semantisk passform, ingen bevisad kausal ökning.

En riktig frågor-och-svar-sida är naturligt lätt för ett hämtningssystem att förstå. Det finns dock ingen stark offentlig studie som bevisar att QAPage-markup i sig ökar AI-citat.

Checklista för QAPage

• Sidan fokuserar på en fråga.
• Användare kan skicka in svar, såvida sidan inte kvalificerar sig för en särskild utbildnings-frågor-och-svar-upplevelse.
• Hela frågan är synlig.
• Hela svarstexten är synlig.
• answerCount matchar det faktiska antalet svar.
• Accepterade och föreslagna svar är korrekt märkta.
• Kommentarer är märkta som kommentarer, inte svar.
• Sidan är inte bara en redaktionell sida med vanliga frågor.
• Sidan innehåller inte flera orelaterade frågor.

Exempel på QAPage

html

Använd detta mönster endast när sidan verkligen stöder en frågor-och-svar-interaktion.

4. HowTo

Vad den gör

HowTo beskriver steg-för-steg-instruktioner. Google stödde en gång How-to rika resultat, men avvecklade den sökfunktionen i september 2023. Google sade att How-to-resultat inte längre skulle visas på datorer och hade redan tagits bort från mobil sökning. (developers.google.com)

Effekt på artificiell intelligens

Bevisnivå: låg för Google.

De synliga stegen kan fortfarande hjälpa användare och hämtningssystem. En tydlig handledning med rubriker, numrerade steg, verktyg, tid och varningar är lättare att läsa och citera. Men aktuella bevis visar inte att HowTo-markup skapar en speciell fördel i Google AI-översikter eller AI-läge.

Rekommendation

Använd HowTo endast när:

• Sidan genuint lär ut en uppgift.
• Stegen är synliga i sidinnehållet.
• En annan sökmotor, plattform eller internt system drar nytta av markupen.
• Ditt team kan underhålla den utan att skapa motstridig data.

För Google Sök, prioritera starka HTML-rubriker, numrerade listor, tydliga instruktioner och användbara bilder eller video.

Checklista för handledning

• Sidan lär ut en verklig uppgift.
• Resultatet av uppgiften är tydligt.
• Varje steg är synligt och komplett.
• Stegnamn matchar de synliga rubrikerna.
• Verktyg och förnödenheter är verkliga och synliga.
• Tidsuppskattningar är korrekta.
• Säkerhetsvarningar ingår vid behov.
• Den första sektionen ger ett kort svar eller resultat.
• Sidan förlitar sig inte på markup för att ge instruktionerna.

5. ClaimReview

Vad den gör

ClaimReview utformades för faktagranskningsinnehåll. Google fasade ut stödet för Claim Review i Sök som en del av sin insats 2025 för att förenkla sökresultaten. Typen togs bort från Search Console-rapporteringen och Rich Results Test. (developers.google.com)

Effekt på artificiell intelligens

Bevisnivå: ingen aktuell Google-fördel.

En högkvalitativ faktagranskning kan fortfarande citeras eftersom den tydligt anger:

• Påståendet
• Betyget
• Bevisen
• Datumet
• Faktagranskningsorganisationen
• Resonemanget bakom slutsatsen

Dessa fördelar kommer främst från själva innehållet, inte från den avvecklade Google-sökfunktionen.

Rekommendation

För en faktasida:

1. Använd Article eller NewsArticle när sidan är redaktionell.
2. Ange tydligt påståendet i synlig text.
3. Citera primära bevis.
4. Identifiera författaren och granskande organisation.
5. Lägg till publicerings- och granskningsdatum.
6. Använd ClaimReview endast om en annan plattform eller datasystem specifikt kräver det.

Lägg inte till ClaimReview enbart för att du förväntar dig att Googles AI-svar ska föredra det.

6. FAQPage

Vad den gör

FAQPage beskriver en sida som innehåller frågor och officiella svar. Google slutade visa FAQ rika resultat i Sök från och med 7 maj 2026, och tog bort den relaterade dokumentationen i juni 2026. (developers.google.com)

Effekt på artificiell intelligens

Bevisnivå: svag och blandad.

En 90-dagars leverantörsstudie lade till FAQPage-markup på 120 sidor. Den fann ingen tillförlitlig förbättring i ChatGPT-, Gemini- eller Google AI Overview-citat. Perplexity visade en liten ökning, men studien själv sade att resultatet var plattformsspecifikt och bevisade inte kausalitet. (authorityradar.com)

En annan studie av 615 redan citerade sidor fann att FAQ-markup oftare förekom på sidor som citerades mycket. Det förhållandet försvann efter att ha kontrollerat för upprepade sidor från samma utgivare. Forskarna drog slutsatsen att bevisen inte fastställde en effekt från markupen i sig. (getintel.ai)

Rekommendation

Använd vanliga frågor när de förbättrar sidan för läsarna. Lägg inte till stora block med generiska frågor bara för att rikta in dig på AI-svar.

Om du behåller FAQPage-markup för en annan sökmotor eller innehållssystem:

• Gör varje fråga synlig.
• Gör varje svar komplett.
• Håll markupen identisk med sidan.
• Upprepa inte samma fråga i flera schema-block.
• Förvänta dig inte ett Google FAQ rikt resultat.

Exempel på FAQPage för icke-Google-konsumenter

html

Detta är en semantisk beskrivning, inte ett löfte om en Google-sökfunktion.

7. Organization

Vad den gör

Organization hjälper Google att förstå och disambiguera ett företag, en ideell organisation, en utgivare, en skola eller annan organisation. Google säger att organisationsmarkup kan påverka visuella element som logotypen som visas i Sök och viss information i kunskapspaneler. Det finns inga obligatoriska egenskaper i Googles nuvarande organisationsguide. (developers.google.com)

Rekommenderade egenskaper

Använd de egenskaper som är sanna och synliga:

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

Effekt på artificiell intelligens

Bevisnivå: indirekt men användbar.

Organization kan koppla:

• Utgivaren till en artikel
• Företaget till dess produkter eller tjänster
• Varumärket till dess officiella profiler
• Organisationen till en känd webbidentitet

Detta är användbart för entitetsdisambiguering. Det bevisar inte att ett AI-system kommer att citera sidan.

Checklista för Organization

• Placera hela organisationsobjektet på hemsidan eller organisationssidan.
• Använd ett stabilt @id, till exempel https://www.example.com/#organization.
• Använd det exakta offentliga organisationsnamnet.
• Länka till verkliga officiella profiler med sameAs.
• Använd rätt organisationstyp när det är lämpligt.
• Använd en riktig logotyp som representerar organisationen.
• Håll kontaktinformationen aktuell.
• Referera till organisationen från artiklar istället för att återskapa motstridiga versioner på varje sida.

8. Person

Vad den gör

Person identifierar en person som skriver, granskar, äger, hanterar eller förekommer på en sida. Det är oftast mest användbart när det är kopplat till:

• Article.author
• QAPage fråga eller svar författare
• ProfilePage.mainEntity
• Organization.employee
• Review.author

Googles vägledning för profilsidor säger att en profilsida måste fokusera på en person eller organisation. ProfilePage-objektet kräver en mainEntity, och den entiteten måste vara en Person eller Organization. Personen eller organisationen måste ha ett name, eller ett alternateName när inget namn finns tillgängligt. (developers.google.com)

Rekommenderade egenskaper

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

Effekt på artificiell intelligens

Bevisnivå: indirekt.

Person-markup kan hjälpa till att koppla en författares namn till:

• En biografi
• Ett jobb eller en roll
• En organisation
• Publicerade artiklar
• Externa profiler
• Expertområden

Använd det för att göra identiteten tydlig, inte för att hävda expertis som sidan inte stöder.

Checklista för Person

• Använd Person endast för en verklig person.
• Använd Organization för ett företag eller en publikation.
• Länka personen till en synlig författarsida.
• Använd sameAs endast för korrekta, officiella profiler.
• Håll jobbtitlar och meriter aktuella.
• Lägg till alla synliga författare, inte bara huvudförfattaren.
• Använd samma person @id över artiklar och profilsidor.

Matris över obligatoriska egenskaper

Googles allmänna vägledning föredrar fullständig och korrekt data framför stora mängder ofullständig markup. Den varnar också för att strukturerad data måste representera synligt innehåll och att korrekt markup fortfarande inte garanterar ett rikt resultat. (developers.google.com)

Checklistor för implementering av användningsfall

Faktasidor

Bästa kombinationen:

• WebPage
• Article eller NewsArticle
• Person
• Organization
• Valfritt ClaimReview endast för en annan stödd konsument

Checklista:

• Ange huvudfakta nära sidans topp.
• Ange källan till fakta.
• Länka till primära bevis.
• Inkludera publiceringsdatum och senaste granskningsdatum.
• Identifiera författaren och granskaren.
• Separera fakta från åsikt.
• Använd Article när sidan är redaktionell.
• Använd inte ClaimReview som en aktuell Google Sök-taktik.

Definitionsidor

Bästa kombinationen:

• WebPage
• DefinedTerm
• Valfritt Article om sidan är en lång redaktionell förklaring
• Organization eller Person när en expert eller utgivare är ansvarig

Schema.org definierar Dataset som en mängd strukturerad information och stöder relationer som includedInDataCatalog och distribution. (schema.org)

Checklista:

• Ge definitionen i första stycket.
• Använd en tydlig term som huvudentitet.
• Lägg till alternativa namn endast när de är verkliga.
• Länka till en tillförlitlig extern definition när det är lämpligt.
• Förklara termen med enkla ord.
• Använd exempel och gränser.
• Undvik att markera en lista med orelaterade termer som en DefinedTerm.

Handledningar

Bästa kombinationen:

• WebPage
• HowTo endast när en annan konsument behöver den
• Article när handledningen också är en redaktionell artikel
• Person och Organization för författarskap

Checklista:

• Ange resultatet före stegen.
• Använd numrerade synliga rubriker.
• Håll varje steg fokuserat på en åtgärd.
• Inkludera verktyg, förnödenheter, tid och varningar vid behov.
• Lägg till bilder eller video när de hjälper.
• Dölj inte stegen endast i JSON-LD.
• Förvänta dig inte How-to rika resultat i Google Sök.

Datakataloger

Bästa kombinationen:

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.org definierar Dataset som en mängd strukturerad information och stöder relationer som includedInDataCatalog och distribution. (schema.org)

Google klargjorde i slutet av 2025 att Dataset strukturerad data används av Dataset Search och inte är en allmän Google Sök-resultatfunktion. Den bör därför behandlas som ett lager för dataupptäckt och interoperabilitet, inte som en genväg för AI-citat. (developers.google.com)

Checklista:

• Ge varje datamängd en stabil identifierare.
• Ange ämnet och omfattningen.
• Inkludera utgivaren eller skaparen.
• Lägg till datumintervallet som data täcker.
• Ange geografisk täckning när det är relevant.
• Beskriv licenser och åtkomstvillkor.
• Lägg till varje nedladdningsbar fil som en DataDownload.
• Inkludera filformat och nedladdnings-URL.
• Håll katalogmetadata synkroniserad med de faktiska filerna.
• Dokumentera uppdateringsfrekvens och senaste uppdateringsdatum.

JSON-LD exempel: faktasida

Detta exempel kopplar samman sidan, artikeln, författaren, utgivaren och ämnet. Ersätt varje värde med information som visas på den verkliga sidan.

html

JSON-LD exempel: definitionsida

html

Definitionen måste också visas som vanlig sidtext. Placera inte definitionen enbart i den strukturerade datan.

JSON-LD exempel: handledning

Eftersom Googles How-to rika resultat har avvecklats, behandla detta som valfri markup för andra system. Den synliga sidan bör fortfarande innehålla de fullständiga instruktionerna.

html

JSON-LD exempel: datakatalog

html

Vanliga implementeringsmisstag

Felaktig schema-matchning

Det allvarligaste misstaget är att märka upp innehåll som användare inte kan se. Google säger att strukturerad data måste vara en sann representation av sidan, och missvisande eller dolt innehåll kan göra en sida inkompatibel för rika resultat. (developers.google.com)

Vanliga exempel:

• Att märka en artikel som en HowTo när den inte innehåller några verkliga steg
• Att märka ett företag som en författare när artikeln skrevs av en person
• Att lägga till FAQ-svar som inte visas på sidan
• Att använda ett framtida publiceringsdatum
• Att märka ett allmänt blogginlägg som QAPage
• Att lägga till ClaimReview till en opinionsartikel

Tunna svar

Strukturerad data kan inte fylla en tom sida.

Ett kort, vagt svar i Answer.text eller acceptedAnswer skapar inte en stark källa. Det synliga innehållet bör:

• Svara på frågan direkt
• Förklara viktiga begränsningar och undantag
• Ange källor
• Inkludera datum, exempel eller mätningar där det är användbart
• Stå för sig själv när det kopieras ur sitt sammanhang

Googles AI-vägledning säger att det inte finns någon ideal sidlängd och inget behov av att bryta ner innehållet i små delar för AI-system. Det bättre målet är användbart, komplett, människocentrerat innehåll. (developers.google.com)

Duplicerade entiteter

Undvik att publicera flera motstridiga versioner av samma organisation, författare eller sida.

Svag implementering:

• Ett Organization-objekt med ett namn på hemsidan
• Ett andra objekt med ett annat namn på varje artikel
• Ett tredje objekt utan @id på författarsidan

Bättre implementering:

• Ge organisationen ett stabilt @id
• Ge varje författare ett stabilt @id
• Referera till dessa objekt från artiklar, profiler och frågesidor
• Håll namn, logotyp, URL och externa identitetslänkar konsekventa

Duplicerade frågor

Upprepa inte samma fråga i:

• FAQPage
• QAPage
• Artikel-markup
• Flera synliga sidavsnitt
• Flera JSON-LD-block

Använd den schematyp som matchar sidans huvudsakliga syfte. Ett enda tydligt svar är bättre än flera överlappande markup-block.

Felaktiga datum

Google använder flera källor för att uppskatta publicerings- och uppdateringsdatum. De rekommenderar att synliga datum och strukturerade datum överensstämmer, och de varnar för att använda framtida datum eller datum relaterade till händelser som diskuteras i artikeln snarare än datum relaterade till själva sidan. (developers.google.com)

Överanvändning av sameAs

En sameAs-länk bör identifiera samma verkliga person eller organisation. Länka inte till:

• En orelaterad social profil
• En sökresultatsida
• En generisk kataloglista
• En sida med annan stavning eller identitet
• En profil som organisationen inte kontrollerar

Endast JavaScript-markup

Google kan behandla strukturerad data som lagts till den renderade sidan, men en JavaScript-only-implementering kan vara svårare för andra genomsökare och granskningsverktyg att upptäcka. Ett server-renderat JSON-LD-block är vanligtvis lättare att testa och underhålla. (developers.google.com)

En praktisk testplan

För att mäta om markup har en inkrementell effekt, använd ett kontrollerat test istället för att förlita dig på några manuella sökningar.

Före ändringen

Registrera:

• Målfrågor
• Aktuell organisk rankning
• Om ett AI-svar visas
• Vilka sidor som citeras
• Citatposition när tillgänglig
• Söktrafik
• Konverteringar
• Aktuell strukturerad data
• Innehållsändringar gjorda under testperioden

Under testet

• Lägg till en större markup-ändring i taget.
• Håll innehåll, interna länkar, titlar och externa länkar stabila.
• Använd liknande kontrollsidor som inte får ändringen.
• Registrera det exakta publiceringsdatumet för ändringen.
• Vänta tillräckligt länge för genomsökning och ombearbetning.

Ahrefs använde matchade kontroller och en före-och-efter skillnad-i-skillnader-metod. Dess tillvägagångssätt är en användbar modell för organisationer som vill testa strukturerad data istället för att anta att en korrelation bevisar kausalitet. (ahrefs.com)

Efter ändringen

Spåra:

• Google Search Console prestandadata för AI
• Google AI Overview-citat
• Google AI-läge-citat
• Bing Webmaster Tools AI-citat
• ChatGPT, Gemini eller Perplexity citat när relevant
• Organiska rankningar
• Sökklick
• Assisterade konverteringar

Google rapporterar AI-söktrafik via Search Console prestandarapportering. Bings AI-prestandarapportering visar citerade sidor och förankringsfrågor, men den visar inte varför en sida valdes eller hur viktig den var i ett svar. (developers.google.com)

Rekommenderad implementeringsordning

För de flesta utgivare är den bästa ordningen:

1. Fixa synligt innehåll först.
2. Se till att genomsökning och indexering är tillförlitlig.
3. Implementera Article för riktiga redaktionella sidor.
4. Koppla författare med Person och profilsidor.
5. Koppla utgivare med Organization.
6. Använd WebPage som ett rent sidnivå-diagramlager.
7. Använd QAPage endast för genuina samhällsfrågor.
8. Använd DefinedTerm för ordlistor och definitionsidor.
9. Använd Dataset och DataCatalog för datakällor.
10. Behandla FAQPage, HowTo och ClaimReview som sekundär eller icke-Google-markup eftersom deras Google-sökfunktioner har tagits bort eller avvecklats.

Slutsats

Den starkaste nuvarande lärdomen är enkel: Schema.org-markup hjälper maskiner att förstå innehåll, men det är ingen garanterad väg in i AI-svar.

Den mest hållbara implementeringen är inte en stor samling schematyper. Det är en liten, korrekt entitetsgraf:

• Article beskriver den redaktionella sidan.
• Person identifierar författaren.
• Organization identifierar utgivaren.
• WebPage kopplar sidan till dess huvudentitet.
• QAPage beskriver en genuin användarfråga och dess svar.
• DefinedTerm förtydligar en definition.
• Dataset och DataCatalog beskriver strukturerade dataresurser.

Använd strukturerad data där den ger tydlig mening. Använd den inte för att dölja tunt innehåll, duplicera synlig text eller imitera en sökfunktion som Google inte längre stöder. För AI-visning förblir det mest värdefulla arbetet tydliga svar, starka bevis, korrekta entiteter, aktuell information och innehåll som kan stå på egna ben.