Plugin-rot: når en AI-bygg etterlater deg med 40 aktive plugins

#Når plugin-listen er lengre enn nettstedskartet

Hvis bygget også leverte egen PHP fra en AI-assistent, kombiner denne revisjonen med revisjon av AI-generert WordPress plugin-kode. Når rot, egen kode og trafikktap forsterker hverandre, ligger arbeidet innenfor redning av AI-bygde nettsteder.

#Den anonymiserte casen: 38 plugins, 1,47 s TTFB

Et B2B-tjenesteside (opplæring og rådgivning for regulerte bransjer på det norske markedet) kom til oss etter at en intern interessent kjørte Lighthouse og spurte hvorfor «WordPress føltes tregt». Siden var satt sammen på omtrent tre uker med Cursor og ChatGPT: sidestruktur, tekstutkast, skjemaflyt og typiske «installer noe for det»-plugin-valg fra katalogen. Ingen eide plugin-listen.

Hosting endret seg ikke: en 2 vCPU VPS hos en nordisk leverandør, PHP 8.2, uten object cache ved inntak. Redis ble lagt til etter plugin-runden og sparte ytterligere ~120 ms TTFB, men mesteparten av gevinsten kom fra å fjerne og slå sammen plugins, ikke infrastrukturoppgraderinger.

På staging kjørte vi Query Monitor parallelt med en enkel curl-loop over fem minutter; de 187 forsidenforespørslene kom ikke fra WooCommerce, men fra tre analyse-plugins som hentet metadata per visning, pluss et relaterte-innlegg-plugin som trigget WP_Query på hver underside. Mønsteret gjentar seg på norske rescues etter at noen har limt inn en «beste plugins for WordPress»-liste fra et webinar, og assistenten har behandlet den som en obligatorisk installasjonsplan.

Eierens første reaksjon var forutsigbar: «Vi la bare til det vi trengte.» Slik presenterer rot seg. Hver enkelt installasjon hadde en plausibel grunn. Kostnaden var kumulativ.

#Hvordan AI-bygg når 40 plugins raskere enn manuelle

Manuell rot vokser vanligvis over måneder: en frilanser legger til en slider, markedsføring et popup-verktøy, noen installerer et andre SEO-plugin «bare for å prøve». AI-assistert rot presser samme atferd inn i dager fordi modellen optimaliserer plausibel fullføring, ikke stakk-sammenheng.

Gjentakende mønstre vi ser på redningsinntak:

1. Én prompt, én plugin. Assistenten sier ikke «utvid ditt eksisterende skjema-plugin». Den returnerer et slug.
2. Ingen inventarhukommelse. Økt to vet ikke at økt én installerte Rank Math; økt fire anbefaler Yoast for «bedre schema».
3. Tutorial-stabling. Bloggposter og YouTube-transkripter modellen ble trent på anbefaler «beste plugins for X»-lister. Bygget arver hele listen.
4. Egen kode pluss kommersiell rot. Samme assistent som foreslo tolv plugins genererte også tre små egne plugins som «raske fikser» og la uvedlikeholdt PHP oppå uvedlikeholdte avhengigheter.
5. Optimizer-plugins som plaster. Når TTFB stiger, er neste prompt «installer et cache-plugin», noen ganger uten å deaktivere det første cache-pluginet.

Dette krever verken ondskap eller inkompetanse. Det krever et prosesshull: ingen med ansvar for WordPress-arkitektur gjennomgikk stakken før lansering.

#Åtte kategorier som overindekserer på AI-bygg

På den anonymiserte siden sto disse åtte bøttene for 31 av 38 plugins. Listen din vil avvike, men kategoriene gjentar seg på redninger.

#1. Dupliserte SEO- og schema-verktøy

To SEO-plugins var aktive. Begge outputtet schema. Begge hektet på wp_head. Én var igjen fra migrering fra gammel hosting, én fra AI-byggeuken. Behold én. Slå sammen innstillinger manuelt; stol ikke blindt på automatiske importere.

#2. Flere skjemabyggere

Contact Form 7, en drag-and-drop-bygger fra en prompt og et lett modal-skjema-plugin samlet leads i ulike innbokser. Konsolidering flyttet tre skjemaer til én bygger og slettet resten.

#3. Konkurrerende cache- og optimaliserings-plugins

Et cache-plugin på vertsnivå og en andre «speed booster» minifiserte skript samtidig. De ga intermittente JavaScript-feil på prissiden. Kjør aldri to fullstendige HTML-cache-lag. Velg ett system og konfigurer det.

