SEO / GEO
Vad är strukturerad data?
Strukturerad data är maskinläsbar information som beskriver vad en sida och dess entiteter redan är — i en form ett system kan läsa utan att tolka brödtexten. Hos Nexitas publiceras den som JSON-LD med vokabulär från schema.org. Den förklarar innehåll som finns; den skapar inga fakta och beställer inga resultat.
Begrepp
Tre begrepp som ofta blandas ihop
Strukturerad data
Själva idén: att beskriva innehållets betydelse i en form som är avsedd att läsas av system i stället för att tolkas ur brödtexten. Det är samlingsbegreppet, inte en specifik teknik.
Schema.org
Vokabulären. Den definierar vilka typer och egenskaper som finns att beskriva något med — Organization, WebSite, Service, BreadcrumbList, FAQPage och många fler. Den säger vad orden betyder, inte hur de publiceras.
JSON-LD
Ett av flera format för att publicera beskrivningen på en sida. Det är serialiseringen — alltså formen — inte vokabulären. Nexitas publicerar sin strukturerade data som JSON-LD.
De tre orden används ofta som synonymer, men de sitter på olika nivåer: idén, vokabulären och formatet. Att hålla isär dem gör det lättare att avgöra vad ett problem faktiskt beror på — fel typ, fel uppgift eller fel publicering.
Entiteter och stabila namn
En entitet är något som går att peka ut och skilja från annat: ett företag, en produkt, en tjänst, en plats. Nexitas är en entitet. Nx Guard är en annan. SEO/GEO-tjänsten är en tredje.
Problemet uppstår när samma sak beskrivs olika på olika ställen. Ett produktnamn som stavas på tre sätt, en tjänst som kallas något annat i metadata än i rubriken, ett gammalt namn som ligger kvar i uppmärkningen — varje sådan variant är en möjlig tolkning av att det rör sig om olika saker.
Därför används en stabil identifierare. I JSON-LD kan en nod få ett @id, och andra noder kan hänvisa till exakt den identifieraren i stället för att beskriva entiteten på nytt. Det är en mekanism för konsekvens — inte en signal som i sig påverkar placeringar.
Funktion
Vad strukturerad data gör
Namnger typen explicit
I stället för att ett system ska härleda ur texten att en sida beskriver en tjänst, står det uttryckligen att det är en tjänst.
Gör relationer läsbara
En tjänst kan peka ut vem som tillhandahåller den, och en webbplats vem som publicerar den, i stället för att sambandet bara antyds i copy.
Knyter sidnoder till en stabil identitet
Sidspecifika beskrivningar kan hänvisa till samma organisation via en fast identifierare, i stället för att beskriva den på nytt varje gång.
Gör svar strukturellt åtkomliga
Ett besvarat spörsmål blir en fråga och ett svar som hör ihop, i stället för två textstycken som råkar stå efter varandra.
Minskar tvetydighet
När uppmärkningen och den synliga sidan säger samma sak finns det färre rimliga tolkningar av vad sidan handlar om. Det är hjälp med förståelse, inte med placering.
Vad strukturerad data inte gör
Uppmärkning är en beskrivning, inte en åtgärd. Den lagar inte svagt innehåll, gör inte en blockerad URL åtkomlig och åsidosätter varken robots.txt eller en WAF-policy. Den ersätter inte heller canonical: vilken URL som är huvudversionen avgörs fortfarande av canonical, omdirigeringar och intern länkning.
Den garanterar inte indexering och inte placering. Den garanterar inte heller en rich result — korrekt uppmärkning kan göra en sida berättigad till en sökfunktion, men Google beskriver uttryckligen berättigande som något annat än en utlovad visning. Och den beställer ingen citering i ett AI-genererat svar.
Slutligen: uppmärkning ska inte innehålla påståenden som besökaren inte kan se. Markup som beskriver något dolt är inte en genväg utan ett kvalitetsproblem — och en risk för att uppmärkningen ignoreras helt.
I praktiken
Så använder Nexitas strukturerad data
Principen är att uppmärkningen hör hemma där entiteten hör hemma. Ingen sida beskriver allt, och ingen entitet beskrivs på alla sidor.
På webbplatsnivå finns två noder som gäller hela siten: organisationen och själva webbplatsen. Webbplatsnoden pekar ut organisationen som utgivare genom att hänvisa till dess identifierare i stället för att upprepa uppgifterna.
På produkt- och tjänstenivå beskrivs entiteten bara på sin egen definierande sida. SEO/GEO-tjänsten beskrivs på tjänstesidan, och Nx Guard beskrivs som en webbapplikation på sin produktsida. Båda anger organisationen som leverantör via samma identifierare. Det är alltså en hänvisning mellan noder, inte en inbyggd hierarki: noderna delar en stabil identitet, de innehåller inte varandra.
På sidnivå tillkommer sammanhang och svar. Sidor som ligger i en hierarki publicerar en brödsmulelista som beskriver var de sitter, och sidor med en synlig frågedel publicerar en FAQ-nod som motsvarar exakt de frågorna. Ingen av dem knyts till organisationen — de beskriver sidan, inte företaget.
Den här sidan följer samma regel. Den publicerar en brödsmulelista och en FAQ-nod, men beskriver sig inte som en tjänst eller en produkt — den förklarar ett ämne, den är inte ett erbjudande.
Källor
Google Search Central: Introduction to structured data markup
Förklarar strukturerad data som explicita ledtrådar om sidans betydelse och kräver att uppmärkningen beskriver synligt innehåll; berättigande till en rich result är inte en garanti för visning.
Läs den officiella dokumentationenGoogle Search Central: AI features and your website
Anger att de vanliga SEO-grunderna gäller för AI Overviews och AI Mode, att sidan måste vara indexerbar och att varken indexering eller visning är garanterad.
Läs den officiella dokumentationenSynligt innehåll och maskinlager måste stämma överens
Den viktigaste regeln är också den enklaste: uppmärkningen ska beskriva det en besökare kan läsa. Ett maskinlager som säger något annat än sidan är inte en extra kanal — det är en motsägelse, och den som upptäcker den har goda skäl att lita mindre på båda.
Det går att bygga bort risken i stället för att kontrollera den i efterhand. Nexitas frågedelar hämtar sina frågor och svar ur en enda källa i sidan: samma uppsättning renderas som synlig text och som FAQ-uppmärkning. Det finns ingen andra uppsättning svar att hålla synkroniserad, så uppmärkningen kan inte glida ifrån innehållet.
Samma resonemang gäller allt annat som beskrivs maskinläsbart. Om en uppgift inte går att visa för en besökare hör den inte hemma i uppmärkningen heller.
Strukturerad data och GEO
Strukturerad data hör hemma i GEO-arbetet, men inte som en spak att dra i. Den är ett maskinläsbart lager som gör det tydligare vilken entitet en sida handlar om och hur den förhåller sig till andra — och tydlighet är svårare att förvanska när något sammanfattas.
Men generativa system använder många olika sätt att hitta, välja och väga källor, och de redovisar dem inte. Ingen uppmärkning avgör om en modell hämtar en sida, litar på den eller refererar till den. Det finns heller ingen särskild AI-typ i schema.org som ger tillträde till AI-genererade svar.
Rimligt att förvänta sig är alltså det mindre men verkliga: att beskrivningen av er går att läsa maskinellt, att den är entydig och att den inte motsäger sidan. Inte att uppmärkningen köper en plats i något svar.
Vanliga fel
De flesta problem vi ser handlar inte om avancerad schema-teknik. De handlar om att uppmärkningen och verkligheten har glidit isär:
- Uppmärkning som beskriver något som inte går att se på sidan.
- Ett tidigare produkt- eller företagsnamn som ligger kvar i markup efter en namnändring.
- Flera sidor som gör anspråk på samma entitet utan att någon av dem är den utpekade källan.
- Kopierad markup med egenskaper som inte gäller den aktuella sidan.
- Organisationen beskriven med olika uppgifter på olika sidor, så att beskrivningarna motsäger varandra.
- Betyg, priser eller erbjudanden som läggs till utan att det finns någon synlig grund för dem.
- FAQ-markup som säger något annat än det svar besökaren faktiskt läser.
- Markup som används som ersättning för crawl- och indexeringsgrunden i stället för som komplement till den.
En sak är värd att skilja på: att samma nodtyp förekommer på flera sidor är inte i sig ett fel — webbplatsomfattande entiteter ska finnas överallt de gäller. Problemet är motstridiga eller onödiga beskrivningar, alltså att uppgifterna skiljer sig åt eller upprepas där de inte tillför något.
Vanliga frågor om strukturerad data
Vad är skillnaden mellan schema.org och JSON-LD?
Schema.org är vokabulären — den definierar typerna och egenskaperna, till exempel Organization, Service och FAQPage. JSON-LD är ett av flera format för att publicera den beskrivningen på en sida. Vokabulär och format är alltså två olika saker, och orden är inte utbytbara.
Vad är en entitet i sök?
En entitet är något som går att peka ut och skilja från annat — ett företag, en produkt, en tjänst eller en plats. Poängen med att beskriva den maskinläsbart är att samma sak ska kunna kännas igen som samma sak, även när den nämns på flera sidor och i flera format.
Påverkar strukturerad data rankningen?
Inte som en direkt rankningsfaktor. Uppmärkningen gör sidans betydelse explicit och kan göra en sida berättigad till vissa sökfunktioner, men den ersätter inte innehållets kvalitet eller den tekniska grunden. Att lägga till markup på en sida som inte går att nå eller inte svarar på frågan förändrar ingenting.
Garanterar strukturerad data rich results?
Nej. Korrekt uppmärkning kan göra en sida berättigad att visas med en viss sökfunktion, men Google beskriver uttryckligen berättigande som något annat än en garanti för visning. Vad som faktiskt visas avgörs vid varje sökning.
Måste strukturerad data matcha det som syns på sidan?
Ja. Uppmärkningen ska beskriva innehåll som en besökare faktiskt kan se, och den får inte tillföra påståenden som sidan inte gör. Markup som beskriver något dolt är både ett kvalitetsproblem och en risk för att uppmärkningen ignoreras.
Hjälper strukturerad data GEO?
Den kan bidra, men den styr ingenting. Strukturerad data är ett maskinläsbart lager som minskar tvetydighet om vad en sida beskriver. Generativa system använder många olika sätt att hämta och välja källor, och ingen uppmärkning avgör om en modell hämtar, litar på eller citerar en sida.
Vad är @id i JSON-LD?
En stabil identifierare för en nod, så att andra noder kan hänvisa till exakt samma entitet i stället för att beskriva den på nytt. Nexitas använder till exempel en fast identifierare för organisationen som tjänste- och produktsidorna refererar till. Det är en konsekvensmekanism, inte en rankningssignal.
Läs vidare
SEO och GEO hos Nexitas
Pillarsidan: vad arbetet omfattar, hur vi granskar den tekniska grunden och vad som inte lovas.
Vad är GEO?
Begreppet i sin helhet: mekanismen, arbetets delar, åtkomstkedjan och vad som går att mäta.
SEO vs GEO
Jämförelsen: den gemensamma grunden, var disciplinerna skiljer sig och varför mätningen skiljer sig mest.
Stämmer er uppmärkning med sidan?
Hör av er så går vi igenom vad som är indexerat, hur era produkter och tjänster beskrivs och vad som är rimligt att börja med.
Kontakta oss