Strukturerad data: vilken en företagswebbplats verkligen behöver
Strukturerad data är ingen rankningsfaktor. Den är en översättning: den talar om för maskiner vad ett textavsnitt betyder i stället för att låta dem gissa. Just det avgör i allt högre grad om en sida över huvud taget förekommer i svar.
Det viktigaste
- Fyra typer räcker för nästan varje företagssida: Organization, WebPage respektive Article, BreadcrumbList och FAQPage.
- Det som levereras är JSON-LD i
<head>– inte som märkning i den löpande texten. - Det vanligaste felet är tyst och dyrt: uppgifter i den strukturerade datan som inte står på själva sidan.
- Tre mycket omdiskuterade typer kan ett tjänsteföretag hoppa över – de biter bara med passande erbjudande eller äkta omdömen.
En maskin som läser en sida ser till att börja med bara text. Att «Emma Woelk» är en människa, «TEISENDA GmbH» ett företag och «22 augusti 2026» ett publiceringsdatum måste den gissa sig till – eller så står det uttryckligen där.
Strukturerad data är den uttryckliga tillvaron. Den förbättrar ingen placering. Den avgör om en sida över huvud taget kommer i fråga för utökade visningar och för genererade svar.
De fyra som räcker
1. Organization – en gång, på startsidan
Vilka ni är: namn, adress, logotyp, grundningsår, profiler i andra nätverk. Det är den post som gör att en logotyp kan visas bredvid sökresultatet – det vanligaste skälet till att den saknas är helt enkelt att posten inte finns.
Viktigt: Logotypen måste finnas som rasterbild. En SVG utvärderas inte på det här stället.
2. WebPage eller Article – på varje sida
Vad den här sidan är: titel, beskrivning, språk, datum för publicering och senaste bearbetning. Vid inlägg dessutom Article respektive BlogPosting med författaren som egen Person-post – med roll, inte bara med namn.
Viktigt: Ändringsdatumet måste stämma. Ett datum som sätts om vid varje sidvisning är en signal som gör sig själv värdelös.
3. BreadcrumbList – på alla undersidor
Var den här sidan står i strukturen. Synlig som en stig högst upp på sidan, maskinläsbar i huvudet. De två hör ihop – en stig i datan som inte finns på sidan är en felaktig uppgift.
4. FAQPage – där det finns äkta frågor
Frågeavsnittet i slutet av ett inlägg. För svarsmaskiner den värdefullaste typen över huvud taget, eftersom den levererar fråga och svar redan som par – exakt den form som citeras.
Viktigt: Endast för frågor som faktiskt syns på sidan. Påhittade frågor som bara står i datan är ett brott mot riktlinjerna.
Tre som man kan hoppa över
Product och Offer. För tjänster med pris på förfrågan ger de ingenting – utan pris och tillgänglighet visas de ändå inte. Meningsfulla först vid en riktig butik.
AggregateRating. Stjärnor i sökresultatet är lockande och knutna till stränga villkor: omdömena måste vara äkta, kontrollerbara och synliga på sidan. Självutdelade omdömen är ett riktlinjebrott med verklig risk.
HowTo. Har dragits tillbaka betydligt i visningen och är för de flesta företagssidor inte längre värd skötselinsatsen.
Visste du att…?
Strukturerad data är ingen rankningsfaktor – det har Google klargjort flera gånger. Den avgör visningen, inte positionen.
För svarsmaskiner ligger saken något annorlunda. En modell som ska bygga ett svar ur en sida använder helst det som är entydigt märkt: fråga-svar-par, författare med roll, datum för senaste kontroll. Den behöver då inte gissa vad som hör ihop. Nyttan ligger alltså mindre i rankningen än i citerbarheten.
Hur de byggs in
Tre regler som undviker de flesta problemen.
- JSON-LD, i
<head>. Inte som attribut i den löpande texten. JSON-LD går att sköta skilt från layouten och går inte förlorat vid ändringar i formgivningen. - Ett block per sida, inte fem. Flera poster hör hemma i en
@graphoch knyts samman via@id. Så hänvisar inlägget till samma organisation som står på startsidan i stället för att upprepa den. - Skapa dem ur samma källa som det synliga innehållet. Om titel, datum och författare kommer ur samma fält som sidan själv kan de omöjligt gå isär. Det är den verksammaste förebyggande åtgärden över huvud taget.
Det dyraste felet är det tystaste: den strukturerade datan säger något som inte står på sidan. Ett ändringsdatum från i går vid en text från 2023. En författare som inte förekommer i det synliga området. Frågor i datan som inte finns på sidan.
Det märker inget kontrollverktyg – datan är formellt giltig. Det märks vid en manuell granskning, och då gäller följden inte bara den berörda märkningen. Därför är regeln «skapa ur samma källa» viktigare än all fullständighet.
Kontrollera – i den här ordningen
| Steg | Med vad | Vad ni ser |
|---|---|---|
| 1. Syntax | Schema Markup Validator | Om JSON-koden är giltig och typen korrekt |
| 2. Visningsbarhet | Testet för utökade sökresultat | Om en utökad visning vore möjlig |
| 3. Verkligheten | Search Console, avsnittet Förbättringar | Vad som faktiskt identifierades, över alla sidor |
| 4. Överensstämmelse | Läsa själv | Om varje uppgift också står synligt på sidan |
Steg fyra är det enda som inget verktyg tar över – och det enda där de allvarliga felen upptäcks.
Granska den här sidans strukturerade data med avseende på fullständighet och på överensstämmelse med det synliga innehållet. Synligt sidinnehåll: [Klistra in sidans text] Sidans JSON-LD: [Klistra in blocket] Uppgifter: 1. Nämn varje uppgift i JSON-LD som inte förekommer i det synliga innehållet. Det är den viktigaste punkten – var grundlig här. 2. Nämn varje synlig uppgift som borde märkas upp, men som saknas (författare med roll, ändringsdatum, frågor, stig). 3. Kontrollera om de fyra grundtyperna är vettigt besatta: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nämn typer i blocket som för ett tjänsteföretag utan butik och utan kontrollerbara omdömen inte har någon nytta. 5. Påpeka varje brott mot riktlinjerna, särskilt självutdelade omdömen och frågor som inte finns på sidan. Skriv ut den rättade JSON-LD-koden i sin helhet på slutet. Hitta inte på värden – märk det som saknas som [att komplettera].
Slutsats
Strukturerad data överskattas snabbt och görs lika snabbt fel. Fyra typer täcker en företagssidas behov, och deras nytta ligger mindre i positionen än i att vara citerbar.
Den enda regel som bär allt: märk inte upp något som inte står på sidan. Den som skapar datan ur samma källa som det synliga innehållet har löst det problemet strukturellt – och kan i stort sett hoppa över efterkontrollerna.
Vanliga frågor
Vilken strukturerad data behöver en företagswebbplats?
Fyra typer räcker: Organization en gång på startsidan, WebPage respektive Article på varje sida, BreadcrumbList på alla undersidor och FAQPage överallt där det finns äkta, synliga frågor. Product, AggregateRating och HowTo lönar sig i regel inte för tjänsteföretag.
Förbättrar strukturerad data rankningen?
Nej. Den är ingen rankningsfaktor, utan avgör visningen – till exempel om en logotyp, en stig eller utfällbara frågor kan visas i sökresultatet. För svarsmaskiner ökar den citerbarheten, eftersom fråga-svar-par, författare och datum är entydigt märkta i stället för att behöva gissas.
Varför visar Google inte vår logotyp?
Det vanligaste skälet är en saknad eller ofullständig Organization-post på startsidan. Det näst vanligaste skälet: den angivna logotypen finns bara som SVG – på det här stället behövs ett rasterbild. Även vid korrekt märkning finns ingen rätt till visning.
Vad är det vanligaste felet i strukturerad data?
Uppgifter som står i datan men inte i det synliga innehållet: ett felaktigt ändringsdatum, en författare som inte nämns, påhittade frågor. Kontrollverktyg rapporterar det inte, eftersom datan är formellt giltig. Det går att undvika genom att märkningen skapas ur samma källa som den synliga texten.
JSON-LD eller Microdata?
JSON-LD i <head>. Det är den form Google rekommenderar, går att sköta skilt från layouten och går inte förlorad vid ändringar i formgivningen. Microdata sprider märkningen över den löpande texten och går sönder vid varje ombyggnad av sidan.
Marknadsföring som sätter upp sig själv
Betan för Studio Engine är öppen. Säkra din plats och var med och forma den från början.
Delta i betan →