Når nettsiden vokser
fortere enn arkitekturen
Tusen produkter i nettbutikken der det før var femti. Bedriftsnettsiden har blitt et verktøy salgsavdelingen lever i hele arbeidsdagen, og vanlig WordPress-utvikling (finn en plugin, lim sammen, håp det holder) var aldri laget for den hverdagen.
Standardarkitekturen er bygget for gjennomsnittet. Dere er ikke gjennomsnittet lenger. Adminpanelet henger på hver eneste lagring. Ingen våger å kjøre plugin-oppdateringene, for sist gang gikk halve butikken ned. Og søket svarer «null treff» på varer som står fullt synlige på lager. Kjent?
Å bytte plattform løser sjelden noe som helst. Arkitekturen må endres — fra hobby-CMS til forretningskritisk applikasjon.
Av alle nettsteder kjører WordPress
TTFB i produksjon med FrankenPHP
Cache hit rate på løsningene våre
Plugins installert «for sikkerhets skyld»
Én plugin
i stedet for fem
Kundeportal med ordrehistorikk, fakturaer og supportsaker? Kobling mot Tripletex, Power Office eller fagsystemet bare dere bruker? Vi bygger det. Også chatboten som har lest hele dokumentasjonen deres før den svarer kundene.
Fem generiske plugins gjør gjerne halvparten av jobben hver. Vi skriver heller én: liten, testet og versjonskontrollert på WPFluent-arkitekturen vår, uten 15 avhengigheter og uten 200 KB JavaScript ingen har bedt om.
Gutenberg-blokker for innholdstyper som bare finnes hos dere. API-lag som snakker med eksterne systemer i sanntid, og minesider med rollestyrt tilgang. Si hva dere trenger, så gjør vi det til en del av WordPress.
Hvorfor vanlig WordPress-utvikling knekker i skala
Diagnosen først. Tradisjonell WordPress-utvikling betyr i praksis å finne en plugin som nesten passer, og deretter lime resten sammen med litt egen kode i functions.php. Hver snarvei er billig der og da. Summen er teknisk gjeld dere betaler renter på i årevis.
- Ytelse: EAV-modellen i databasen er fleksibel, men blir treg når volumet vokser. Skal du filtrere 1 000 produkter på farge, størrelse og lagerstatus, sluker det urimelig mye prosessorkraft
- Uten en arkitektur som holder igjen, lekker forretningslogikken ut i temafiler og hooks. Til slutt vet ingen hva en liten endring faktisk berører lenger
- Standardsøket forstår verken skrivefeil, synonymer eller vekting. Kunden taster «Ifone» og får null treff på en telefon dere har hundre av på lager
- Sikkerhet henger i en tynn tråd: plugins med kjente sårbarheter og oppdateringer som drar med seg nye konflikter. Uten struktur blir hvert eneste vedlikehold et sjansespill
WPFluent: WordPress-utvikling med arkitektur
MVC-arkitektur
Dependency injection
Testbar kode
Ingen leverandørlås
Serverne
gjør halve jobben
Trafikken dobler seg, og serveren blir flaskehalsen. Et delt webhotell til 99 kroner måneden var aldri dimensjonert for enterprise-last.
Stacken vår er satt opp for én ting: fart under press. FrankenPHP holder hele applikasjonen klar i minnet, så ingenting bootes på nytt per forespørsel. Traefik fordeler trafikk mellom flere instanser og gir zero-downtime deploy, mens Redis tar object cache, sesjoner og køer.
Effekten i tall? Responstider fra 200–300 ms ned til 20–30 ms. Og vi ruller ut ny kode klokka to en tirsdag uten at en eneste kunde mister handlekurven sin.
Stacken vi faktisk kjører
FrankenPHP Worker Mode
Traefik som edge router
Redis: Mer enn cache
CI/CD og versjonskontroll
Samme nettsted, ny motor
Avstanden mellom 3,2 sekunder og 28 millisekunder avgjør om den besøkende blir værende. Google har målt hvordan hvert ekstra sekund lastetid spiser konverteringer — besøkende venter rett og slett ikke [1].
Sikkerhet som ligger i arkitekturen
Web Application Firewall
Automatiserte sikkerhetsoppdateringer
Daglig backup
Overvåkning og varsling
Søk som selger
og headless bare når det lønner seg
Standardsøket i WordPress er et enkelt LIKE-oppslag i databasen. Verken mer eller mindre. Kunden skriver «vinterstøvler dame», produktet heter «Støvletter — Vinter 2026», og resultatlisten blir stående tom. Derfor kjører vi Meilisearch som dedikert søkemotor ved siden av WordPress.
Meilisearch tilgir skrivefeil og vekter relevans, og viser fasetter momentant mens kunden taster. Semantisk søk med AI-embeddings løfter det et hakk til: motoren tolker meningen i søket, ikke ordlyden. «Noe varmt til beina» treffer faktisk vinterstøvlene.
Indeksen oppdateres i sanntid fra WordPress-backenden. Svartid under 12 millisekunder. Og 94 % relevans selv når kunden søker upresist.
Tre måter å bygge WordPress på
Norske krav som ikke forsvinner
Personvern og GDPR
Universell utforming (WCAG)
Norske integrasjoner
Samtykke og skjemahåndtering
Hva enterprise WordPress-utvikling koster
| Type | Prosjekttype | Investering |
|---|---|---|
| Bedriftsnettside med WPFluent | MVC-arkitektur, CI/CD, staging, FrankenPHP | fra 80 000 kr |
| Bedriftsplattform med integrasjoner | + CRM/ERP-kobling, dedikert søk, custom API-er | fra 150 000 kr |
| Enterprise WooCommerce | Meilisearch, Redis, lastbalansering, Vipps/Klarna | fra 200 000 kr |
| Vedlikehold og SLA | Overvåkning, sikkerhet, oppdateringer, garantert responstid | fra 3 000 kr/mnd |
Bedriftsnettside med WPFluent
MVC-arkitektur, CI/CD, staging, FrankenPHP
fra 80 000 krBedriftsplattform med integrasjoner
+ CRM/ERP-kobling, dedikert søk, custom API-er
fra 150 000 krEnterprise WooCommerce
Meilisearch, Redis, lastbalansering, Vipps/Klarna
fra 200 000 krVedlikehold og SLA
Overvåkning, sikkerhet, oppdateringer, garantert responstid
fra 3 000 kr/mndFire faser, ett ansvar
Kartlegging og arkitektur
Utvikling med CI/CD fra dag én
Lansering med zero downtime
Drift etter lansering
Når trenger dere enterprise WordPress?
Langt fra alle trenger dette. Fem informasjonssider og moderat trafikk? Da klarer dere dere nok med en standardløsning. Kjenner dere igjen punktene under, derimot, er det på tide å tenke arkitektur:
- Nettstedet er forretningskritisk, og hver time nedetid koster penger
- Utviklingen har stoppet opp fordi standardarkitekturen ikke strekker til
- Databasen eser ut, og søket leverer stadig dårligere treff
- Dere trenger koblinger mot norske systemer som Tripletex, HubSpot eller booking
- Sikkerhet og compliance står som harde krav i kontraktene dere signerer
- Dere vil eie koden selv, uten å være gissel for én leverandørs «hemmelige oppskrift»
Da bygger dere ikke en nettside lenger. Da bygger dere infrastruktur — og infrastruktur kan vi jo en del om.
Åtte spørsmål til neste WordPress-utvikler
- 01
Ligger koden i Git? Nei betyr takk for praten
- 02
Finnes det et staging-miljø, eller testes endringer rett i produksjon?
- 03
Kan de legge frem målte ytelsestall i stedet for å love at «den er rask»?
- 04
Hva er sikkerhetsrutinen? «Vi oppdaterer WordPress» teller ikke som svar
- 05
Skriver de egne plugins, eller monterer de ferdigvarer fra markedsplassen?
- 06
Hva tilbyr de etter lansering — vedlikeholdsavtale med SLA og garantert responstid?
- 07
Har de referanser fra norske bedrifter med tilsvarende behov?
- 08
Eier dere koden etterpå, eller sitter leverandøren på nøkkelen?