AI SEO på WordPress: Sådan gør du din hjemmeside klar til AI søgning

AI søgning ændrer ikke alt, men den afslører mere

Der bliver skrevet og talt meget om AI SEO, GEO, AEO og alle mulige nye forkortelser. Noget af det giver mening. Meget af det er bare SEO pakket ind i nye ord.

Efter min mening er den vigtigste pointe ret enkel:

AI søgning gør ikke teknisk SEO mindre vigtig. Den gør teknisk SEO mere synlig.

Hvis Google, ChatGPT, Perplexity eller andre AI baserede søgesystemer skal forstå, bruge eller citere dit indhold, skal de først kunne finde det, hente det, læse det, forstå sammenhængen og vurdere om det er værd at bruge.

Det lyder måske banalt, men det er her mange WordPress hjemmesider allerede fejler.

Jeg har arbejdet med webudvikling siden 1995, og hver gang der kommer en ny stor ændring i søgning, sker der næsten det samme. Først opstår der en masse nye begreber. Så kommer der en masse hurtige løsninger. Til sidst viser det sig, at det stadig er det tekniske fundament, indholdets kvalitet og hjemmesidens troværdighed, der afgør meget af arbejdet.

Sådan er det også med AI søgning.

Forskellen er bare, at AI søgeresultater ofte arbejder med flere lag på én gang. De kan hente information fra flere kilder, sammenholde svar, udtrække konkrete afsnit og bruge indhold på andre måder end den klassiske liste med ti blå links.

Det betyder ikke, at du skal skrive til robotter. Men det betyder, at din hjemmeside skal være teknisk nem at forstå.

AI SEO er stadig SEO

Jeg bryder mig egentlig ikke specielt meget om begrebet AI SEO, fordi det hurtigt kommer til at lyde som en helt ny disciplin. Det er det ikke.

AI SEO er i praksis en kombination af:

• teknisk SEO
• godt og konkret indhold
• tydelig informationsstruktur
• crawlbar HTML
• fornuftig intern linkstruktur
• schema og structured data
• god performance
• troværdighed og erfaring
• en hjemmeside uden unødvendigt teknisk rod

Det meste af det burde man allerede arbejde med.

Det nye er, at AI søgning i højere grad kan bruge dele af dit indhold direkte i et svar. Derfor bliver det vigtigere, at dine sider ikke bare kan rangere, men også kan forstås i mindre, men stadig meningsfulde dele.

En klassisk SEO tekst kan godt rangere, selvom den er lidt rodet. Men hvis en AI skal bruge dit indhold som kilde til et konkret svar, er det en fordel, at siden er bygget klart op.

Det handler ikke om at skrive små mekaniske tekstbidder til AI. Det handler om at skrive og strukturere siden, så både mennesker, søgemaskiner og AI systemer kan se, hvad siden handler om.

Det første krav: Indholdet skal kunne læses uden bøvl

Hvis jeg skulle starte ét sted, ville jeg starte med dette:

Kan dit vigtigste indhold læses direkte i HTML?

Alt for mange moderne hjemmesider er bygget sådan, at store dele af indholdet først kommer frem efter JavaScript, animationer, builders, tabs, accordions, filtre, AJAX kald eller andre lag ovenpå siden.

Det er ikke altid et problem. Google kan godt arbejde med JavaScript i mange tilfælde. Men det gør tingene mere komplekse.

Og kompleksitet er sjældent din ven i SEO.

På en WordPress hjemmeside ser jeg ofte problemer som:

• tekst der først indlæses efter JavaScript
• vigtige links der kun findes i klikbaserede elementer
• indhold i tabs som ikke er tydeligt i HTML
• servicesider bygget så tungt i Elementor eller andre builders, at strukturen bliver mudret
• overskrifter brugt til design i stedet for indholdsstruktur
• interne links der ligger i blokke, som ikke er lette at gennemskue
• canonical tags der peger forkert
• sider som ved en fejl er noindex
• gamle redirects der skaber unødvendige hop
• filter URL’er og søgesider der skaber crawlspild

