De fleste AI-synlighetsverktøy selger en enkelt score. Kjøp den ikke. Et tall som blander hvor godt dere rangerer på en merkevare-identitetsprompt med hvor usynlige dere er på en transaksjonell kjøps-prompt, er ikke en metrikk - det er et gjennomsnitt som skjuler gapet dere betaler for å lukke. Vår egen Geoboard-baseline datert 2026-06-11 rangerte wppoland.com først i fem av seks modeller på den smale identitetsprompten «Polish agency for foreign WordPress clients» og viste null tilstedeværelse på transaksjonelle WooCommerce- og AI-implementeringsfamilier i samme kjøring. En score ville ha rapportert det som «sterk AI-synlighet». Skillet forteller sannheten: mekanismen som skaper ett gap er ikke mekanismen som skaper det andre, og de trenger ulike fiks. Denne guiden er overvåkingslaget i det programmet: hvilke spørringsfamilier å spore, hvilke metrikker som faktisk forutsier inntekt, stacken vi kjører på eget nettsted, og en kadens-tabell dere kan gi til en leverandør eller en innkjøpsleder.
Råvarene denne guiden bygger på har vi allerede publisert: 90-dagers sporingslanseringen som satte baseline, og målingssyklusen Q2 2026 som viste hvor mye måleinstrumentet selv kan flytte det rapporterte tallet. Denne artikkelen gjør begge til en driftsmanual: hva spore, hvor ofte, og hva kreve av alle som selger dere en «AI-synlighets»-rapport.
Hvorfor en enkelt AI-synlighets-score svikter innkjøp
En sammensatt score finnes for at en slide skal se ren ut, ikke for at en beslutning skal være forsvarlig. Den komprimerer minst fire ulike signaler - identitetsgjenkjenning, tilstedeværelse på informasjonsspørringer, transaksjonell siteringsrate og konkurrent share of voice - til ett tall, og gjennomsnittsberegning over dem ødelegger akkurat informasjonen en kjøper trenger.
Her er det mekaniske problemet. Vårt identitetsprompt-resultat (først i fem av seks modeller) og vårt transaksjonsresultat (null tilstedeværelse) sitter i samme Geoboard-baseline-kjøring, samme dato, for samme domene. Gjennomsnittsberegn dem og dere får en midt-score som ser ut som «rom for forbedring». Rapporter dem som et skille og dere får den nøyaktige historien: en forsvarlig posisjon som koster lite å vedlikeholde, ved siden av et reelt gap som koster reelt off-page-arbeid å lukke. En leverandør som gir dere ett tall har enten ikke skilt spørringsfamiliene eller vil ikke at dere skal se skillet.
I norsk innkjøp dukker samme feil opp når byråer legger en «AI-synlighets-score» ved siden av rapporter fra Digdir-veiledning eller interne KPI-ark og behandler den som nok et tall i RFP-tabellen. Innkjøp bør behandle en enkelt AI-synlighets-score slik de ville behandlet en enkelt «SEO-score» fra en nettleserutvidelse: et markedsføringsartefakt, ikke et revisjonsgrunnlag. Be om tabellen i stedet for tallet, hver gang.
Spørringsfamilier å overvåke
Skill prompts etter intensjon før dere teller noe. Fire familier dekker det meste av B2B-kjøpsatferd rundt WordPress og WooCommerce, og hver svarer på et annet forretningsspørsmål.
Identitets- og posisjoneringsprompts er smale merkevarespørsmål en kjøper stiller når de allerede vet at dere kan være aktuelle: «Polish agency for foreign WordPress clients», nearshore-posisjonering fra Polen, leveranse i EU-tidssone. Denne familien måler om modeller løser hvem dere er. Å vinne her er nødvendig og alene verdt veldig lite for en salgspipeline.
Informasjons- og practitioner-prompts speiler hvordan en teknisk evaluator researcher før et RFP finnes: headless WordPress-tradeoffs, WooCommerce-ERP-integrasjonsmetoder, Core Web Vitals på store kataloger. AI-svar erstatter i økende grad de første søkeresultatene en practitioner ville åpnet, så fravær her betyr at dere ikke er i shortlist-samtalen selv når identitetsprompten rangerer først. Hos norske nettbutikker ser vi dette tydelig på spørringer om Vipps Checkout, Tripletex eller PowerOffice-integrasjon - modeller siterer ofte generelle SEO-blogger, ikke Woo-spesialistene som faktisk bygger broene.
Transaksjonelle WooCommerce-prompts er der budsjettene faktisk sitter: ansett en WooCommerce-utvikler, WooCommerce- og ERP-integrasjonspartner, fikse treg checkout på en stor butikk, byrå for Woo pluss AI-automatisering. Vår egen baseline viste null tilstedeværelse her.
AI-implementeringsprompts kjører parallelt med WooCommerce: WordPress AI-integrasjon, agentklare produktfeeds, governance for AI-plugins, MCP-eksponering for butikkdata. Samme baseline-resultat, null 2026-06-11, og i økende grad pakket inn i enterprise-innkjøpspakker som kobler plattformarbeid med «AI readiness».
| Spørringsfamilie | Hva den tester | Vårt baseline-signal (2026-06-11) | Hva kreve av leverandørrapport |
|---|---|---|---|
| Identitet / posisjonering | Entity-resolusjon for nischen deres | #1 i 5/6 modeller på ankerprompt | Bekreft eksakt promptformulering, ikke parafrase |
| Informasjon / practitioner | Teknisk shortlist før RFP | Blanding, ikke headline-metrikken | Spør hvilke practitioner-spørsmål som ble testet |
| Transaksjonell (f.eks. WooCommerce) | Inntektsnær ansettelsesintensjon | Null tilstedeværelse | Be om konkurrentdomener sitert i stedet for dere |
| AI-implementering | Agent- og automatiseringsinnkjøp | Null tilstedeværelse | Spør om denne familien ble testet i det hele tatt |
Hvis en rapport ikke bryter ut disse fire radene separat, er det ikke en overvåkingsrapport - det er et sammendrag designet for å bli trodd heller enn revidert.
Metrikker som betyr noe
Når spørringsfamilier er skilt, bærer fire metrikker det faktiske signalet. Alt annet er et vanity-aggregat kledd som data.
Merkeomtale. Nevnte assistenten merkevaren deres noe sted i svaret, uavhengig av lenke. Dette er det løseste signalet og det letteste å treffe, så behandle en stigende omtalerate alene som svak evidens.
URL-sitering. Lenket assistenten til den konkrete siden deres. Dette er nærmere en reell referral og mye vanskeligere å tjene enn en bar omtale, særlig i transaksjonelle familier der modeller tenderer til å sitere kataloger heller enn spesialister.
Konkurrentdomener sitert. Hvilke andre domener dukket opp i stedet for dere, logget med navn, ikke oppsummert som «konkurrenter». I våre egne transaksjonelle sjekker var domenene som surfacerte generelle SEO- eller SEM-butikker som reklamerte for «AI SEO», ikke WooCommerce-spesialister - det er i seg selv et funn: gapet er assosiasjon og authority, ikke innholdskvalitet. I det norske markedet ser vi ofte byråkataloger og generiske «AI-synlighet»-sider uten Woo- eller ERP-dybde.
Share of voice. Siteringstallet deres delt på totale siteringer over det sporede promptsettet, beregnet per spørringsfamilie, per motor. Dette er den eneste av de fire som oppfører seg som en reell KPI over tid, fordi den er relativ og sammenlignbar på tvers av re-kjøringer, så lenge promptlisten holder seg fast.
Hva som bevisst mangler: en enkelt «AI-synlighetsprosent», en 0-til-100 «AI SEO-score», eller enhver metrikk som ikke kan spores tilbake til en konkret prompt, motor og dato. Hvis et dashbord ikke kan vise prompten bak et tall, er tallet ikke evidens.
Overvåkingsstacken vi faktisk bruker
Vi kjører fire lag på eget nettsted, og hvert dekker en feilmodus de andre misser.
Geoboard batch-re-kjøringer gir repeterbar multi-modell-dekning mot et deklarert promptsett. Vår frosne baseline fra 2026-06-11 produserte identitets-versus-transaksjon-skillet beskrevet over, sammen med motor-skew mellom ChatGPT og Perplexity. Batch-verktøy er riktig lag for trend-sammenligning, ikke for daglig overvåking, fordi daglig multi-modell-polling mest måler grensesnittstøy.
Ukentlige manuelle stikkprøver i forbrukergrensesnitt - ChatGPT, Perplexity, Copilot og Claude der det passer - fanger produktendringer raskt. Vi logger fire felt hver gang: dato, motor, promptfamilie og utfall (merkeomtale, URL sitert, konkurrentdomener eller ingen). Dette laget er tidligvarslingssystemet når en modell legger til eller fjerner live browsing. Hos norske kunder med Microsoft 365 og Teams ser vi ofte at Copilot-stikkprøver fanger tenant-spesifikk drift tidligere enn batch, fordi forbruker-UI og organisasjonskontekst kan diverge.
Brand-radar-stil tracking for konkurrent-siteringsdomener. Geoboard og manuelle sjekker forteller om dere dukket opp. Dette laget forteller hvem som dukket opp i stedet - det er inputen off-page authority-planen faktisk trenger. Å vite at generalistiske SEO-butikker, ikke Woo-spesialister, vinner den transaksjonelle familien, endrer hvor remedieringsbudsjettet bør gå.
Renderingsporten. Ingenting av det ovenfor betyr noe hvis bærende fakta ikke ligger i raw HTML-svaret i utgangspunktet. Andre Alpars juni 2026-eksperiment, publisert via CitationOne, fant at seks av sju vestlige AI-assistenter leser bare raw HTML, ikke utført JavaScript. Før dere stoler på et null-siteringsresultat som et innholds- eller authority-problem, bekreft at innholdet faktisk var synlig for assistentens fetch. Et null forårsaket av klient-side-rendering er en helt annen fiks enn et null forårsaket av manglende off-page-korroborasjon. For offentlige og semioffentlige norske aktører er det også verdt å sjekke at kritiske fakta ikke ligger bak Cookiebot- eller Consent-lag som krever klient-JS - et mønster vi ser oftere når Digdir-inspirerte UU-krav møtes med tung SPA-frontend.
Kadens: hvor ofte kjøre hvert lag
Kadens er der de fleste overvåkingsprogrammer enten brenner budsjett på støy eller misser reell drift. Tre intervaller, mappet til hva hvert er godt for:
| Kadens | Hva kjører | Hvorfor dette intervallet |
|---|---|---|
| Ukentlig | Manuelle stikkprøver, fast promptliste, forbruker-UI | Fanger modell- eller UI-endringer raskt; billig nok til å holde uendelig |
| Hver 6-8 uke | Geoboard-stil batch multi-modell-re-kjøring | Langt nok til at off-page- og on-page-endringer er crawlet og assosiert; kort nok til å fange regresjoner før kvartalet lukkes |
| Kvartalsvis | Programavlesning til interessenter, knyttet til budsjett eller leverandørreview | Matcher innkjøps- og markedsføringsrapporteringssykluser; unngår å overclaim en trend fra støy |
Daglig eller til og med hver-få-dagers polling over mange modeller måler mest grensesnittvarians, ikke reell endring i hvordan modeller assosierer merkevaren deres med en spørring. Vi lærte dette direkte: målingssyklusen Q2 2026 viste at et proxy-snapshot og et forbruker-UI-snapshot var uenige nok innen samme uker til at instrumentet, ikke den underliggende virkeligheten, forklarte det meste av forskjellen. Kadensdisiplin finnes for å holde den typen støy fra å bli tatt for en trend. I norske innkjøpsavdelinger lander kvartalsavlesningen typisk i samme syklus som IT-leverandørreview og budsjettgodkjenninger etter regnskapsåret - ikke i ukentlige SEO-standup-er.
Perplexity versus ChatGPT: hvorfor motorskillet er obligatorisk
Å behandle «AI-synlighet» som ett tall på tvers av motorer skjuler en konkret, målbar feilmodus. I vår egen baseline-kjøring viste ChatGPT null tilstedeværelse over åtte sporede prompts i blind-spot-snittet av spørringssettet, mens Perplexity var den sterkeste motoren i samme kjøring. Det er ikke tilfeldig én dårlig uke. Perplexity grounder tungt på live websøk, så den tenderer til å surfacere ferskere, smalere treff. ChatGPTs standardatferd i samme periode lente annerledes, og gapet mellom de to var stort nok til å endre hele lesningen av merkets siteringshelse avhengig av hvilken motor dere tilfeldigvis sjekket.
Den praktiske konsekvensen for overvåkingsomfang: rapporter aldri ChatGPT alene som «AI-synlighet», og gjennomsnittsberegn aldri ChatGPT- og Perplexity-resultater til en figur. Et omfang som stopper på ChatGPT vil underrapportere et merke Perplexity allerede siterer, og et omfang som stopper på Perplexity vil overdrive hvor synlige dere er for publikum som fortsatt default til ChatGPT. Spor begge, rapporter begge, og hvis budsjettet tvinger valg mellom å legge til en tredje motor eller fikse dette skillet, fiks skillet først. Full informasjonsoppdeling av hvorfor skillet oppstår finner dere i hvorfor Perplexity siterer merkevaren deres, men ChatGPT ikke.
Innkjøpssjekkliste: hva kreve av leverandører
Før dere signerer av på noen AI-synlighets- eller GEO-overvåkingsleverandør, krev svar på alle følgende. Hvis en leverandør ikke kan svare på ett av dem skriftlig, behandle tallene deres som markedsføringsmateriell, ikke måling.
- Den eksakte promptlisten, ikke en kategorietikett som «WooCommerce-spørringer». Formulering endrer resultater.
- Hvilke motorer som ble testet, og om resultater rapporteres per motor eller blandet til en score.
- Om hvert tall kom fra et forbrukergrensesnitt eller en API-proxy. Vår egen Q2-syklus viste at disse er uenige nok til at mixing er misvisende som standard.
- Datoen hver figur ble produsert. Et siteringssnapshot fra for tre måneder er ikke aktuell status.
- Konkurrentdomener sitert i stedet for dere, ikke bare egen tilstedeværelse eller fravær.
- Spørringsfamilier rapportert separat: identitet, informasjon, transaksjonell, og enhver implementerings- eller agentspesifikk familie relevant for virksomheten.
- Om overvåkingen tok hensyn til rendering. Hvis nettstedet eller konkurrentsettet bruker tung klient-side-rendering, spør om leverandørens metode i det hele tatt kan oppdage innhold bak JavaScript.
Hva on-page versus off-page fikser for hver gaptype
Overvåking forteller hvilken familie som er ødelagt. Den fikser ingenting alene, og fiksen avhenger av hvilken gaptype dere ser på.
Identitets- og informasjonsgap responderer vanligvis på on-page-arbeid: serverrendret HTML med bærende fakta til stede i raw-svaret, strukturerte data, faktatette innholdsblokker og tydelige entity-signaler som løser hvem dere er og hva dere gjør. Dette er gulvet, og det er table stakes nettopp fordi de fleste vestlige AI-assistenter bare leser raw HTML heller enn å kjøre klient-side JavaScript. Hvis nøkkelfakta laster bak et skript, fikser ingen on-page-polering gapet, fordi assistenten aldri så innholdet i utgangspunktet.
Transaksjonelle og AI-implementeringsgap lukkes sjelden med nok en FAQ-blokk eller en omskrevet landingsside. Modeller siterer det det åpne nettet bekrefter: uavhengige tekniske svar, verifiserbare katalogoppslag, tredjepartsomtaler og off-page-signaler som forsterker entityen utover eget domene. Vårt baseline-null på WooCommerce- og AI-implementeringsprompts vedvarte til tross for allerede modent on-page-innhold - det er i seg selv diagnosen: når on-page-kvalitet ikke er flaskehalsen, må fiksen flytte off-page. For norske Woo-butikker betyr det ofte synlighet i uavhengige ERP-integrasjonssammenligninger og partner-case-studier, ikke nok et H2 på egen tjenesteside.
AI- og LLM-synlighets-playbooken ordner disse spakene slik vi implementerer dem i kundeprogrammer: først on-page som gulv, deretter off-page som spaken som faktisk flytter transaksjonelle siteringsrater.
Avsluttende merknad
Overvåking er ikke målstreken - det er instrumentet som forteller hvor dere skal bruke. En enkelt AI-synlighets-score vil alltid smigre den letteste seieren og skjule det dyreste gapet, som er nøyaktig baklengs av det innkjøp trenger. Skill etter spørringsfamilie, spor merkeomtale, URL-sitering, konkurrentdomener og share of voice heller enn et blandet aggregat, kjør ukentlige stikkprøver og batch-re-kjøringer hver sjette til åtte uke, og siter aldri et tall uten å oppgi motor, dato og om det kom fra forbrukergrensesnitt eller API-proxy. En WordPress-spesifikk implementeringssjekkliste finner dere i WordPress AI-søk GEO/AEO. Hvis dere vil ha denne instrumenteringen bygget og drevet mot egen eiendom, knyttet til on-page- og off-page-fiksene hver gaptype faktisk trenger - det er programmet vår tjeneste GEO- og LLMO-optimalisering leverer.
