Strukturerad data: beskriv det som faktiskt finns

Vad strukturerad data faktiskt är – och vad det inte är

Strukturerad data är ett sätt att beskriva ett innehåll i ett format som datorer kan tolka entydigt. I praktiken innebär det att du lägger till ett JSON-LD-block på en sida där du med Schema.org-vokabulär talar om vad sidan representerar: en artikel, en organisation, en produkt, ett evenemang eller något annat konkret. Markeringen är riktad till system som behöver förstå innebörden av ett innehåll utan att analysera löpande text.

Kontrollera syntax och datamodell mot W3C:s JSON-LD-specifikation. En giltig serialisering och en sakligt korrekt beskrivning är två olika kontroller; ett syntaxtest bevisar inte att uppgifterna är sanna.

Det är viktigt att skilja på vad strukturerad data är och vad den inte gör. Som Schema.org dokumenterar är Article ett sätt att beskriva en artikel och dess egenskaper – markeringen är inte en synlighetsgaranti. Den semantiska beskrivningen är en signal, inte ett löfte om ett visst utseende i sökresultaten. En implementering som är korrekt gjord ökar precisionen i hur en sida kan förstås maskinellt, men den ersätter inte välskrivet, relevant och tekniskt tillgängligt innehåll. Det finns inget garanterat samband mellan korrekt markup och förbättrad synlighet eller klickfrekvens.

En vanlig missuppfattning är att strukturerad data fungerar som en snabb genväg till förbättrade resultat. I verkligheten är markup utan synlig förankring i sidinnehållet ett problem, inte en fördel. Om ditt JSON-LD-block hävdar att sidan innehåller fem kundrecensioner, men sidan inte visar ett enda omdöme för besökaren, är markeringen felaktig oavsett hur välformaterad JSON-strukturen är.

Artikeln här handlar om hur du gör implementeringen rätt från grunden: väljer rätt entitetstyp, skriver giltig JSON-LD med korrekt referensstruktur, kontrollerar synlig överensstämmelse och underhåller markeringen över tid. Det kräver disciplin men är ett hanterbart tekniskt arbete.

Tre sidtyper, tre olika semantiska behov

En av de mest praktiska insikterna när man arbetar med strukturerad data på en B2B-webbplats är att en artikel, en tjänstesida och en produktsida har fundamentalt olika semantiska behov. De ska aldrig behandlas med samma mall.

En artikelsida – till exempel en guide eller ett blogginlägg – har vanligtvis en tydlig publiceringstidpunkt, ett eller flera författarnamn och en väldefinierad rubrik. Dessa egenskaper passar Schema.org-typen Article eller dess undertyp TechArticle. Det finns obligatoriska egenskaper som headline, author och datePublished. Om sidan inte visar ett pubdatum synligt för besökaren bör du inte inkludera datePublished i markeringen bara för att CMSet har ett internt datum lagrat.

En tjänstesida beskriver vad ett företag erbjuder. Här är Service en lämplig typ, med egenskaper som name, description och provider. Tjänstesidor har sällan ett pris i löpande text – och om de saknar ett konkret erbjudande med villkor finns det heller inget underlag för att använda Offer. Att fabricera ett Offer-block för att det kan ge ett prisutseende i sökresultaten är ett exempel på felaktig markup.

En produktsida i ett e-handelssystem har däremot ofta ett konkret pris, ett SKU-nummer, tillgänglighetsstatus och möjligen genuina kundrecensioner. Här är Product rätt typ och Offer är inte bara tillåtet utan nödvändigt om du vill att produkten ska kunna identifieras korrekt. Nyckeln är att varje egenskap du inkluderar måste ha ett synligt motstycke på sidan.

Den praktiska konsekvensen är att du behöver separata JSON-LD-mallar för varje sidtyp i din webbplats – inte en universalmall som kopieras och modifieras slumpmässigt. Om du underhåller strukturerad data som en del av ett CMS-template-system är det värt att titta på hur ramverk som Astro hanterar server-side rendering av metadata, vilket påverkar om ditt JSON-LD-block faktiskt når crawlern.

