Den här texten finns för att jag säljer en teknik som är ovanlig bland svenska webbyråer. 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. När någon gör något annat än de flesta är det rimligt att förklara varför, och att göra det utan att såga det verktyg som driver en stor del av webben.
Jag börjar med det som är lätt att missa i den här sortens text: WordPress är inte fel. 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. Det gick fort att komma i gång. Det fanns ett tillägg för i princip varje sak någon kunde be om, en temamarknad med tusentals utgångspunkter, och en så stor användarbas att svaret på varje fråga låg i ett forum någonstans.
Sedan hade jag sajter och butiker som ansvar under flera år. Det var något jag levde med varje dag, långt utöver den dag sajten gick live. Det var där bilden ändrades.
Det som slet var sällan bygget
Att bygga en sajt i WordPress är oftast den relativt lätta delen. Det som kostade huvudvärk var underhållet, och det syntes först efter ett år eller två. En uppdatering av ett tillägg som slog sönder ett formulär en fredagseftermiddag. En sidbyggare som lade tre lager runt en rubrik och gjorde varje liten ändring till ett arkeologiskt arbete. Ett cachelager ovanpå ett cachelager, 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. Licensen gäller ofta en enda webbadress. Har man flera sajter blir det flera licenser, med olika förnyelsedatum, olika konton och olika leverantörer. Någon ska hålla reda på det, någon ska betala det, och till slut hamnar den kostnaden hos den som äger sajten.
Ingen av de sakerna är WordPress fel i sig. De följer av en konstruktion där sajten sätts ihop på nytt varje gång någon besöker den, och där funktionerna består av delar från många olika utvecklare som ska hållas i takt med varandra.
Det som faktiskt fick mig att byta
Det var inte en teknisk analys. Det var att jag bytte sätt att lösa problem.
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 som var 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, desto tydligare blev det 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. Att prata med systemet om vad som ska hända, och lägga sin tid på om resultatet blev rätt.
Men vem som helst kan inte göra det. Här vill jag vara ärlig, för det påstås en hel del just nu. Vi är inte 2026 i ett läge där vem som helst kan be en AI om en webbplats och få något som håller. Det går att få fram något som ser rätt ut på en skärm.
Det som avgör om det håller är sådant som inte syns: att sidan är byggd så att den går att hitta, att den fungerar likadant i en mobil som i en dator, 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 man vet vad man tittar efter. Det är där yrkeskunskapen har flyttat, inte försvunnit.
En snickare som byter från handsåg till cirkelsåg blir snabbare, och kan ta sig an större jobb. Men sågen avgör inte om huset står rakt. Det gör den som håller i den.
Vad som konkret skiljer
Här är den tekniska delen, så kort jag kan göra den.
I ett publiceringssystem sätts sidan ihop vid besöket. Någon 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 besökaren. Sex led som alla måste svara innan någon ser en bokstav, och varje led är ett ställe där det kan bli långsamt eller gå sönder.
I den teknik jag bygger i görs allt det en gång. När sajten publiceras sätts varje sida ihop färdig och sparas som en fil. När en besökare sedan kommer skickas filen som den är. Ingen databas frågas, ingen mall byggs, inga tillägg körs. Filerna ligger dessutom kopierade på servrar i flera länder, så besökaren 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. Dra i sidled på mobil.
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.
Konsekvenserna av den undre banan är rätt raka:
- Snabbare. Det finns inget arbete att utföra vid besöket, så det går inte att göra långsamt genom att lägga till innehåll.
- Mycket mindre som kan gå sönder. 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 inte uppdaterats, och den vägen finns 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 de nås inte av att många läser samma sida.
- Färre löpande kostnader. Ingen licens för publiceringssystem, ingen prenumeration för sidbyggare, ingen kedja av 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 teknikstack jag har valt är byggd för det från början, och det märks 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 får jag bygga det. Ska cookiesamtycket fungera enligt reglerna får jag bygga det. Ska bilderna optimeras händer det inte av sig självt.
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. Det jag faktiskt har gett upp är att kunna plocka upp vilken sajt som helst och laga den. Ligger ett företag i WordPress och vill stanna där är jag fel person, och det säger jag hellre direkt.
När jag ändå säger WordPress
Det händer, och då säger jag det i genomgången i stället för att sälja in ett bygge. 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 är ett eget projekt med egen risk. Ett bygge som säljs in på fel grund kostar mer än det uteblivna uppdraget.
Vad bytet gav
Det avgörande var inte laddtiden i sig. Det var vad jag fick tillbaka i tid. En sajt som är byggd enklare har helt enkelt inte lika mycket som kan gå sönder mellan besöken. Inga fredagseftermiddagar med ett trasigt formulär. Ingen uppdatering som ska testas i en kopia först. 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 kunderna har mest nytta av.
Det är hela argumentet. Ingen teknisk övertygelse, utan ett val av vad jag ska vara bra på.