Googles retningslinjer for review-schema: Derfor bør du unngå «self-serving»-anmeldelser

Hvorfor strukturert data for anmeldelser ikke gir direkte rankingløft

Det eksisterer en seiglivet myte i SEO-miljøet: Legg inn nok Review- og AggregateRating-markup i JSON-LD, og Google vil belønne deg med bedre rangering. Vi har observert aktører i markedet med over 5 000 anmeldelser lagt inn i egen strukturert data – et volum som på papiret ser imponerende ut. Realiteten er imidlertid en annen.

Review- og AggregateRating-markup er først og fremst en mekanisme for rike søkeresultater (rich results). Den styrer om Google viser stjerner og sammendrag i søkeresultatet, ikke selve rangeringsalgoritmen. Google dokumenterer ingen direkte organisk rangeringsfordel av å legge tusenvis av anmeldelser inn i egen markup. Effekten er i beste fall indirekte, gjennom potensielt bedre klikkrate (CTR) dersom Google faktisk velger å vise stjernene – noe som langt fra er garantert. Med andre ord: Et høyt antall anmeldelser i JSON-LD er ikke et konkurransefortrinn i seg selv. Det er snarere en risiko for brudd på retningslinjene.

To viktige presiseringer i Googles retningslinjer

Google har to sentrale regelsett som styrer hva som er tillatt i review-markup – ett godt etablert, og ett av nyere dato.

1. Regelen om «self-serving»-anmeldelser: I flere år har Google vært tydelig på at dersom virksomheten som omtales selv kontrollerer anmeldelsene om seg selv, er ikke sidetyper som LocalBusiness og Organization kvalifisert for å vise anmeldelsesstjerner i søkeresultatet. Dette gjelder uavhengig av om markupen ligger direkte på siden eller hentes inn via en tredjepartswidget (som Google Business Profile, Facebook eller lignende). Markupen kan fortsatt ligge på siden, men Google vil slutte å vise stjernene i søket.
2. Den nylige presiseringen av retningslinjene: Google oppdaterte nylig sin dokumentasjon for review-snippets med et eksplisitt forbud mot to kategorier anmeldelser i strukturert data:
   • Anmeldelser som ikke bygger på en genuin bruks- eller kjøpserfaring.
   • Anmeldelser skrevet mot en fordel (penger, rabatt, gavekort eller gratis produkter) uten at dette insentivet er tydelig og fremtredende opplyst.

Det er viktig å forstå at dette ikke er en helt ny spam-policy. Prinsippet om ekte, ikke-kjøpte anmeldelser har ligget i Googles generelle retningslinjer i lang tid. Det nye er at formuleringen nå står direkte i de tekniske kravene for strukturert data. Dette betyr at reglene kan håndheves direkte mot selve markupen, og ikke bare mot det generelle innholdet på nettsiden.

Hvorfor import av eksterne anmeldelser ofte mislykkes

Mange antar feilaktig at dersom anmeldelsene stammer fra en reell, ekstern kilde – som Trustpilot eller en import fra Google Business Profile via API – så er markupen automatisk trygg og kvalifisert for rike søkeresultater. Dette stemmer ikke.

Google oppgir eksplisitt at man ikke skal aggregere anmeldelser eller rangeringer fra andre nettsteder. Å kopiere, importere eller gjenbruke anmeldelser fra en ekstern plattform inn i din egen AggregateRating-markup gir ikke rett til visning av stjerner, selv om de underliggende anmeldelsene er helt ekte.

Det er avgjørende å skille mellom fire ulike konsepter som ofte forveksles:

• Reelle anmeldelser som eksisterer på en uavhengig plattform.
• Å vise en visuell widget med disse anmeldelsene på eget nettsted for brukerne.
• Å kopiere eller importere disse dataene som egen AggregateRating-markup i kildekoden.
• At Google faktisk velger å vise stjerner i det organiske søkeresultatet.

Det første punktet er legitimt og verdifullt for å bygge tillit hos besøkende. De tre siste punktene gir derimot ikke automatisk rett til stjernevisning for en LocalBusiness eller Organization.

Måling av tillitssignaler for søkemotorer og AI-agenter

