Vad är schema markup och vad beskriver det?
Schema markup är strukturerad data som använder typer och egenskaper från Schema.org för att beskriva innehåll och relationer. Den kan exempelvis ange att en sida handlar om en organisation, en produkt eller en artikel. Beskrivningen ska motsvara verkligt innehåll och faktiska förhållanden, inte lägga till meriter eller erbjudanden som saknas.
Skilj på sidans dokument och det som dokumentet beskriver. En WebPage kan handla om en Product, vara del av en WebSite och publiceras av en Organization. Genom identifierare kan samma organisation återanvändas utan att modelleras som flera olika aktörer. Detta är en semantisk modell, inte en anledning att fylla varje sida med alla typer som finns. Välj det som hjälper till att beskriva sidans huvudsakliga innehåll korrekt.
Gör först en inventering av sidmallarna. Lista vilka verkliga entiteter varje mall presenterar, var uppgifterna hämtas och vem som kan intyga att de stämmer. En artikelmall har andra behov än en kategori med flera produkter. Dokumentera skillnaderna innan utvecklingen börjar. Då blir det lättare att undvika att ett plugin eller en gemensam komponent lägger samma felaktiga produkttyp på webbplatsens startsida, kontaktsida och guider.
Vad är skillnaden mellan giltigt schema och utökade resultat?
Giltigt schema betyder att strukturen följer relevanta syntaxregler och kan använda Schema.orgs begrepp korrekt. Behörighet för en viss Google-funktion kräver dessutom stöd för typen, obligatoriska uppgifter och efterlevnad av särskilda riktlinjer. Även när samtliga krav uppfylls avgör Google om presentationen används. Strukturerad data garanterar därför aldrig automatiskt utökade sökresultat för sidan.
En sida kan ha korrekt Service-markup utan att den typen ger en särskild fristående tjänstepresentation i Googles resultat. På samma sätt kan en korrekt beskrivning av organisationen hjälpa till med förståelse utan att leda till ett synligt tillägg. Sätt därför mål som går att verifiera: rätt modell, rätt innehåll och fungerande underhåll. Använd inte frånvaron av en dekorativ presentation som enda bevis på att implementationen har misslyckats.
Kontrollera alltid aktuell dokumentation för den sökfunktion ni faktiskt vill stödja. Schema.org har fler typer och egenskaper än Google använder för sina särskilda funktioner, och stödet kan ändras. Dokumentera vilken källa som kontrollerades och vid vilket datum. Om en funktion begränsas eller avvecklas ska teamet kunna skilja det från ett eget tekniskt fel och besluta om markeringen fortfarande fyller ett semantiskt syfte.
Hur väljer man rätt typer för organisation och webbplats?
Välj Organization för en organisation och en mer specifik undertyp när den faktiskt stämmer med verksamheten. LocalBusiness passar en verklig lokal verksamhet, inte automatiskt varje geografisk landningssida. WebSite beskriver webbplatsen som helhet och WebPage en enskild sida. Använd stabila identifierare för att visa hur dessa objekt hör samman utan dubbla identiteter.
Utgå från verifierbara uppgifter: namn, webbadress, logotyp och relevanta kontaktvägar. Om en specifik verksamhetsplats beskrivs behöver adress och övriga detaljer motsvara den verkliga platsen. Skapa inte påhittade kontor för orter där företaget endast erbjuder distansleverans. När flera riktiga enheter finns behöver modellen kunna skilja deras identiteter, adresser och relation till huvudorganisationen. En gemensam webbplats innebär inte att alla verksamhetsställen är samma objekt.
Använd exempelvis en stabil identifierare med ett fragment för organisationen och referera till den från sidornas publisher när relationen stämmer. Exakta fältnamn ska implementeras enligt vald typ och aktuell dokumentation. sameAs bör peka på relevanta identitetssidor, inte en samling externa artiklar som råkar nämna företaget. Kontrollera särskilt att namn, logotyp och adresser inte skiljer sig mellan synligt innehåll, strukturerad data och företagets förvaltade profiler.
När passar Article och hur används datum och författare?
Article och dess relevanta undertyper passar redaktionellt innehåll som faktiskt är artiklar. Ange en verklig rubrik, ansvarig författare och datum som motsvarar publicering och meningsfull uppdatering. Författaren kan vara en person eller organisation enligt modellens förutsättningar. Ändra inte datum enbart för att få gammalt innehåll att framstå som nyligen granskat.
Koppla författaren till en sida där läsaren kan förstå avsändarens roll när en sådan sida finns. Beskriv inte en redaktör som ämnesexpert om det saknas stöd. Skilj gärna mellan skrivande och sakgranskning i det synliga innehållet, men välj endast egenskaper som faktiskt stöds av den modell ni implementerar. En detaljerad författarbeskrivning kan inte kompensera för en artikel som innehåller felaktiga råd eller saknar underbyggda resonemang.
Hämta datum och rubrik från samma källa som används i sidans presentation. Om en revidering ändrar viktiga råd bör datumModified uppdateras enligt en dokumenterad redaktionell rutin. En rättning av ett blanksteg behöver inte beskrivas som en omfattande innehållsrevision. Testa även tidszon och format. Importer mellan publiceringssystem kan annars flytta datum eller återställa alla artiklar till importdagen, vilket skapar en missvisande historik.
Hur modellerar man produkter, erbjudanden och recensioner korrekt?
Product ska beskriva en verklig produkt, och Offer ska innehålla aktuella uppgifter om ett faktiskt erbjudande. Pris, valuta, tillgänglighet och identifierare behöver stämma med sidan och relevanta krav. Recensioner och sammanfattade betyg får inte fabriceras. Behörighet för produktrelaterade sökfunktioner beror på innehållet, sidtypen och de särskilda riktlinjer som gäller för funktionen.
Börja med skillnaden mellan en produktdetaljsida och en kategorisida. En lista över flera produkter ska inte utan vidare beskrivas som en enda produkt med ett sammanslaget pris. Varianter behöver modelleras så att produktrelationer och erbjudanden blir begripliga. Kontrollera hur systemet hanterar slut i lager, reapriser och val av variant. Ett cachat JSON-LD-block kan bli fel även när den synliga prislappen har uppdaterats korrekt i gränssnittet.
För recensioner behöver det vara tydligt vad som bedöms, vem som lämnat omdömet och hur det presenteras. Skapa inte AggregateRating genom att räkna rekommendationer eller interna kvalitetsbetyg som kundrecensioner. Självbetjänande omdömen om den egna organisationen eller lokala verksamheten omfattas av särskilda begränsningar för Googles recensionspresentation. En extern recensionswidget gör inte automatiskt en sådan sida behörig. Bedöm den aktuella typen och funktionen separat innan ni publicerar markeringen.
När kan FAQPage, QAPage och brödsmulor användas?
FAQPage beskriver frågor där webbplatsen tillhandahåller svar, medan QAPage avser en sida fokuserad på en fråga där användare kan bidra med svar. Googles FAQ-presentation är begränsad till vissa välkända auktoritativa myndighets- och hälsowebbplatser. BreadcrumbList beskriver en verklig navigationshierarki. Ingen av typerna ska användas som en generell genväg till större sökresultat för företag.
En kommersiell guide kan alltså ha en användbar FAQ utan att vara behörig för Googles särskilda FAQ-presentation. Skriv frågorna för läsaren och håll svaren åtkomliga på sidan. Använd inte QAPage bara för att artikeln råkar ha ett frågetecken i rubriken. Avgör först om sidans verkliga funktion är en användarbaserad frågesida. Modellvalet ska beskriva innehållet, inte efterlikna en funktion vars krav inte är uppfyllda.
Brödsmulor behöver visa begripliga nivåer och rätt destinationer. De ska inte bli en alternativ lista med prioriterade sökord. Kontrollera positioner, namn och adresser när kategorier byter struktur. En sida kan ibland ha flera relevanta vägar, men modellen måste förbli tydlig och stämma med dokumenterade navigationsbeslut. Användaren ska förstå var sidan hör hemma utan att behöva läsa den strukturerade datan eller känna till företagets interna innehållsplan.
Hur implementerar man JSON-LD utan dubbla uppgifter?
Implementera JSON-LD från samma tillförlitliga datakällor som bygger sidans synliga innehåll. Samla ansvar för varje objekt och använd stabila identifierare när flera block beskriver samma entitet. Granska samtidigt teman, plugins och tagghantering. Flera tekniskt giltiga block kan tillsammans skapa motsägande priser, organisationsnamn eller sidtyper som behöver rättas innan publicering sker.
JSON-LD placeras i ett script-element med typen application/ld+json och behöver vara giltig JSON. Det innebär bland annat korrekta citationstecken, inga kommentarer och korrekt hantering av specialtecken. Använd säkra serialiseringsfunktioner i utvecklingen i stället för att bygga långa textsträngar manuellt. Håll schemaobjekten nära den källa där informationen förvaltas så att uppdateringar av produkter och redaktionella uppgifter inte kräver en separat handredigerad kodändring varje gång.
Utse en ägare för organisationens grunddata och en annan tydlig rutin för sidunika uppgifter. Om ett plugin redan genererar Product behöver en ny komponent antingen komplettera genom referenser eller ersätta den gamla implementationen kontrollerat. Testa den färdiga renderade sidan, eftersom koden som finns i en mall inte alltid är densamma som en besökare eller sökmotor får efter serverrendering, caching och efterföljande JavaScript-körning i webbläsaren.
Hur testar man syntax, semantik och behörighet?
Testa först JSON-syntax och att modellen beskriver rätt innehåll. Använd sedan Schema Markup Validator för Schema.org-strukturen och Googles Rich Results Test för stödda Google-funktioner. Granska även sidan manuellt. Ett godkänt verktygsresultat bevisar inte att alla innehållsregler är uppfyllda eller att en viss presentation kommer att visas i sökresultaten för användare.
Välj representativa exempel från varje mall och inkludera svåra fall: saknat pris, författare utan profilsida, utgången produkt och flera verksamhetsplatser. Kontrollera vilka uppgifter som är obligatoriska respektive rekommenderade för den aktuella funktionen. En varning är inte alltid samma sak som ett blockerande fel, men behöver förstås. Lägg inte till påhittade värden bara för att få en grön rapport eller för att tysta ett generellt pluginmeddelande.
Testa både kod före publicering och den publika adressen efteråt. Jämför innehåll som kräver JavaScript och kontrollera att resurser kan hämtas. Använd URL-granskning i Search Console för prioriterade sidor när de är åtkomliga. Dokumentera testadress, datum, förväntad typ och eventuella begränsningar. Då kan nästa utvecklare avgöra om en förändring är en avsiktlig modelljustering eller en regression som behöver åtgärdas i mall eller datakälla.
Hur felsöker man utebliven presentation och ändrade rapporter?
Vid utebliven presentation ska ni kontrollera åtkomst, indexering, innehåll och behörighet innan ni ändrar markeringen. Sidan kan vara korrekt men ändå inte väljas för en särskild sökfunktion. Granska Search Console och aktuell dokumentation för typen. Rapportförändringar kan också bero på ändrat stöd eller datatäckning, inte enbart på fel i er implementation.
Börja med att se om rätt adress är indexerad och om Google har valt en annan kanonisk version. Kontrollera sedan att den strukturerade datan finns i den version som kan hämtas och att den motsvarar synligt innehåll. Vid ändrade produktuppgifter kan cache eller olika prislogik mellan system vara orsaken. Felsök källan till skillnaden i stället för att lägga ett extra block ovanpå den befintliga markeringen.
Om tekniken fungerar och kraven uppfylls behöver ni acceptera att presentationen inte går att beställa. Förklara detta tydligt i rapportering och avtal. Undvik upprepade ändringar utan hypotes; de kan göra implementationen svårare att förstå och mäta. Följ i stället utveckling över relevanta sidor och perioder, med hänsyn till sökefterfrågan och andra ändringar. En isolerad skärmbild från en sökning är inte ett stabilt mått på funktionens användning.
Hur förvaltar man strukturerad data efter lansering?
Förvalta strukturerad data som en del av webbplatsens innehålls- och utvecklingsarbete. Utse ansvariga, dokumentera källor och testa berörda mallar vid varje relevant förändring. Övervaka fel och kontrollera förändrade riktlinjer regelbundet. Korrekt markering kräver fortsatt underhåll när priser, adresser, personer, sidtyper och stödet för olika sökfunktioner förändras över tid i verksamheten.
Skapa en liten testmatris med mall, datakälla, förväntad typ och ansvarig person. Låt automatiska tester kontrollera att obligatoriska fält finns där de verkligen krävs och att felaktiga tomma objekt inte publiceras. Komplettera med manuell granskning av sakuppgifter. Automatik kan upptäcka ett saknat namn men inte alltid att namnet tillhör en person som slutade för ett år sedan eller att en angiven adress inte längre används.
Vid migrering behöver identifierare och relationer ses över tillsammans med nya adresser. Behåll stabila identiteter där det är rimligt, men uppdatera URL-fält och referenser som annars pekar på gamla destinationer. Kontrollera även hur export och import hanterar datum och specialtecken. Dokumentera beslut så att nästa byrå eller utvecklingsteam kan fortsätta arbetet utan att börja med att gissa vilka block som är avsiktliga och vilka som skapats av tidigare plugins.
Vill ni ha hjälp att prioritera? Vår SEO-byrå kopplar sökmotoroptimering till er affär.