Schema markup: typer, JSON-LD och validering

Välj en typ som passar sidans huvudsakliga innehåll. En tjänst kan beskrivas som Service, en artikel som Article eller BlogPosting och en brödsmulesti som BreadcrumbList.

Google kräver att relevant markering motsvarar synligt innehåll och inte vilseleder. Läs riktlinjerna för strukturerad data.

Hur skiljer ni sidans typ från det som sidan beskriver?

Webbsidan, dess huvudämne och dess avsändare kan vara olika objekt. En artikel är ett innehållsobjekt, en tjänst är ett erbjudande och organisationen är dess leverantör. Välj inte samma huvudtyp för alla sidor bara för att de använder samma design.

Typvalet beskriver innehållet. För en särskild sökfunktion behöver ni dessutom läsa Googles dokumentation om stödda resultattyper. Att Schema.org har en typ innebär inte automatiskt att Google erbjuder ett eget utökat resultat för den.

Ska alla egenskaper i Schema.org fyllas i?

Nej. Fyll i relevanta och bekräftade uppgifter; följ sedan kraven för den Google-funktion ni faktiskt riktar er mot. Obligatoriska och rekommenderade egenskaper skiljer sig mellan funktionerna. Ett obligatoriskt fält som saknas kan göra ett objekt obehörigt för just det resultatet. En verklig men okänd uppgift blir inte sann av att ett testverktyg efterfrågar den. Läs Googles riktlinjer om innehåll och fullständighet.

Återanvänd stabila identifierare och samma bekräftade företagsnamn, adress och kontaktuppgifter. I JSON-LD anger @id vilket objekt en beskrivning gäller. Samma företag ska därför behålla samma identifierare när andra sidor hänvisar till det. En referens med företagets @id pekar på samma objekt i stället för att beskriva en ny leverantör. Företaget, tjänsten och webbsidan är olika objekt och kan ha var sin identifierare. W3C:s specifikation för JSON-LD förklarar identifierare och objektreferenser.

Hitta inte på grundandedatum, kundbetyg, kontor eller författare för att fylla valfria fält. Markera pris endast när omfattning och villkor stämmer med sidans erbjudande.

Vad händer om flera mallar beskriver samma företag?

Flera beskrivningar behöver peka på samma identitet och ge förenliga uppgifter. Granska vilka mallar, tillägg och datakällor som skriver JSON-LD. Ett gammalt företagsnamn från ett tillägg kan annars finnas kvar samtidigt som sidans nya kod beskriver rätt namn. Antalet scriptblock är inte i sig felet; konflikten mellan uppgifterna är det som behöver lösas.

Praktisk kontroll: sök efter företagets namn och identifierare i sidans samtliga JSON-LD-block. Jämför namn, URL och kontaktuppgifter med den synliga informationen. Utse sedan den bekräftade datakällan för varje uppgift. Gör inte alla objekt identiska: företagets identifierare ska fortfarande skiljas från artikelns eller tjänstens.

En tjänstesida kan koppla ett Service-objekt till byråns Organization och den aktuella WebPage. Namn och beskrivning ska hämtas från den synliga sidan. Detta beskriver tjänsten; det innebär inte att Google erbjuder ett särskilt sökresultat för varje Service-objekt.

Schema.org beskriver typen Service och dess egenskaper.

Hur ser ett minimalt JSON-LD-exempel ut?

Ett avgränsat JSON-LD-exempel kan ge tjänsten en identifierare och koppla den till leverantören och webbsidan. Illustrativ synlig text: ”Exempelföretaget erbjuder webbplatsunderhåll med avtalade innehållsuppdateringar.” I exemplet finns texten på example.com/underhall. Objekten kan beskrivas så här: {"@context": "https://schema.org", "@graph": [{"@type": "Organization", "@id": "https://example.com/id/company", "name": "Exempelföretaget"}, {"@type": "WebPage", "@id": "https://example.com/underhall", "name": "Webbplatsunderhåll"}, {"@type": "Service", "@id": "https://example.com/id/maintenance", "name": "Webbplatsunderhåll", "description": "Avtalade innehållsuppdateringar", "provider": {"@id": "https://example.com/id/company"}, "mainEntityOfPage": {"@id": "https://example.com/underhall"}}]}. provider hänvisar till företagets @id, medan mainEntityOfPage hänvisar till webbsidans. Samma identifierare återkommer i objektet och referensen. Exemplet visar dessa kopplingar, inte en fullständig implementation eller ett löfte om utökade sökresultat.

