Tidlig i 2025 drev WordPress 43,6 prosent av nettet. I dag er tallet 41,5 prosent, og fallet akselererer. Det interessante er ikke tallet i seg selv, men hvor andelen tar veien. Ikke til Wix eller Shopify, som står stille. Den går til nettsteder der W3Techs ikke oppdager noe CMS i det hele tatt. Pantheon-medgrunnlegger Josh Koenig oppsummerte det i tre ord: “it’s vibecoding”.
Før vi avgjør om det er et problem for WordPress, er det verdt å være presis på hva begrepet betyr, for det sprer seg fort og oppfattes ulikt fra person til person.
Hva vibecoding er
Vibecoding er å bygge en applikasjon ved å beskrive den for en språkmodell og godta det den lager, uten å lese koden linje for linje. Verktøyene er Lovable, Bolt.new, v0 fra Vercel, Replit Agent og Base44. Du skriver “lag en butikk med innlogging og betaling”, og du får en fungerende frontend, en database (som regel Supabase) og en deploy på noen minutter.
Til en prototype, et internt verktøy eller en kampanjeside som skal leve en uke, er dette faktisk bra. Vi bruker det selv til egne skisser, for å vise en kunde en retning før noen skriver produksjonskode. Problemet oppstår først når resultatet settes i drift som fundamentet under en bedrift.
Der vibecodede nettsteder ryker
Dette er ikke et refleksforsvar for WordPress. Det er en liste over hva som faktisk dukker opp når noen kommer og sier “det virket, og nå virker det ikke”:
- Nøkler i bundlen. Modellen legger en Supabase
service_role-nøkkel inn i kode som havner i nettleseren. Alle med utviklerverktøy kan lese den. Gjennom 2025 lekket hele brukertabeller ut fra Lovable-bygde apper og Supabase-databaser uten Row Level Security påslått. - Endepunkter uten autorisasjon. Prompten “lag et adminpanel” lager et panel, men ruten
/api/adminsjekker aldri hvem som banker på. Det ser riktig ut fordi forfatteren tester det innlogget på sin egen konto. - Ingen validering eller grenser. Et kontaktskjema uten rate limiting og uten sanitering blir en åpen dør for spam og injeksjonsforsøk.
- Usynlig i søk. Innhold som rendres kun på klienten, uten serverside-rendering, er en tom side for Googlebot. En produktkatalog som ikke finnes i HTML-en, blir ikke indeksert.
- Ingen vedlikeholdsvei. Ingen databasemigreringer, ingen sikkerhetskopier, ingen versjonering, ingen pipeline. Den første reelle endringen betyr omskriving fra bunnen, for ingen, heller ikke den som skrev prompten, vet hvorfor det ble bygd slik det ble.
To konkrete tilfeller fra de siste månedene. En startup i Oslo bygde et kundepanel i Bolt.new og lanserte på en uke. To uker senere kunne brukerne se og redigere data fra andres kontoer, fordi Supabase-anon-nøkkelen lå i koden og Row Level Security aldri var slått på. En nettbutikk på Vestlandet satte opp en “butikk” i v0. Den var rask og pen, og etter tre måneder hadde den null trafikk fra Google, fordi hele katalogen rendret seg først i nettleseren. Begge nettstedene så plettfrie ut på lanseringsdagen. Det er fella i vibecoding: demoen er perfekt, og regningen kommer senere.
Hvordan du kjenner igjen et vibecodet nettsted
Du trenger ikke tilgang til koden. Noen signaler holder:
- Vis kilde (Ctrl+U) viser en nesten tom
<body>og én stor JavaScript-fil. Innholdet dukker først opp etter at skriptet er lastet. - Slå av JavaScript etterlater en blank side i stedet for tekst.
- I Google har nettstedet ingen sider utover forsiden, selv om nettleseren viser mange.
- Ingen innloggingsside på nettstedets eget domene, eller et adminpanel som lener seg helt på en ekstern tjeneste uten oppsatte rettigheter.
- Svarhodene peker på preview-hosting (Vercel, Netlify) uten et eget applikasjonslag.
Ingen av punktene er en dom alene. Til sammen tegner de et nettsted som kom ut av en prompt og aldri fikk et fundament.
Vibecoding vs WordPress i produksjon
| Kriterium | Vibecodet nettsted | WordPress driftet av en senior |
|---|---|---|
| Tid til første demo | Minutter | Dager |
| Rendering for SEO | Vanligvis på klienten | Serverside-HTML |
| Tilgangskontroll | Ingen som standard, må legges til | Roller og rettigheter i kjernen |
| Vedlikeholdsvei | Ingen migreringer eller backup | Oppdateringer, backup, pipeline |
| Videreutvikling etter ett år | Ofte omskriving | Iterasjon på eksisterende kode |
| Ansvar ved feil | Uklart | Én ingeniør som kan koden |
Tabellen sier ikke at vibecoding er dårlig. Den sier hva hvert verktøy passer til. Til å teste en idé over en helg vinner vibecoding uten diskusjon. Til et nettsted som skal tjene penger om ett år, vinner fundamentet.
Hvorfor dette ikke er slutten for WordPress
Andelen faller fordi den nederste delen av markedet, de enkle nettstedene som før ble satt opp på WordPress “bare fordi”, faktisk flytter til AI. Og det er greit. Det var den minst lønnsomme, mest engangsaktige delen av markedet. WordPress mister arbeidet ingen tjente penger på uansett.
Igjen står resten: WooCommerce-butikker med reell omsetning, flerspråklige nettsteder med korrekt hreflang, GDPR-bundne prosjekter, arbeid som skal leve i fem år og overleve et titalls oppdateringer. Dit når ikke vibecoding, for der handler jobben ikke om å generere en skjerm. Det handler om et fundament: sikkerhet, ytelse du kan måle i Core Web Vitals, vedlikehold, og ansvar for hva som skjer klokka to om natta på topplasten under Black Friday.
WordPress vinner ikke fordi det er på moten. Det vinner fordi det har to tiår med økosystem, en forutsigbar vedlikeholdsvei, og et menneske som vet hvorfor noe ble bygd slik det ble.
Når vibecoding passer, og når du bør ringe en senior
Enkelt sagt: til en prototype, en MVP, et internt verktøy eller en kampanjeside, vibecod i vei. Raskt, billig, godt nok. Til en butikk, et bedriftsnettsted, eller noe som skal tjene penger og fremdeles finnes om ett år, trenger du et fundament, ikke en generert skjerm.
Har du allerede et AI-bygd nettsted og noe begynner å ryke, fra lekkasjer til tapt trafikk til “vi får ikke utvidet det”, er det som regel reparerbart, men ikke med enda en prompt. Vi redder AI-bygde nettsteder: en sikkerhetsgjennomgang, SEO fra bunnen, og en avgjørelse om hva som skal skrives om og hva som kan reddes. Arbeidet gjøres av en utvikler som leser koden ingen har lest før.
