WordPress är dött som det automatiska svaret, inte som mjukvara.
Den distinktionen är viktig. Om du säger "WordPress är dött" som ett bokstavligt marknadsanspråk, så motbevisar datan detta. W3Techs rapporterar att WordPress driver 59,2 % av webbplatserna med ett känt CMS och 41,5 % av alla webbplatser i juni 2026. Det kan man inte kalla dött.
Men om du bygger webbplatser år 2026 har den gamla reflexen börjat kännas fel. En kund vill ha en snabb sida, anpassad layout, ren SEO, några integrationer och ett redigeringsflöde som inte behöver tio plugins. Svaret brukade vara WordPress eftersom anpassad kod var långsam och dyr. AI har ändrat den kalkylen.
Cloudflares EmDash gör skiftet svårare att ignorera. Cloudflare säger inte att WordPress saknar värde. De säger att nästa CMS kan vara TypeScript, serverlöst, Astro-drivet, plugin-sandlådelockat och byggt för AI-agenter från dag ett.
Jag respekterar fortfarande WordPress. Jag skulle fortfarande använda det i rätt projekt. Jag tror inte längre att det förtjänar att vara standardvalet.
Varför WordPress är dött som standard
WordPress vann eftersom det gav icke-tekniska personer publiceringsmakt. Det var ett verkligt genombrott. Du kunde installera ett tema, lägga till en page builder, publicera blogginlägg, lägga till formulär, lägga till SEO-metadata och överlämna sidan till en kund.
Det löftet har åldrats illa för många företagssidor.
En enkel sida blir ofta en hög av plugins: page builder, cache-plugin, SEO-plugin, formulär-plugin, säkerhets-plugin, bild-plugin, cookie-plugin, omdirigerings-plugin, schema-plugin och ibland en plugin för anpassade fält för att göra page buildern mindre smärtsam. Varje del lägger till uppdateringar, inställningar, databastabeller, tillgångar och ytterligare en felpunkt.
Problemet är inte WordPress-kärnan. Problemet är den operativa form som många WordPress-projekt antar efter ett år. Sidan blir ett litet backend-system för sidor som kunde ha levererats som ren HTML, ett litet CMS och några API-anrop.
Patchstacks säkerhetsrapport för WordPress 2026 gör underhållskostnaderna svårare att ignorera. Rapporten säger att 11 334 nya sårbarheter hittades i WordPress-ekosystemet 2025, en ökning med 42 % från 2024. Den säger också att 91 % av nya sårbarheter hittades i plugins, 9 % i teman och endast 6 sårbarheter rapporterades i WordPress-kärnan, alla med låg prioritet.
Det är poängen. WordPress i sig är inte skurken. Plugin-ytan är där risken finns.
EmDash är den renaste signalen
Detta var delen jag borde ha inkluderat från början. Cloudflare introducerade EmDash den 1 april 2026 som en v0.1.0-förhandsversion och beskrev det som en andlig efterträdare till WordPress.
Detaljerna stämmer överens med argumentet i denna artikel. EmDash är skrivet i TypeScript, drivet av Astro, öppen källkod under MIT-licens och designat för serverlös hosting. Det riktar sig också mot den specifika WordPress-smärtpunkt som dyker upp om och om igen: plugins.
I WordPress körs en plugin i samma värld som sidan. Den kan beröra databasen, filsystemet och körtiden på sätt som kräver mycket förtroende. Cloudflares EmDash-modell flyttar plugins till isolerade Dynamic Workers och ger dem deklarerade kapaciteter genom bindningar. En plugin bör begära exakt de behörigheter den behöver, som att läsa innehåll eller skicka e-post, innan den kan utföra det arbetet.
Det är den moderna CMS-idén: mindre ambient förtroende, mer explicita behörigheter.
EmDash är också viktigt eftersom det behandlar AI-agenter som en del av arbetsflödet. Cloudflare säger att varje EmDash-instans kan exponera en fjärr-MCP-server, plus CLI-verktyg och agentfärdigheter. Det betyder att en kodningsagent kan hantera innehåll, scheman, media och migreringsarbete genom strukturerade verktyg istället för att skrapa en admin-panel eller gissa var data finns.
Jag skulle inte råda en kund att migrera till EmDash blindt idag. Det är en förhandsversion. Det viktiga är riktningen: Cloudflare bygger WordPress-ersättningen kring samma saker jag nu vill ha från webbplatser: sandlådade tillägg, ren frontend-arkitektur, programmatisk kontroll och agentläsbara operationer.
AI har ändrat matematiken för anpassade sidor
För några år sedan betydde anpassat dyrt. Du betalade antingen en utvecklare för att bygga varje sida och komponent, eller så använde du en page builder och accepterade tyngden.
AI gör medelvägen praktisk. Du kan beskriva en layout, generera komponenter, finjustera avstånd, skriva text, skapa strukturerat innehåll, bygga ett litet admin-flöde och ansluta exakt de tjänster du behöver. Verktyg som v0, Framer AI, Webflow AI, Lovable-liknande appbyggare och moderna kodningsagenter har gjort anpassade gränssnitt snabbare att producera.
Det betyder inte att AI ersätter smak, QA eller tekniskt omdöme. Det betyder att den första utkasten inte längre tar hela budgeten.
Det är här WordPress förlorar sin standardposition. Om jag kan få en anpassad Next.js-, Astro-, EmDash- eller Webflow-byggnation som matchar varumärket exakt, laddas snabbt, levererar rent schema och undviker en tung backend, blir WordPress-kompromissen svårare att motivera.
En page builder ger dig reglage. Ett AI-assisterat kodarbetsflöde ger dig det faktiska systemet: komponenter, innehållsmodell, rutter, metadata, bildhantering, formulär, analys och distributionsregler. Du kan inspektera det. Du kan versionshantera det. Du kan testa det.
Det betyder mer än en temamarknadsplats.
Backend bör matcha jobbet
En broschyrsida behöver inte en databasdriven admin-panel som standard. En landningssida behöver inte PHP, MySQL, tjugo alternativskärmar och ett cachelager för att se snabb ut.
Använd en backend när projektet behöver en:
Lägg inte till en backend bara för att ett tema behöver någonstans att lagra block.
En smal modern stack kan vara mindre. Statiska sidor, serverrenderade rutter, ett headless CMS, Supabase, ett Git-baserat innehållsflöde, hostade formulär, Stripe, en sökleverantör och ett litet API täcker en stor procentandel av webbplatser. Du får färre rörliga delar och bättre kontroll över prestanda.
Detta är samma anledning till att jag bryr mig om ren HTML och noggrann SEO-arbete. I min fallstudie om Lighthouse SEO-poäng→ kom vinsten från disciplinerad markup, schema, hastighet, tillgänglighet och cachelagring. En sidbyggare kan hjälpa, men det slutliga utdata måste fortfarande vara läsbart av webbläsare, sökmotorer och AI-agenter.
AI gör exakt design mindre kostsam
Det starkaste argumentet mot WordPress är inte längre bara hastighet. Det är designkontroll.
De flesta WordPress-projekt börjar med ett tema och böjer sedan varumärket för att passa det. Du ändrar typsnitt, färger, sektioner och avstånd, men temat lämnar fortfarande fingeravtryck. Sidan ser ut som verktyget som byggde den.
AI vänder på det arbetsflödet. Du kan börja med varumärket, erbjudandet, målgruppen och den faktiska interaktionsmodellen. Sedan genererar du gränssnittet runt dessa begränsningar.
Det är en bättre ordning.
En konsultsida kan ha exakt den bevisstruktur den behöver. En SaaS-sida kan visa en tät produktyta istället för en generisk hero-sektion. En musikproduktsida kan kännas som ett riktigt studieverktyg istället för en mall. En lokal företagssida kan göra bokning, förtroende, plats och serviceinformation synlig utan att kämpa mot tematets layoutantaganden.
Utdata behöver fortfarande granskning. AI kan generera dålig CSS, svag tillgänglighet, uppblåst JavaScript och vag text. En människa måste fortfarande inspektera sidan, testa mobil, kontrollera länkar, verifiera metadata, köra Lighthouse och hålla skrivandet ärligt.
Men AI tar bort ursäkten att anpassat betyder långsamt.
När WordPress fortfarande vinner
Jag skulle fortfarande välja WordPress när redigeringsflödet är produkten.
Om ett team publicerar många inlägg, använder befintliga WordPress-redaktionella vanor, är beroende av WooCommerce, behöver specifika mogna plugins eller redan har års av SEO-historik i en stabil WordPress-installation, är det ett dåligt drag att bygga om för mode skull.
WordPress fungerar också bra för team som behöver en bekant admin-yta mer än de behöver en anpassad frontend. Det finns värde i ett verktyg som folk redan kan.
Misstaget är att välja WordPress innan man frågar vad sidan behöver göra.
För många nya byggen behöver sidan hastighet, struktur, anpassad design, kontrollerade integrationer och lågt underhåll. WordPress kan göra dessa saker, men det når dem ofta genom extra lager. AI-assisterade anpassade byggen når dem mer direkt.
Min praktiska regel
Jag skulle ställa tre frågor innan jag väljer WordPress idag.
Först, behöver kunden specifikt WordPress-admin-upplevelsen?
För det andra, löser en plugin ett svårt affärsproblem bättre än en liten anpassad integration?
För det tredje, kommer sidan fortfarande vara lätt att underhålla efter tolv månader av uppdateringar, marknadsföringsförfrågningar, spårningsskript och innehållsändringar?
Om svaret är ja kan WordPress vara rätt val.
Om svaret är nej skulle jag börja med en lättare arkitektur och använda AI för att bygga exakt det gränssnitt som behövs. Det kan betyda en statisk sida, ett headless CMS, en React- eller Astro-frontend, EmDash, Webflow, Framer eller en liten fullstack-app. Stacken bör passa arbetet, inte vanan.
Det är också här AI-agenter blir användbara. En bra agent kan inspektera sidan, verifiera länkar, kontrollera metadata, testa en byggnation, uppdatera innehåll och lämna en spårning. Jag skrev om det kontrollskiktet i min artikel om MCP-utvecklararbetsflöden→. Samma idé gäller för webbplatser: verktyg bör exponera tydliga åtgärder, inte dölja allt bakom en plugin-skärm.
Dom
WordPress är dött som det automatiska svaret. WordPress är inte dött som mjukvara.
EmDash är tidigt, men det visar vart CMS-konversationen är på väg: serverlöst som standard, TypeScript-vänligt, frontend-nativt, säkrare plugin-gränser och AI-agent-arbetsflöden istället för manuella admin-göromål.
Webben har rört sig mot snabbare frontends, mindre backends, AI-assisterad design och mer explicit kontroll över det slutliga utdatat. WordPress har fortfarande en plats, men det måste förtjäna den platsen projekt för projekt.
Om du behöver en publiceringsmaskin, använd en. Om du behöver en anpassad webbplats som känns exakt, laddas snabbt och undviker en tung backend, har AI gjort den bättre vägen lättare att ta.