Vibe coding løste det nemme problem
Jeg kan vibe-code en hjemmeside eller landingsside på meget kortere tid, end det tog for bare et par år siden. Design, komponenter, frontend, API'er – AI-værktøjer gør den del hurtig. Den sværere og mere interessante opgave er noget andet: kan Google, ChatGPT og andre systemer rent faktisk forstå, hvad jeg har bygget?
Mange AI-byggede websites stopper, når siden ser godt ud, og koden virker. Det er præcis dér, det rigtige arbejde starter. Jeg har skrevet mere om den distinktion i vibe coding er kun halve arbejdet – denne artikel går et skridt videre og ser konkret på, hvordan man gør en vibe-codet side synlig for søgemaskiner og AI-søgning.
Kan en AI-genereret hjemmeside overhovedet ranke i Google?
Kort svar: ja, i princippet. Google kræver ikke, at en side er manuelt kodet af et menneske. Det, der betyder noget, er om det færdige resultat opfylder Googles tekniske, kvalitets- og spam-krav. Det gælder også, når siden skal optræde i AI-funktioner som AI Overviews og AI Mode. Google skriver selv i deres dokumentation om AI-funktioner, at en side skal være indekseret og kvalificeret til at blive vist i Google Søgning med et uddrag for at kunne vises som understøttende link i AI Overviews eller AI Mode, og at der ikke er yderligere tekniske krav. Med andre ord: der findes ikke en hemmelig AI-søgnings-tjekliste ved siden af normal SEO.
Hvorfor en flot vibe-codet side alligevel kan være usynlig
Det er her de fleste AI-byggede sider falder. Typiske problemer: indhold gemt bag JavaScript, svag semantisk HTML, uklart sidehierarki, manglende eller duplikerede metadata, ingen sitemap, dårlig intern linking og manglende structured data. Google kan behandle JavaScript, men processen går gennem flere trin, og hvis det kritiske indhold kun findes efter JavaScript er kørt, bliver siden mere skrøbelig rent SEO-mæssigt. Som en gennemgang af JavaScript SEO beskriver det, går flowet grundlæggende URL discovery → HTML crawl → JavaScript rendering → Content extraction → Indexing, og for SEO-kritiske sider bør vigtigt indhold, links, metadata og structured data fremgå af den indledende HTML eller server-renderede output, ikke kun efter JavaScript er kørt.
SEO skal være en del af arkitekturen, ikke noget man tilføjer bagefter
Det, jeg har lært ved at bygge mange forskellige projekter – fra WordPress-temaer bygget fra bunden med AI til statiske sider – er, at SEO ikke er et lag, man lægger ovenpå til sidst. Det er en del af, hvordan man strukturerer semantiske headings, HTML, sideopbygning, kanoniske URL'er, sitemap og intern linking fra dag ét. Structured data hører til her. Googles egen dokumentation om structured data anbefaler JSON-LD, fordi det er den nemmeste løsning for sideejere at implementere og vedligeholde i stor skala, og formatet kan håndtere indlejrede data uden at blande sig med det synlige indhold.
SEO, GEO og AEO er ikke genveje
SEO handler om at hjælpe søgemaskiner med at finde, forstå og indeksere indhold. GEO (Generative Engine Optimization) handler om at øge sandsynligheden for, at indhold bliver forstået og brugt i generative søgeoplevelser. AEO (Answer Engine Optimization) handler om at strukturere information, så systemer kan udpege klare svar. Google selv er eksplicit om, at dette ikke er hemmelige hacks: deres nyeste ressource om generativ AI fokuserer på vejledning i vigtigheden af at levere værdifuldt, unikt indhold samt en afmystificering af almindelige AEO/GEO-misforståelser. Der findes ingen speciel skema-type eller teknisk genvej, der omgår fundamentalt god SEO.
Sådan bygger jeg en landingsside anderledes
Før jeg skriver kode, tænker jeg på hvad virksomheden egentlig tilbyder, hvem siden er til, og hvilke spørgsmål brugerne stiller. Mens jeg bygger, tænker jeg på semantisk HTML, sidehierarki, metadata, kanoniske URL'er og JSON-LD. Efter jeg bygger, tester jeg mobilperformance, Core Web Vitals, Lighthouse, renderet HTML, structured data, sitemap og robots.txt. Den samme tilgang bruger jeg på KodeKid selv – for eksempel da jeg lod kodekid.app køre uden backend i en uge for at teste, hvor meget man kan opnå med en ren statisk arkitektur, før database og CMS kommer ind i billedet. Det beviser ikke, at siden ranker højt – det viser, at siden bliver bygget og testet med vilje.
Hvad kræver AI-søgning af et website?
AI-søgesystemer har brug for tilgængeligt, forståeligt webindhold: klare entitetsnavne, logiske overskrifter, direkte svar og crawlbare links. For ChatGPT specifikt gælder det at tillade OAI-SearchBot. OpenAI skriver direkte i deres hjælpecenter, at man for at gøre et website berettiget til inklusion skal tillade OAI-SearchBot at crawle sitet og bekræfte, at hosting eller CDN tillader trafik fra OpenAIs offentliggjorte IP-adresser. Blokerer man botten, forsvinder siden fra svarene, selvom sites, der er fravalgt OAI-SearchBot, ikke vil blive vist i ChatGPT-søgesvar, men stadig kan optræde som navigationslinks. At tillade botten garanterer ikke placering – det gør den blot teknisk muligt.
Kan man sætte en vibe-codet hjemmeside på toppen af Google?
Nej – ingen kan garantere en #1-placering. Det, der kan styres, er teknisk kvalitet, indholdskvalitet, relevans, arkitektur, crawlbarhed, structured data og løbende iteration. Jeg kan bygge og optimere de forhold, der gør en hjemmeside konkurrencedygtig i søgning. Jeg kan ikke kontrollere Googles rankingalgoritme.
Fra vibe coding til search-ready produkt
Vibe coding ændrede, hvor hurtigt jeg kan bygge en hjemmeside. Det ændrede ikke, hvad der gør et website forståeligt for mennesker, søgemaskiner og AI-agenter. AI giver hastighed. Design giver retning. Kode giver kontrol. SEO giver synlighed. Structured data giver maskiner kontekst.
Har du et AI-bygget website, der ser godt ud, men ikke bliver fundet? Jeg hjælper med at gøre det til et egentligt search-ready website eller landingsside – se flere guides om, hvordan jeg arbejder på tværs af design, kode og discoverability.