JSON-LD i praktiken: ett genomarbetat exempelblock

Nedan följer ett illustrativt exempel på ett JSON-LD-block för en hypotetisk artikelsida på en B2B-webbplats. Antag att sidan är en guide om teknisk SEO, publicerad den 15 september 2026, med en namngiven redaktör och en tydlig rubrik synlig i H1. Alla egenskaper i blocket nedan har ett synligt motstycke i det antagna sidinnehållet.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://rangel.se/guider/teknisk-seo-guide/#artikel",
  "headline": "Teknisk SEO: prioritera det som blockerar indexering",
  "datePublished": "2026-09-15",
  "dateModified": "2026-10-01",
  "author": {
    "@type": "Person",
    "name": "Anna Lindqvist",
    "url": "https://rangel.se/om/anna-lindqvist/"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://rangel.se/#organisation",
    "name": "RANGEL",
    "url": "https://rangel.se"
  },
  "inLanguage": "sv",
  "isPartOf": {
    "@type": "WebSite",
    "@id": "https://rangel.se/#webbplats",
    "url": "https://rangel.se"
  }
}
</script>

Lägg märke till användningen av @id med fragmentidentifierare (#artikel, #organisation). Det är ett mönster för att skapa stabila entitetsreferenser som kan återanvändas och länkas ihop mellan sidor. Organization-entiteten med @id värdet https://rangel.se/#organisation kan definieras fullständigt på startsidan och sedan refereras med bara "@id"-nyckeln på alla undersidor – utan att duplicera hela blocket.

Vad blocket ovan inte innehåller är lika viktigt: inga omdömen, ingen FAQ, inget pris. Det beror på att de saknas i det antagna sidinnehållet. Om artikelsidan senare byggs ut med faktiska kundcitat som namnges med person och datum kan en comment-egenskap läggas till – men inte förrän innehållet faktiskt finns.

Organisation och breadcrumb: de mest underskattade blocken

I arbetet med strukturerad data på B2B-webbplatser är det vanligaste fallet att fokus läggs på innehållssidor medan två fundamentala block negligeras: Organization och BreadcrumbList.

Organization-blocket är basen för hur din webbplats identifierar sig som en sammanhängande juridisk entitet. Det placeras lämpligast på startsidan och innehåller namn, URL, kontaktuppgifter och eventuell sameAs-koppling till externa profiler som LinkedIn. Nyckeln är att @id-värdet är identiskt med det som refereras i publisher-egenskapen på varje artikelsida. Saknas denna konsekvens skapas separata, orelaterade entiteter i stället för en sammanhängande graf.

BreadcrumbList beskriver navigationshierarkin till den aktuella sidan. Det är semantiskt användbart på alla sidor som befinner sig djupare än startsidan i hierarkin. Varje steg i brödsmulestigen representeras av ett ListItem-objekt med ett positionsnummer, en läsbar benämning och en URL. Strukturen ska spegla den faktiska navigationsstrukturen på sidan – inte en påhittad hierarki. Om din webbplats faktiskt inte visar en brödsmulsstig för besökaren bör du fundera på om markeringen är motiverad, eftersom den idealt ska motsvara synlig navigation. Hur du bygger den navigeringsstrukturen hänger tätt samman med hur du planerar interna länkar genom webbplatsen.

Ett vanligt fel på B2B-sajter med platta URL-strukturer är att BreadcrumbList konstrueras med tre nivåer trots att navigationen faktiskt bara har två. Det ger en missmatchning som är lätt att missa om man aldrig jämför JSON-LD-blocket med vad sidan visar visuellt.

RANGELs beslutsramverk: välj rätt entitetstyp och undvik vanliga fabriceringsmisstag

Det är enkelt att hamna i ett mönster där man kopierar en JSON-LD-mall, byter ut rubrik och URL och betraktar implementeringen som klar. Problemet är att mallen ofta är utformad för en annan sidtyp, med egenskaper som inte existerar på den aktuella sidan. Det leder till fabricerade egenskaper – ett av de vanligaste och mest skadliga felen i implementeringen.

RANGELs arbetsmetod för att undvika detta bygger på tre frågor som ställs till varje sidtyp innan markup skrivs:

1. Vad är sidans primära entitet? Är det ett innehåll med datum och upphovsperson (Article), ett erbjudande med pris och tillgänglighet (Product/Offer), eller en beskrivning av en verksamhets tjänst utan transaktionselement (Service)?
2. Vilka egenskaper finns synliga för besökaren? Gå igenom Schema.org-typens egenskaper och kryssa av enbart dem som har ett verifierbart, synligt innehåll på sidan.
3. Finns det @id-konsekvens med resten av webbplatsen? Återanvänds Organization- och WebSite-entiteterna med identiska @id-värden på alla sidor?

Resultatet av dessa tre frågor avgör vilket JSON-LD-block som skrivs. I beslutstabellen nedan sammanfattas de vanligaste sidtyperna med rekommenderad entitet, kritiska egenskaper och de vanligaste fabriceringsmistagen för varje typ.

Illustrativt typfall: en hypotetisk B2B-sajt med blandade sidtyper

Antag att ett hypotetiskt konsultföretag – vi kallar det Merkurio AB – driver en webbplats med fyra olika sidtyper: en startsida med företagsbeskrivning, tre tjänstesidor utan prislista, en blogg med löpande artiklar och en kontaktsida. Merkurio har tidigare använt ett SEO-plugin som genererat likadana JSON-LD-block för alla sidor baserat på en generisk Article-mall.

När Merkurio inventerar sin markup med RANGELs tre frågor framkommer följande problem. Tjänstesidorna har Article-markup med en datePublished som är satt till det datum pluginet installerades – inte ett publiceringsdatum för ett redaktionellt innehåll. Startsidan har ett Organization-block med ett @id-värde som skiljer sig från det Organization-block som bloggartiklarna refererar i sin publisher-egenskap. Bloggartiklarna har dessutom ett aggregateRating-block med ett påhittat snittbetyg, trots att Merkurios webbplats inte visar ett enda kundomdöme.

Åtgärdsplanen för Merkurio blir följande: tjänstesidorna byter till Service-typ och Organization-referens tas bort från Article-mallen. Startsidan får ett nytt, kanoniskt @id-värde som används konsekvent på alla sidor. aggregateRating-blocket tas bort från alla sidor tills verkliga kundomdömen finns publicerade och synliga. Bloggartiklarna valideras mot Schema.org Article och kompletteras med dateModified för sidor som uppdaterats sedan publicering.

Merkurio är ett illustrativt och hypotetiskt exempel. Siffrorna och problemen är konstruerade för att visa en realistisk felsituation, inte ett verkligt kundärende. Det är ändå ett mönster som är vanligt förekommande i verkligheten hos webbplatser som byggt sin markup från plugin-standardinställningar utan manuell granskning.

Versionerad QA och underhåll av strukturerad data

Strukturerad data är inte ett projekt man avslutar – det är ett underhållsansvar. Varje gång en sidmall förändras, ett CMS-fält byter namn eller ett nytt innehållsformat introduceras riskerar JSON-LD-blocken att bli felaktiga. En versionerad QA-process skyddar mot dessa typer av regression.

Den enklaste versionen av en QA-process ser ut så här: JSON-LD-mallen för varje sidtyp finns lagrad i versionskontroll med en kommentar om vilket innehåll den förutsätter. Vid varje release-cykel körs en automatiserad kontroll som hämtar sidans HTML-svar och extraherar JSON-LD-blocket för validering mot Schema.org:s strukturerade testverktyg. Dessutom görs en manuell visuell kontroll av minst en sida per sidtyp, där varje egenskap i JSON-LD-blocket konfirmeras mot synligt sidinnehåll.

Vid ett domänbyte är JSON-LD-hanteringen ett av de moment som oftast glöms bort. Om du byter från gammaldoman.se till nydoman.se måste du inte bara hantera canonical-taggar och indexeringskontroll korrekt – du måste också uppdatera varje @id-värde i hela JSON-LD-systemet. Ett @id som pekar på en gammal domän skapar en entitetsidentitet som inte matchar den aktuella URL-strukturen. Det är ett problem som uppstår tyst och kan vara svårt att spåra i efterhand.

För att hålla QA-arbetet hanterbart kan du använda ett strukturerat schema för vilka kontroller som görs i vilken ordning. Som startpunkt är RANGELs SEO-checklista ett praktiskt underlag för att strukturera vad som behöver kontrolleras tekniskt inför en lansering eller omstrukturering.

Strukturerad data: beskriv det som faktiskt finns
https://rangel.se/guider/strukturerad-data/

LÄSARUPPGIFT
Granska en sida på din sajt: kontrollera att varje strukturerad data-egenskap motsvarar synligt innehåll och ta bort det som saknar synlig motsvarighet.

Kontrollera metadata mot synligt innehåll
[ ] Välj rätt typ
Underlag att dokumentera: Motivera typen utifrån det faktiska innehållet på sidan.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Jämför varje uppgift
Underlag att dokumentera: Kontrollera namn, datum, erbjudanden och FAQ mot synlig text.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Kontrollera sidkällan
Underlag att dokumentera: Spara JSON-LD och det parserresultat som verifierar syntaxen.
Mitt underlag:
Ansvarig / nästa steg:

Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.

Tre beslutssituationer som ger väsentligt olika utfall

I arbetet med strukturerad data finns det tre återkommande beslutssituationer där valet av riktning ger väsensskilda konsekvenser. Det är inte situationer med ett uppenbart rätt svar – de kräver att du analyserar din specifika webbplats och ditt innehålls faktiska egenskaper.

Situation 1: Tjänstesida med prisuppgift eller utan. Om din tjänstesida faktiskt anger ett fast eller ett ungefärligt pris i synligt text är det motiverat att inkludera ett Offer-block i din Service-markup. Om sidan hänvisar besökaren till att kontakta er för prisuppgift – ett vanligt B2B-mönster – saknas underlaget för Offer. Att ändå lägga till ett Offer med ett påhittat pris är ett tydligt fabriceringsfel. Beslutet är binärt: synligt pris på sidan ger Offer-block, annars inte.

Situation 2: Artikel med eller utan namngivet upphovsperson. Om ditt CMS lagrar ett internt redaktörskonto men aldrig visar ett namn synligt på sidan saknas underlaget för en specifik Person-entitet i author-egenskapen. Du kan i stället använda Organization som author om innehållet är redaktionellt producerat av företaget som helhet. Om du däremot publicerar bylines synligt är det korrekt och värdefullt att inkludera Person-entiteten med namn och eventuell profilsida.

Situation 3: Flerspråkig webbplats med länderspecifika entiteter. Om du driver en webbplats med separata URL-strukturer per språk eller marknad – till exempel /sv/ och /en/ – behöver varje språkversion ha sina egna @id-värden för Organization och WebSite. Delar de samma @id uppstår entitetskollisioner. Om de hanteras korrekt med separata @id och en konsekvent inLanguage-egenskap på artikel-blocken ger det en tydligare semantisk separation. Det hänger samman med hur canonical-strukturen är upplagd för de olika språkversionerna.

Diagnos: identifiera och åtgärda de vanligaste felen

De vanligaste felen i implementerad strukturerad data kan delas in i tre kategorier: fabricerade egenskaper, inkonsekvent @id-referensstruktur och typfel. Varje kategori har specifika diagnostiska tecken.

Fabricerade egenskaper identifieras genom att gå igenom varje egenskap i JSON-LD-blocket och söka efter dess innehåll på den synliga sidan. Om du inte hittar ett synligt motstycke är egenskapen fabricerad. Vanliga fall: aggregateRating utan omdömen, FAQ-block utan synliga svar, datePublished utan synligt datum. Åtgärd: ta bort egenskapen omedelbart.

Inkonsekvent @id identifieras genom att söka i kodbasen efter alla förekomster av Organization-entitetens @id. Finns det mer än ett unikt värde finns en inkonsistens. Åtgärd: bestäm ett kanoniskt @id-värde för Organization och ersätt alla avvikande värden.

Typfel – att använda fel Schema.org-typ för en sida – identifieras genom att jämföra sidans faktiska innehåll mot vad Schema.org-typen är avsedd att beskriva. En tjänstesida med Article-markup är ett typfel. En FAQ-sida med Service-markup är ett typfel. Åtgärd: skriv om blocket med rätt typ och behåll enbart egenskaper som är relevanta för den typen.

För en snabb inventering av en hel webbplats kan du använda ett crawlingverktyg som extraherar JSON-LD-blocken per URL och kategoriserar dem efter typ. Det ger en snabb överblick av hur konsekvent markup-strukturen är. Om du vill arbeta mer strukturerat med hur SEO-arbetet motiveras mot affärsmål kan verktyget SEO-affärscase hjälpa dig att rama in prioriteringar på dina egna indata. För att få ett lokalt formatförslag kopplat till sidtyp kan innehållsformat-verktyget ge en startpunkt.

Det är också värt att notera att HTTP-svarskoder påverkar om strukturerad data ens är relevant. En sida som returnerar 301 och omdirigerar besökaren bör inte ha ett JSON-LD-block på den ursprungliga adressen – markeringen hör hemma på den kanoniska destinationssidan. Det är ett grundläggande tekniskt sammanhang som påverkar hur du strukturerar din implementering, och du kan läsa mer om HTTP-omdirigeringarnas mekanik i MDN:s tekniska genomgång av redirections.

Strukturerad data som en del av teknisk SEO – inte ett separat spår

En av de vanligaste organisatoriska misstagen är att behandla strukturerad data som en fristående aktivitet separerad från övrig teknisk SEO. I praktiken är markup beroende av samma tekniska fundament som all annan SEO: sidan måste vara indexerbar, canonical-taggen måste peka på rätt URL och HTML-innehållet måste faktiskt vara tillgängligt utan JavaScript-beroende för att markeringen ska vara relevant.

Det innebär att strukturerad data bör planeras och granskas som en del av det tekniska SEO-arbetet, inte som ett tillägg som läggs på efteråt. Om du arbetar med teknisk SEO som en löpande tjänst kan markup-granskning ingå i det arbetet – inklusive kontroll av @id-konsekvens, validering per sidtyp och integrering med övriga tekniska kontrollpunkter som canonicals och indexeringsstatus.

Det är också värt att notera hur strukturerad data förhåller sig till innehållsarbete på ett bredare plan. Schema.org-markeringen är en maskinläsbar representation av det mänskliga innehållet – inte en ersättning för det. Om du funderar på hur AI-system och sökmotorer tolkar strukturerat innehåll är det ett område i snabb utveckling där kausala samband mellan markup och synlighet ännu inte är välbelagda. Som en annan vinkel att undersöka kan Astros dokumentation om on-demand rendering ge konkret perspektiv på hur server-side renderingsval påverkar vad som faktiskt levereras i HTML-svaret – vilket är direkt relevant för om din strukturerade data överhuvudtaget nås av en crawler.

Slutsatsen är enkel men kräver disciplin i genomförandet: strukturerad data beskriver det som faktiskt finns, och ingenting annat. Varje egenskap du lägger till ska kunna pekas ut på den synliga sidan. Varje @id-värde ska vara stabilt och konsekvent. Varje sidtyp ska ha sin egen anpassade mall. Det är ett begränsat men precist arbete – och det är just precisionen som gör det värdefullt.