#4. Analyse- og pixel-rot

GA-kobling, Facebook pixel-plugin, LinkedIn insight tag-plugin, heatmap-prøve og GTM satt inn to ganger (én gang via plugin, én gang via header-snippet). Målingen ble ikke bedre. Forespørselsvekten gjorde det.

#5. Sidebygger og tilleggspakker

Elementor pluss kommersiell tilleggspakke pluss legacy-slider liggende «for sikkerhets skyld». Forsiden brukte byggeren; undersider gjorde det ikke. Vi eksporterte statiske seksjoner der mulig og fjernet slideren helt.

#6. Sikkerhets- og oppryddingsduplikater

To innloggingsbegrensere, et filbehandler-plugin (fjernet umiddelbart) og en «database-renser» som kjørte ved hver admin-lasting. Sikkerhet hører hjemme i en bevisst stakk, ikke tre overlappende plugins.

#7. AI-innholds- og bildeverktøy

Et AI-skrive-plugin og et auto-alt-tekst-verktøy la til admin-cron-jobber og utgående API-kall. Innholdsarbeidsflyt flyttet til redaksjonell prosess; pluginene forsvant.

#8. Egendefinerte AI mu-plugins

Tre filer i mu-plugins/ fra limt inn PHP: egen redirect-håndterer, en «fiks» for REST-tillatelser og en admin-kolonnejustering. Én redirect dupliserte .htaccess-regler. Én REST-justering deaktiverte en integrasjon markedsføring brukte daglig. Etter sikkerhetsgjennomgang beholdt vi admin-kolonnejusteringen som verifisert kode i én vedlikeholdt fil og slettet de to andre.

#Selvdiagnostikk: tegn på at du er plugin-dyp

Kjør dette før du installerer enda en optimizer.

Installer Query Monitor på staging (ikke produksjon hvis policy forbyr det), last forsiden utlogget, ta skjermbilde av forespørselsstakken. Den ene visningen gjør ofte at noen i selskapet tar ansvar for stakken.

#Triage: behold, slå sammen, erstatt, fjern

Vi bruker et firekolonners register på hver rot-redning. Hvert aktivt plugin får nøyaktig én etikett.

Behold - enkelt eier av en funksjon, vedlikeholdt, ingen overlapp. Eksempel: det ene SEO-pluginet etter innstillings-sammenslåing.

Slå sammen - to plugins med tilstøtende jobber som ett vedlikeholdt verktøy kan dekke. Eksempel: tre skjema-plugins til én.

Erstatt - plugin-jobb er gyldig men implementasjonen tung; erstatt med noen linjer i child theme eller et blokkmønster. Eksempel: relaterte-innlegg-plugin med WP_Query på hver visning erstattet med en kuratert blokk.

Fjern - forlatt, duplisert, farlig eller ubrukt. Filbehandler-plugins, hello-world SEO-prøver og «midlertidige» debug-verktøy havner her.

Arbeid i batcher på maks fem til åtte plugins. Deaktiver, test kasse og skjemaer, mål TTFB, slett deretter. Masse-sletting er hvordan produksjon ryker på en fredag.

På den anonymiserte siden så inndelingen slik ut:

• Behold: 21 plugins etter konsolidering (ett SEO, ett skjema, én cache, én sikkerhetspakke)
• Slå sammen: 9 plugins foldet inn i beholdte verktøy
• Erstatt: 4 plugin-jobber flyttet til temakode eller blokker
• Fjern: 8 plugins slettet (inkludert 2 forlatte, 1 filbehandler, 1 duplisert cache)

#Egendefinerte AI-plugins er fortsatt plugins

Team teller ofte bare katalog-plugins og glemmer mu-plugins eller «code snippets»-plugins som injiserer PHP. AI-assistenter elsker å generere disse fordi det føles raskere enn å lære riktig plugin-struktur.

Behandle hver egen fil som tredjepartskode:

• Se etter ABSPATH-vakter, nonces og $wpdb->prepare()
• Sjekk om funksjonen dupliserer et eksisterende plugin
• Flytt overlevende kode til versjonskontroll, ikke en lim-boks i wp-admin

Finner du manglende nonces og konkatenert SQL, stopp avinstallasjon av kommersielle plugins til egen kode er avklart. Dårlig egen PHP pluss krympende kommersiell stakk kan eksponere endepunkter ingen husket.

#Konsolideringsarbeidsflyt på staging

