Praktisk guide för strukturerad data

Guide för JSON-LD schema markup för praktisk SEO

JSON-LD hjälper sökmotorer att förstå vad en sida är, vem som publicerat den, hur den passar in på din sajt och vilka fakta som är värda att använda i stöd för sökfunktioner.

Det användbara målet är inte att lägga till alla schema-typer du hittar. Målet är korrekt strukturerad data som matchar sidan, valideras utan fel och hålls uppdaterad vid innehållsändringar.

Den användbara kortversionen

Använd JSON-LD när du kan beskriva sidan med ärliga, synliga fakta: titel, beskrivning, författare, publiceringsdatum, brödsmulor, produktdetaljer, videodata eller tydligt frågor-och-svar-innehåll. Lägg inte till schema för att lova funktioner Google inte längre visar eller för att markera innehåll användare inte kan se.

Bästa schema först Article, WebPage och BreadcrumbList för de flesta guidesidor.
Bästa arbetsflödet Generera schema från samma metadata som styr titel, beskrivning, kanonisk URL och Open Graph.
Bästa verklighetskontrollen FAQPage och WebSite-markering kan fortfarande beskriva innehåll, men bygg inte strategi kring föråldrade Google-visningar.

Vad JSON-LD faktiskt gör

JSON-LD är ett maskinläsbart block med strukturerad data. Det ligger normalt i ett script-tag i head eller body och beskriver entiteter med schema.org-ordförråd. Sökmotorer använder det som ett tydliggörande lager ovanpå synligt innehåll.

Parsertydlighet

Betydelse

Det omvandlar sidfakta till namngivna entiteter och egenskaper, som Article, författare, datePublished, BreadcrumbList eller SoftwareApplication.

Sökfunktion

Behörighet

Det kan göra en sida berättigad till stöd för rich results, men Google avgör vad som visas baserat på kvalitet, policy, sökfråga och funktionstillgänglighet.

Sajtens graf

Konsekvens

Det ger ditt CMS eller Blazor-app en strukturerad plats att återanvända samma kanoniska URL, språk, titel, datum, bilder och utgivardata.

Ingen genväg

Begränsa

Det reparerar inte svagt innehåll, falska recensioner, dolda FAQ-svar, föråldrade datum eller sidor som inte stämmer med strukturerad data.

Viktigt: Strukturerad data ska stödja sidan, inte ersätta användbart innehåll. Om sidan är tunn, förvirrande, föråldrad eller vilseledande gör schema markup den inte till ett starkt sökresultat.

Välj schema efter sidans syfte

Det enklaste sättet att undvika spam eller duplicerad strukturerad data är att fråga vad sidan försöker göra. Lägg till det minsta schema som beskriver uppgiften korrekt.

Innehåll

Article / BlogPosting

Använd det för
Guider, tutorials, recensioner, nyhetsliknande inlägg och långa förklaringar.
Lägg till när
Sidan har en tydlig rubrik, författare eller utgivare, publiceringsdatum, ändringsdatum, kanonisk URL och bild.
Undvik när
Sidan är mestadels ett verktygsgränssnitt, produktlista, kategorisida eller tunn landningssida.

Navigering

BreadcrumbList

Använd det för
Nästan varje sida under startsidan.
Lägg till när
Användare kan förstå var sidan ligger i sajtens hierarki.
Undvik när
Brödsmulevägen stämmer inte överens med interna länkar, kanoniska URL:er eller synlig navigering.

Sajtidentitet

WebPage / WebSite / Organization

Använd det för
Startsida, nav, om-sidor och sidor där utgivaridentitet är viktig.
Lägg till när
Du vill ha en stabil entitetsgraf som kopplar sidan, sajten, utgivaren och språket.
Undvik när
Du lägger till WebSite-markering bara för att jaga den gamla sitelinks-sökrutans visning.

Produkt eller app

Product / SoftwareApplication

Använd det för
Verktyg, appar, SaaS-sidor, tillägg, nedladdningsbar mjukvara eller riktiga produktsidor.
Lägg till när
Synligt sidinnehåll inkluderar namn, beskrivning, OS eller kategori, pris, erbjudanden och betyg när du markerar dem.
Undvik när
Betyg, pris, tillgänglighet eller recensioner är inte synliga för användare på sidan.

Frågor

FAQPage

Använd det för
Synliga frågor-och-svar-sektioner som verkligen hjälper användare att förstå ämnet.
Lägg till när
Frågor och svar är användbara på sidan även om Google inte visar FAQ rich results.
Undvik när
Du lägger till generiska frågor och svar bara för att ta upp sökutrymme eller upprepa samma svar på många sidor.

Media

VideoObject / ImageObject

