Rich snippets

Rich snippets er en udbredt betegnelse for søgeresultater, der viser mere end den almindelige titel, URL og metabeskrivelse. Det kan eksempelvis være pris og lagerstatus for et produkt, dato for en begivenhed, brødkrummer eller en bedømmelse. Google bruger i dag ofte samlebetegnelsen rich results.

Grundlaget er normalt strukturerede data: maskinlæsbar information i et standardiseret format, som beskriver sidens indhold. På en produktside kan markuppen fortælle, hvad der er produktnavn, pris, valuta, lagerstatus og anmeldelsesdata. Google kan bruge oplysningerne til at forstå siden og vælge en mere informativ visning.

Et rich snippet er ikke det samme som et featured snippet. Featured snippets er fremhævede uddrag, som Google selv henter fra indholdet for at besvare en søgning. Rich results er knyttet til bestemte søgeresultatfunktioner og understøttede typer strukturerede data.

Det er heller ikke en ekstra annonce. Resultatet kan stadig være organisk og ligge i den almindelige SERP. Den udvidede visning kan gøre resultatet lettere at vurdere og i nogle tilfælde forbedre CTR, men Google garanterer hverken visning eller flere klik.

Start med sidetypen og ikke med ønsket om at fylde mere i Google. En webshop kan have relevante produktdata, mens en virksomhedsside kan have organisation, breadcrumb eller lokationsoplysninger. Brug kun en type, når sidens synlige indhold faktisk matcher Googles krav.

JSON-LD er ofte det letteste format at vedligeholde, fordi markuppen kan ligge samlet i et script. Felterne skal dog hentes fra de samme data, som brugeren ser. Hvis prisen ændres i WooCommerce, bør den strukturerede pris følge med automatisk, så Google ikke møder en anden værdi end kunden.

Test siden i Googles Rich Results Test, før ændringen går live. Værktøjet viser, hvilke understøttede typer der findes, og om påkrævede eller anbefalede felter mangler. En teknisk gyldig test er dog ikke en garanti for visning. Indholdets kvalitet, politikker og Googles vurdering spiller stadig ind.

Efter lancering bør rapporterne i Google Search Console overvåges. De kan vise gyldige elementer, advarsler og fejl på tværs af mange URL’er. Ved skabelonændringer er det især vigtigt at kontrollere, om en enkelt fejl er blevet kopieret ud på hele websitets produkt- eller artikelsider.

En webshop sælger arbejdstøj. Det normale søgeresultat viser titel og beskrivelse, men produktsiden har også korrekt produktmarkup med pris, valuta, lagerstatus og anmeldelser, som er synlige på siden. Google kan vælge at vise nogle af disse oplysninger direkte i resultatet, så brugeren bedre kan vurdere produktet før klikket.

Et andet website har en artikel med en breadcrumb som “Forside → Guides → SEO → Rich snippets”. Korrekt breadcrumb-markup kan give Google et mere læsbart sti-element i stedet for en rå URL. Det hænger tæt sammen med almindelige breadcrumbs på siden og bør afspejle den rigtige struktur.

En tredje virksomhed tilføjer femstjernede anmeldelser i markuppen, selv om anmeldelserne ikke står på siden og ikke kommer fra virkelige kunder. Koden kan være syntaktisk korrekt, men indholdet er misvisende og kan gøre siden uegnet til udvidet visning.

Eksemplerne viser, at markup ikke skaber information. Den beskriver information, som allerede skal være reel, relevant og tilgængelig for brugeren. Den bedste implementering begynder derfor i datakilden og sidens indhold, ikke i et tilfældigt felt i et SEO-plugin.

Den mest almindelige fejl er at love rich snippets som et fast resultat. Google beslutter selv, om en udvidet visning hjælper ved den konkrete søgning. En side kan være fuldt gyldig og alligevel blive vist som et almindeligt søgeresultat.

En anden fejl er at markere skjulte eller forældede data. Lagerstatus, pris, datoer og anmeldelser skal holdes opdateret. På en stor webshop kan en fejl i integrationen sende gamle værdier til Google, mens kunden ser nye værdier på siden.