1. Frys nye installasjoner. Ingen plugin-svar før registeret finnes.
2. Eksporter aktiv listen til regneark: slug, versjon, sist oppdatert, oppgitt jobb, faktisk jobb.
3. Flagg overlapp i SEO, cache, skjemaer, analyse og sikkerhet først.
4. Deaktiver duplikater på staging, tøm alle cacher, test primære konverteringsstier.
5. Mål TTFB og antall forespørsler på forsiden, tyngste landingsside og kasse/kontakt takk-side.
6. Slett i små batcher, mål igjen etter hver.
7. Dokumenter endelig stakk i prosjekt-README eller kundeoverlevering slik at neste AI-økt har et inventar å lese.

Prising for redningsarbeid er alltid individuell fordi plugin-antall bare er én variabel. Databaseoppblåsting, egen AI-kode og trafikknivå teller like mye som tallet i wp-admin.

#Hva du ikke bør gjøre

• Ikke installer et «plugin manager»-plugin for å fikse plugin-rot. Du la til enda et plugin.
• Ikke aktiver to fullside-cacher «for sikkerhets skyld».
• Ikke la en AI-assistent generere et oppryddingsskript som massesletter rader i wp_options uten backup og diff-gjennomgang.
• Ikke anta at deaktiverte plugins er ufarlige. Noen laster fortsatt kode på init i merkelige tilstander; slett etter verifisering.
• Ikke hopp over skjema- og kasse-tester fordi «det bare er en blogg». På casen i denne artikkelen satt ødelagt JavaScript på prissiden, ikke blogg-indeksen.

#Når eskalere til redning

Inkrementell opprydding fungerer når overlapp er åpenbart, egen kode er minimal og noen teknisk eier staging. Eskaler til et formelt redning av AI-bygde nettsteder-oppdrag når:

• Aktive plugins holder seg over midt-trettitalene etter første runde
• Flere egendefinerte AI-plugins berører autentisering, opplastinger eller SQL
• TTFB ukachet holder seg over ~1 s etter fjerning av dupliserte cache- og SEO-verktøy
• Virksomheten ikke har råd til ødelagt skjema- eller betalingsflyt under uveiledet sletting
• Sikkerhetsskan viser kjente CVE-er på forlatte plugins ingen vil oppdatere

Redning er ikke et eufemisme for ombygging. I casen over forlot 17 plugins stakken, tema og hosting-nivå ble. Leveransen er et målt register, ikke et salgspitch for ny plattform.

#Måle suksess utover plugin-antall

Plugin-antall er en proxy. Spor metrikker som speiler brukeropplevelse:

Etter konsolidering, sett et plugin-budsjett: for denne sidetypen ingen nytt plugin uten å pensjonere eller slå sammen et eksisterende. Skriv den regelen i prosjektinstruksjonsfilen for AI-assistenter slik at neste prompt ikke reverserer redningen på en ettermiddag.

#Ordliste

• Plugin sprawl / plugin-rot - opphopning av aktive plugins med overlappende jobber til ytelse, sikkerhet og vedlikehold svekkes.
• TTFB (Time to First Byte) - servertid før nettleseren renderer innhold; følsom for PHP-hook-antall og databaseforespørsler.
• mu-plugin - must-use-plugin lastet på hver forespørsel fra wp-content/mu-plugins/; ofte brukt for AI-genererte «raske fikser».
• Autoloadede alternativer - WordPress-alternativer lastet på hver forespørsel; oppblåst av plugins som lagrer store arrays med autoload=yes.
• Forespørselsrot - overdreven databaseforespørsler per sidevisning, vanlig når mange plugins henter metadata uavhengig.

#Konklusjon

Førti plugins dypt er ikke en moralsk feil. Det skjer når rask AI-assistert montering løper foran arkitekturgjennomgang. Den anonymiserte siden i denne guiden gikk fra 38 til 21 aktive plugins, median ukachet TTFB fra 1,47 s til 0,68 s, og forsiden fra 187 til 94 forespørsler uten vertsbytte eller temaombygging. Arbeidet var kjedelig, målbart og for det meste avinstallasjoner.

Start med registeret, drep dupliserte SEO- og cache-lag, revider egne AI-filer før du feirer sletting av kommersielle plugins, og mål etter hver batch. Hvis stakken fortsatt slåss, er det det redning av AI-bygde nettsteder er til: en behold-skriv-om-fjern-inndeling med tall vedlagt, ikke enda en plugin-anbefaling.