Strukturerad data hjälper sökmotorer och andra system att förstå vad innehållet på en sida representerar. Med rätt Schema.org-vokabulär och JSON-LD kan ni beskriva exempelvis organisationer, produkter, artiklar och brödsmulor på ett maskinläsbart sätt.
Det är inte ett fristående kodprojekt. Hållbar märkning börjar med sidans verkliga innehåll, kopplas till rätt datakällor och följs upp när mallar, produktinformation och Googles stöd förändras. Vi på TribuSoft arbetar med hela kedjan, från datamodell och implementation till validering och löpande förvaltning.
Strukturerad data är standardiserad information som beskriver innehållet på en webbsida med tydliga typer och egenskaper. Den fungerar som uttryckliga ledtrådar till sökmotorer om vilka entiteter sidan handlar om, till exempel en produkt, ett företag eller ett evenemang.
Begreppen används ofta som om de vore synonymer, men de fyller olika funktioner. Att skilja dem åt gör det enklare att välja rätt lösning och felsöka när något inte fungerar som planerat.
Korrekt märkning kan göra det lättare för sökmotorer att tolka fakta, entiteter och relationer på sidan. Den kan också göra en sida berättigad till Googles aktuella sökfunktioner med utökad presentation.
Strukturerad data är däremot ingen garanti för högre placeringar, fler klick eller visning av ett rich result. Google avgör presentationen utifrån bland annat sökfråga, innehåll, enhet, plats och användarupplevelse. Märkningen ersätter inte relevant innehåll eller väl utförd On-page SEO för relevanta och väloptimerade sidor.
Schema.org omfattar en bred datamodell. En typ eller egenskap kan därför vara helt giltig enligt Schema.org utan att Google använder den för någon särskild sökfunktion.
Vi utgår alltid från två frågor: Vilken information beskriver sidan sanningsenligt, och vilken konsument ska använda datan? För Googles rich results är Googles aktuella krav styrande. För bredare semantik kan Schema.org-vokabulären ge ett större utrymme.
Google kan hantera JSON-LD, Microdata och RDFa. JSON-LD är normalt förstahandsvalet när webbplatsens tekniska lösning tillåter det, eftersom märkningen kan hållas separat från sidans presentation och ofta blir enklare att implementera, granska och förvalta.
Det betyder inte att befintlig Microdata eller RDFa alltid måste byggas om. Valet bör utgå från webbplatsens arkitektur, datakällor och möjligheten att hålla märkningen korrekt över tid.
Börja inte med en lista över populära schematyper. Börja med sidan. Identifiera dess huvudinnehåll, den viktigaste entiteten och de fakta som besökaren faktiskt kan se. Välj därefter den mest specifika typ som passar innehållet och den funktion ni vill stödja.
En tjänstesida för ett B2B-företag behöver inte automatiskt Product-märkning. En verksamhet med en adress behöver inte automatiskt vara en LocalBusiness i den aktuella sidans data. Typvalet måste spegla verksamheten, sidans syfte och den information som visas för användaren.
Vi rekommenderar en enkel arbetsordning: sida och synligt innehåll, huvudentitet, relevant Schema.org-typ, aktuell konsument eller sökfunktion, egenskaper, datakälla, implementation, testning och övervakning.
Den processen minskar risken för generisk plugin-data och märkning som blir frikopplad från webbplatsens faktiska information. Den gör också ansvarsfördelningen tydligare mellan marknad, e-handel, utveckling och innehållsteam.
Schema.org har inte en universell lista med obligatoriska egenskaper för varje typ. Kraven varierar med syftet. När ni vill stödja en specifik Google-funktion måste däremot Googles obligatoriska egenskaper finnas med.
Rekommenderade egenskaper kan göra datan mer komplett. Men korrekt och relevant data är alltid bättre än ett stort, ofullständigt objekt. Lägg aldrig in information som saknas på sidan, är felaktig eller inte längre stämmer.
Ett JSON-LD-block beskriver objekt och deras egenskaper. @context anger den vokabulär som används, vanligtvis https://schema.org. @type anger vilken typ av objekt som beskrivs. Egenskaper som name, url och description fyller sedan objektet med faktiska uppgifter.
@id ger en entitet en stabil identifierare. Det är särskilt användbart när samma organisation, författare eller produkt ska refereras från flera objekt. Då kan ni koppla samman datan utan att skapa olika och potentiellt motstridiga kopior.
Nedan visar ett förenklat exempel på hur ett företag, en webbplats och en webbsida kan beskrivas utan att organisationens uppgifter dupliceras i flera block. Exemplet ska anpassas till er faktiska webbplats och dess synliga innehåll.
”`html<script type=”application/ld+json”>{ ”@context”: ”https://schema.org”, ”@graph”: [ { ”@type”: ”Organization”, ”@id”: ”https://example.se/#organization”, ”name”: ”Exempelföretaget AB”, ”url”: ”https://example.se/” }, { ”@type”: ”WebSite”, ”@id”: ”https://example.se/#website”, ”url”: ”https://example.se/”, ”name”: ”Exempelföretaget” }, { ”@type”: ”WebPage”, ”@id”: ”https://example.se/tjanster/#webpage”, ”url”: ”https://example.se/tjanster/”, ”name”: ”Tjänster”, ”isPartOf”: { ”@id”: ”https://example.se/#website” }, ”publisher”: { ”@id”: ”https://example.se/#organization” } } ]}</script>”`
För en produktsida måste Product-data beskriva just den produkt som användaren ser. Pris, valuta och tillgänglighet ska vara konsekventa med sidans synliga erbjudande och uppdateras när produktdatan förändras.
”`html<script type=”application/ld+json”>{ ”@context”: ”https://schema.org”, ”@type”: ”Product”, ”name”: ”Exempelprodukt”, ”image”: ”https://example.se/images/exempelprodukt.jpg”, ”description”: ”Produktbeskrivning som också finns på sidan.”, ”sku”: ”EX-123”, ”offers”: { ”@type”: ”Offer”, ”url”: ”https://example.se/produkt/exempelprodukt/”, ”priceCurrency”: ”SEK”, ”price”: ”899.00”, ”availability”: ”https://schema.org/InStock” }}</script>”`
En hållbar implementation skapas helst i CMS:ets mallar, komponenter eller serverrenderade output. Då kan märkningen kopplas till samma fält som visar produktnamn, pris, lagerstatus, publiceringsdatum och annan information på sidan.
JSON-LD kan även genereras med JavaScript och Google kan bearbeta märkning som finns i den renderade DOM:en. För affärskritiska och snabbt föränderliga uppgifter är en stabil servergenererad eller väl synkroniserad lösning ofta mer robust. Särskilt produktpris och tillgänglighet kräver tät koppling till produktkällan.
En sida kan innehålla flera relevanta objekt. En artikel kan exempelvis kopplas till en författare och en utgivare. En produktsida kan innehålla en Product, ett Offer och synliga brödsmulor.
Målet är inte största möjliga datagraf. Målet är en korrekt och underhållbar modell. Kontrollera därför alltid om CMS, tema eller tillägg redan genererar samma typ innan ny kod läggs till.
Strukturerad data är en del av vårt arbete med Teknisk SEO för crawlning, indexering och prestanda, men fokus här är semantisk märkning.
Märkningen måste också stämma med det synliga sidinnehållet och den presentation som användaren möter. Det gör den till ett naturligt komplement till On-page SEO för relevanta och väloptimerade sidor.
Validering handlar om mer än att JSON-koden är syntaktiskt korrekt. Ni behöver kontrollera både att Schema.org-grafen beskriver rätt entiteter och att märkningen uppfyller Googles krav när ni riktar er mot en specifik rich-result-funktion.
Vi kvalitetssäkrar den renderade sidan, inte bara ett kodutkast. Det fångar fel som uppstår i CMS-mallar, JavaScript, cachelager eller produktflöden efter att utvecklingen är klar.
Fel betyder normalt att krav för en identifierad funktion inte är uppfyllda och bör rättas. Varningar betyder ofta att rekommenderad information saknas. Prioritera dem utifrån betydelse, datatillgång och risk för felaktiga värden.
Att ett testverktyg inte hittar någon Google-stödd funktion innebär inte alltid att Schema.org-datan är ogiltig. Det kan också betyda att typen inte är kopplad till ett aktuellt Google-rich-result eller att sidan saknar de egenskaper som krävs för funktionen.
Använd checklistan som ett sista kvalitetstest före publicering och efter större ändringar i CMS, tema, produktflöde eller design.
Strukturerad data är en del av webbplatsens informationsarkitektur och behöver förvaltas därefter. En implementation som är korrekt vid lansering kan få problem när innehållsfält ändras, nya sidmallar införs eller produktdatan byter källa.
Följ relevanta rich-result-rapporter i Search Console när Google har upptäckt den aktuella typen. Kontrollera också ett representativt urval av URL:er efter större releaser. Vid mallbaserade fel kan Search Consoles valideringsfunktion användas för att följa Googles kontroll av rättningen.
FAQPage finns kvar som Schema.org-typ, men Google visar inte längre FAQ-rich-results i Google Search. Den bör därför inte implementeras med förväntningen att skapa en FAQ-accordion i Googles sökresultat.
Strukturerad data gör fakta och relationer tydligare för maskiner. Det kan vara värdefullt i en bredare semantisk strategi. Däremot finns det inte stöd för att lova att viss Schema.org-märkning ger citeringar eller synlighet i AI Overviews, ChatGPT, Gemini eller andra generativa tjänster.
Hos oss på TribuSoft ser vi strukturerad data som en koppling mellan SEO, webbutveckling och affärsdata. Vi inventerar befintlig märkning, väljer relevanta typer, mappar egenskaper mot tillförlitliga datakällor och implementerar JSON-LD på ett sätt som fungerar i era mallar och publiceringsflöden.
Vi hjälper etablerade B2B- och B2C-företag, e-handlare och retailverksamheter med både nya implementationer och felsökning av befintliga lösningar. Arbetet kan omfatta allt från en avgränsad produktmall till kvalitetssäkring av en större webbplats före eller efter en förändring.
Nej. Schema.org är vokabulären med typer och egenskaper. JSON-LD är ett format som används för att publicera den informationen på webbsidan.
Strukturerad data ska inte ses som en garanti för högre placeringar. Den kan ge Google tydligare information om innehållet och göra sidan berättigad till relevanta sökfunktioner, men resultatet varierar.
Godkänd märkning innebär behörighet, inte garanterad visning. Google väljer presentation utifrån sökfråga, enhet, plats, innehåll och andra faktorer i sökresultatet.
JSON-LD kan behandlas även när det ligger i body. En konsekvent implementation i head eller i mallarnas renderade output gör ofta lösningen enklare att förvalta.
Ja, men pluginet måste kontrolleras. Det kan generera generiska typer, sakna viktiga egenskaper eller skapa dubbletter tillsammans med tema och egen kod.
Google kan hantera alla tre formaten. JSON-LD är ofta det mest praktiska valet eftersom märkningen kan hållas separat från sidans presentation, men rätt val beror på er tekniska lösning och hur datan kan förvaltas.
Använd Schema.org Markup Validator för att kontrollera vokabulär, syntax och datagraf. Använd Google Rich Results Test för Googles stödda rich results. Följ sedan upp publicerade sidor i Search Console och vid behov Bing Webmaster Tools.
Vi hjälper er att göra Schema.org till en hållbar del av webbplatsen, från typval och datamappning till JSON-LD, validering och förvaltning.
Få en kostnadsfri offert eller inled en dialog med oss om företagets tillväxt.
