Publicerad: 18 augusti 2026

Rätt structured data testing tool: så väljer du och testar korrekt

En person sitter vid sin laptop och skriver kod för att hantera strukturerad data.

Använd Rich Results Test när du vill se om Google kan generera rich results från din sida. Använd Schema Markup Validator när du vill kontrollera att markupen följer schema.org‑syntaxen korrekt. Skillnaden är enkel men avgörande: det första verktyget avgör eligibilitet, det andra avgör giltighet.

De flesta felsökningsflöden börjar med Rich Results Test, eftersom Google rekommenderar det för att se vilka rich result‑typer en sida kvalificerar för. Om felet ligger djupare, i själva syntaxen snarare än i Googles regler, tar du markupen vidare till Schema Markup Validator.

Rich Results Test — kontrollera Google‑specifika rich results och eligibilitet.
Schema Markup Validator — validera ren schema.org‑syntax utan Google‑policyer inblandade.
Kör i den ordningen: Google‑test först, syntaxvalidering vid behov.

Viktiga insikter

Rätt val av verktyg avgörs av frågan du ställer: Rich Results Test svarar på om Google visar rich results, Schema Markup Validator svarar på om koden är korrekt.

Punkt	Detaljer
Välj verktyg efter syfte	Rich Results Test för Google‑eligibilitet, Schema Markup Validator för ren syntax.
Testa via URL eller kod	Använd kodläge när sidan ligger bakom inloggning eller på en lokal server.
Använd JSON‑LD i första hand	Det är enklast att injicera separat och underhålla via CMS eller affärssystem.
Ett giltigt schema räcker inte	Eligibilitet för rich results kräver också att innehållet matchar markupen.
Automatisera testerna	Kör validering pre‑deploy och schemalägg återkommande kontroller efter lansering.

Innehållsförteckning

Verktyg för strukturerad datatestning: Rich Results Test mot Schema Markup Validator
Så testar du strukturerad data steg för steg
Vilka format stöds: JSON‑LD, Microdata och RDFa
Så tolkar du fel och varningar utan att gissa
Bygg in strukturerad datatestning i publiceringsflödet
Vanliga frågor om verktyg för strukturerad datatestning
Källor

Verktyg för strukturerad datatestning: Rich Results Test mot Schema Markup Validator

De två verktygen löser olika problem, trots att de ofta förväxlas. Rich Results Test är byggt kring Googles egna regler för vad som krävs för att en sida ska visas med stjärnbetyg, priser eller receptbilder i sökresultatet. Schema Markup Validator bryr sig inte om Google alls, det kontrollerar bara om markupen är korrekt uppbyggd enligt schema.org:s vokabulär.

Den skillnaden märks tydligt i praktiken. En sida kan ha helt giltig schema.org‑kod och ändå misslyckas i Rich Results Test, eftersom Google ställer extra krav utöver ren syntax, till exempel att innehållet i markupen faktiskt syns för besökaren.

Dimension	Rich Results Test	Schema Markup Validator
Fokus	Google‑eligibilitet för rich results	Schema.org‑syntax, oberoende av sökmotor
Indata	URL eller inklistrad kod	URL eller inklistrad kod
Vad som rapporteras	Fel plus eligibility‑varningar	Syntaktiska fel, ingen Google‑policy
Format som stöds	JSON‑LD, Microdata, RDFa	JSON‑LD, Microdata, RDFa
Typiskt användningsfall	Publik SEO‑optimering mot Google	Utvecklardebugging av ren markup

Har du en produktsida som ska visa pris och recensioner i Google? Kör Rich Results Test först.
Bygger du en ny mall och vill säkerställa att koden är korrekt innan publicering? Kör Schema Markup Validator.
Fungerar sidan i validatorn men inte i Rich Results Test? Då handlar det troligen om ett eligibilitetskrav, inte ett syntaxfel.

Så testar du strukturerad data steg för steg

Öppna Rich Results Test och klistra in URL:en till sidan du vill kontrollera. Sidan måste vara offentligt åtkomlig för att verktyget ska kunna hämta allt innehåll, enligt Search Console Help.
Välj user agent, mobil eller desktop, eftersom Google kan rendera sidan olika beroende på enhet.
Granska resultatet: vilka rich result‑typer hittades, vilka fel finns och vilka varningar dyker upp.
Om sidan ligger bakom inloggning, brandvägg eller på en lokal server, byt till kodläge och klistra in HTML‑ eller JSON‑LD‑snippet direkt istället för att ange en URL.
Kör samma markup genom Schema Markup Validator för att se om syntaxen håller helt oberoende av Googles regler.

Proffstips: Kör alltid om testet efter varje ändring i koden, även små justeringar kan flytta ett fält utanför rätt objekt och tysta felmeddelanden dyker sällan upp förrän du testar på nytt.

Sida inte åtkomlig? Använd tunnling som ngrok eller kör direkt i kodläge.
JavaScript‑renderad markup? Testa efter att sidan laddats klart, inte bara källkoden.
Osäker på vilken user agent som spökar? Testa båda innan du drar slutsatser.

Vilka format stöds: JSON‑LD, Microdata och RDFa

Båda verktygen läser JSON‑LD, Microdata och RDFa, men de skiljer sig i hur de hanterar dem tekniskt. Schema Markup Validator kan kombinera flera JSON‑LD‑block från samma sida och bygga en sammanhängande graf, vilket är praktiskt när markup sprids över flera widgets eller mallfragment.

JSON‑LD är det rekommenderade valet i de flesta fall. Det går att injicera separat från HTML‑strukturen, vilket gör det enklare att hantera via ett CMS eller affärssystem utan att röra den synliga koden. Microdata och RDFa kräver att attributen vävs in direkt i HTML‑taggarna, vilket ökar risken för fel vid mallbyten.

