← Guides

Vibe coding er kun halve arbejdet: SEO, GEO og AEO i praksis

Vibe coding løser ét problem, ikke alle

Vibe coding har gjort det markant hurtigere at gå fra idé til fungerende website eller web app. Det er en reel gevinst. Men "fungerer" er en lav bar. Et website kan rendere korrekt, have pæne animationer og stadig være usynligt for Google, uforståeligt for et AI-svar og umuligt at navigere for en agent. Koden virker. Arkitekturen gør det ikke.

Det er forskellen, jeg arbejder i: ikke om koden kører, men om løsningen er bygget til at blive fundet, forstået og brugt.

SEO, GEO og AEO er lag, ikke alternativer

Det er fristende at behandle SEO, GEO og AEO som tre separate discipliner, man kan vælge imellem. I praksis bygger de oven på hinanden.

SEO er fundamentet: semantisk HTML, crawling, indeksering, metadata, interne links, performance. Googles egen SEO Starter Guide dækker det grundlæggende.

GEO handler om, hvordan indhold bliver forstået og genbrugt i generative søgeoplevelser som AI Overviews og AI Mode. Google er eksplicit omkring, at disse funktioner bygger videre på eksisterende Search-systemer og klassiske SEO-principper. Der findes ikke en separat, hemmelig "AI SEO".

AEO er mere specifikt: kan et konkret spørgsmål besvares klart, fordi indholdet er struktureret til det? Det er her FAQ-markup, klare overskrifter og entydige svar gør en forskel.

Pointen er ikke at optimere til ét af de tre. Det er at bygge et website, der er maskinforståeligt fra bunden, så alle tre lag har noget at arbejde med.

Googles SEO Starter Guide er et godt udgangspunkt for de grundlæggende principper:

Google: AI features and your website

Hvad jeg faktisk kigger på

Når jeg går igennem et AI- eller vibe-coded website, ser jeg ikke kun på det visuelle. Jeg tjekker struktur (er HTML'en semantisk korrekt?), metadata (titles, descriptions, canonical URLs), structured data (kan søgemaskiner identificere organisationer, personer, produkter og FAQ'er som entiteter?), crawling og indeksering, performance under realistiske forhold, og accessibility — altså om både mennesker og software rent faktisk kan forstå og interagere med siden.

Det sidste punkt bliver stadig vigtigere, fordi det også er det, AI-agenter er afhængige af.

Performance er ikke en engangsopgave

Google bruger Core Web Vitals — LCP, INP og CLS — som del af deres vurdering af brugeroplevelsen. Jeg måler derfor ikke kun, om en side ser rigtig ud på min egen skærm. Jeg ser på, hvordan den opfører sig teknisk, særligt på mobil, hvor problemer ofte er usynlige på en hurtig desktop-forbindelse.

Det vigtige her er ærlighed: performance-optimering er ikke noget, man opnår én gang og så er færdig med. Det er en løbende proces, hvor man dokumenterer både det, der fungerer, og det, der stadig kan forbedres.

Den nye variabel: AI-agenter

Chrome eksperimenterer med en Agentic Browsing-kategori i Lighthouse, der undersøger, hvor godt websites kan forstås og bruges af AI-agenter. Her bliver accessibility-træet centralt, fordi en agent skal kunne identificere knapper, links og formularer for overhovedet at kunne handle på en side.

Det giver fire forskellige, men beslægtede spørgsmål: Kan søgemaskinen finde siden (SEO)? Kan AI forstå og genbruge indholdet (GEO)? Kan systemet finde et konkret svar (AEO)? Kan en agent navigere og udføre en handling (agent-ready)?

llms.txt: nyttigt værktøj, ikke en genvej

llms.txt er et eksempel på noget, der har fået mere hype end substans indtil videre. Filen skal give LLM-systemer en struktureret indgang til et websites vigtigste information. Chrome kalder det selv en emerging convention, og Google siger direkte, at llms.txt ikke er nødvendig for at optræde i Googles AI-funktioner. Jeg bruger det som ét værktøj blandt mange — ikke som en magisk knap.

Konklusion

Vibe coding ændrer, hvor hurtigt man kan bygge. Det ændrer ikke behovet for arkitektur, struktur og optimering bagefter. Et godt website kræver stadig nogen, der stiller de kedelige spørgsmål: Kan Google læse det? Er data markeret korrekt? Er siden hurtig? Kan en agent navigere i den? Målet er ikke et website, der bare er kodet — det er et website, der kan findes, forstås og bruges.

BEVIS

Kilder:

Google: Optimizing your website for generative AI features

Google: Introduction to Structured Data

Forfatter: Lars Sohl skaber of www.klokly.app and www.kodekid.dk

Ofte stillede spørgsmål

Er GEO og AEO bare marketingbegreber uden reelt indhold?
Delvist. Google bekræfter selv, at AI-funktioner bygger på eksisterende SEO-principper, så der findes ikke en separat hemmelig teknik. Men begreberne peger på reelle, konkrete praksisser: hvordan indhold struktureres, så det kan genbruges i generative svar og besvare specifikke spørgsmål.
Skal jeg tilføje en llms.txt-fil til mit website?
Det kan ikke skade, men forvent ikke en stor effekt. Chrome beskriver det som en emerging convention, og Google siger direkte, at filen ikke er nødvendig for at blive vist i deres AI-funktioner.
Kan et vibe-coded website overhovedet blive godt til SEO?
Ja, men det kræver et ekstra lag arbejde efter koden fungerer: semantisk HTML, structured data, korrekt metadata, performance-tuning og accessibility. AI ændrer værktøjerne, ikke behovet for den arkitektur.
Hvordan ved jeg, om mit website er klar til AI-agenter?
Se på accessibility-træet: kan knapper, links og formularer identificeres programmatisk? Chromes eksperimentelle Agentic Browsing-kategori i Lighthouse er et godt sted at starte for at få et konkret billede.

ENDA