Når du vil have dine produkter vist med pris, lagerstatus og stjerner direkte i Google, handler det ikke kun om at “tilføje schema”. Det handler i høj grad om, hvad der faktisk findes i dit produktkatalog, og om data kan omsættes til pålidelige signaler uden modstrid.
I denne artikel får du en praktisk gennemgang af, hvordan struktureret produktdata understøtter schema og rich results, hvilke felter du skal sikre i dit katalog, hvordan variantdata typisk skal hænge sammen, og hvilke fejl der oftest spænder ben. Du får også konkrete tjeklister, så du kan gå fra teori til handling uden gætterier.
Hvad er struktureret produktdata, og hvorfor betyder det noget?
Struktureret produktdata er standardiserede felter om et produkt (fx navn, pris, valuta, lagerstatus, varianter og anmeldelser), der kan bruges konsekvent på tværs af dit website, dit feed og dit schema markup. Når felterne er ensartede, kan søgemaskiner lettere forstå, validere og præsentere dine produkter som rich results.
Hvorfor betyder det noget? Fordi rich results kan øge synlighed og klikrate ved at vise mere information i søgeresultatet, og fordi schema uden solid datakvalitet ofte ender i fejl, advarsler eller slet ingen visning.
Mini-konklusion: Hvis dit katalog er rodet, kan dit schema være nok så “korrekt” syntaktisk, men stadig ubrugeligt i praksis.
Hvilke katalogfelter driver pris og availability i rich results?
Pris og lagerstatus er de to felter, der oftest afgør, om Google kan vise et produkt som et troværdigt tilbud. Det kræver, at dine katalogdata kan udtrykkes som en entydig “offer”: en pris i en valuta, en tilgængelighed og en landing page, hvor samme information kan verificeres.
Pris: mere end et tal
Din pris skal være entydig, opdateret og knyttet til den rigtige variant. I kataloget bør du som minimum have pris, valuta og en klar angivelse af, om prisen er kampagnepris eller normalpris. Hvis du arbejder med “før/nu”-priser, skal du kunne dokumentere, hvilken pris der er den gældende salgspris.
Availability: lagerstatus med klare regler
Availability skal være baseret på en defineret lagerlogik. “På lager”, “ikke på lager”, “forudbestilling” og “restordre” er ikke bare labels til kunder; de er også maskinlæsbare tilstande, der skal mappes konsekvent. Et klassisk problem er, at produktsiden viser “på lager”, mens feed eller schema siger “out of stock”.
Mini-konklusion: Pris og availability skal kunne valideres på siden og være synkroniseret på tværs af systemer, ellers risikerer du mismatch og tab af rich results.
Ratings og reviews: hvad skal findes, før du markerer det?
Stjerner i søgeresultatet kræver, at dine vurderingsdata er reelle, tilgængelige og korrekt knyttet til det specifikke produkt. I kataloget betyder det typisk, at du skal kunne lagre en samlet ratingværdi og et antal anmeldelser, samt have en kilde der kan dokumenteres på siden.
Minimumsfelter til aggregate rating
Hvis du vil markere en samlet bedømmelse, skal du kunne udfylde felter som ratingværdi, antal ratings og skala (fx 1–5). Det er vigtigt, at disse tal ikke er “opfundne” eller genereret uden brugersignaler, og at de matcher den synlige visning på produktsiden.
Typiske faldgruber ved ratings
De mest almindelige fejl er at tilføje rating-markup på kategorisider, at bruge samme rating på alle produkter, eller at vise stjerner uden faktiske anmeldelser. En anden fejl er at knytte anmeldelser til en forældremodel, mens schema ligger på en variant-URL, så Google ikke kan afgøre, hvad der bedømmes.
Mini-konklusion: Hvis du ikke kan vise ratingdata tydeligt og produkt-specifikt på siden, bør du ikke forvente stabile stjerner i rich results.
Variantdata: farver, størrelser og SKU’er uden kaos
Variantdata er ofte det sted, hvor et ellers solidt katalog falder fra hinanden. Rich results kræver, at det er klart, hvilken variant der har hvilken pris, lagerstatus og identitet. Det handler om at have en robust datamodel: forældreprodukt, varianter, attributter og entydige identifikatorer.
Hvad dit katalog bør kunne repræsentere
For hver variant bør du have en unik SKU eller variant-ID, variantens attributter (fx farve og størrelse), en variant-specifik URL eller en stabil måde at linke til den på, samt variantens pris og lagerstatus. Hvis du kun har pris på forældreproduktet, men lager per variant, opstår der hurtigt inkonsistens.
Sådan undgår du “blandede” tilbud
Et typisk problem er, at schema viser den laveste pris blandt varianter, mens brugeren lander på en variant, der er dyrere eller udsolgt. Derfor bør du overveje, om du vil markere et prisinterval eller markere tilbud pr. variant, afhængigt af hvordan dine URL’er og produktvalg fungerer.
Mini-konklusion: Variantdata skal være konsekvente nok til, at en maskine kan vælge den rigtige kombination af variant, pris og availability uden at gætte.
Schema og rich results: sådan hænger katalog og markup sammen
Schema markup er i praksis et “output-lag”, der trækker på dine katalogdata. Når kataloget er komplet, kan du generere Product, Offer og AggregateRating med færre specialregler. Det er her, mange opdager, at deres katalog mangler felter, eller at felter findes, men ikke kan bruges konsekvent på tværs af kanaler.
Hvis du arbejder målrettet med rich snippets til produkter, er det en god disciplin at starte med datagrundlaget og derefter beslutte, hvor schema skal ligge: server-side, i din template eller via en feed-baseret løsning. Uanset metode vinder du på at have samme sandhed i kataloget.
- Produktnavn der matcher sidens H1 og titel
- Entydig produktidentitet: SKU, GTIN eller MPN hvor muligt
- Pris og valuta pr. relevant enhed (ofte variant)
- Availability med klar mapping fra lagerlogik
- Produkt-URL der er kanonisk og stabil
- Brand og evt. model/serie for filtrering og forståelse
Mini-konklusion: Jo mere af din schema kan genereres direkte fra katalogfelter uden manuelle undtagelser, jo mere robust bliver dine rich results over tid.
Typiske fejl: manglende felter, mismatch og “skjulte” data
De fleste problemer opstår ikke, fordi schema er skrevet forkert, men fordi data er ufuldstændige eller i konflikt. Google sammenligner ofte markup med det synlige indhold og kan ignorere felter, hvis de ikke stemmer.
Manglende felter, der stopper det hele
Hvis pris mangler på visse produkter, hvis valuta ikke er angivet, eller hvis availability ikke kan udledes, ender du med advarsler eller manglende rich results. Det samme gælder, hvis du har varianter uden egne SKU’er og derfor ikke kan skelne mellem dem.
Mismatch mellem katalog, side og feed
Mismatches sker især ved kampagner, udsolgte varer og dynamiske prisændringer. Eksempler: schema siger “in stock”, men siden viser “udsolgt”; schema angiver en kampagnepris, men siden viser normalpris; eller du viser et prisinterval, mens markup angiver en enkelt pris.
Andre klassikere er tidszoner og cache: din lagerstatus opdateres kl. 08, men schema caches til kl. 12. I praksis er det stadig mismatch, og det kan koste visning.
Mini-konklusion: Hvis du vil have stabil visning, skal du behandle mismatch som en datakvalitetsfejl, ikke som et “SEO-problem”.
Hvad skal findes i dit katalog? En praktisk tjekliste
Den hurtigste vej til bedre struktur er at gøre kataloget “schema-klar”. Det betyder, at du kan udfylde de centrale schema-felter uden ekstra manuelt arbejde, og at du kan gøre det på samme måde for alle produkter.
- Unik identitet pr. produkt og pr. variant (SKU/variant-ID; gerne GTIN hvor muligt)
- Kanonisk URL pr. produkt eller variant, afhængigt af din sidearkitektur
- Prisfelter: salgspris, normalpris, valuta, og gyldighedsperiode for kampagner
- Lagerfelter: tilgængelighedstilstand, antal på lager (hvis relevant), og leveringsstatus
- Attributter til varianter: størrelse, farve, materiale, og en stabil rækkefølge/normalisering
- Brand, produktkategori og evt. modelnavn til bedre entydighed
- Ratingfelter: gennemsnit, antal, og reference til hvor anmeldelser vises
Mini-konklusion: Når disse felter er på plads, bliver schema en automatiserbar “oversættelse” i stedet for et skrøbeligt specialprojekt.
Implementering i hverdagen: processer, tests og vedligehold
Det praktiske spørgsmål er ofte “hvordan gør vi det uden at drukne i vedligehold?”. Svaret er at kombinere faste datakrav med løbende kontrolpunkter, især omkring pris og lager, der ændrer sig hyppigt.
Data governance i miniature
Definér en datakontrakt mellem PIM/ERP, webshop og eventuelle feeds: hvem ejer pris, hvem ejer lager, og hvor hurtigt skal ændringer slå igennem. Brug gerne en enkelt kilde til sandhed for hver datatype, og sørg for at andre systemer kun kopierer, ikke “finder på” værdier.
Test, før det bliver et problem
Planlæg en fast rutine: stikprøver på produktsider, validering af markup og overvågning af fejl i Search Console. Når en kampagne går live, bør du teste et par varianter: en billig, en dyr, en udsolgt og en med rabat. På den måde fanger du de fejl, der ellers først opdages, når synligheden falder.
- Kontrollér at synlig pris på siden matcher schema-prisen
- Kontrollér at udsolgte varianter ikke markeres som på lager
- Kontrollér at ratings på siden matcher aggregate rating i markup
- Kontrollér at kanonisk URL svarer til den URL, du markerer
Mini-konklusion: Vedligeholdelse handler mindre om SEO-tricks og mere om driftsrutiner, der holder data synkroniseret.
Hvad koster det, og hvad er bedste praksis på tværs af teams?
Omkostningen afhænger af, hvor moden din katalogstruktur er. Hvis du allerede har et PIM med varianter, prisfelter og lagerlogik, kan arbejdet ofte klares på dage til få uger. Hvis data er spredt i manuelle felter, eller hvis variantmodellen er utydelig, kan projektet blive større, fordi du først skal normalisere data.
Bedste praksis er at få marketing, e-commerce og udvikling til at mødes om de samme definitioner: Hvad er en variant? Hvornår er noget “på lager”? Hvilken pris er gældende? Og hvordan håndterer vi kampagner, bundles og mængderabatter uden at skabe mismatch? Når definitionerne er fælles, kan du lave regler, der holder.
Mini-konklusion: Den største udgift er sjældent schema-koden; det er at få produktdata til at være komplette, konsistente og vedligeholdelige.