I Nettpilots metodikk for digital rådgivning bruker vi spesifikke parametre for å fange opp denne typen strukturelle utfordringer. Dette handler ikke bare om juss, men om hvordan søkemotorer og AI-agenter (som ChatGPT og Perplexity) verifiserer informasjon:

Structural Proof Gap (SPG) måler i hvilken grad en nettsides forretningskritiske påstander – som priser, tjenesteparametre og kundevurderinger – er eksplisitt verifisert gjennom Schema.org-markup, sammenlignet med om de kun er påstått i vanlig brødtekst. En høy SPG betyr at siden hevder mye, men beviser lite i et maskilesbart format. Et påstått høyt antall anmeldelser i ren tekst, uten gyldig og kvalifisert markup, er et typisk eksempel på et slikt avvik.

Consistency & Redundancy Gap (CRG) måler om samme kjernefakta er forankret på tvers av flere uavhengige elementer – for eksempel i brødteksten, i en semantisk HTML-tabell og i en JSON-LD-blokk. For en maskin er dataredundans og konsistens ensbetydende med tillit. Anmeldelser som kun eksisterer i en selvbetjent JSON-LD-blokk uten ekstern forankring, vil score svakt på CRG fordi datakilden er isolert og enkel å manipulere.

Dette rammeverket hjelper oss med å vurdere fremtidig synlighet. Selv om en praksis ikke utløser et umiddelbart regelbrudd hos Google i dag, kan den likevel svekke den strukturelle troverdigheten overfor AI-agenter som vurderer hvilke kilder de skal sitere fremover.

Risikoen ved feil markup: Tap av stjerner versus manuell aksjon

Det er viktig å skille mellom tap av visning og direkte straffereaksjoner fra Google:

• Self-serving markup: Dette fører vanligvis ikke til en manuell sanksjon (manuell aksjon). Den direkte konsekvensen er at Google slutter å vise stjernene i søkeresultatet for den aktuelle siden. Siden mister sin kvalifisering for rike resultater, men beholder normalt sin indeksering og rangering.
• Falske eller villedende anmeldelser: Dersom anmeldelsene eller markupen er falske, villedende eller inneholder uoppgitte insentiver, faller det under kategorien for retningslinjebrudd. Dette kan utløse en manuell aksjon, som i verste fall kan føre til at nettstedet mister muligheten til å vise strukturert data overhodet inntil forholdene er utbedret.

Et stort volum av anmeldelser endrer ikke de juridiske eller tekniske realitetene, men det øker sannsynligheten for at kvalitetssystemer eller konkurrenter oppdager avvikene. Det er også verdt å merke seg at en aggregert verdi i kildekoden ikke er det samme som å ha faktiske, individuelle anmeldelsesobjekter i JSON-LD-koden. Markupen bør alltid analyseres i detalj før man trekker konklusjoner.

Slik bygger du anmeldelser søkemotorene stoler på

For å sikre langsiktig synlighet og troverdighet bør du følge disse fire prinsippene:

1. Fokuser på uavhengige plattformer: Bygg ekte, brukerskapte anmeldelser på uavhengige flater som Google Business Profile eller Trustpilot. Dette reduserer risikoen for villedende innhold og gir sterke tillitssignaler til både mennesker og maskiner.
2. Unngå ulovlig aggregering: Vis gjerne eksterne anmeldelser i en visuell widget for de besøkende på nettsiden, men ikke kopier disse dataene inn i din egen AggregateRating-markup.
3. Bruk riktige verktøy for validering: Bruk verktøy som Googles test for rike resultater for å sjekke den tekniske koden. Husk at en grønn feilfri test kun bekrefter at koden kan leses, ikke at Google faktisk vil velge å vise stjernene i det levende søkeresultatet. Dette må overvåkes manuelt eller via Search Console over tid.
4. Sørg for strukturell konsistens: Tett eventuelle gap mellom påstander i teksten og den strukturerte koden. Sørg for at viktige data er konsistent representert flere steder på nettstedet, slik at både søkemotorer og AI-agenter kan verifisere informasjonen på en pålitelig måte.

Ofte stilte spørsmål om review-schema

Konklusjon: Volum uten reell forankring er en strukturell svakhet, ikke en styrke – verken for tradisjonelle søkemotorer i dag eller for AI-søk fremover. Ekte, dokumenterte og konsistente kundesignaler vil alltid gi best resultater over tid.