Strukturerad data för e-handel: Komplett implementeringsguide
En omfattande guide till implementering av strukturerad data på e-handelssajter. Täcker Product, Offer, Review och BreadcrumbList-schema med JSON-LD-exempel och vanliga fel att undvika.
Det här är en steg-för-steg-implementeringsguide för strukturerad data på e-handelssajter. Den täcker vilka schematyper du ska implementera — Product, Offer, AggregateRating, BreadcrumbList, FAQPage, Organization — hur du skriver korrekt JSON-LD för varje typ, och hur du upprätthåller noggrannhet när priser, lagersaldo och produktvarianter ändras dagligen.
Varje schematyp i den här guiden inkluderar ett komplett, kopieringsklart JSON-LD-exempel. Vi täcker även de fem vanligaste felen i strukturerad data på e-handelssajter — saknade obligatoriska fält, felaktigt prisformat, inaktuell tillgänglighetsdata, felaktiga valutakoder och markup som inte matchar synligt innehåll — med specifik vägledning om hur du undviker vart och ett.
För den bredare SEO-strategin för e-handel — kataloghantering, optimering av kategorisidor, facetterad navigering och intern länkarkitektur — se vår kompletterande artikel om SEO för e-handel i stor skala. Den här artikeln fokuserar specifikt på att få strukturerad data rätt: markup, validering och den operativa utmaningen att hålla den korrekt över tiotusentals produktsidor.
Varför strukturerad data är viktigt för e-handel
Sökmotorer använder strukturerad data för att förstå sidinnehåll och generera rich results — förbättrade söklistningar som visar produktpriser, omdömesstjärnor, lagerstatus och andra detaljer direkt på sökresultatsidan.
Publicerade fallstudier från Google Developers visar att korrekt structured data-implementation driver mätbara CTR-förbättringar — från 25 till 82 procent beroende på sajt och schema-typ. För en detaljerad genomgång av dessa fall, se vår artikel om den verkliga kostnaden av att inte implementera SEO-rekommendationer.
För e-handelssajter inkluderar de relevanta rich result-typerna produktkort med prissättning och tillgänglighet, omdömesstjärnor, FAQ-dragspel, brödsmulenavigering och söklådor för sajten. Var och en av dessa ger ytterligare information i söklistningen som hjälper användare att avgöra om de ska klicka — och var och en kräver korrekt strukturerad data för att utlösas.
Väsentliga schematyper för e-handel
Schematyperna nedan listas i prioritetsordning. Product- och Offer-schema bör implementeras först, eftersom de har den mest direkta påverkan på söksynlighet för kommersiella sidor.
Product-schema
Product-schema beskriver en enskild vara till försäljning. Det är grunden för strukturerad data inom e-handel och den viktigaste schematypen att få rätt.
Här är ett komplett Product-schema-exempel i JSON-LD:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trådlösa brusreducerande hörlurar WH-1000XM5",
"image": [
"https://example.com/images/headphones-front.jpg",
"https://example.com/images/headphones-side.jpg",
"https://example.com/images/headphones-case.jpg"
],
"description": "Branschledande brusreducering med Auto NC Optimizer. 30 timmars batteritid. Kristallklara handsfree-samtal med 4 strålformande mikrofoner.",
"sku": "WH1000XM5B",
"mpn": "WH-1000XM5/B",
"brand": {
"@type": "Brand",
"name": "Sony"
},
"offers": {
"@type": "Offer",
"url": "https://example.com/headphones/wh-1000xm5",
"priceCurrency": "SEK",
"price": 3990.00,
"priceValidUntil": "2026-12-31",
"itemCondition": "https://schema.org/NewCondition",
"availability": "https://schema.org/InStock",
"seller": {
"@type": "Organization",
"name": "Example Electronics"
}
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"bestRating": "5",
"ratingCount": "2847"
}
}
Viktiga krav för Product-schema:
- name är obligatoriskt och ska matcha den synliga produkttiteln på sidan
- image bör inkludera minst en högkvalitativ bild-URL; flera bilder rekommenderas
- offers måste finnas för att Google ska visa prisinformation i rich results
- brand förbättrar relevansmatchning och rekommenderas av Google
- sku eller mpn hjälper Google matcha din produkt med shoppingresultat
Offer-schema
Offer-schema är nästan alltid inbäddat inom Product-schema. Det beskriver de kommersiella villkoren — pris, valuta, tillgänglighet och skick.
De mest kritiska fälten är:
{
"@type": "Offer",
"priceCurrency": "SEK",
"price": 3990.00,
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
För produkter med flera varianter — storlekar, färger, konfigurationer — använd AggregateOffer för att representera prisintervallet:
{
"@type": "AggregateOffer",
"lowPrice": 2990.00,
"highPrice": 4490.00,
"priceCurrency": "SEK",
"offerCount": 4,
"availability": "https://schema.org/InStock"
}
Vanliga tillgänglighetsvärden du kommer använda mest:
https://schema.org/InStock— tillgänglig för köphttps://schema.org/OutOfStock— inte tillgänglig för tillfällethttps://schema.org/PreOrder— tar emot beställningar före lanseringhttps://schema.org/BackOrder— tillfälligt slut men tar emot beställningarhttps://schema.org/Discontinued— permanent borttagen från försäljning
AggregateRating och Review-schema
Omdömesstjärnor i sökresultat är bland de mest effektfulla rich results för CTR inom e-handel. De kräver antingen AggregateRating, individuell Review-markering, eller båda.
AggregateRating sammanfattar alla omdömen för en produkt:
{
"@type": "AggregateRating",
"ratingValue": "4.7",
"bestRating": "5",
"worstRating": "1",
"ratingCount": "2847",
"reviewCount": "1203"
}
Individuell Review-markering representerar ett specifikt kundomdöme:
{
"@type": "Review",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
},
"author": {
"@type": "Person",
"name": "Sarah M."
},
"datePublished": "2026-03-15",
"reviewBody": "Bästa brusreducerande hörlurarna jag någonsin ägt. Batteritiden är otrolig och ljudkvaliteten är enastående."
}
Viktiga riktlinjer för omdömesschema:
- Omdömen måste komma från din egen sajt, inte aggregerade från tredjepartsplattformar
- Omdömesinnehållet måste vara synligt på sidan — dolda omdömen genererar inte rich results
- Google kräver att omdömesmarkering representerar genuina kundrecensioner, inte redaktionella åsikter presenterade som användaromdömen
BreadcrumbList-schema
BreadcrumbList hjälper sökmotorer förstå din sajthierarki och kan generera brödsmulenavigering i sökresultat. För e-handelssajter med djupa kategoristrukturer är detta särskilt värdefullt eftersom det visar användare vägen till en produkt innan de klickar.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Hem",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Elektronik",
"item": "https://example.com/elektronik"
},
{
"@type": "ListItem",
"position": 3,
"name": "Hörlurar",
"item": "https://example.com/elektronik/horlurar"
},
{
"@type": "ListItem",
"position": 4,
"name": "Trådlösa brusreducerande hörlurar WH-1000XM5"
}
]
}
Observera att det sista objektet i brödsmulestigen — den aktuella sidan — inte ska inkludera en item-URL, eftersom det representerar sidan som användaren redan befinner sig på.
FAQPage-schema
FAQ-sektioner på produktsidor och kategorisidor kan generera expanderbara FAQ-dragspel i sökresultat, som tar upp betydande extra utrymme i SERP.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Vad är batteritiden för WH-1000XM5?",
"acceptedAnswer": {
"@type": "Answer",
"text": "WH-1000XM5 ger upp till 30 timmars batteritid med brusreducering aktiverad och upp till 40 timmar med brusreducering avaktiverad."
}
},
{
"@type": "Question",
"name": "Stöder WH-1000XM5-hörlurarna multipoint-anslutning?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja, WH-1000XM5 stöder multipoint Bluetooth-anslutning, vilket gör att du kan ansluta till två enheter samtidigt."
}
}
]
}
FAQ-schema fungerar bäst på sidor där frågorna genuint besvarar vanliga kundfrågor. Undvik att fabricera frågor enbart för SEO — Google kan och granskar manuellt FAQ-rich results och kan återkalla behörighet för sidor som missbrukar formatet.
Organization- och WebSite-schema
Dessa är sajttäckande scheman som bör visas på din startsida. De etablerar din varumärkesidentitet och kan aktivera söklådan för sajtlänkar i sökresultat.
Organization-schema:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Electronics",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://www.facebook.com/exampleelectronics",
"https://twitter.com/exampleelec",
"https://www.instagram.com/exampleelectronics"
],
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+1-800-555-0199",
"contactType": "customer service",
"availableLanguage": ["English", "Swedish"]
}
}
WebSite-schema med SearchAction för söklådan för sajtlänkar:
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Example Electronics",
"url": "https://example.com",
"potentialAction": {
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://example.com/search?q=SEARCH_TERM_STRING"
},
"query-input": "required name=SEARCH_TERM_STRING"
}
}
Ersätt SEARCH_TERM_STRING med den faktiska frågeparameter som din sajtsökning använder. Google kommer att ersätta användarens sökfråga på denna position.
Vanliga fel i strukturerad data på e-handelssajter
Enligt Schema Apps forskning har ungefär 20 procent av sajter med strukturerad data valideringsfel. För e-handelssajter finns det flera felmönster som är särskilt vanliga.
Saknade obligatoriska fält
Det vanligaste felet är att utelämna fält som Google kräver för rich result-behörighet. För Product-schema är de tre oftast saknade fälten:
- price — utan det kan Google inte visa produktkortets rich result
- availability — Google kräver alltmer detta för att visa produktlistningar
- image — krävs för produkt-rich results; Product-schema utan bild ignoreras
Felaktigt prisformat
Priser måste vara numeriska värden, inte formaterade strängar. Att använda "SEK 3990,00" eller "3990 kr" som prisvärde kommer att orsaka valideringsfel. Det korrekta tillvägagångssättet är att använda ett numeriskt price-fält parat med ett separat priceCurrency-fält.
Felaktigt:
{
"price": "3990 kr"
}
Korrekt:
{
"price": 3990.00,
"priceCurrency": "SEK"
}
Inaktuell tillgänglighetsdata
Detta är det mest skadliga felet för användarförtroende. När din strukturerade data säger att en produkt är "InStock" men användaren anländer och finner den slut på lager, är upplevelsen negativ. Google behandlar detta som en kvalitetssignal och kan minska rich result-behörigheten för sajter med ihållande tillgänglighetsavvikelser.
Grundorsaken är vanligtvis en avvikelse mellan datakällan som genererar den strukturerade datan och lagersystemet i realtid. Om din strukturerade data genereras vid byggtid eller cachas under långa perioder kan tillgängligheten glida ifrån verkligheten.
Felaktiga valutakoder
Valuta måste anges som en trebokstavs ISO 4217-kod. Vanliga misstag inkluderar att använda valutasymboler, landskoder eller förkortade namn. Det är SEK, inte kr eller SE. Det är USD, inte $ eller US eller Dollar. Det är GBP, inte £ eller UK.
Markering som inte matchar synligt innehåll
Google kräver att strukturerad data speglar information som är synlig på sidan. Om ditt schema säger att priset är 2 990 kronor men sidan visar 3 490 kronor, eller om ditt schema inkluderar en omdömessammanfattning som inte visas på sidan, kan Google utfärda en manuell åtgärd eller helt enkelt inte generera rich results.
Denna avvikelse uppstår ofta när strukturerad data genereras från en annan datakälla än sidinnehållet — till exempel att schemat hämtar från produktdatabasen medan det visade priset inkluderar regionala justeringar eller kampanjrabatter som tillämpas på mallnivå.
Utmaningen med skala
Allt som beskrivs ovan är enkelt för en enskild produktsida. Svårigheten ligger i att göra det korrekt över 10 000 eller 100 000 produktsidor, var och en med sitt eget pris, sin tillgänglighet, sina varianter och sina omdömen.
Produktvarianter
En enskild produkt kan finnas i fem färger och fyra storlekar, vilket skapar tjugo varianter. Varje variant kan ha ett annat pris, ett annat artikelnummer och annan tillgänglighet. Din strukturerade data behöver representera detta korrekt. För de flesta implementeringar är AggregateOffer med korrekt prisintervall det praktiska tillvägagångssättet. För sajter som skapar separata URL:er per variant behöver varje sida sitt eget Product-schema med variantspecifika detaljer.
Dynamisk prissättning
Priser förändras. Kampanjer körs. Rabatter tillämpas och tas bort. Om din strukturerade data bakas in i statisk HTML vid byggtid kommer den att vara inaktuell i samma ögonblick som ett pris ändras. Realtids- eller nära realtidsschemagenerering är nödvändig för sajter med frekventa prisändringar. Det innebär vanligtvis att JSON-LD genereras på serversidan från samma datakälla som visar priset på sidan.
Verksamhet på flera marknader
E-handelssajter som verkar i flera länder möter ytterligare komplexitet. Varje marknad kan ha:
- Olika valutor som kräver korrekta ISO 4217-koder
- Olika språk som kräver översatta produktnamn och beskrivningar
- Olika skatteregler som påverkar visade priser
- Olika regulatoriska krav för produktpåståenden och certifieringar
- Olika tillgänglighet baserat på regional lagerhållning
Din strukturerade data måste spegla den version av sidan som användaren på varje marknad faktiskt ser. Att servera tyskspråkigt schema på en engelskspråkig sida, eller visa USD-priser på en sida som visas i EUR, skapar den typ av innehålls-schema-avvikelse som Google straffar.
Lagersynkronisering
Den operativt mest utmanande aspekten av strukturerad data för e-handel är att hålla tillgängligheten korrekt. En produkt kan gå från i lager till slut på lager på minuter under en högefterfrågan-kampanj. Om din strukturerade data halkar efter ditt lagersystem med ens en timme under toppperioder kommer användare att se "InStock" i sökresultat och anländer till sidor som visar "Slut på lager."
Lösningarna här är arkitektoniska: generera strukturerad data från samma realtidsdatakälla som driver lägg-till-i-varukorgen-knappen, använd korta cache-TTL:er för sidor med volatilt lager, och implementera övervakning som varnar när strukturerad data-tillgänglighet avviker från faktisk lagerstatus.
Implementeringsmetoder
Det finns tre primära metoder för att lägga till strukturerad data på e-handelssidor, var och en med olika avvägningar.
Inline JSON-LD i sidmallar
Det vanligaste tillvägagångssättet är att bädda in JSON-LD-script-taggar direkt i dina sidmallar. Mallen hämtar data från din produktdatabas och renderar den som ett JSON-LD-block i sidhuvudet.
Detta är det tillvägagångssätt som Google rekommenderar, och det fungerar bra för sajter med ett hanterbart antal sidmallar. Den strukturerade datan genereras på serversidan, förblir synkroniserad med sidinnehållet och är omedelbart tillgänglig för sökmotorernas crawlers.
Nackdelen är underhåll. Varje mall behöver sin egen strukturerade datalogik. Ändringar i ditt schema — att lägga till ett nytt fält, fixa ett formateringsproblem, justera strukturen — kräver koddistribution över varje mall.
Tag Manager-injektion
Vissa team använder tag management-system för att injicera strukturerad data via JavaScript. Detta undviker behovet av utvecklardistributioner och ger marknadsföringsteam direkt kontroll.
Google har dock historiskt varit inkonsekvent med att bearbeta JavaScript-injicerad strukturerad data. Även om Googlebot exekverar JavaScript lägger renderingssteget till latens och komplexitet. För kritisk strukturerad data som Product-schema som direkt påverkar rich results är serversiderendering mer pålitlig.
Edge-nivå eller middleware-injektion
Ett tredje tillvägagångssätt är att injicera strukturerad data vid edge-nivå eller genom server-middleware, efter att sidan genererats men innan den når användaren och sökmotorerna. Detta frikopplar hanteringen av strukturerad data från applikationens kodbas helt.
Server-side-injektionsplattformar använder detta mönster och låter SEO-team definiera strukturerade datamallar som tillämpas automatiskt baserat på URL-mönster och sidkategorier. Den strukturerade datan injiceras på serversidan, vilket säkerställer full crawler-kompatibilitet, medan ändringar kan göras utan koddistributioner.
Detta tillvägagångssätt är särskilt lämpat för stora e-handelssajter där antalet sidtyper och frekvensen av ändringar gör mallnivåhantering opraktisk.
Testning och validering
Innan du distribuerar strukturerad data till produktion, validera den med dessa verktyg:
- Google Rich Results Test — testar enskilda URL:er och visar vilka rich results som är behöriga
- Schema Markup Validator — validerar mot hela schema.org-specifikationen och fångar problem som Rich Results Test kanske inte flaggar
- Google Search Console — Förbättringsrapporterna visar strukturerad data-status över hela din sajt, inklusive feltrender över tid
Ett vanligt arbetsflöde är att validera exempelsidor från varje malltyp med Rich Results Test, distribuera till en staging-miljö, kontrollera staging-URL:erna, sedan distribuera till produktion och övervaka Search Console för fel.
För stora sajter är automatiserad validering avgörande. Bygg tester som genererar strukturerad data för representativa sidor och validerar utmatningen mot förväntat schema. Kör dessa tester som en del av din distributionspipeline så att schemafel fångas innan de når produktion.
Mätning av effekt
Efter implementering, följ dessa mätvärden för att mäta effekten av din strukturerade data:
- Rich result-visningar i Google Search Console — jämför före och efter implementering
- Klickfrekvens för sidor med rich results jämfört med de utan
- Sökutseende-rapport i Search Console, filtrerad efter rich result-typ
- Intäkt per organisk session för sidor som fått rich results
Tidslinjen för att se resultat varierar. Google behöver crawla om och indexera om sidor med ny strukturerad data, vilket kan ta dagar till veckor beroende på din sajts crawlfrekvens. Planera att utvärdera effekt över ett 60-till-90-dagars fönster snarare än att förvänta sig omedelbara förändringar.
Vanliga frågor
Vilka strukturerade datatyper bör e-handelssajter implementera?
De väsentliga typerna i prioritetsordning är Product med inbäddat Offer-schema, AggregateRating och Review för kundomdömen, BreadcrumbList för sajtnavigering, FAQPage för produkt- och kategori-FAQ-sektioner, samt Organization och WebSite-schema på startsidan. Product- och Offer-schema bör implementeras först eftersom de har den mest direkta påverkan på söksynlighet genom produktspecifika rich results inklusive pris, tillgänglighet och omdömesstjärnor.
Hur lägger jag till produktschema-markering på alla mina produktsidor?
Den mest pålitliga metoden är att generera JSON-LD på serversidan inom dina produktsidmallar, genom att hämta data direkt från din produktdatabas. Detta säkerställer att den strukturerade datan förblir synkroniserad med det synliga sidinnehållet. För sajter med många produktmallar eller frekventa schemaändringar kan edge-nivåinjektion eller middleware-metoder vara mer underhållsvänliga, eftersom de tillåter schemaändringar utan koddistributioner. Oavsett vilken metod du väljer bör den strukturerade datan finnas i det initiala HTML-svaret snarare än injiceras via klientsidans JavaScript.
Vilka är de vanligaste felen i strukturerad data på e-handelssajter?
De mest förekommande felen är saknade obligatoriska fält — särskilt price, availability och image i Product-schema — följt av felaktigt prisformat som att inkludera valutasymboler i prisvärdet istället för att använda ett separat priceCurrency-fält. Inaktuell tillgänglighetsdata är det mest skadliga felet, eftersom det skapar en dålig användarupplevelse när sökresultat visar "i lager" för produkter som faktiskt inte är tillgängliga. Felaktiga valutakoder och avvikelser mellan strukturerad data och synligt sidinnehåll kompletterar topp fem.
Förbättrar strukturerad data direkt SEO-rankningar för e-handel?
Strukturerad data är inte en direkt rankingfaktor — att lägga till schemamarkering kommer inte i sig att flytta dina sidor högre i sökresultaten. Det möjliggör dock rich results som avsevärt ökar klickfrekvensen. Googles fallstudier visar CTR-förbättringar på 25 % till 82 % för sidor med rich results. Högre CTR innebär mer trafik från samma rankingpositioner, och det ökade engagemanget kan indirekt stödja rankningar över tid. För e-handelssajter är de produktspecifika rich results — pris, tillgänglighet, omdömesstjärnor — bland de mest effektfulla när det gäller CTR-förbättring.
Hur upprätthåller jag noggrannhet i strukturerad data när produktpriser och tillgänglighet ändras?
Nyckeln är att generera strukturerad data från samma realtidsdatakälla som driver din produktvisning och lägg-till-i-varukorgen-funktionalitet. Om din sida visar ett livepris från ditt lagersystem bör din strukturerade data hämta från samma källa. Undvik att cacha strukturerad data separat från sidinnehåll, eftersom detta skapar avdrift. För sajter med mycket volatilt lager, implementera övervakning som jämför strukturerad data-utmatning mot faktisk produktstatus och varnar när avvikelser uppstår. Ställ in korta cache-TTL:er för sidor där priser eller tillgänglighet ändras ofta, och överväg att implementera automatiserad validering i din distributionspipeline.
