En knowledge graph, på dansk en vidensgraf, organiserer viden om ting og deres forbindelser. Virksomheder, personer, produkter, emner og steder beskrives som entities, der knyttes sammen med navngivne relationer.

Begrebet er veletableret inden for data og AI, selv om de præcise definitioner varierer. Grundidéen er at beskrive, hvad noget er, og hvordan det hænger sammen med andet. En knowledge graph kan implementeres på flere måder. ([emse.fr](https://www.emse.fr/~zimmermann/Papers/csur2021.pdf))

Hvad er entities og relationer?

En entity er en identificerbar ting eller et begreb. I grafen repræsenteres den som et knudepunkt. Relationerne er forbindelserne mellem knudepunkterne, og deres navne fortæller, hvad forbindelserne betyder.

Tænk på en fiktiv B2B-virksomhed, NordTek:

• NordTek udvikler produktet FlowPlan.
• Maja Jensen arbejder for NordTek.
• NordTek har hovedkontor i Aarhus.
• FlowPlan bruges til produktionsplanlægning.
• En kundecase beskriver brugen af FlowPlan.

Virksomheden, personen, produktet, stedet, emnet og kundecasen kan forbindes i samme model. Relationer som »arbejder for« og »udvikler« har hver deres betydning. ([emse.fr](https://www.emse.fr/~zimmermann/Papers/csur2021.pdf))

Entydig identifikation gør det muligt at samle oplysninger om samme entity på tværs af kilder. Et produkt kan godt have tre kælenavne i salgsafdelingen. Systemet bør vide, at det stadig er samme produkt. ([w3.org](https://www.w3.org/TR/rdf12-primer/))

Hvordan adskiller en knowledge graph sig fra en dokumentdatabase?

En dokumentdatabase samler typisk oplysninger i dokumenter, eksempelvis en produktpost med navn, egenskaber og beskrivelser. Den kan også bruge referencer mellem dokumenter. I en knowledge graph er de navngivne relationer en central del af datamodellen. ([mongodb.com](https://www.mongodb.com/docs/manual/data-modeling/concepts/embedding-vs-references/))

Grafen kan derfor bruges til at følge forbindelser gennem flere led. Et spørgsmål som »Hvilke kundecases handler om produkter til produktionsplanlægning?« kan besvares ved at forbinde cases, produkter og emner, hvis oplysningerne er modelleret.

Dokumenter og grafer kan supplere hinanden. Produktark og cases leverer forklaringer og belæg, mens grafen beskriver udvalgte sammenhænge mellem oplysningerne. ([emse.fr](https://www.emse.fr/~zimmermann/Papers/csur2021.pdf))

Hvordan hænger RDF og schema.org sammen med knowledge graphs?

RDF står for Resource Description Framework. Det er en datamodel til at udtrykke oplysninger som udsagn med tre dele: subjekt, relation og objekt. Et forenklet eksempel er »NordTek – udvikler – FlowPlan«. Sådanne udsagn kaldes triples og kan tilsammen danne en graf. RDF understøtter også værdier som navne, datoer og tal. ([w3.org](https://www.w3.org/TR/rdf12-primer/))

Schema.org er et fælles ordforråd til at beskrive blandt andet virksomheder, personer, produkter og steder med strukturerede data. Det giver betegnelser som Organization, Person og Product samt egenskaber, der beskriver dem. Ordforrådet kan bruges på websites, så søgemaskiner får tydeligere oplysninger om indholdets betydning. ([schema.org](https://schema.org/docs/gs.html))

RDF og schema.org udfylder altså forskellige roller: RDF beskriver modellen for udsagn, mens schema.org leverer et ordforråd. En knowledge graph behøver ikke bruge RDF, og schema.org-markup på et website udgør ikke nødvendigvis en samlet virksomhedsvidensgraf. ([emse.fr](https://www.emse.fr/~zimmermann/Papers/csur2021.pdf))

Hvorfor er knowledge graphs relevante for søgning og AI visibility?

Google har sin egen Knowledge Graph med entities som organisationer, personer og steder. Google beskriver også, hvordan strukturerede data om en organisation kan hjælpe med at identificere virksomheden og skelne den fra andre organisationer i søgeresultaterne. ([developers.google.com](https://developers.google.com/knowledge-graph))

For en marketingansvarlig peger det mod et konkret arbejde: Beskriv tydeligt, hvem virksomheden er, hvilke produkter den tilbyder, og hvordan indholdet hænger sammen. Brug konsekvente navne, præcise beskrivelser og relevante strukturerede data.

Effekten på AI visibility bør vurderes med forbehold. Google kræver ingen særlig schema.org-markup til AI Overviews eller AI Mode. Strukturerede data skal stemme med sidens synlige indhold, og opfyldte krav giver ingen garanti for visning. Den vejledning gælder Googles egne søgefunktioner. ([developers.google.com](https://developers.google.com/search/docs/appearance/ai-features))

Hvordan kan AI bruge en knowledge graph?

Knowledge graphs kan indgå i systemer, der finder relevant viden til en sprogmodel. Microsofts GraphRAG er et eksempel: Systemet udtrækker entities og relationer fra tekst og bruger grafen sammen med opsummeringer som grundlag for AI-svar. ([microsoft.github.io](https://microsoft.github.io/graphrag/))

En intern assistent kunne eksempelvis forbinde et produkt med dets anvendelsesområder, relevante cases og ansvarlige fagpersoner. Det kræver, at oplysningerne findes, forbindelserne er korrekte, og assistenten har adgang til dem.

En intern graf bliver kun brugbar for de systemer, der får adgang til den. Ekstern synlighed og intern vidensstruktur bør derfor behandles som to særskilte opgaver.

HappiLeap-perspektivet: Afprøv behovet med rigtige spørgsmål

Hos HappiLeap bruger vi entity clarity som et praktisk arbejdsbegreb for entydig identitet og tydelige forbindelser. Start med at afklare, hvad der er virksomhed, brand, produkt og emne, og hvilke navne der dækker samme ting.

Arbejdsreglen er enkel: Vælg fem spørgsmål, som kunder eller medarbejdere faktisk stiller. Kortlæg de entities og relationer, der skal til for at besvare dem. Det giver et konkret grundlag for at vurdere, om en knowledge graph er relevant.

Lav derefter en ændringstest: Hvis et produkt skifter navn eller udgår, hvem retter oplysningerne, og hvilke forbindelser skal opdateres? Knyt centrale oplysninger til en aftalt source of truth og en ansvarlig ejer. En graf kan også forbinde forældede oplysninger ganske effektivt.

Structured data, eller strukturerede data, er oplysninger organiseret efter en defineret struktur, så maskiner kan fortolke deres betydning. På et website kan det eksempelvis beskrive en virksomhed, et produkt, en artikel eller en begivenhed.

I SEO bruges begrebet især om schema markup: maskinlæsbare oplysninger i sidens kode, som hjælper søgemaskiner med at forstå indholdet og kan gøre siden egnet til bestemte udvidede søgeresultater.

Hvordan hænger schema.org og JSON-LD sammen?

Tre begreber optræder ofte i samme samtale:

• Structured data er den overordnede betegnelse for strukturerede oplysninger.
• Schema.org er et fælles ordforråd med typer og egenskaber. Organization beskriver eksempelvis en organisation, mens name angiver dens navn.
• JSON-LD er et format til at skrive oplysningerne ind i websiden.

Schema.org leverer altså betegnelserne, og JSON-LD leverer en måde at udtrykke dem på. Google anbefaler normalt JSON-LD, fordi det er forholdsvis nemt at implementere og vedligeholde. Oplysningerne ligger typisk i en særskilt kodeblok uden at ændre sidens udseende.

Hvilke oplysninger er relevante for B2B?

Markeringen hjælper med at afklare, hvad en oplysning beskriver, og hvordan den hænger sammen med andre oplysninger. Et navn kan eksempelvis tilhøre virksomheden, artiklens forfatter eller et produkt.

Relevante typer på et B2B-website omfatter ofte:

• Organization: virksomhedsnavn, logo, adresse og kontaktoplysninger.
• Article: artikeloverskrift, forfatter og publiceringsdato.
• Product: produktinformation og eventuelt pris, tilgængelighed og anmeldelser.
• Event: oplysninger om eksempelvis et fagligt arrangement.
• BreadcrumbList: sidens placering i websitets hierarki.

En softwarevirksomhed kan eksempelvis beskrive virksomheden som Organization og en fagartikel som Article med en navngiven forfatter. Det tydeliggør både indholdets type og dets afsender.

Organization-markup kan også hjælpe Google med at skelne virksomheden fra andre organisationer. Det er særligt relevant, når navnet deles med flere virksomheder.

Structured data, rich results og ranking

De tre begreber beskriver forskellige dele af søgningen:

• Structured data er de oplysninger, websitet stiller til rådighed.
• Rich results er udvidede visninger i søgeresultaterne, eksempelvis produktinformation med pris eller anmeldelsesstjerner.
• Ranking er placeringen af et resultat i forhold til andre resultater.

Korrekt markup kan gøre en side kvalificeret til en understøttet visning. Google garanterer dog ikke, at visningen bliver brugt, selv når implementeringen består en teknisk test.

Structured data er heller ikke i sig selv en generel rankingfaktor. Det kan hjælpe Google med at forstå siden og vise den i relevante sammenhænge. Et løfte om højere placeringer alene gennem mere schema markup går længere end Googles dokumentation.

Schema.org rummer desuden flere typer og egenskaber, end Google understøtter som rich results. Googles aktuelle dokumentation afgør, hvilke visninger man kan arbejde hen imod.

Forbedrer schema markup AI visibility?

Schema markup giver en tydelig beskrivelse af indholdet. En automatisk forbedring af AI visibility eller garanti for at blive citeret i AI-svar kan man ikke udlede af det.

Googles aktuelle vejledning om generativ søgning er konkret: Structured data er ikke et krav for generative søgefunktioner, og der kræves ingen særlig schema.org-markup. Det gælder vejledningen for blandt andet AI Overviews og AI Mode.

Google anbefaler fortsat almindeligt SEO-arbejde med nyttigt, troværdigt indhold og en tilgængelig teknisk struktur. Sider skal være indekserede og kunne vises med et tekstuddrag. Websitet skal også være inkluderet i generative søgefunktioner via indstillingerne i Search Console. Opfyldte krav giver ingen garanti for visning.

Et tilbud om særligt “AI-schema” bør derfor følges af et spørgsmål: Hvilken platform dokumenterer, at den bruger markeringen, og til hvad? Googles vejledning dokumenterer Googles praksis. Påstande om andre AI-platforme kræver deres egen dokumentation.

Sådan arbejder du med structured data

1. Undersøg det eksisterende setup. Jeres CMS eller SEO-plugin kan allerede generere markup. Få overblik, før I tilføjer mere.
2. Vælg relevante sidetyper. Tag udgangspunkt i sidens faktiske indhold og de søgefunktioner, der er relevante for virksomheden.
3. Brug korrekte, synlige oplysninger. Markuppen skal afspejle sidens indhold. Undlad opdigtede priser, anmeldelser og egenskaber.
4. Test og kontrollér. Brug Googles Rich Results Test til understøttede visninger og Search Console til at undersøge, hvordan Google ser siden.
5. Vedligehold og mål. Opdater markuppen sammen med indholdet, og følg relevante visninger og klik over tid.

En pris fra sidste kvartal bliver ikke mere aktuel af at stå i JSON-LD. Teknisk gyldighed og faktuel korrekthed skal kontrolleres hver for sig.

HappiLeap-perspektivet: Giv hvert felt en ejer

Hos HappiLeap bruger vi en enkel arbejdsregel: Hvert centralt felt i markuppen skal have en autoritativ kilde og en ansvarlig ejer. Produktteamet kan eksempelvis eje produktinformationen, mens marketing ejer virksomhedsbeskrivelsen.

Ved ændringer skal den synlige side og markuppen følge samme godkendte information. Aftal derfor, hvor oplysningerne kommer fra, hvem der godkender dem, og hvordan ændringer bliver publiceret.

Vurder også indsatsen ud fra et konkret formål: mere præcis virksomhedsidentifikation, mulighed for en relevant søgevisning eller færre modstridende oplysninger. Det giver et bedre beslutningsgrundlag end antallet af schema-typer, et værktøj kan sætte flueben ved.

Et agent-ready website er et website eller en digital service, som AI-agenter kan forstå og bruge til at løse konkrete opgaver. Det kan være at sammenligne produkter, hente dokumentation eller sende en tilbudsforespørgsel på en kundes vegne.

Begrebet er nyere og har ikke én universelt accepteret definition. Det betegner heller ikke en officiel webstandard. Hos HappiLeap bruger vi det som en praktisk ramme for at gøre udvalgte kundeopgaver gennemførlige med tydelig information, brugbare interfaces og klare adgangsregler.

Fra læsbar information til mulige handlinger

Agent-readiness omfatter to forskellige opgaver.

Information skal kunne forstås. Agenten skal kunne identificere virksomheden, dens ydelser, produkternes egenskaber og relevante vilkår. Klare overskrifter, konkrete beskrivelser og konsistente oplysninger giver et bedre grundlag for at arbejde med indholdet.

Structured data, eksempelvis Schema.org-markup, kan beskrive, hvilke oplysninger der handler om en organisation, et produkt eller et tilbud. Det supplerer sidens indhold med en maskinlæsbar struktur.

Handlinger skal kunne gennemføres. Agenten skal have en brugbar vej til eksempelvis at vælge en service, udfylde en formular eller oprette en forespørgsel. Det kræver tydelige input, forståelige trin og et resultat, der kan kontrolleres.

En produktside kan altså give et godt grundlag for en sammenligning, mens tilbudsformularen stadig kræver, at nogen ringer til Lars for at forstå feltet “Kategori B”.

Hvordan arbejder AI-agenter med websites?

En AI-agent kan arbejde mod et mål gennem flere trin og bruge værktøjer undervejs. Hvordan den møder virksomhedens website, afhænger af agentløsningen.

Computer use: Agenten bruger grænsefladen

Ved computer use kan en model betjene en browser eller anden brugergrænseflade gennem software. Den kan eksempelvis vurdere skærmbilleder, klikke på knapper og udfylde formularer.

For websiteejeren gør det tydelig navigation, genkendelige betjeningselementer og forståelige formularforløb relevante. Om agenten faktisk kan gennemføre opgaven, skal testes.

Tool calling: Agenten kalder en funktion

Tool calling betyder, at modellen anmoder om at bruge et tilgængeligt værktøj. Det kan eksempelvis være en funktion, der henter produktdata eller opretter en tilbudsforespørgsel via et API. Et API er en grænseflade, som software kan bruge til at udveksle data eller anmode om handlinger.

Softwaren omkring modellen udfører kaldet og sender resultatet tilbage. Virksomheden bør derfor beskrive funktionens formål, nødvendige oplysninger og mulige resultater præcist.

MCP: En fælles måde at forbinde værktøjer på

MCP, Model Context Protocol, er en åben protokol for at forbinde AI-applikationer med eksterne data og værktøjer. En virksomhed kan eksempelvis stille udvalgte funktioner til rådighed gennem en MCP-server.

Den konkrete agentløsning skal være forbundet med serveren og have den nødvendige adgang. Et API eller en MCP-server på virksomhedens side giver ikke automatisk alle agenter adgang. Valget af integration bør følge opgaven og de systemer, der skal bruge den.

Hvad bør en B2B-virksomhed gennemgå?

En praktisk gennemgang kan begynde med fem områder:

1. Gældende fakta: Er produktnavne, specifikationer og vilkår konsistente? Udpeg en ansvarlig for oplysningerne, så website og eventuelle integrationer bygger på samme grundlag.
2. Tilgængeligt indhold: Kan relevante løsninger og dokumenter findes gennem tydelige links? Sørg for, at centrale oplysninger også er tilgængelige som tekst.
3. Formularer: Har felterne klare navne og instruktioner? Bed om de oplysninger, opgaven kræver, og forklar fejl, så de kan rettes.
4. Integrationer: Hvis virksomheden tilbyder APIs eller værktøjer, bør dokumentationen forklare adgang, input, begrænsninger og svar. Afgræns funktionerne til konkrete opgaver.
5. Bekræftelse: Vis, hvad der er sket efter en handling. En kvittering bør gøre det tydeligt, om en forespørgsel er modtaget, en booking er gennemført, eller noget stadig afventer.

Eksempel: En agent anmoder om en demo

En softwarevirksomhed tilbyder løsninger til facility management. En potentiel kunde beder sin agent undersøge, om løsningen understøtter flere lokationer, og derefter anmode om en demo.

Agenten skal først kunne finde præcise oplysninger om funktionen. Derefter skal den kunne identificere demoformularen eller et tilgængeligt bookingværktøj, indtaste godkendte kontaktoplysninger og kontrollere kvitteringen.

Virksomheden bør tydeliggøre, om kunden har reserveret et tidspunkt eller blot bedt om at blive kontaktet. Den forskel kan let blive til en tom plads i kalenderen.

Sikker adgang er en del af opgaven

Fastlæg, hvilke oplysninger der er offentlige, og hvilke handlinger der kræver login, bestemte rettigheder eller brugerens godkendelse. Køb, ændringer og videregivelse af følsomme oplysninger bør have passende kontrolpunkter.

Rettigheder og validering skal håndhæves i virksomhedens systemer. Instruktioner til modellen kan supplere kontrollen. En hjemmeside bør heller ikke kunne give agenten tilladelse til handlinger, som brugeren ikke har godkendt.

HappiLeap-perspektiv

Vores arbejdsregel er: Vurder agent-readiness pr. kundeopgave. Vælg eksempelvis tre opgaver fra kunderejsen, og undersøg for hver: Kan agenten forstå informationen, udføre den tilladte handling og kontrollere resultatet?

Registrér, hvor forløbet stopper. Manglende produktfakta kræver typisk arbejde med indholdet. Uklare formularer kræver arbejde med brugeroplevelsen. Manglende adgang til en funktion kan kræve en integration. Det giver marketing, salg og IT en konkret prioriteringsliste.

Byg videre på virksomhedens eksisterende website og relevante standarder. Test med de agentløsninger, kunderne forventes at bruge, i et afgrænset miljø. Kontrollér resultatet i det modtagende system, og gentag testen efter væsentlige ændringer. Succes måles her på korrekt gennemførte opgaver.

RAG står for Retrieval-Augmented Generation. Det er en etableret AI-metode, hvor et system finder relevante oplysninger og giver dem til en sprogmodel som grundlag for et svar.

I en B2B-virksomhed kan oplysningerne komme fra produktdokumentation, godkendte cases, servicevilkår eller andre udvalgte kilder. Modellen får dermed adgang til virksomhedsspecifik viden, når opgaven løses. Kilderne kan opdateres, uden at modellen skal trænes på ny for hver ændring.

Sådan fungerer RAG: Retrieve, augment og generate

Forestil dig, at en sælger spørger en intern AI-assistent: Hvad indeholder vores onboarding for enterprise-kunder?

1. Retrieve: Find oplysningerne. Systemet søger i de tilsluttede kilder og henter relevante afsnit, eksempelvis fra onboardingbeskrivelsen og de gældende servicevilkår. Det kan søge efter både bestemte ord og indhold med en beslægtet betydning.
2. Augment: Giv modellen et grundlag. De fundne oplysninger føjes til spørgsmålet sammen med instruktioner om, hvordan de skal bruges. Modellen kan eksempelvis få besked på at holde sig til materialet og markere manglende oplysninger.
3. Generate: Formulér svaret. Sprogmodellen bruger materialet til at skrive et sammenhængende svar. Løsningen kan også vise kildehenvisninger, så sælgeren kan kontrollere oplysningerne.

I en typisk RAG-løsning får modellen udvalgte dele af materialet ved den enkelte forespørgsel. Hele virksomhedens dokumentarkiv bliver altså ikke læst igennem hver gang.

Hvad bruger B2B-virksomheder RAG til?

RAG er relevant i opgaver, hvor svaret afhænger af virksomhedens konkrete viden. Mulige anvendelser er:

• Salg: Udkast til kundesvar baseret på gældende produktfunktioner, vilkår og dokumenterede cases.
• Marketing: Produkttekster og kampagneudkast med afsæt i godkendte budskaber og faktuelle oplysninger.
• Kundeservice: Svar baseret på vejledninger, supportartikler og kendte problemer.

Eksempelvis kan marketing bede AI om et webinarudkast om en ny produktfunktion. RAG kan hente den aktuelle produktbeskrivelse og relevante kundecases. Teamet skal stadig vurdere vinklen og kontrollere, at formuleringerne holder sig inden for dokumentationen.

Sammenhængen med grounding, knowledge bases og source of truth

Grounding betyder, at AI-svar forankres i konkrete, verificerbare oplysninger. RAG er en metode til grounding: Systemet henter materiale, som modellen kan bruge som grundlag. Grounding kan også ske ved, at en bruger selv giver modellen relevant materiale.

En knowledge base er den organiserede viden, løsningen kan søge i. Den kan bestå af dokumenter, artikler eller andre datakilder. Dens værdi afhænger blandt andet af, om indholdet er dækkende, forståeligt og tilgængeligt for søgningen.

AI-ready brand knowledge base bruger HappiLeap som et praktisk arbejdsbegreb for en struktureret, vedligeholdt samling af brand- og virksomhedsviden, der er egnet til AI-brug. Den kan give en RAG-løsning et mere sammenhængende grundlag for produktbeskrivelser, positionering og dokumentation.

En source of truth er den udpegede autoritative reference for en bestemt oplysning. Aftal eksempelvis, hvilken kilde der bestemmer, hvad et abonnement indeholder. RAG-løsningen skal kunne prioritere den gældende reference, når andre dokumenter beskriver noget andet.

Hvilke begrænsninger har RAG?

RAG kan forbedre svarenes faktuelle grundlag. Der er stadig flere steder, hvor kvaliteten kan svigte:

• Kilderne kan være forældede eller modstridende. RAG gør ikke automatisk materialet korrekt. Virksomheden skal sørge for, at ændringer bliver tilgængelige for søgningen. Gamle salgspræsentationer har ofte en imponerende levetid.
• Søgningen kan overse noget vigtigt. Systemet kan hente et relevant afsnit og samtidig mangle en afgørende undtagelse. Det kan give et ufuldstændigt svar.
• Modellen kan stadig fejle. Den kan misfortolke materialet, sammenblande oplysninger eller tilføje udokumenterede påstande. Hallucinationer er fortsat mulige.
• Adgang skal styres. Søgningen skal respektere brugerens rettigheder. En kundeassistent skal eksempelvis ikke kunne hente fortrolige interne oplysninger.

En kildehenvisning hjælper med kontrol. Kontrollér også, at kilden faktisk understøtter den konkrete påstand i svaret.

Hvordan hænger RAG sammen med AI visibility?

AI visibility handler i marketing om virksomhedens synlighed i AI-genererede svar. En intern RAG-løsning bruger de kilder, den har adgang til. At tilslutte interne dokumenter giver derfor ikke i sig selv virksomheden større synlighed i offentlige AI-tjenester.

Arbejdet med klare og konsistente oplysninger kan bruges både internt og i offentligt indhold. Vurder dog de to formål hver for sig: intern svarkvalitet og ekstern synlighed kræver forskellige målinger.

HappiLeap-perspektivet: Test spørgsmålene og kilderne sammen

Begynd med 15-20 spørgsmål, som salg, marketing eller kunder faktisk stiller. Udpeg den gældende kilde og det forventede svar til hvert spørgsmål. Så får I et konkret testgrundlag, før løsningen bliver en fast del af arbejdet.

Vores arbejdsregel er at kontrollere tre ting: Fandt systemet det relevante materiale? Understøtter materialet svarets påstande? Besvarer svaret hele spørgsmålet? Et velformuleret svar kan sagtens dumpe på de to sidste.

Aftal også, hvornår løsningen skal markere manglende dokumentation eller sende opgaven videre til et menneske. Ved ændringer i produkter og vilkår bør de berørte testspørgsmål køres igen. Det gør vedligeholdelse til en synlig opgave med en ansvarlig ejer.

Hvad er AEO?

AEO står for Answer Engine Optimization og bruges typisk om arbejdet med at gøre indhold let at finde, forstå og anvende i søge- og AI-systemer, der giver direkte svar på brugerens spørgsmål.

Det kan eksempelvis være et fremhævet uddrag i Google eller et genereret svar i Google AI Overviews, AI Mode eller Microsoft Copilot. Svarformen kan være forskellig: Et system kan fremhæve en passage eller sammensætte en forklaring fra flere kilder.

AEO har ikke én universelt fastlagt definition. Hos HappiLeap bruger vi begrebet om arbejdet med at gøre virksomhedens faglige indhold brugbart som svar på reelle spørgsmål.

Hvordan hænger AEO sammen med SEO, GEO og AI visibility?

Begreberne overlapper. En praktisk måde at skelne mellem dem er:

• SEO er det brede arbejde med at gøre indhold tilgængeligt, forståeligt og synligt i søgemaskiner.
• AEO lægger vægt på, om indholdet besvarer spørgsmål tydeligt og kan anvendes i direkte svar.
• GEO, Generative Engine Optimization, fokuserer på synlighed i svar, som generative AI-systemer sammensætter.
• AI visibility beskriver virksomhedens synlighed og repræsentation i AI-systemer, eksempelvis gennem omtale, kildehenvisninger og links.

Afgrænsningen mellem AEO og GEO varierer i praksis. AEO bruges også om svarformater uden generativ AI.

AEO er ikke en officiel, separat Google-disciplin. Google beskriver optimering til sine generative søgefunktioner som SEO og understreger, at de grundlæggende SEO-principper fortsat gælder.

Hvordan kan indhold blive en del af et svar?

AI-baseret søgning kan hente relevante websider og bruge informationen som grundlag for et svar. Det kaldes grounding. Indholdet kan dermed bidrage til en forklaring, hvor flere kilder indgår.

For Googles generative søgefunktioner skal en side blandt andet være indekseret og kunne vises med et tekstuddrag i almindelig søgning. Teknisk tilgængelighed er derfor stadig en forudsætning.

En velformuleret side giver ingen garanti for at blive valgt eller citeret. Systemet vurderer relevansen i forhold til den konkrete forespørgsel.

Sådan arbejder du med AEO i praksis

1. Besvar kundens konkrete spørgsmål

Start med spørgsmål fra salg, kundeservice og faglige rådgivere. Hvad skal kunden vide for at forstå løsningen, vurdere risikoen eller vælge næste skridt?

Hos en tænkt softwareleverandør kunne spørgsmålet være: Kan systemet bruges på flere fabrikker?

Et tydeligt svar kunne lyde: Systemet samler vedligeholdelsesopgaver fra flere fabrikker. Hver fabrik kan have egne planer og adgangsrettigheder. Fælles rapportering er en tilvalgsfunktion.

Svaret gør både muligheder og begrænsninger konkrete. Ordet fleksibel har allerede haft et langt arbejdsliv i B2B-marketing.

2. Giv indholdet en brugbar struktur

Brug en beskrivende titel og overskrifter, som hjælper læseren med at finde svarene. På en produktside kan det være integrationer, adgangsrettigheder, implementering og begrænsninger.

Placér den centrale forklaring tidligt og uddyb bagefter. Lister fungerer godt til krav og trin. Sammenligninger bør bruge de samme kriterier for alle løsninger.

Strukturen skal passe til emnet. Der er ingen grund til at presse en kompleks forklaring ind i en række små FAQ-svar.

3. Underbyg påstandene

Gør det muligt at vurdere, hvor oplysningerne kommer fra. Brug relevante kilder, navngivne fagpersoner, dokumenterede cases og egne erfaringer.

Hvis en case beskriver en tidsbesparelse, bør den også forklare opgaven, målemetoden og betingelserne. Et resultat fra én implementering kræver kontekst, før andre kan bruge det i deres beslutning.

Original faglig viden kan eksempelvis være en specialists forklaring af, hvorfor en integration ofte bliver forsinket, og hvad kunden bør afklare på forhånd.

4. Hold svarene tilgængelige og opdaterede

Kontrollér, at vigtige sider kan findes og læses af de relevante søgesystemer. Gode interne links og et sundt teknisk SEO-fundament hjælper med at gøre indholdet tilgængeligt.

Udpeg samtidig en ansvarlig for centrale oplysninger. Produktnavne, funktioner og vilkår bør være konsistente på tværs af sider. Opdatér indholdet, når fakta ændrer sig.

Hvordan måler man AEO?

Der findes ingen fælles AEO-score på tværs af platforme. Følg de observationer, som passer til virksomhedens mål.

Google Search Console har særskilt rapportering af visninger i generative søgefunktioner som AI Overviews og AI Mode. Bing Webmaster Tools har AI Performance, som blandt andet viser citationer, citerede sider og et udvalg af de søgefraser, AI-systemet brugte til at hente information.

Bings citationstal viser kildehenvisninger. De angiver ikke en sides placering eller betydning i det enkelte svar.

Følg samtidig organisk trafik og kvalificerede henvendelser. Hold observationer af AI-synlighed adskilt fra dokumentation for forretningsresultater.

HappiLeap-perspektivet: Brug en svartest før publicering

Hos HappiLeap anbefaler vi en enkel redaktionel svartest: Kan en fagligt relevant læser forstå svaret, se betingelserne og vurdere dokumentationen uden at booke et møde først?

Gennemgå en vigtig side med fire spørgsmål: Hvilket spørgsmål besvarer den? Hvor står svaret? Hvad underbygger det? Hvad kan læseren gøre bagefter?

Hvis testen afslører huller, bør de ind i indholdsplanen. Prioritér spørgsmål, der påvirker kundens valg, eksempelvis anvendelighed, integrationer og begrænsninger. Testen er vores praktiske arbejdsregel og kan bruges, før man investerer i mere avanceret måling.

Hvad er GEO?

GEO står for Generative Engine Optimization. Begrebet bruges typisk om arbejdet med at forbedre virksomheders og indholds synlighed i AI-genererede søgesvar, eksempelvis Google AI Overviews, AI Mode og Microsoft Copilot. Målet kan være at blive vist som kilde, få en side citeret eller få virksomheden omtalt relevant.

GEO er et nyere begreb uden én universelt accepteret definition eller metode. Forskning, platforme og rådgivere bruger det med lidt forskellige afgrænsninger.

I generativ søgning kan systemet hente information fra flere websider og bruge den som grundlag for svaret. Det kaldes grounding. En citation er her en kildehenvisning, som kan indeholde et link. Den behøver ikke være et ordret citat.

Hvor kommer begrebet fra?

GEO blev introduceret som forskningsramme af Pranjal Aggarwal og kolleger i artiklen GEO: Generative Engine Optimization, først offentliggjort den 16. november 2023 og senere accepteret til KDD 2024. Forskerne undersøgte, hvordan ændringer i webindhold påvirkede kilders synlighed i genererede svar.

Blandt de undersøgte greb var tilføjelse af kildehenvisninger, citater og statistik. Studiet rapporterede forbedringer på op til 40 procent i sine synlighedsmål. Resultaterne afhængede af emne, metode og forsøgsopsætning. Tallet beskriver effekter i undersøgelsen og kan ikke bruges som løfte om mere trafik eller flere citationer på nutidens platforme.

Hvordan hænger GEO sammen med SEO, AEO og AI visibility?

En praktisk arbejdsinddeling er:

• SEO: Arbejdet med at gøre indhold tilgængeligt, forståeligt og relevant i søgemaskiner, herunder deres generative funktioner.
• AEO: Answer Engine Optimization, som fokuserer på synlighed i oplevelser, der leverer direkte svar. Begrebet overlapper betydeligt med GEO.
• AI visibility: Det bredere billede af, hvordan en virksomhed optræder i AI-baserede søge- og svarsystemer, eksempelvis gennem omtale og kildehenvisninger.

Google betragter optimering til generative søgefunktioner som SEO. GEO kan derfor bruges som et fokusområde i det eksisterende arbejde med søgning, indhold og faglig positionering.

Hvordan arbejder en B2B-virksomhed med GEO?

Start med kundernes informationsbehov og jeres vigtigste referencesider:

1. Kontrollér tilgængeligheden. Siderne skal kunne findes og behandles af den relevante platform. For Google skal de være indekserede og kunne vises med et tekstuddrag. Kontrollér også indstillingen for generative AI-funktioner i Search Console.
2. Besvar konkrete spørgsmål. Brug salgsdialoger og kundeservice til at finde spørgsmål om krav, integrationer, omkostninger og valg af løsning. Organisér svarene med klare overskrifter.
3. Publicér dokumenterbar viden. Brug egne erfaringer, cases, faglige forklaringer og relevante data. Beskriv metode og begrænsninger, når I offentliggør tal eller resultater.
4. Vedligehold oplysningerne. Hold produktnavne, funktioner og centrale fakta konsistente. Forbind forklaringer, produkter og cases med interne links, og giv opdateringer en ansvarlig ejer.

En softwareleverandør kan eksempelvis forklare, hvilke datakilder løsningen understøtter, hvordan implementeringen foregår, og hvilke forudsætninger kunden skal opfylde. Det giver et konkret grundlag for research og sammenligning. Formuleringen »fleksibel platform« besvarer forbavsende få indkøbsspørgsmål.

Hvilke GEO-principper er dokumenterede?

Platformenes officielle vejledninger peger på tilgængeligt indhold, klar struktur, original ekspertise og opdaterede oplysninger. Der findes ingen offentlig opskrift, som garanterer citationer. Forskningsresultater skal vurderes ud fra den undersøgte platform og målemetode.

Google oplyser specifikt, at Search ignorerer llms.txt og ikke kræver særlig AI-markup eller en bestemt opdeling i små tekststykker. Masseproduktion af sider for at manipulere generative svar kan desuden overtræde Googles spamregler. Disse oplysninger handler om Google og bør ikke automatisk overføres til andre tjenester.

Hvordan måler man GEO og AI-synlighed?

Google Search Console

Google lancerede særskilte rapporter for generative AI-funktioner den 3. juni 2026 og meddelte fuld global udrulning den 31. august 2026.

Rapporten Generative AI performance for Search viser impressions, altså eksponeringer af links til sitet, i blandt andet AI Overviews og AI Mode. Data kan undersøges efter sider, lande, enheder og datoer. Discover har en separat rapport. Dermed kan I følge, hvilke URL’er der opnår synlighed, og hvordan eksponeringerne udvikler sig.

Bing Webmaster Tools

Microsoft introducerede AI Performance i offentlig preview den 10. februar 2026. Rapporten viser citationer og citerede URL’er på tværs af Copilot, AI-genererede Bing-svar og udvalgte partneroplevelser.

Den viser også grounding queries: de søgefraser, systemet brugte til at hente kildeindhold. De er et udsnit af aktiviteten og skal ikke læses som en komplet liste over brugernes oprindelige spørgsmål.

Den 16. juni 2026 blev preview udvidet med Intents, Topics, Citation Share og Compare. Funktionerne grupperer forespørgsler efter hensigt og emne, viser sitets andel af citationerne for en bestemt grounding query og sammenligner perioder. Citation Share måler citationernes fordeling, ikke trafikandel eller en kvalitetsvurdering.

Hold platformenes målinger adskilt, og supplér med websiteanalyse og kvalitative observationer. Eksponeringer og citationer fortæller ikke i sig selv, om synligheden skaber relevante besøg eller henvendelser.

HappiLeap-perspektivet: Gør GEO til et afgrænset forbedringsarbejde

Hos HappiLeap bruger vi GEO som et praktisk fokusområde: Hvilke kundespørgsmål skal virksomhedens offentlige viden kunne besvare troværdigt?

Vælg eksempelvis ti vigtige spørgsmål og fem eksisterende sider. Registrér udgangspunktet, forbedr forklaringer og dokumentation, og aftal på forhånd, hvilke målinger I følger. Hold en ændringslog, så udviklingen kan sammenholdes med konkrete opdateringer.

Vurdér både omfang og relevans: Bliver de rigtige sider citeret, og bliver virksomhedens kompetencer gengivet korrekt? En stigning efter en opdatering giver anledning til undersøgelse. Modeller, efterspørgsel og andre kilder kan også have ændret sig.

Hvad er AI governance?

AI governance betegner de principper, roller, processer og kontroller, en virksomhed bruger til at styre sin anvendelse af AI ansvarligt og konsistent.

Det handler om konkrete beslutninger: Hvem må bruge hvilke værktøjer? Hvilke oplysninger må deles? Hvem godkender resultatet? Og hvem tager ansvar, når noget går galt?

Begrebet bruges i flere faglige rammer. I en almindelig B2B-virksomhed omfatter det både indkøb, adgang, arbejdsprocesser, kvalitetskontrol og løbende opfølgning.

Hvad skal AI governance dække i praksis?

En brugbar governance-model bør give medarbejderne tydelige svar på fem områder:

1. Værktøjer og adgang: Vedligehold en liste over godkendte AI-værktøjer og deres tilladte anvendelser. Beskriv, hvilke medarbejdere der må bruge dem, og hvordan nye værktøjer bliver vurderet. Medtag AI-funktioner i eksisterende systemer og relevante bureauers brug på virksomhedens vegne.
2. Data: Fastlæg, hvilke oplysninger der må deles med hvert værktøj. Vurdér personoplysninger, kundeaftaler og fortrolig viden særskilt. Undersøg leverandørens databehandling, opbevaring og eventuelle brug af data til træning.
3. Output og godkendelse: Aftal, hvornår en medarbejder selv må bruge resultatet, og hvornår en faglig godkender skal involveres. Beskriv, hvad kontrollen skal omfatte, eksempelvis fakta, produktpåstande, rettigheder og kundeløfter.
4. Dokumentation: Registrér formål, værktøj, ansvarlig, datatyper, væsentlige risici og aftalte kontroller for tilbagevendende anvendelser. Gem relevante godkendelser og testresultater. Tilpas dokumentationens omfang til risikoen.
5. Fejl og ændringer: Gør det tydeligt, hvor fejl rapporteres, hvem der undersøger dem, og hvem der kan standse brugen. Aftal også, hvornår ændringer i værktøj, data eller anvendelse kræver en ny vurdering.

En værktøjsgodkendelse bør altid have et afgrænset formål. Godkendelse til tekstudkast siger eksempelvis ikke i sig selv noget om tilladelse til at dele kundedata.

Hvem ejer beslutningerne?

Ledelsen bør fastlægge virksomhedens risikovillighed og placere ansvaret for væsentlige beslutninger. En koordinator kan holde styr på politikker, værktøjslisten og opfølgningen.

Fordel derefter opgaverne efter faglig kompetence. IT og sikkerhed vurderer adgang og leverandørforhold. Marketing ejer godkendelsen af brandbudskaber og kampagneindhold. Produktansvarlige verificerer produktpåstande. Juridisk eller databeskyttelsesfaglig hjælp inddrages, når anvendelsen kræver det.

Hver tilbagevendende AI-anvendelse bør have en navngiven ejer med mandat til at ændre eller stoppe processen. En kollega på ferie bør ikke være virksomhedens eneste sikkerhedsmekanisme.

Hvordan vurderer man risikoen?

Start med tre spørgsmål: Hvem kan blive påvirket? Hvor sandsynlig og alvorlig er en fejl? Hvor hurtigt kan den opdages og stoppes?

Et udkast til et opslag baseret på offentlige produktfakta kan have en enkel godkendelsesproces. En løsning, der læser kundeaftaler og automatisk sender tilbud, bør vurderes mere grundigt og testes før brug.

Se på både datalæk, faktuelle fejl, skævheder og utilsigtede handlinger. Hold virksomhedens vurdering af forretningsrisiko adskilt fra AI Acts juridiske risikoklassifikation.

Hvad betyder AI Act for governance?

EU’s AI Act har en risikobaseret tilgang. Virksomhedens konkrete forpligtelser afhænger blandt andet af anvendelsen og dens rolle som udbyder eller bruger af et AI-system.

Artikel 50 indeholder specifikke transparenskrav, blandt andet om information ved AI-interaktion og om AI-genereret eller manipuleret indhold som deepfakes. Reglerne indebærer forskellige opgaver for udbydere og virksomheder, der anvender systemerne.

Governance bør derfor omfatte en proces for at afklare relevante krav og undtagelser. Konkrete juridiske spørgsmål skal vurderes ud fra den aktuelle lovgivning og virksomhedens situation.

AI literacy gør reglerne anvendelige

AI literacy omfatter viden og færdigheder til at forstå, bruge og vurdere AI med blik for muligheder og risici.

AI Acts artikel 4 kræver, at udbydere og virksomheder, der anvender AI-systemer, understøtter udviklingen af AI-kompetencer hos relevante medarbejdere og andre, der arbejder med systemerne på deres vegne. Indsatsen skal tilpasses deres erfaring, opgaver og anvendelsens kontekst. Der er ikke ét obligatorisk kursusformat eller krav om et særligt certifikat.

Træn eksempelvis marketing i at opdage opdigtede produktpåstande og salg i at håndtere kundeoplysninger. Registrér aktiviteterne, og opdatér vejledningen, når anvendelsen ændrer sig.

NIST AI RMF og ISO/IEC 42001

NISTs AI Risk Management Framework 1.0 er en frivillig ramme for AI-risikostyring. Den har fire funktioner: GOVERN, MAP, MEASURE og MANAGE. De omfatter organisering af ansvar, forståelse af anvendelsen, undersøgelse af risici og håndtering af dem. GOVERN går på tværs af arbejdet, og funktionerne bruges løbende.

ISO/IEC 42001 er en international standard med krav til at etablere, vedligeholde og løbende forbedre et ledelsessystem for AI. Begge rammer kan hjælpe med at strukturere arbejdet og gøre ansvar og opfølgning mere systematisk.

HappiLeap-perspektivet: Godkend anvendelsen

Hos HappiLeap anbefaler vi at formulere AI-godkendelser som konkrete arbejdsregler: Dette team må bruge dette værktøj til denne opgave, med disse data og denne kontrol. Det gør godkendelsen lettere at omsætte til en arbejdsdag.

I marketing bør reglen også pege på det godkendte vidensgrundlag. Aftal, hvilke produktfakta, budskaber og cases der gælder, hvem der vedligeholder dem, og hvordan ændringer når ud til AI-understøttede processer.

Test derefter reglerne på en faktisk opgave. Kan medarbejderen finde materialet, forstå datagrænsen og identificere godkenderen? Hvis det kræver tre møder at få svar, har governance-modellen stadig noget arbejde foran sig.