JSON‑LD — enklast att underhålla, injiceras separat, rekommenderas av de flesta utvecklare.
Microdata — inbäddat i HTML, känsligt för strukturändringar i mallen.
RDFa — liknar Microdata men med annan attributsyntax, mindre vanligt i nya projekt.

Så tolkar du fel och varningar utan att gissa

Fel delas oftast in i fyra kategorier: syntaxfel i själva koden, saknade obligatoriska egenskaper, felaktiga datatyper (till exempel text där ett datum förväntas) och mismatch mellan vad som visas för besökaren och vad markupen påstår. Den sista kategorin är den vanligaste orsaken till att sidor blockeras från rich results trots att koden ser korrekt ut.

Ett giltigt schema garanterar aldrig ett rich result. Google skiljer medvetet på de två verktygen: syntaktisk giltighet avgörs av Schema Markup Validator, medan eligibilitet för faktiska rich results styrs av separata policyer i Rich Results Test.

Ett vanligt exempel: en produktsida anger "price": "299" utan valutakod. Validatorn flaggar det som varning för saknad priceCurrency. Fixen är att lägga till fältet explicit, till exempel "priceCurrency": "SEK", varefter varningen försvinner vid nästa körning.

Läs felmeddelandet ordagrant, det pekar ofta ut exakt vilket fält och vilken typ som saknas.
Jämför markupen med Schema för att se vilka egenskaper som är obligatoriska för just den typen.
Åtgärda ett fel i taget och kör om testet innan du går vidare till nästa.

Saknad egenskap? Lägg till fältet enligt schema.org:s typdefinition.
Fel datatyp? Kontrollera att datum, nummer och URL:er formateras enligt standarden.
Innehåll som inte matchar markupen? Synka texten på sidan med det som anges i koden.

Bygg in strukturerad datatestning i publiceringsflödet

Testning ska inte vara en engångsinsats. De starkaste teamen kör kontroller på tre nivåer: pre‑deploy i en teströrledning innan koden går live, post‑deploy direkt efter publicering för att fånga fel som bara syns i produktion, och schemalagda kontroller som körs regelbundet för att upptäcka regressioner efter oberoende ändringar i CMS eller mallar.

Tekniskt sett går det att koppla in testerna via API‑anrop mot valideringsverktygen, headless‑testsviter som körs i CI, eller webhook‑triggers som aktiveras vid varje deploy. För privata staging‑miljöer används kodläge istället för URL, precis som vid manuell felsökning.

Kör syntaxvalidering automatiskt vid varje pull request som rör mallar eller produktdata.
Schemalägg en fullständig genomgång av sajtens viktigaste sidtyper varje vecka.
Sätt upp en rollback‑policy: om en release bryter strukturerad data på kritiska sidor, återställ innan nästa test körs.

Håll markupen synkad med backend‑data som pris och lagersaldo, ett affärssystem som centraliserar den informationen minskar risken för mismatch.
Logga varje testkörning så att du kan spåra när ett fel introducerades.
Involvera IT‑support tidigt om testmiljön kräver nätverkskonfiguration för tunnling eller serveråtkomst.

Proffstips: Lägg valideringssteget direkt efter build‑steget i pipelinen, inte efter deploy, då hinner du stoppa en trasig release innan den når besökarna.

Författarens snabba praxis: teknisk SEO‑synpunkt

Det vanligaste misstaget är inte trasig kod, det är markup som glömts bort efter lansering. Priser ändras, lager tar slut, recensioner uppdateras, men schemat i mallen fryser. Prioritera synkronisering mellan markup och faktiskt innehåll före allt annat. Testa i staging, ha en rollback‑plan redo, och behandla schema som en del av mallen, inte ett engångsprojekt.

Ett system som håller order, priser och lagerstatus uppdaterat i realtid gör den synkroniseringen enklare att upprätthålla över tid. Seerms orderhantering kopplar affärsdata direkt till samma källa som driver webbplatsens innehåll, vilket minskar risken att markupen halkar efter verkligheten. Boka en demo för att se hur plattformen kan hålla din strukturerade data i fas med resten av verksamheten.

Författarens snabba praxis: teknisk SEO‑synpunkt — overview diagram

Vanliga frågor om verktyg för strukturerad datatestning

Vad är skillnaden mellan att validera och att testa strukturerad data? Validering kontrollerar om syntaxen är korrekt enligt schema.org. Testning, som i Rich Results Test, kontrollerar om Google faktiskt kan visa sidan som ett rich result baserat på både syntax och innehåll.

Fungerar samma verktyg för Bing som för Google? Rich Results Test är specifikt byggt för Googles regelverk. Schema Markup Validator är sökmotorsoberoende eftersom det bara kontrollerar schema.org‑syntaxen, vilket gör det mer relevant om du optimerar för flera sökmotorer samtidigt.

Varför visar validatorn inga fel men rich results syns ändå inte i Google? Ett giltigt schema garanterar inte eligibilitet. Google kan neka rich results av policyskäl, till exempel om markupen inte matchar synligt innehåll, även om syntaxen är helt korrekt.

Kan jag testa strukturerad data på en sida som inte är publicerad än? Ja, genom att använda kodläge i Rich Results Test och klistra in HTML‑ eller JSON‑LD‑koden direkt istället för att ange en URL. Det är särskilt användbart för staging‑miljöer som inte är offentligt åtkomliga.

Vilket format bör jag använda om jag bygger nytt? JSON‑LD rekommenderas i de flesta fall eftersom det går att injicera separat från HTML‑strukturen, vilket minskar risken för fel när mallar uppdateras.