Använd det för
Sidor med viktig inbäddad video, instruktionsvideo eller crawlbar bildresurs.
Lägg till när
Mediet är centralt för sidan och har titel, beskrivning, miniatyrbild, uppladdningsdatum och en stabil URL.
Undvik när
Mediet är dekorativt, dolt, blockerat eller inte relevant för sidans huvudsyfte.

Implementeringschecklista som förhindrar de flesta misstag

Bra JSON-LD är tråkigt på bästa sätt: konsekvent, genererat från pålitliga fält, lätt att validera och svårt att glömma vid sidändringar.

01

Välj en huvudentitet för sidan

Bestäm om sidan främst är en artikel, produkt, app, video, FAQ, samling eller generell webbsida. Sekundärt schema ska stödja huvudentiteten.

02

Matcha synligt innehåll

Varje markerat påstående ska vara synligt eller tydligt härledbart på sidan: titel, författare, datum, pris, betyg, frågor & svar, brödsmulor och bilder.

03

Använd stabila @id-värden

Ge viktiga entiteter stabila ID:n som kanonisk URL plus #article, #webpage, #organization eller #faq. Detta hjälper parsers att koppla ihop grafdelar.

04

Generera från delad metadata

Återanvänd samma källfält som skapar titeltaggar, metabeskrivningar, kanoniska URL:er, Open Graph-bilder, språktaggar och senaste ändringsdatum.

05

Håll datum ärliga

Ändra endast dateModified när sidans innehåll ändrats väsentligt. Uppdatera inte datum automatiskt bara för att se nyare ut i sökresultat.

06

Gör bilder crawlbara

Använd absoluta bild-URL:er, lämpliga dimensioner och filer som inte blockeras av robots, autentisering eller lazy-loading.

07

Rendera tidigt

I Blazor och andra JavaScript-appar, föredra prerenderad eller server-renderad JSON-LD så crawlers ser det i initiala HTML-svaret.

08

Validera och övervaka

Kör Rich Results Test före publicering, kontrollera syntax med Schema Markup Validator och följ Search Console efter indexering.

Ett rent JSON-LD-mönster för Blazor-sidor

För Blazor är det säkraste mönstret att bygga schema från sidans metadata vid initiering eller prerendering, serialisera det en gång och rendera application/ld+json-scriptet där crawlers kan se det i initial HTML.

HTMLExempel på Article JSON-LD
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/en/json-ld-schema-guide/#article",
  "headline": "JSON-LD Schema Markup Guide for Practical SEO",
  "description": "A practical guide to choosing, generating, and validating structured data.",
  "image": "https://example.com/images/json-ld-guide.png",
  "datePublished": "2026-03-28T10:00:00+00:00",
  "dateModified": "2026-05-31T10:00:00+00:00",
  "author": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/en/json-ld-schema-guide/"
  }
}
</script>
C#C# hjälpmönster
private MarkupString BuildJsonLd(PageMetaData meta)
{
    var pageUrl = BuildPageUrl(meta);

    var schema = new Dictionary<string, object?>
    {
        ["@context"] = "https://schema.org",
        ["@type"] = "Article",
        ["@id"] = $"{pageUrl}#article",
        ["headline"] = meta.Title,
        ["description"] = meta.Description,
        ["url"] = pageUrl,
        ["datePublished"] = meta.Published?.ToString("O"),
        ["dateModified"] = meta.Modified?.ToString("O"),
        ["inLanguage"] = CS.Culture
    };

    var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
    {
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    });

    return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}
Praktisk regel: Använd stabila URL:er för url och @id. Använd samma kanoniska URL överallt. Om samma sida finns under flera språk-URL:er, generera språk-specifik metadata och håll varje hreflang/kanonisk inställning konsekvent.

Validera JSON-LD innan du förlitar dig på det

Validering har två olika uppgifter. Schema Markup Validator kontrollerar om vokabulär och JSON-LD-syntax är förståelig. Googles Rich Results Test kontrollerar om Google känner igen sidan som berättigad till stöd för rich results.

Google behörighet

Test för rika resultat

Kontrollerar om Google kan läsa sidan och om strukturerad data är berättigad till stöd för rich results.

Öppna Rich Results Test

Vokabulär

Validator för schema markup

Kontrollerar schema.org-struktur och JSON-LD-syntax, inklusive typer, egenskaper, inbäddade enheter och felaktig JSON.

Öppna Schema Markup Validator

Vanliga JSON-LD-misstag som skadar förtroendet

De flesta schema-problem är inte komplexa tekniska fel. De är skillnader mellan vad markeringen säger och vad användare eller crawlers kan verifiera på sidan.

Markera inte dolt eller saknat innehåll

Om användare inte kan se svaret, recensionen, erbjudandet, bilden eller författaruppgiften, inkludera det inte i strukturerad data. Det är snabbaste sättet att förlora förtroende.