Pas også på plugins, der tilføjer flere overlappende markupblokke. Tema, SEO-plugin og webshopplugin kan alle beskrive samme produkt eller organisation. Dobbelt eller modstridende data gør fejlsøgningen vanskeligere og kan give uklare signaler.

Rich snippets bør ikke bruges som pynt på tyndt indhold. En side skal stadig have en præcis title tag, relevant tekst, god hastighed og en brugbar landingsoplevelse. Den udvidede visning kan ikke redde en side, der ikke opfylder søgeintentionen.

Google understøtter kun bestemte typer og egenskaber til rich results. Schema.org indeholder langt flere begreber, end Google nødvendigvis bruger i søgeresultaterne. Følg derfor Googles dokumentation for den konkrete funktion i stedet for at antage, at al gyldig schema-markup giver en visuel effekt.

Søgeresultatfunktioner ændrer sig løbende. En type kan få nye krav, mindre synlighed eller blive fjernet. Derfor bør markup betragtes som vedligeholdelse og ikke som en engangsopgave. Dokumentér, hvilket plugin eller hvilken skabelon der genererer dataene.

På et redesign bør strukturerede data testes sammen med canonical, indeksering og interne links. En gyldig produktblok hjælper ikke, hvis siden samtidig har forkert canonical, returnerer en fejl eller ikke kan crawles.

Produktresultater kræver mere end et produktnavn og en pris. Varianter, tilbudspriser, valuta, tilgængelighed og anmeldelser skal hænge sammen med den konkrete URL. På produkter med mange størrelser kan datamodellen blive den svære del, fordi én side kan rumme flere tilbud og lagerstatusser.

Breadcrumb-markup er ofte en relativt enkel gevinst, fordi den følger en struktur, som allerede bør være synlig på siden. Den kan samtidig afsløre inkonsistens: Hvis den visuelle breadcrumb siger én kategori, mens JSON-LD siger en anden, bør datakilden samles.

Organisation- og lokal virksomhedsdata bør være ens på tværs af website, Google Business Profile og andre profiler. Markup er ikke en erstatning for at vedligeholde navn, adresse og kontaktoplysninger. Modstridende information kan gøre både kunder og systemer usikre.

Google kan vise andre elementer end dem, du forventer, eller vælge en almindelig visning. Det er derfor bedre at måle udviklingen i visninger, klik og CTR over en længere periode end at kontrollere én søgning fra egen computer. Personalisering og test kan ændre resultatet fra bruger til bruger.

Når indholdet genereres fra et CMS, bør markup komme fra strukturerede felter frem for fri tekst, hvor det er muligt. En redaktør skal kunne ændre en pris eller dato ét sted. Parallelle felter øger risikoen for, at den synlige side og de maskinlæsbare data går hver sin vej.

Fejlrapporterne bør prioriteres efter sidetype og trafik. En markupfejl på alle produktsider er vigtigere end en advarsel på en gammel artikel uden visninger. Det samme princip gælder som ved anden teknisk SEO: omfang og forretningsværdi bør styre rækkefølgen.

På artikler og guides kan korrekt dato og forfatterinformation hjælpe Google med at forstå siden, men markup bør ikke bruges til kunstigt at få gammelt indhold til at se nyt ud. Opdateringsdatoen skal afspejle en reel redaktionel ændring og være synlig for læseren.

En gyldig markupblok kan stadig mangle anbefalede felter. Advarsler er ikke altid kritiske, men de kan vise muligheder for bedre data. Prioritér felter, der findes på siden og kan vedligeholdes stabilt, frem for at udfylde alt med tomme standardværdier.

Screenshots af søgeresultater bør dateres i dokumentationen, fordi visningen ændrer sig. Det er mere robust at beskrive den ønskede datamodel og Googles aktuelle krav end at love, at resultatet altid vil se ud præcis som på et enkelt billede.

På en webshop skal strukturerede produktdata stemme med pris, lagerstatus og anmeldelser, som kunden kan se på siden. Hvis data kun opdateres i markup og ikke i det synlige indhold, kan resultatet blive misvisende. Den bedste løsning henter begge dele fra samme datakilde, så de ikke glider fra hinanden.

Vi tænker teknisk SEO ind, når vi bygger hjemmesider og webshops. I vores guide om SEO-optimering, kan du se, hvordan søgeresultatet hænger sammen med resten af siden.