Sommige websites worden niet verwaarloosd uit onverschilligheid, maar omdat er nooit een goed moment was. Zo ging het ook bij een installatiebedrijf uit de omgeving van Amersfoort: twintig medewerkers, een nette site uit 2021, en daarna twee jaar waarin niemand meer had ingelogd. De bouwer was gestopt, het wachtwoord lag ergens, en zolang de site het deed was er geen aanleiding.

De aanleiding kwam toen het contactformulier stopte met versturen en de eigenaar erachter kwam dat er waarschijnlijk al weken aanvragen waren misgelopen. Deze case beschrijft hoe die berg website met achterstallig onderhoud in drie weken is weggewerkt, wat de volgorde was en wat er onderweg misging. De namen zijn weggelaten; de aanpak is precies zoals hij is gelopen.

Week 1: eerst kijken, niet klikken

De verleiding bij zo’n site is groot om meteen op “alles bijwerken” te drukken. Dat is precies wat u niet doet. Bij twee jaar achterstand zijn er plugins die drie hoofdversies verder zijn, en de kans dat de site daarna niet meer laadt is aanzienlijk.

De eerste dagen gingen dus op aan inventariseren. Wat er werd aangetroffen:

  • WordPress liep vijf minor-versies achter, inclusief twee beveiligingsupdates.
  • 31 plugins hadden een update klaarstaan. Vier daarvan waren premium plugins met een verlopen licentie, en die konden dus helemaal niet worden bijgewerkt.
  • Drie plugins hadden al meer dan twee jaar geen update meer gekregen; de makers waren gestopt.
  • De site draaide op PHP 7.4, dat al geruime tijd geen beveiligingsupdates meer krijgt.
  • Er stonden zeven gebruikersaccounts in, waarvan er vier bij oud-medewerkers of het oude bureau hoorden. Twee daarvan hadden beheerdersrechten.
  • Er was geen enkele back-up buiten de server. De hosting bewaarde er veertien dagen.
  • Het thema was rechtstreeks aangepast, dus zonder child-thema. Elke thema-update zou dat maatwerk wissen.

Voordat er iets werd aangeraakt, is er een volledige kopie van bestanden en database gemaakt en buiten de server opgeslagen. Daarna is er een testomgeving opgezet: een exacte kopie van de site op een apart adres, afgeschermd voor bezoekers en zoekmachines. Al het werk van de weken daarna is daar eerst gedaan.

Week 1 en 2: de volgorde die problemen voorkomt

De volgorde waarin u dit aanpakt, bepaalt hoeveel tijd het kost. Deze route bleek de rustigste.

  1. Eerst de gebruikers opschonen. Onbekende beheerdersaccounts eruit, wachtwoorden van de rest vervangen. Dit kost tien minuten en dekt het grootste directe risico af.
  2. Dan het child-thema. Het maatwerk uit het thema is overgezet naar een child-thema, zodat thema-updates het niet meer zouden wissen. Zonder deze stap had het bedrijf later opnieuw zijn aanpassingen kwijt geweest.
  3. Dan de dode plugins. Twee van de drie verlaten plugins deden niets meer en zijn verwijderd. De derde, een verouderde sliderplugin, is vervangen door een alternatief dat wel wordt onderhouden.
  4. Dan de plugin-updates, in groepjes van drie tot vijf. Na elk groepje werd de site nagelopen. Zo blijft duidelijk welke update iets veroorzaakt.
  5. Dan WordPress zelf, in stappen naar de laatste versie.
  6. Pas daarna PHP. Van 7.4 naar 8.2, nadat alles bijgewerkt was. Andersom had gegarandeerd fouten opgeleverd.

Er ging onderweg twee keer iets mis, beide keren op de testomgeving. Een SEO-plugin die vier hoofdversies oversloeg gaf na de update een wit scherm; die is teruggezet en in twee tussenstappen bijgewerkt. En de overstap naar PHP 8.2 legde een formulierplugin plat die een verwijderde functie gebruikte. Die is vervangen, en meteen zat daar de verklaring voor het formulier dat geen mail meer verstuurde.

Week 3: naar live en controleren

Toen de testomgeving een week stabiel draaide, is de operatie op de live site herhaald. Niet door de testomgeving over de live site te kopiëren, want er waren intussen echte aanvragen binnengekomen; de stappen zijn opnieuw gezet, nu met de zekerheid dat ze werkten. Dat kostte een avond, en de site is geen moment onbereikbaar geweest.

Daarna volgde de controleronde: alle pagina’s nagelopen, het contactformulier drie keer getest en gecontroleerd of de mail daadwerkelijk in de inbox kwam en niet in de spam. Op mobiel opnieuw gecontroleerd, omdat updates van een pagebuilder vaak juist daar iets verschuiven. En de snelheid gemeten, waar de nieuwere PHP-versie een merkbaar verschil had gemaakt: de pagina’s laadden bij een steekproef ruim een seconde sneller dan ervoor.

Tot slot is het onderhoud ingericht in plaats van eenmalig gedaan: dagelijkse back-ups naar een externe locatie, monitoring die meldt als de site offline gaat, een firewall op de inlogpagina en tweestapsverificatie voor de twee resterende beheerders. Hoe dat laatste werkt, staat in het artikel over tweestapsverificatie.

Het resultaat, en wat het kostte

Na drie weken stond er een site op de actuele WordPress-versie, met 24 in plaats van 31 plugins, op een ondersteunde PHP-versie, met een werkend formulier en back-ups die daadwerkelijk buiten de server staan. Het formulierprobleem, de directe aanleiding, bleek een symptoom van de achterstand en niet de oorzaak op zichzelf.

Eerlijk over de kosten: dit was geen goedkope operatie. Inhalen kost meer dan bijhouden, en dat komt vooral door het testen. Een update van vandaag naar morgen kost minuten; een update over twee jaar kost een testomgeving, tussenstappen en soms een vervangende plugin. Ruwweg gold hier dat de inhaalslag ongeveer evenveel kostte als anderhalf jaar regulier onderhoud.

Wat u hieruit kunt meenemen

Drie dingen vallen op als u dit soort trajecten vaker doet.

Ten eerste: het is bijna nooit één ding. De eigenaar dacht een formulierprobleem te hebben. Wat er lag, was een verlopen licentie, een verouderde PHP-versie en drie verlaten plugins die elkaar in stand hielden. Een symptoom is bij een verwaarloosde site zelden de kern.

Ten tweede: de volgorde is het hele verhaal. Gebruikers, child-thema, dode plugins, plugin-updates, kern, PHP. Wie meteen op PHP 8 springt of alles in één klap bijwerkt, maakt van drie weken werk een maand.

Ten derde: het echte werk begint na de inhaalslag. Zonder vaste routine staat u over twee jaar op dezelfde plek. Of u dat zelf doet of onderbrengt bij een partij die het maandelijks oppakt, maakt minder uit dan dát het gebeurt. Dit bedrijf koos voor het laatste, bij WebMaintor, vooral omdat niemand intern zin had in de maandelijkse controle.

Herkent u de situatie, begin dan niet met updaten maar met inventariseren. Log in, kijk hoeveel updates er klaarstaan, welke PHP-versie er draait en welke accounts er zijn. Die lijst is uw uitgangspunt, en bepaalt of het een avond of een paar weken wordt. Een handig kader daarvoor staat in het artikel over de jaarlijkse website-apk.