Lägger till FAQPage överallt

FAQ-schema kan fortfarande beskriva synliga frågor och svar, men bör inte kopieras till varje artikel. Använd det bara när Q&A förbättrar sidan.

Motstridiga dubblettskript

Flera Article-block med olika rubriker, datum eller URL:er gör sidan svårare att tolka. En tydlig graf är bättre än tre delvisa.

Felaktig kanonisk URL eller @id

Schema-URL:er ska matcha kanonisk sida, kultur-URL och hreflang-inställning. Blandade språk-URL:er skapar duplicerat innehåll och entitetsförvirring.

Falsk aktualitet

Ändra inte dateModified för malländringar, spårningsändringar eller schema-uppdateringar. Använd datum för verkliga innehållsändringar.

Sen rendering endast på klienten

Om JSON-LD visas först efter fördröjd klientrendering kan crawlers missa det. Föredra server- eller prerendering för viktiga sidor.

Praktiska schema-recept efter sidtyp

Du behöver sällan en jättestor graf. Dessa kombinationer täcker de sidor som de flesta små sajter, bloggar, verktyg och recensionsprojekt faktiskt publicerar.

Guideartikel

Article + BreadcrumbList + WebPage

  • Använd Article för rubrik, författare, utgivare, bild, datum och sektionsnamn.
  • Använd BreadcrumbList för den synliga sajtvängen.
  • Använd WebPage eller @id-referenser för att koppla sidan och artikelentiteten.

Verktygssida

SoftwareApplication + WebPage + BreadcrumbList

  • Använd SoftwareApplication endast om sidan handlar om en riktig app eller verktyg.
  • Inkludera operativsystem, kategori, pris eller erbjudandedetaljer endast när de är synliga.
  • Undvik recension- eller betygsmarkering om sidan inte visar verkliga recensioner.

Recensionssida

Recension / Produkt endast när sidan stödjer det

  • Markera det granskade objektet, författare, datum och betyg endast när sidan tydligt visar dem.
  • Håll affiliate-länkar och kommersiell kontext transparent.
  • Använd samma poäng i schema och synligt innehåll.

Frågesida

FAQPage endast för användbara synliga frågor och svar

  • Gör varje svar användbart i sig, inte bara som en nyckelordsvariant.
  • Dölj inte svar bakom blockerad UI som crawlers inte kan nå.
  • Förvänta dig inte FAQ rich results som huvudfördel för SEO.

Källor kontrollerade

Vägledningen ovan baseras på officiell Google Search Central och schema.org-dokumentation, och har omvandlats till en praktisk JSON-LD-checklista.

01 Introduktion till Googles strukturerade data developers.google.com 02 Googles policy för strukturerad data developers.google.com 03 Google Article strukturerad data developers.google.com 04 Google Breadcrumb strukturerad data developers.google.com 05 Google FAQ strukturerad data developers.google.com 06 Google uppdatering av sitelinks sökruta developers.google.com 07 Kom igång med Schema.org schema.org 08 Google Rich Results Test search.google.com 09 Validator för schema markup validator.schema.org

Vanliga frågor

Är JSON-LD schema markup en rankingfaktor?

JSON-LD är inte en magisk rankingknapp. Det hjälper sökmotorer att förstå berättigat innehåll och kan stödja rich results, men rankning beror fortfarande på innehållskvalitet, relevans, crawlbarhet, länkar och många andra signaler.

Var ska JSON-LD placeras på en sida?

Ett script-tag i head är oftast enklast att hantera, men Google kan också läsa JSON-LD i body. Det viktiga är att markeringen finns i den renderade sidan och stämmer med synligt innehåll.

Bör jag fortfarande använda FAQPage-schema?

Använd FAQPage endast när sidan har verkligt användbara synliga frågor och svar. Lita inte på det för extra Google-resultatutrymme, eftersom FAQ rich results har kraftigt minskats och föråldrats för de flesta vanliga sajter.

Kan en sida ha flera JSON-LD-block?

Ja. En vanlig artikelsida kan ha Article, BreadcrumbList och WebPage-data. Håll blocken konsekventa, undvik dubbletter och använd stabila @id-värden för att koppla ihop relaterade delar.

Är JSON-LD bättre än Microdata?

För de flesta moderna sajter, ja. Google stödjer JSON-LD, Microdata och RDFa, men JSON-LD är oftast enklare att underhålla eftersom det inte kräver schemaattribut i HTML-mallar.

Hur ofta bör jag validera strukturerad data?

Validera när du ändrar mallar, metadatafält, schema-hjälpare, URL:er, språkvägledning, bildgenerering, recensionsdata eller FAQ-sektioner. Kontrollera även Search Console efter indexering av viktiga sidor.