Kodexemplet beskriver inte en faktisk SOVRA Digital-produkt och ska inte publiceras som webbplatsens egen tjänstemarkering. I ett verkligt projekt tillkommer bara uppgifter som är bekräftade för tjänsten. Ett pris, ett betyg eller en leverantör får inte fyllas i genom att kopiera värden från ett exempel.

Hur läser ni kopplingarna i kodexemplet?

Organisationen beskriver vem som levererar, tjänsten vad som erbjuds och webbsidan var erbjudandet förklaras. I exemplet innehåller grafen tre separata objekt. Tjänstens provider refererar till företagets identifierare och mainEntityOfPage till sidans identifierare. Ändras företagets namn uppdateras dess egen beskrivning; tjänstens referens ska fortfarande peka på samma verkliga leverantör.

Pröva exemplet som text först: går det att hitta varje påstående på sidan? Finns det verkligen en namngiven leverantör och den beskrivna tjänsten? Om svaret är nej behöver underlaget rättas innan kodexemplet anpassas. Den kontrollen förhindrar att korrekt syntax används för felaktigt innehåll.

Var placeras JSON-LD på sidan?

JSON-LD kan ligga i ett scriptblock med typen application/ld+json i sidans head eller body. Det är strukturerad information för maskiner, inte den synliga artikeltexten. Google beskriver formatet i sin introduktion till strukturerad data. Ett kodexempel som bara visas i en artikel är inte automatiskt aktiv markering för sidans verksamhet.

Låt en gemensam datakälla försörja både synlig fakta och relevant markering när implementationen tillåter det. Kontrollera sedan den levererade sidan: att administratören har fyllt i ett fält bevisar inte att rätt kod faktiskt följer med till besökaren eller sökmotorn.

Kontrollera syntaxen, uppgifternas betydelse och den markering som faktiskt finns på den publicerade sidan. Följ dessa kontroller innan resultatet bedöms som färdigt:

1. Att JSON-LD går att läsa utan syntaxfel.
2. Att typer och egenskaper används rimligt.
3. Att uppgifterna är sanna och finns på sidan.
4. Att referenser och adresser pekar rätt.
5. Att den publicerade sidan innehåller rätt markering utan dubblerade konflikter.

Ett godkänt verktygstest garanterar inte att Google visar ett utökat resultat. FAQ, HowTo och betyg är inte ett paket som ska läggas på alla sidor.

Vad skiljer Schema Markup Validator från Rich Results Test?

Schema Markup Validator kontrollerar Schema.org-markering generellt, medan Rich Results Test granskar stöd för Googles utökade sökresultat. Ett godkänt schema-test betyder därför inte att en viss Google-funktion stöds eller kommer att visas. Google förklarar skillnaden mellan testverktygen.

Vad måste kontrolleras på den publicerade sidan?

Kontrollera att den publicerade URL:en innehåller rätt JSON-LD, att objekten beskriver samma företag och att värdena motsvarar den synliga texten. Googles introduktion till strukturerad data förklarar stöd, format och testning. Testverktyg ersätter inte kontrollen av att fakta är riktiga.

När sidans text och markering ger olika uppgifter behöver felet spåras till rätt mall eller datakälla. SOVRA Digitals tekniska SEO-arbete kan omfatta en sådan granskning av webbplatsens implementation.

I vilken ordning bör testen göras?

Testa först det avgränsade kodunderlaget, sedan den faktiska URL:en och till sist innehållets överensstämmelse. Då skiljer ni ett skrivfel i JSON från ett fel i sidmallen eller i företagets uppgifter.

1. Kontrollera kodens syntax och rätta fel som hindrar tolkning.
2. Granska typer, egenskaper och identifierare i Schema Markup Validator.
3. Om en Google-funktion är relevant, använd Rich Results Test och följ den funktionens krav.
4. Testa den publicerade adressen, inklusive rätt språkversion, och jämför resultatet med den tänkta koden.
5. Läs motsvarande rubrik, namn, bild och fakta på sidan. Dokumentera eventuella skillnader och vem som rättar dem.
6. Upprepa berörda kontroller när text, mall eller företagsuppgifter ändras.

En användbar rapport anger URL, datum, testverktyg, det fel som hittades och vilken uppgift som ska ändras. ”Godkänd schema” räcker inte som slutsats om faktakontrollen återstår. Ett korrekt Article-objekt kan exempelvis fortfarande innehålla fel författarnamn om underlaget var fel från början.