Hvis en side er vigtig for din forretning, skal den ikke gemmes bag teknisk trylleri.

Det gælder især for WordPress sider, hvor man hurtigt kan bygge noget, der ser pænt ud, men som teknisk bliver tungt, rodet og svært at læse.

AI søgning elsker ikke nødvendigvis flot design

Design betyder noget. Selvfølgelig gør det det.

Men flot design redder ikke en side, hvis indholdet er svært at hente, strukturen er uklar, og siden loader langsomt.

Jeg ser stadig hjemmesider, hvor forsiden er pakket ind i sliders, animationer, baggrundsbilleder, ikoner, tunge scripts og designblokke, men hvor der næsten ikke er noget rigtigt tekstindhold i HTML.

Det kan se fint ud for brugeren. Men teknisk er det ofte noget rod.

Hvis du vil være synlig i både klassisk Google søgning og AI søgning, skal du gøre det let at forstå:

• hvem du er
• hvad du tilbyder
• hvem du hjælper
• hvorfor du har erfaring med emnet
• hvilke konkrete problemer du løser
• hvilke sider der er de vigtigste
• hvordan dine emner hænger sammen

Det lyder simpelt. Men det er ofte det, der mangler.

En side om hastighedsoptimering skal ikke kun sige, at hjemmesiden bliver hurtigere. Den skal forklare hvad der typisk gør siden langsom, hvordan man finder flaskehalsene, hvad TTFB betyder, hvad Core Web Vitals måler, hvorfor plugins kan være et problem, og hvorfor server, tema, billeder, JavaScript og database spiller sammen.

Det er sådan noget indhold, AI systemer bedre kan bruge. Ikke fordi man “optimerer til AI”, men fordi man forklarer emnet ordentligt.

Query fan out gør emnedækning vigtigere

AI søgning arbejder ofte bredere end den konkrete søgning, brugeren skriver.

Hvis en bruger søger efter noget som “hvorfor er min WordPress hjemmeside langsom”, kan et AI system også have brug for at forstå emner som:

• hosting
• TTFB
• cache
• billeder
• JavaScript
• Core Web Vitals
• temaer
• plugins
• database
• WooCommerce
• tredjeparts scripts
• mobil performance

Det betyder ikke, at du skal lave 40 tynde sider om alle små variationer af samme emne.

Tværtimod.

Det betyder, at du skal bygge rigtige emneområder, hvor hovedsider og undersider hænger sammen.

På en WordPress hjemmeside kan det for eksempel være:

• en hovedside om hastighedsoptimering
• en underside om WordPress hastighedsoptimering
• en underside om WooCommerce hastighedsoptimering
• et indlæg om TTFB
• et indlæg om Core Web Vitals
• et indlæg om INP
• et indlæg om billedoptimering
• et indlæg om JavaScript og tredjeparts scripts
• et værktøj der kan teste sidestørrelse eller svartid

Når de sider linker naturligt til hinanden, bliver det lettere for både Google og AI systemer at forstå, at du ikke bare har skrevet én tekst om emnet. Du har faktisk arbejdet med området.

Det er en vigtig forskel.

Schema er ikke magi, men det hjælper med tydelighed

Schema og structured data bliver ofte solgt som noget, der næsten kan løfte en side alene. Det kan det ikke.

Men schema kan hjælpe med at gøre sidens betydning tydeligere.

På en WordPress hjemmeside bør man især se på schema for:

• Organization
• Person
• WebSite
• WebPage
• Article
• BlogPosting
• Service
• Product
• FAQPage
• BreadcrumbList
• LocalBusiness, hvis det passer til virksomheden

Problemet er, at mange bare slår Rank Math, Yoast eller et andet SEO plugin til og regner med, at alt er løst.

Det er det sjældent.

