Bygger du din hemsida i WordPress? Då är du i sällskap med de flesta. Tre av tio byråer på första sidan för “webbyrå växjö” säger rakt ut i sin sidtitel att de bygger i WordPress, och flera av de övriga gör det också utan att skriva det. Jag gör något annat, och då tycker jag att du har rätt att få veta varför.
Jag börjar med det som är lätt att missa i den här sortens text: jag har inget emot WordPress. Jag byggde mina första sajter där, jag förespråkade det, och det är fortfarande rätt val för många. Det jag inte gör längre är att bygga och underhålla det, och skälet handlar mindre om WordPress än om att sättet jag arbetar på har ändrats i grunden.
Varför jag valde WordPress till att börja med
Valet var enkelt när jag började. Allt fanns färdigt och det gick fort att komma i gång. Jag hittade ett tillägg för i princip varje sak någon kunde be om, tusentals teman att utgå ifrån, och en så stor användarbas att svaret på varje fråga låg i ett forum någonstans.
Sedan fick jag ansvar för sajter och butiker under flera år, och det var något jag levde med varje dag, långt utöver den dag sajten gick live. Där började min bild ändras.
Det som slet var sällan bygget
Att bygga en sajt i WordPress är oftast den lätta delen. Underhållet var det som gav mig huvudvärk, och det märkte jag först efter ett år eller två. Ett tillägg uppdaterades och slog sönder ett formulär en fredagseftermiddag. Sidbyggaren la tre lager runt varje rubrik, så att varje liten ändring blev ett arkeologiskt arbete. Vi la ett cachelager ovanpå ett annat för att dölja att sidan egentligen behövde en dryg sekund innan något syntes.
Och så det administrativa, som ingen pratar om när sajten säljs in. Ett tillägg har en licens, och licensen gäller ofta en enda webbadress. Har ni flera sajter? Då har ni flera licenser, med olika förnyelsedatum, olika konton och olika leverantörer. Någon ska hålla reda på det och någon ska betala det, och till slut hamnar den kostnaden hos den som äger sajten.
Det är helt enkelt så WordPress fungerar. Sidan byggs om vid varje besök, och varje tillägg har sin egen utvecklare som ska hänga med när de andra uppdaterar.
Det som faktiskt fick mig att byta
Jag bytte sätt att lösa problem, helt enkelt.
Tidigare satt jag i Stack Overflow och på YouTube. Ett tillägg betedde sig konstigt, jag sökte, hittade någon som haft samma problem och klistrade in en lösning. Det fungerade oftast, men det blev sällan perfekt direkt. Det blev en omväg ovanpå en omväg, och efter ett par år bestod sajten av lager som ingen riktigt kunde förklara.
När jag började ta hjälp av AI i arbetet ändrades det. Jag kunde beskriva vad jag ville uppnå och få kod byggd för just det, i stället för att leta efter någon annans lösning på ett näraliggande problem. Koden blev renare, jag förstod den bättre, och jag slutade bygga in saker jag egentligen inte behövde.
Ju mer jag arbetade så, desto tydligare såg jag att framtiden inte handlar om att sitta veckor och skriva rad efter rad. Den handlar om att kunna formulera en målbild och arbeta mot den: prata med systemet om vad som ska hända, och lägga sin tid på om resultatet blev rätt.
Betyder det att vem som helst kan be en AI om en webbplats och få något som håller? Nej, inte 2026, hur mycket det än påstås just nu. Du får fram något som ser rätt ut på en skärm. Det som avgör om sajten håller syns däremot inte på skärmen: att den går att hitta, att den fungerar likadant i mobilen som i datorn, att den laddar snabbt även när innehållet växer, att den följer reglerna kring samtycke och mätning, och att den går att ändra om ett år utan att något annat går sönder. Det kräver systematik och att du vet vad du tittar efter. Yrkeskunskapen behövs alltså fortfarande, men på ett annat ställe än förut.
Vad som konkret skiljer
Här kommer den tekniska delen, så kort jag kan göra den.
I ett publiceringssystem sätts sidan ihop vid besöket. Du skriver in adressen. En webbserver tar emot anropet och startar ett program. Programmet frågar en databas efter innehållet. En mall hämtas fram och fylls med det som kom tillbaka. Temat och alla aktiva tillägg får köra sin kod. Först därefter finns det något att skicka till dig. Sex led som alla måste svara innan du ser en bokstav, och i varje led kan det bli långsamt eller gå sönder.
I den teknik jag bygger i görs allt det en gång. När jag publicerar sajten sätts varje sida ihop färdig och sparas som en fil. När du sedan besöker den skickas filen som den är, utan databas, mall eller tillägg inblandade. Filerna ligger dessutom kopierade på servrar i flera länder, så du får dem från den som råkar ligga närmast.
Ritat bredvid varandra ser skillnaden ut så här.
Övre banan är ett publiceringssystem, undre banan en färdigbyggd sajt.
Det är också därför cache blir nästan obligatoriskt i den övre banan. Ett cachelager sparar det färdiga resultatet så att nästa besökare slipper hela kedjan. Det fungerar, och en välskött WordPress-sajt med bra cache kan vara riktigt snabb. Priset är att cachen blir ännu en sak som ska ställas in, övervakas och tömmas vid rätt tillfälle.
Vad får du av den undre banan?
- Snabbare. Det finns inget arbete att utföra vid besöket, så sajten blir inte långsammare av att ni lägger till innehåll.
- Mycket mindre som kan gå sönder. Sajten har ingen inloggningssida, ingen databas och inga tillägg i drift. Den vanligaste orsaken till att en företagssajt blir kapad är ett tillägg som ingen uppdaterat, och den vägen finns helt enkelt inte.
- Tål trafik bättre. Att skicka en färdig fil till tio tusen personer är inte tio tusen gånger svårare än att skicka den till en. Gränser finns förstås, men ni når dem inte av att många läser samma sida.
- Färre löpande kostnader. Ni slipper licensen för publiceringssystemet och prenumerationen på sidbyggaren, och ni har inga tillägg som ska förnyas.
System ska prata med dig
Det här är en insikt jag har med mig från e-handeln, framför allt från åren i Shopify. En sajt är i dag sällan bara en sajt. Den ska prata med affärssystemet, med lagret, med bokföringen, med utskicken, och numera med AI-verktyg som ska kunna hämta och lämna information åt ett företag.
Det kräver att systemen har färdiga vägar in och ut, alltså kopplingar som andra program kan använda utan att en människa sitter och klistrar mellan flikar. Det är vad ett API är. Det nyare motsvarande för AI-verktyg kallas MCP och gör samma sak för agenter: ger dem en dörr in i systemet i stället för att gissa.
Det går att lösa i WordPress också. Men den teknik jag har valt är byggd för det från början, och jag märker det varje gång något ska kopplas ihop. Ju mer av ett företags vardag som sköts av system som pratar med varandra, desto mer betyder det.
Hur bytet gick till
Det gick inte över en natt. Jag körde ett projekt i den nya tekniken parallellt med att jag fortsatte förvalta det gamla, just för att kunna jämföra utan att lova något jag inte kunde hålla.
Första tiden var ovan. Jag var van vid att varje behov hade ett tillägg, och nu fanns inget att installera. Ska det finnas ett kontaktformulär? Då får jag bygga det. Ska cookiesamtycket fungera enligt reglerna? Då får jag bygga det också. Och bilderna optimeras inte av sig själva.
Det som förvånade mig kom senare. Ett tillägg gick att installera på tio minuter, och därför gjorde jag ofta det utan att först fråga vad funktionen skulle vara bra för. När den genvägen försvann blev jag tvungen att ställa frågan. Och svaret blev nästan alltid något mindre än det jag hade tänkt installera. Jag trodde också att jag skulle sakna tilläggen mer än jag gör.
När jag ändå säger WordPress
Det händer, och då säger jag det i genomgången. Det gäller framför allt en redaktion som publicerar dagligen med flera skribenter och granskningssteg, och en verksamhet vars affär hänger på ett färdigt tillägg som redan fungerar, som bokning eller ett medlemsregister. I båda fallen är ett publiceringssystem rätt verktyg, och att bygga om samma sak från grunden är ett eget projekt som jag hellre avråder från.
Vad bytet gav
Det avgörande för mig var tiden jag fick tillbaka, mer än laddtiden i sig. En sajt som är byggd enklare har helt enkelt inte lika mycket som kan gå sönder mellan besöken: inget trasigt formulär på fredagseftermiddagen och ingen licens som gick ut utan att någon märkte det.
Den tiden lade jag förut på manuellt arbete som ingen kund egentligen ville betala för. Nu går den till att tänka större kring vad ett företag faktiskt ska ha ut av sin sajt, till att lära mig ny teknik medan den fortfarande är ny, och till att se möjligheter innan de blir självklara för alla. Det är den delen ni har mest nytta av.
Kommer WordPress att komma ikapp på de här punkterna? Kanske. Tekniken rör sig fort just nu, och jag prövar gärna om min egen hållning med jämna mellanrum. Men i dag bygger jag så här, och vill du veta hur det skulle se ut för er sajt är det bara att höra av dig.