Spørgsmålet om WordPress eller en AI-bygget hjemmeside er det rigtige valg har fået et nyt lag siden efteråret 2025. Indtil for nylig handlet valget om, hvor hurtigt et site kunne produceres.
Nu kan en AI-agent operere begge spor løbende – og ikke bare bygge et site én gang. En agent kan opdatere, fejlsøge og videreudvikle det efter lancering.
WordPress 6.9 introducerede Abilities API, et register hvor plugins, temaer og kernen eksponerer funktioner i maskinlæsbart format. Ovenpå det kører den officielle MCP Adapter, som bygger på Model Context Protocol (MCP) og gør funktionerne tilgængelige for AI-agenter som Claude og Cursor.
Parallelt bygger værktøjer som Lovable hele backend-løsninger direkte fra chat mod et Supabase-projekt, som kunden selv ejer.
Ingen af disse muligheder er per definition bedre, for de giver AI-agenten helt forskellige arbejdsmaterialer:
- WordPress er et etableret system at koble sig på
- Et AI-bygget websted en egen kodebase ogdatabase at bygge frit i.
Kort svar
Vælg WordPress, hvis sitet er indholdstungt og skal forvaltes løbende af flere parter, såsom redaktør, bureau og AI-agent i fællesskab – i et system med dokumenteret historik og en lav driftspris.
Vælg en AI-bygget hjemmeside, hvis sitet i praksis er et produkt: skræddersyet funktionalitet, direkte forbundet til egne data og indhold, der genereres ud fra kundens specifikke forudsætninger. Et forkert valg mærkes sjældent i byggefasen. Det mærkes i forvaltningsfasen, når nogen, enten et menneske eller en agent, skal vedligeholde koden.
Så ser AI-agentens adgang ud i WordPress
Spørgsmålet er ikke længere, om en agent kan arbejde i WordPress (for det kan den). Spørgsmålet er i stedet, hvad den får adgang til, og under hvilke betingelser.
Følgende information bliver lidt teknisk, men det er vigtigt, hvis du virkelig vil forstå forskellen.
Abilities API og MCP Adapter: Intet behøver at blive trænet
WordPress 6.9 leverer tre standardfunktioner:
core/get-site-infocore/get-user-info- og
core/get-environment-info
Den officielle MCP-adapter oversætter dem til værktøjer, som en agent kan opdage og køre:
opdag evnerhent-evne-info- og
gennemførlighed.
Ifølge [insert name/source] kræves der i praksis intet ekstra udviklingsarbejde for at gøre et plugins funktioner tilgængelige for en agent, hvis de allerede er registreret som abilities. WordPress Udviklerblog.
MCP organiserar interaktionen i tre delar: verktyg agenten kör, resurser agenten läser, och fördefinierade promptmallar för återkommande arbetsflöden.
Se vores side om AI-integrationer for hvordan vi kobler dette op hos kunder.
Elementor-sporet via tredjeparts MCP-servere
Elementor har ingen egen, officiel MCP-løsning. Tredjepartsværktøjet EMCP Tools bygger oven på WordPress MCP Adapter og eksponerer op til 277 værktøjer til at bygge sider, administrere indhold og styre plugins og brugere. 134 af dem er slået fra som standard, hvilket betyder, at alt, der skriver, sletter eller påvirker hele sitet, kræver et aktivt tilvalg for at blive aktiveret.
Autorisationsmodellen — agenten arver en brugers rettigheder
En MCP-klient agerer som en logget ind WordPress-bruger. Hver ability bør have et tilladelses_callback som kræver de lavest nødvendige rettigheder, for eksempel rediger_indlæg eller administrer_indstillinger, snarere end at åbne det hele. WordPress anbefaler en dedikeret bruger med begrænsede rettigheder i produktion, og at offentligt eksponerede endpoints primært holdes læsende.
Fordele ved WordPress
- Etableret system med dokumenteret historik. Millioner af installationer, et modent økosystem af plugins og temaer, tusindvis af udviklere, der kender kodebasen.
- PHP og MySQL gør driften billig og forudsigelig. Fungerer hos praktisk talt enhver svensk WordPress-webhotel enhver.
- Intet behøver at blive trænset for at tilslutte en agent. Abilities API og MCP Adapter leverer en klar protokol til at oprette forbindelse til.
- Flere veje ind for agenter: Kärnas MCP-adapter, WordPress.coms indbyggede MCP-server og tredjeparts Elementor-værktøjer.
- Lederen findes allerede. En agent kan revidera, supplere og indhente ekstern information uden at der skal bygges et helt nyt arbejdsområde. Se vores side om hjemmesider i WordPress.
Ulemper ved WordPress
- Plugin-afhængighed er den dominerende sikkerhedsrisiko. 91 % af de 11 334 nye sårbarheder i WordPress-økosystemet i 2025 fandtes i plugins, mens kun seks (alle med lav prioritet) fandtes i kernen. En stigning på 42 % i forhold til 2024, ifølge Patchstack.
- Paddtakt hänger inte alltid med. 46 % af sårbarhederne manglede en patch ved offentliggørelsen, og medianen for masseudnyttelse af de mest udsatte var fem timer.
- Førsteklasses komponenter er særligt udsatte. 76 % af sårbarhederne i betalte plugins og temaer viste sig faktisk at være udnyttelige i virkelige angreb.
- TTFB er flaskehalsen for ydeevnen. Kun 33,2 % af alle WordPress-origins opnår en god serverresponstid, mod 63,3 % blandt de 100.000 mest trafikerede websteder. Forskellen ligger i hosting, ikke i platformen, ifølge Hostingstep.
- Agentflows kræver et velgennemtænkt tilladelsessæt. Et WordPress supportaftale med disciplinerad plugin-håndtering vejer tungere end selve platformvalget.
Fordele ved AI-byggede hjemmesider
- Hurtigt fra idé til fungerende produkt, især for funktionalitet, der ikke findes som et færdigt plugin.
- Direkte forbindelse til egen data. Med Supabase tilkoblet bygger Lovable database, autentisering, filhåndtering og edge functions direkte op mod et projekt, som kunden selv ejer, i overensstemmelse med Elskbare Dokumenter.
- Skræddersyede landingssider og datadrevet indhold som genereres ud fra den enkelte kundes egne forudsætninger, hvilket er sværere at fremskaffe i et generelt CMS.
- Ingen plugins at administrere og ingen arvet temakod at trække med sig.
- Realtidsopdateringer og skræddersyede backend-funktioner i samme arbejdsgang som frontend-koden.
Ulemper ved AI-byggede hjemmesider
- Du ejer kode, som ingen andre kender. Der findes ingen bred, ekstern vidensbase at læne sig op ad, hvis udvikleren forsvinder.
- Redaktørvisningen skal bygges fra grunden. Ingen ikke-teknisk person kan stole på at redigere indhold uden at den overflade skabes separat.
- Ansvaret for Row Level Security ligger hos dig. Hver tabel har brug for sine egne politikker før lancering. Manglende RLS-politikker er ifølge Lovable den mest almindelige måde, hvorpå appdata lækker.
- Migrationsvejene er begrænsede. Der er ingen migrering med én knap mellem Lovables indbyggede backend og et eget Supabase-projekt i nogen af retningerne.
- Ingen bred økosystemhistorik. Supabase advarsel om selv at forbinde deres MCP-server til produktionsdatabaser uden et ekstra beskyttelseslag.
Sammenligningstabel
| Kriterium | WordPress | AI-bygget hjemmeside |
|---|---|---|
| Byggetid | Hurtig med færdige temaer/plugins | Hurtig, ofte hurtigere til en unik funktion |
| Redigeringsvenlighed | Klar redaktørvisning fra start | Bygges separat |
| Agentadgang | Standardiseret protokol via MCP-adapter | Egen kodebase, agenten koder direkte |
| Dataforbindelse | Via plugins og API-integrationer | Direkte mod egen database |
| Skræddersyet funktionalitet | Begrænset af de tilgængelige plugins | Ubegrænset, bygget fra grunden |
| Forvaltningsansvar | Fordelt mellem bureau, redaktør, hosting | Helt hos kodeejeren |
| Sikkerhedszone | Plugin-afhængighed, kendt risikoprofil | Afhænger af RLS-disciplin og egen kode |
| Ydeevne | Afhænger af hosting og TTFB | Afhænger af backend-arkitektur |
| Omkostninger over tid | Forudsigelig, hosting plus vedligeholdelse | Varierer med kompleksitet og skala |
| Exit/migrering | Etablerede eksportveje | Ingen automatisk migrering mellem backends |
Sådan vælger du
- Indholdshub eller blog som opdateres løbende af flere skribenter → WordPress.
- E-handel med etableret behov for betaling, lager og fragt → WordPress med WooCommerce.
- Tjenesteside med løbende SEO-arbejde → WordPress, hvor redaktørvisningen gør det billigere at arbejde med indhold løbende.
- Kundeportal eller lommeregner med eget login og realtidsdata → AI-bygget applikation mod egen database.
- Datadrevet landingsside der tilpasser indholdet efter den besøgendes egne forudsætninger → AI-bygget.
- Intern app til et specifikt arbejdsflow uden behov for bred plugin-kompatibilitet → AI-bygget.
- Kampagneside med kort levetid begge fungerer, men AI-byggede skal I ikke vedligeholde bagefter.
Hybridsporet
Det ærligste svar er ofte et hybridspor: WordPress som indholds- og synlighedsnav, en AI-bygget applikation til det, der kræver egne data.
En tjenesteside kan leve i WordPress til blogg, teknisk SEO og redaktionelt arbejde, mens en kundeportal eller lommeregner bygges separat og kobles på via link eller indlejring. Se vores side om AI-konsulent hvis I vil kortlægge hvilket spor der passer til jeres virksomhed.
AI-synligheten påvirkes ikke af platformvalget
Hverken schemamarkup eller llms.txt er en genvej til AI-synlighed, uanset hvilken platform sitet er bygget på. En analyse fra Search/Atlas i december 2024 fandt ingen sammenhæng mellem mængden af schemamarkup og hvor ofte en side citeres af AI-motorer, samtidig med at både Google og Microsoft Bing har bekræftet, at struktureret data hjælper deres systemer med at forstå indhold.
Betragt dette som en indikation snarere end en bevist sammenhæng — studiet er en brancheundersøgelse, ikke fagfællebedømt.
llms.txt er vokset hurtigt i antal, fra godt 4.000 filer i juni 2025 til over 36.000 i maj 2026. Ahrefs' analyse af 137.000 domæner viste dog, at 97 % af filerne aldrig fik en eneste forespørgsel, og at AI-hentningsbotter stod for cirka 1 % af trafikken til de filer, der faktisk blev læst. Læs mere om, hvad der rent faktisk flytter nålen, på vores side om AI-synlighed.
Ofte stillede spørgsmål
Kan en AI-agent selv opdatere mit WordPress-websted? Ja, hvis agenten er tilsluttet en MCP-server, og funktionerne (abilities) er korrekt konfigureret med de rette tilladelser. Uden en dedikeret, begrænset bruger bør produktionsagenter holdes til læseopgaver.
Er AI-byggede hjemmesider dårligere til SEO? Ikke per definition, men redigeringsværktøjer, sidehastighed og teknisk SEO skal opbygges bevidst, i modsætning til WordPress, hvor meget allerede er på plads.
Hvad koster det over tid? WordPress har ofte lavere og mere forudsigelige driftsomkostninger takket være det modne hosting-økosystem. AI-byggede løsninger varierer mere afhængigt af kompleksitet, databasetværsnit og hvor meget egen udvikling der kræves løbende.
Kan jeg flytte fra et AI-bygget websted til WordPress? Det kan lade sig gøre, men der er ingen automatisk migreringsvej. Indhold, database og autentifikation skal flyttes manuelt eller ved hjælp af tredjepartsværktøjer.
Har jeg brug for llms.txt? Nej, ikke som synlighedstrategi i dag. Google har udtrykkeligt sagt, at filen ikke er påkrævet for søgeresultater, og adoptionsdata viser, at næsten ingen AI-bot faktisk læser den.
Så vælger I rigtigt
Valget mellem WordPress og en AI-bygget hjemmeside handler sjældent om, hvad der er hurtigst at bygge. Det handler om hvem, eller hvilken agent, der skal administrere sitet om to år, og hvor meget egen kode I er parate til at eje. Vil I have et konkret beslutningsgrundlag til jeres eget projekt, så book en gratis analyse så går vi igennem hvilket spor, eller hvilken hybrid, der passer til jeres virksomhed.