Plugins er gode til standardting. Men de ved ikke altid, hvordan din virksomhed faktisk hænger sammen. De ved ikke nødvendigvis, hvilke services der er vigtigst, hvem eksperten bag indholdet er, eller hvordan dine sider bør forbindes semantisk.

Et SEO plugin kan for eksempel godt lave Article schema på et indlæg. Men det betyder ikke, at din forfatterprofil, organisation, serviceområder og interne sammenhænge er beskrevet godt nok.

På en specialist hjemmeside bør schema ikke bare være automatisk pynt. Det bør afspejle virkeligheden.

Eksempelvis kan en side om WordPress hastighedsoptimering med fordel kobles til en service, en organisation, en person og relevante emner som Core Web Vitals, server performance, WordPress, WooCommerce og teknisk SEO.

Ikke ved at spamme schema med alt muligt. Men ved at beskrive det, der faktisk er sandt.

Robots.txt, AI crawlere og Google Extended

Der er også kommet mere fokus på, hvilke crawlere man vil give adgang til.

Her skal man passe lidt på med hurtige konklusioner.

Robots.txt er ikke en sikkerhedsmekanisme. Det er en anvisning til crawlere om, hvad de må hente. Seriøse crawlere følger den normalt, men det betyder ikke, at robots.txt beskytter privat indhold. Privat indhold skal beskyttes med login, adgangskontrol eller andre rigtige sikkerhedsmetoder.

Når vi taler AI crawlere, er det vigtigt at skelne mellem forskellige formål.

Nogle crawlere bruges til søgning. Andre bruges til træning. Andre igen kan være brugerinitierede besøg, hvor en bruger beder et AI værktøj om at hente en side.

Det er ikke det samme.

Derfor giver det sjældent mening bare at blokere alt, der lugter af AI, uden at tænke sig om. Hvis du blokerer en crawler, der bruges til AI søgning, kan du også miste mulighed for at blive vist som kilde i den type søgeresultat.

Et simpelt eksempel kunne være, at man gerne vil tillade en søgecrawler, men blokere en træningscrawler.

Eksempel:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Det betyder i praksis, at man forsøger at give adgang til OpenAIs søgefunktion, men ikke ønsker at indholdet bruges til træning via GPTBot.

For Google findes Google Extended som en særskilt product token. Den handler ikke om almindelig Googlebot på samme måde som klassisk søgning. Den bruges til at styre bestemte former for brug af indhold i Googles AI produkter.

Eksempel:

User-agent: Google-Extended
Disallow: /

Man skal dog ikke bilde sig selv ind, at én linje i robots.txt løser hele spørgsmålet om AI synlighed, AI træning, AI Overviews og rettigheder. Det er mere nuanceret end det.

Min anbefaling er normalt:

• lad almindelig søgning crawle de sider, du vil findes på
• blokér ikke vigtige sider uden en klar grund
• brug noindex til sider, der ikke skal indekseres
• brug login eller adgangskontrol til privat indhold
• kig i serverlogs før du beslutter dig
• skeln mellem søgecrawlere og træningscrawlere
• dokumentér hvorfor du blokerer noget

Det sidste punkt er vigtigt. Mange robots.txt filer ender som rodekasser, hvor ingen længere ved, hvorfor noget er blokeret.

llms.txt kan være nyttigt, men ikke som mirakelkur

llms.txt er et forslag til en fil, der kan ligge i roden af en hjemmeside og give AI systemer en mere overskuelig indgang til vigtige sider og beskrivelser.

Jeg synes idéen er interessant.

Men jeg ville ikke starte der.

Hvis din hjemmeside har dårlig intern linkstruktur, svage tekster, forkert canonical, langsom server, noindex fejl og rodet schema, så er llms.txt ikke det, der redder dig.

En llms.txt fil kan være fin som supplement. Især hvis du har mange gode guides, værktøjer eller dokumentation, som du gerne vil gøre nemmere at finde.

Men det bør komme efter det grundlæggende:

