Frågan om wordpress eller ai-byggd hemsida är rätt val har fått ett nytt lager sedan hösten 2025. Fram tills nyligen handlade valet om hur snabbt en sajt kunde tas fram.
Nu kan en AI-agent operera båda spåren löpande – och inte bara bygga en sajt en gång. En agent kan uppdatera, felsöka och vidareutveckla den efter lansering.
WordPress 6.9 introducerade Abilities API, ett register där plugins, teman och kärnan exponerar funktioner i maskinläsbart format. Ovanpå det körs den officiella MCP Adapter, som bygger på Model Context Protocol (MCP) och gör funktionerna tillgängliga för AI-agenter som Claude och Cursor.
Parallellt bygger verktyg som Lovable hela backend-lösningar direkt från chatt, mot ett Supabase-projekt kunden själv äger.
Ingen av dessa alternativ är per definition bättre, för de ger AI-agenten helt olika arbetsmaterial:
- WordPress ett etablerat system att koppla in sig i
- En AI-byggd sajt en egen kodbas och databas att bygga fritt i.
Kort svar
Välj WordPress om sajten är innehållstung och ska förvaltas löpande av flera parter, som redaktör, byrå och AI-agent tillsammans – i ett system med beprövad historik och lågt driftpris.
Välj en AI-byggd hemsida om sajten i praktiken är en produkt: bespoke (skräddarsydd) funktionalitet, direktkoppling till egen data och innehåll som genereras utifrån kundens specifika förutsättningar. Fel val märks sällan i byggfasen. Det märks i förvaltningsfasen, när någon, antingen människa eller agent, ska underhålla koden.
Så ser AI-agentens tillgång ut i WordPress
Frågan är inte längre om en agent kan arbeta i WordPress (för det kan den). Frågan är istället vad den får tillgång till och under vilka villkor.
Följande information blir lite teknisk, men det är viktigt om du verkligen vill förstå skillnaden.
Abilities API och MCP Adapter: Inget behöver tränas
WordPress 6.9 levererar tre standardförmågor:
core/get-site-infocore/get-user-info- och
core/get-environment-info
Den officiella MCP Adapter översätter dem till verktyg en agent kan upptäcka och köra:
discover-abilitiesget-ability-info- och
execute-ability.
Har en plugin redan registrerat sina funktioner som abilities krävs i praktiken inget extra utvecklingsarbete för att göra dem tillgängliga för en agent, enligt WordPress Developer Blog.
MCP organiserar interaktionen i tre delar: verktyg agenten kör, resurser agenten läser, och fördefinierade promptmallar för återkommande arbetsflöden.
Se vår sida om AI-integrationer för hur vi kopplar in detta hos kunder.
Elementor-spåret via tredjeparts MCP-servrar
Elementor har ingen egen, officiell MCP-lösning. Tredjepartsverktyget EMCP Tools bygger ovanpå WordPress MCP Adapter och exponerar upp till 277 verktyg för att bygga sidor, hantera innehåll och administrera plugins och användare. 134 av dem är avstängda som standard, alltså allt som skriver, raderar eller påverkar hela sajten kräver ett aktivt val att slå på.
Behörighetsmodellen — agenten ärver en användares rättigheter
En MCP-klient agerar som en inloggad WordPress-användare. Varje ability bör ha ett permission_callback som kräver lägsta nödvändiga behörighet, till exempel edit_posts eller manage_options, snarare än att öppna allt. WordPress rekommenderar en dedikerad användare med begränsade rättigheter i produktion, och att offentligt exponerade endpoints i första hand hålls läsande.
Fördelar med WordPress
- Etablerat system med beprövad historik. Miljontals installationer, ett moget ekosystem av plugins och teman, tusentals utvecklare som känner kodbasen.
- PHP och MySQL gör drift billig och förutsägbar. Fungerar hos praktiskt taget vilket svenskt webbhotell för WordPress som helst.
- Inget behöver tränas för att koppla in en agent. Abilities API och MCP Adapter ger ett färdigt protokoll att ansluta mot.
- Flera vägar in för agenter: kärnans MCP Adapter, WordPress.coms inbyggda MCP-server och tredjeparts Elementor-verktyg.
- Redaktörsledet finns redan. En agent kan revidera, komplettera och hämta in extern information utan att en helt ny arbetsyta måste byggas. Se vår sida om hemsidor i WordPress.
Nackdelar med WordPress
- Pluginberoende är den dominerande säkerhetsrisken. 91 % av de 11 334 nya sårbarheterna i WordPress-ekosystemet 2025 låg i plugins, bara sex (samtliga lågprioriterade) i kärnan. En ökning på 42 % mot 2024, enligt Patchstack.
- Patchtakten hänger inte alltid med. 46 % av sårbarheterna saknade patch vid publik disclosure, och medianen till massexploatering för de mest utsatta var fem timmar.
- Premiumkomponenter är särskilt utsatta. 76 % av sårbarheterna i betalda plugins och teman visade sig faktiskt exploaterbara i verkliga attacker.
- TTFB är flaskhalsen för prestanda. Bara 33,2 % av alla WordPress-origins når god serverresponstid, mot 63,3 % bland de 100 000 mest trafikerade sajterna. Skillnaden sitter i hosting, inte i plattformen, enligt Hostingstep.
- Agentflöden kräver en genomtänkt behörighetsuppsättning. Ett supportavtal för WordPress med disciplinerad pluginhantering väger tyngre än plattformsvalet i sig.
Fördelar med AI-byggda hemsidor
- Snabbt från idé till fungerande produkt, särskilt för funktionalitet som inte finns som färdig plugin.
- Direktkoppling till egen data. Med Supabase anslutet bygger Lovable databas, autentisering, filhantering och edge functions direkt mot ett projekt kunden själv äger, enligt Lovable Docs.
- Custom landningssidor och datadrivet innehåll som genereras utifrån varje kunds egna förutsättningar, svårare att få fram i ett generellt CMS.
- Inga plugins att förvalta och ingen ärvd temakod att dra med sig.
- Realtidsuppdateringar och skräddarsydda backend-funktioner i samma arbetsflöde som frontend-koden.
Nackdelar med AI-byggda hemsidor
- Du äger kod ingen annan känner. Det finns ingen bred, extern kunskapsbas att luta sig mot om utvecklaren försvinner.
- Redaktörsvyn måste byggas från grunden. Ingen icke-teknisk person kan lita på att redigera innehåll utan att den ytan skapas separat.
- Row Level Security-ansvaret är ditt. Varje tabell behöver egna policyer innan lansering. Saknade RLS-policyer är enligt Lovable det vanligaste sättet appdata läcker.
- Migreringsvägarna är begränsade. Det finns ingen enknapps-migrering mellan Lovables inbyggda backend och ett eget Supabase-projekt, i någondera riktningen.
- Ingen bred ekosystemhistorik. Supabase varnar själva för att koppla sin MCP-server mot produktionsdatabaser utan extra skyddslager.
Jämförelsetabell
| Kriterium | WordPress | AI-byggd hemsida |
|---|---|---|
| Byggtid | Snabb med färdiga teman/plugins | Snabb, ofta snabbare för unik funktion |
| Redaktörsvänlighet | Färdig redaktörsvy från start | Byggs separat |
| Agenttillgång | Standardiserat protokoll via MCP Adapter | Egen kodbas, agenten kodar direkt |
| Datakoppling | Via plugins och API-integrationer | Direkt mot egen databas |
| Bespoke funktionalitet | Begränsad av tillgängliga plugins | Obegränsad, byggs från grunden |
| Förvaltningsansvar | Delat mellan byrå, redaktör, hosting | Helt hos kodägaren |
| Säkerhetsyta | Pluginberoende, känd riskprofil | Beror på RLS-disciplin och egen kod |
| Prestanda | Beror på hosting och TTFB | Beror på backend-arkitektur |
| Kostnad över tid | Förutsägbar, hosting plus underhåll | Varierar med komplexitet och skala |
| Exit/migrering | Etablerade exportvägar | Ingen automatisk migrering mellan backends |
Så väljer du
- Innehållshub eller blogg som uppdateras löpande av flera skribenter → WordPress.
- E-handel med etablerat behov av betalning, lager och frakt → WordPress med WooCommerce.
- Tjänstesajt med löpande SEO-arbete → WordPress, där redaktörsvyn gör kontinuerligt innehållsarbete billigare.
- Kundportal eller kalkylator med egen inloggning och realtidsdata → AI-byggd applikation mot egen databas.
- Datadriven landningssida som anpassar innehåll efter besökarens egna förutsättningar → AI-byggt.
- Intern app för ett specifikt arbetsflöde utan behov av bred plugin-kompatibilitet → AI-byggt.
- Kampanjsajt med kort livslängd → båda fungerar, men AI-byggt slipper ni underhålla efteråt.
Hybridspåret
Det ärligaste svaret är ofta ett hybridspår: WordPress som innehålls- och synlighetsnav, en AI-byggd applikation för det som kräver egen data.
En tjänstesajt kan leva i WordPress för blogg, teknisk SEO och redaktörsarbete, medan en kundportal eller kalkylator byggs separat och kopplas in via länk eller inbäddning. Se vår sida om AI-konsult om ni vill kartlägga vilket spår som passar er verksamhet.
AI-synlighet påverkas inte av plattformsvalet
Varken schemamarkup eller llms.txt är en genväg till AI-synlighet, oavsett vilken plattform sajten byggs på. En analys från Search/Atlas i december 2024 fann ingen korrelation mellan mängden schemamarkup och hur ofta en sida citeras av AI-motorer, samtidigt som både Google och Microsoft Bing har bekräftat att strukturerad data hjälper deras system förstå innehåll.
Ta detta som en indikation snarare än ett bevisat samband — studien är en branschundersökning, inte peer-review.
llms.txt har vuxit snabbt i antal, från drygt 4 000 filer i juni 2025 till över 36 000 i maj 2026. Ahrefs analys av 137 000 domäner visade ändå att 97 % av filerna aldrig fick en enda förfrågan, och att AI-hämtningsbottar stod för ungefär 1 % av trafiken till de filer som faktiskt lästes. Läs mer om vad som faktiskt flyttar nålen på vår sida om AI-synlighet.
Vanliga frågor
Kan en AI-agent uppdatera min WordPress-sajt själv? Ja, om agenten kopplas till en MCP-server och abilities är korrekt konfigurerade med rätt behörigheter. Utan en dedikerad, begränsad användare bör produktionsagenter hållas till läsande uppgifter.
Är AI-byggda hemsidor sämre för SEO? Inte per definition, men redaktörsverktyg, sidhastighet och teknisk SEO måste byggas medvetet, till skillnad från WordPress där mycket redan finns på plats.
Vad kostar det över tid? WordPress har ofta lägre och mer förutsägbar driftskostnad tack vare det mogna hosting-ekosystemet. AI-byggda lösningar varierar mer beroende på komplexitet, databasanvändning och hur mycket egen utveckling som krävs löpande.
Kan jag flytta från en AI-byggd sajt till WordPress? Det går, men det finns ingen automatisk migreringsväg. Innehåll, databas och autentisering behöver flyttas manuellt eller med tredjepartsverktyg.
Behöver jag llms.txt? Nej, inte som synlighetsstrategi idag. Google har uttryckligen sagt att filen inte krävs för sökresultat, och adoptionsdata visar att nästan ingen AI-bot faktiskt läser den.
Så väljer ni rätt
Valet mellan WordPress och en AI-byggd hemsida handlar sällan om vad som är snabbast att bygga. Det handlar om vem, eller vilken agent, som ska förvalta sajten om två år, och hur mycket egen kod ni är beredda att äga. Vill ni ha ett konkret beslutsunderlag för ert eget projekt, boka en kostnadsfri analys så går vi igenom vilket spår, eller vilken hybrid, som passar er verksamhet.
