2026-01-14 · Redaktionen Baduno · 6 blog.readMin · Blog & Kunskap
Strukturerad data: Schema.org förklarat på ett begripligt sätt
Maskinläsbara tilläggsinformationer gör sökträffar till rika resultat med betyg, FAQ och företagsdata. Så fungerar det.
Vad strukturerad data är
Osynliga JSON-block i källkoden beskriver vad som står på sidan: Det är ett företag med denna adress, det är en artikel med detta datum, det är en FAQ med dessa frågor. Sökmotorer behöver inte gissa – de läser.
Vad det ger
Berättigande till utökade visningar (FAQ-utdrag, breadcrumbs, organisationspanel), bättre förståelse av samband och renare kunskapsgrafinlägg. Ingen ranking-turbo – men mer yta och förtroende i sökresultatet.
De viktigaste typerna för företag
Organization med registerdata, WebSite, Service eller Product med Offer, Article för fackartiklar, FAQPage och BreadcrumbList. Flerspråkigt gäller: Varje språkversion bär sin egen, översatta märkning.
Glöm inte att validera
Rich-Results-testet visar vad Google läser, Schema-Validator kontrollerar syntaxen. Felaktig märkning är värre än ingen – den kostar förtroende och i värsta fall den utökade visningen.
Strukturerad data och hreflang: Perfekt samspel för flerspråkiga sidor
En vanlig felkälla på flerspråkiga webbplatser är inkonsekvent användning av strukturerad data och hreflang-taggar. Medan hreflang signalerar språk- och regionalternativ för en sida till sökmotorerna, avslöjar strukturerad data innehållstypen. Båda är oberoende av varandra men kompletterar varandra: En tysk produktsida bör både ha en hreflang-tagg som pekar på den engelska varianten och i det strukturerade datablocket markera samma produkt-ID med olika erbjudanden och språk. Viktigt: Varje språkversion får sitt eget JSON-LD-block med lämpliga värden – annars uppstår motsägelser. Googles Rich-Result-test visar ofta fel om till exempel organisationen i den tyska versionen innehåller en engelsk adress. Kontrollera därför efter varje språklansering båda markeringarna parallellt.
Underhåll och uppdatering: Vem sköter datan?
Strukturerad data är inget engångsprojekt. Om priser, öppettider eller produktdetaljer ändras måste JSON-LD-blocken uppdateras. Helst ska innehållshanteringssystemet sköta den dynamiska ifyllningen. Om denna automatisering saknas, behövs en tydlig ansvarig i teamet – exempelvis redaktören för artikel- och FAQ-data, utvecklaren för organisationsdata. Undvik datasilor: Ett föråldrat telefonnummer i Organization-blocket skadar förtroendet. Planera kvartalsvisa granskningar av all strukturerad data, åtminstone före varje större omstart. Ett centralt dashboard som visar alla märkta sidor och deras valideringsstatus är till hjälp.
AI-stödd skapande och granskning av strukturerad data
Moderna AI-verktyg kan automatiskt generera JSON-LD från ostrukturerad text – till exempel för FAQ-sidor eller artiklar. Det påskyndar arbetet men innebär risker: AI missar ofta kontextuella nyanser (t.ex. felaktigt pris eller föråldrat datum). Därför är modersmålsgranskning av en redaktör oumbärlig. Använd AI för utkastet, låt sedan en människa validera värdena. Även på flerspråkiga sidor hjälper AI med översättningar av strukturerad data, men hreflang-taggar och språkspecifika ID:n måste ställas in manuellt. En beprövad metod: AI skapar den engelska standardblocket, en lokal redaktör korrigerar och kompletterar de landsspecifika fälten.
Maskinläsbara tilläggsinformationer gör sökträffar till rika resultat med betyg, FAQ och företagsdata. Så fungerar det.
Markera dynamiskt innehåll: FAQ, recensioner och produkter
Särskilt vanligt förekommer fel vid dynamiskt innehåll. FAQ-sidor bör ha en egen JSON-LD-post per fråga – inte hela listan som ett enda Question-objekt. Vid recensioner måste betygsskalan anges korrekt (t.ex. bestRating och worstRating). Produktsidor med varianter kräver AggregateOffer-block med all pris- och tillgänglighetsinformation. Använd mallar i CMS som automatiskt genererar korrekta typer. Testa varje dynamisk sida separat i Rich-Results-testet, eftersom fel först blir synliga vid specifika värden. Ett vanligt fel: användning av 'Review' istället för 'AggregateRating' för genomsnittsbetyg.
Kombination av flera Schema.org-typer på en sida
På en enskild sida kan du markera flera Schema.org-typer parallellt, förutsatt att de beskriver olika aspekter av innehållet. En produktsida kan samtidigt innehålla ett Product-block (med pris, tillgänglighet), ett Organization-block (för tillverkaren) och ett Review-block (för recensioner). Det är viktigt att varje typ står i ett eget JSON-LD-skript eller länkas samman konsekvent via @id. Exempel: Product-blocket refererar med "brand": {"@id": "#organisation"} till Organization-blocket. Undvik motstridiga uppgifter – till exempel olika adresser i Organization- och LocalBusiness-blocken. Varje typ måste vara korrekt och språkspecifik: en fransk sida får franska värden i alla block. Använd CMS för att hantera typer modulärt, så att du inte måste justera varje block manuellt. Kontrollera i Rich-Results-testet om alla block accepteras – vissa tester visar bara det första blocket. En ren kombination av flera typer ökar chanserna till rika resultat som karusell, produktboxar eller organisationspanel.
Arbeta med @id och referenser för sammanlänkade data
Schema.org tillåter att objekt refereras via @id och på så sätt undvika redundanta data. Istället för att upprepa hela organisationen på varje sida, definiera ett centralt Organization-block med en unik @id (t.ex. "https://beispiel.de/#firma") och referera till det i andra block via "@id": "https://beispiel.de/#firma". Detta är särskilt användbart för flerspråkiga webbplatser: organisationen förblir densamma, bara de språkspecifika fälten som 'name' eller 'description' skiljer sig. Se till att @id är konsekvent över alla språkversioner – alltså samma URI för svenska, engelska osv. Referenser kan även användas för artikel-författare, produktmärken eller recensionsobjekt. Validera med Schema-validatorn att alla @id-referenser är lösbara. Ett fel: om den refererade @id inte är definierad i samma sidkällkod eller på en annan sida, bryts valideringen. Lagra därför centrala entiteter antingen i en global fil (t.ex. organisation.json) och bädda in den via JavaScript, eller använd CMS för dynamisk inbäddning. En ren @id-struktur underlättar för sökmotorer att koppla samman information och förbättrar konsistensen i Knowledge Graph.
BreadcrumbList korrekt märka ut: Tips och fallgropar
Att märka ut BreadcrumbList kan verka enkelt, men i praktiken uppstår ofta fel som äventyrar framgången med rich snippets. En korrekt implementering börjar med förståelse av hierarkin: Varje post i listan kräver ett ItemListElement-objekt, som i sin tur innehåller ett ListItem-objekt. Avgörande är position-egenskapen: Den numrerar elementen stigande, med start på 1 för startsidan. Undvik att utelämna startsidan – även om den inte syns i brödsmulans synliga del ska den finnas med i de strukturerade data. Ett vanligt misstag är att använda absoluta webbadresser utan hänsyn till språkversion: Se till att webbadressen i brödsmulan pekar på rätt språkvariant, t.ex. /de/produkte istället för /en/products. Namngivningen av elementen måste också vara språkspecifik – 'Startsida' på svenska, 'Home' på engelska. Använd name-fältet för den visade texten och undvik förkortningar som sökmotorer kan missförstå. Efter implementeringen, testa varje sökväg med Rich Results Test, eftersom dynamiskt genererade brödsmulor lätt kan få fel ordning eller dubbla poster. Observera också att Google visar maximalt tio element – en kortare, precis navigation är att föredra framför en alltför lång.
Nästlade objekt och referenser: @id och @context
Komplexa strukturerade data använder ofta kopplingen av flera typer via @id-referenser. Ett typiskt exempel är en produktsida som innehåller både ett Offer och en Review. Istället för att packa all data i ett monolitiskt block är det renare att definiera separata block med unika @id-värden och sedan referera till dem. @id-värdet måste vara unikt inom sidan och hela domänen – helst använder man objektets absoluta webbadress med ett fragment som #product-1. Undvik generiska ID som #produkt, eftersom de kan leda till konflikter på flera sidor. En annan viktig aspekt är @context: Som standard används Schema.org-vokabuläret, men för egenutvecklade tillägg kan en egen kontext anges. Se till att validerade tillägg som health-lifesci eller bib inte av misstag hamnar på kommersiella sidor. På flerspråkiga sidor måste @id-referenser vara språkspecifika: Den tyska produktsidan refererar till det tyska Offer-ID, inte det engelska. En användbar teknik är att använda @reverse för inversa relationer, till exempel när en produkt hänvisar till en organisation, men organisationen inte har en direkt lista över alla produkter. Testa sådana kedjningar i Schema-validatorn, eftersom en enda felaktig kolon kan leda till ett valideringsfel. Avsätt tillräckligt med tid för felsökning av refererade objekt – de är en vanlig felkälla i omfattande implementeringar.
blog.faqT
Kan jag lägga till strukturerad data i efterhand på gamla sidor?
Ja, strukturerad data kan läggas till när som helst. Se till att all information är aktuell. Använd Googles Rich-Results-test för att kontrollera korrekt implementering. För många sidor rekommenderas ett stegvist tillvägagångssätt per innehållstyp.
Hur ofta bör strukturerad data uppdateras?
Alltid när den underliggande informationen ändras (priser, öppettider, produktdetaljer). Planera in en kvartalsvis helhetskontroll. Dynamiska system kan fylla i data automatiskt – vilket minskar uppdateringsarbete och felkällor.