• god informationsarkitektur
• rigtige interne links
• HTML der kan læses
• sitemap
• schema
• gode titles og descriptions
• tydelige kategorier
• stærke hovedsider
• teknisk ryddelighed

Ellers bliver llms.txt bare endnu en fil, der peger på en hjemmeside, som stadig ikke er ordentligt bygget.

Serverlogs bliver vigtigere

Hvis man virkelig vil forstå, hvad der sker, skal man kigge i serverlogs.

Ikke kun PageSpeed. Ikke kun Search Console. Ikke kun et SEO værktøj.

Serverlogs viser, hvilke bots der faktisk besøger hjemmesiden.

Her kan du se:

• om Googlebot kommer forbi dine vigtige sider
• om crawl budget bliver brugt på ligegyldige URL’er
• om AI crawlere besøger siden
• om bots rammer redirects
• om de får 200, 301, 404 eller 500 svar
• om serveren svarer hurtigt nok
• om bestemte sektioner aldrig bliver crawlet
• om parametre og filtre skaber unødvendig støj

Det er især vigtigt på større WordPress og WooCommerce løsninger, hvor der kan være mange tekniske URL’er.

Jeg har set mange shops, hvor Google bruger alt for meget tid på filter URL’er, gamle produktvarianter, søgninger, paginering, sortering og andre sider, som aldrig burde fylde så meget.

Hvis AI søgning i højere grad skal bygge på crawlbar, forståelig og aktuel information, så giver det endnu mindre mening at lade crawlere drukne i teknisk støj.

Hastighed betyder stadig noget

AI søgning ændrer heller ikke på, at hastighed betyder noget.

En langsom hjemmeside er ikke bare dårlig for brugeren. Den er også dårligere at crawle, dårligere at arbejde med og ofte et tegn på teknisk gæld.

På WordPress ser jeg typisk problemer med:

• for langsom hosting
• høj TTFB
• for mange plugins
• tunge page builders
• dårlig billedhåndtering
• for meget JavaScript
• tracking scripts
• WooCommerce AJAX kald
• dårlig cache opsætning
• for mange eksterne kald
• gamle temaer
• database rod

Cache kan hjælpe, men cache løser ikke alt.

Hvis en side har tung frontend, dårlig kode, for mange scripts og langsomme tredjeparts kald, så hjælper det ikke nok bare at installere et cache plugin.

Det gælder især for INP og den oplevede hastighed, hvor problemet ofte ligger i JavaScript og browserens arbejde efter siden er hentet.

AI søgning gør ikke hastighed til den eneste faktor. Men en hurtig og teknisk ren hjemmeside er stadig et bedre fundament end en langsom og rodet installation.

Indholdet skal vise erfaring, ikke bare opsummere nettet

Der er et andet punkt, som bliver mere og mere vigtigt:

Indhold skal ikke bare være en opsummering af det, alle andre allerede har skrevet.

Hvis du skriver en tekst om WordPress hastighedsoptimering, men den bare siger “brug cache, komprimer billeder og vælg god hosting”, så tilføjer du ikke meget.

Det kan enhver skrive.

Det stærke indhold kommer, når du viser, hvad du faktisk har set i praksis.

For eksempel:

• hvilke plugins skaber typisk problemer
• hvornår WP Rocket hjælper, og hvornår det ikke gør
• hvorfor WooCommerce ofte er langsommere end almindelige indholdssider
• hvorfor Elementor kan være tungt, men ikke altid er hovedproblemet
• hvordan dårlig hosting viser sig i TTFB
• hvorfor billedstørrelser ofte er værre end billedformatet
• hvordan man opdager crawl traps
• hvorfor canonical fejl kan ødelægge et ellers godt site
• hvordan serverlogs afslører ting, Search Console ikke viser direkte

Det er her erfaring betyder noget.

AI kan godt skrive en pæn generel tekst. Men AI har ikke selv siddet med en WordPress installation, hvor 40 plugins, et tungt tema, dårligt cache setup og tre tracking scripts har gjort siden langsom.

Det har jeg.

Og det er den slags erfaring, der bør ind i indholdet.

Sådan ville jeg gøre en WordPress hjemmeside klar til AI søgning

Hvis jeg skulle gennemgå en WordPress hjemmeside med AI søgning i baghovedet, ville jeg ikke starte med llms.txt eller nye smarte forkortelser.

Jeg ville starte med det tekniske fundament.

1. Tjek om de vigtigste sider kan crawles

Først skal de vigtigste sider kunne findes og hentes.

Det gælder typisk:

• forsiden
• servicesider
• kategorisider
• vigtige blogindlæg
• værktøjer
• produktsider
• om siden
• kontakt siden

Jeg ville tjekke robots.txt, noindex, canonical, sitemap, redirects og HTTP statuskoder.

Hvis en vigtig side ikke kan crawles eller indekseres korrekt, er resten ligegyldigt.

2. Tjek HTML og rendering

Derefter ville jeg se på, hvad der faktisk ligger i HTML.

Ikke kun hvad man kan se i browseren som almindelig bruger.

Jeg ville tjekke:

• om hovedindholdet ligger i HTML
• om overskrifterne giver mening
• om interne links er rigtige links
• om vigtige tekster er gemt i scripts
• om schema bliver outputtet korrekt
• om siden fungerer uden unødvendigt JavaScript

På mange WordPress sider finder man hurtigt ud af, at designet ser fint ud, men HTML strukturen er mindre heldig.

3. Tjek intern linkstruktur

AI søgning arbejder ikke kun med enkelte sider. Den skal også kunne forstå sammenhænge.

Derfor er intern linkstruktur vigtig.

En god side om teknisk SEO bør linke til relevante undersider om for eksempel:

• hastighedsoptimering
• Core Web Vitals
• schema
• crawl og indeksering
• WordPress udvikling
• server performance
• redirects
• canonical tags

Og de sider bør linke naturligt tilbage eller videre.

Det skal ikke være mekanisk. Det skal bare afspejle, hvordan emnerne faktisk hænger sammen.

4. Tjek schema

Jeg ville ikke bare stole blindt på SEO pluginets standard schema.

Jeg ville se på, om schema passer til siden.

På en specialistside kan det give mening at have tydelig sammenhæng mellem person, organisation, website, services, artikler og breadcrumbs.

Det skal valideres. Ikke bare antages.

5. Tjek performance

Jeg ville måle både teknisk hastighed og oplevet hastighed.

Det betyder blandt andet:

• TTFB
• LCP
• INP
• CLS
• sidestørrelse
• antal requests
• JavaScript belastning
• serverens svartid
• cache headers
• billedstørrelser
• tredjeparts scripts

PageSpeed er et fint værktøj, men det er ikke hele sandheden.

6. Tjek serverlogs

Til sidst ville jeg kigge i logs.

Det er her man kan se, hvad der faktisk sker.

Search Console viser meget, men den viser ikke alt. Serverlogs kan vise, hvilke bots der kommer, hvilke URL’er de rammer, hvor ofte de kommer, og hvilke svar de får.

Det er især relevant, når man begynder at tale om AI crawlere.

AI SEO starter ikke med AI

AI SEO starter ikke med en prompt, en ny forkortelse eller en llms.txt fil.

Det starter med en hjemmeside, der teknisk fungerer.

En WordPress hjemmeside skal kunne crawles, læses, forstås og bruges. Den skal have stærkt indhold, tydelige sider, en god intern struktur, korrekt schema, hurtig server, fornuftige redirects og en teknisk opsætning uden for meget støj.

Det har altid været vigtigt.

AI søgning gør det bare endnu mere tydeligt.

For hvis dit indhold skal bruges som kilde i en AI baseret søgeoplevelse, skal det ikke kun findes. Det skal også være værd at bruge.

Og det kræver mere end bare et SEO plugin.

Det kræver teknisk forståelse, erfaring og en hjemmeside, der er bygget ordentligt.