Herbouw of likje verf: de checklist voordat je geld uitgeeft aan je website

Of een website opnieuw gebouwd moet worden, zie je zelden aan de buitenkant. Een site die gedateerd oogt, kan technisch prima in elkaar zitten. En een site die er strak uitziet, kan ongemerkt bijna niet meer te onderhouden zijn. Uiterlijk is daarmee het minst betrouwbare signaal dat er is. Wat je moet controleren voordat iemand een budget goedkeurt, zit in de bouw en in het dagelijks beheer: wat het platform tegenhoudt, wat het team niet kan aanpassen zonder developer, en hoeveel risico elke wijziging inmiddels met zich meebrengt. Deze checklist gebruik je vóór de uitgave. Hij helpt je een echte herbouw te onderscheiden van een probleem dat een kleiner project ook oplost. Per signaal lees je hoe je het zelf nagaat, en aan het eind hoe je de uitkomst leest.

Dat maakt uit, want van de drie gangbare ingrepen is herbouw de duurste. Het is ook de ingreep die het vaakst op het verkeerde bewijs wordt goedgekeurd. Teams zien een vermoeide site en kiezen voor herbouw waar een opfrisbeurt genoeg was. Of ze keuren een redesign goed dat een nieuwe laag verf zet op een fundament dat juist het probleem was. In beide gevallen is het geld op en is het echte probleem er nog. De checklist hieronder moet dat voorkomen. Je telt een signaal pas mee als je hebt vastgesteld dat het in de bouw zit. Zo hangt de beslissing af van hoe de site gebouwd en onderhouden wordt, en niet van hoe hij eruitzag op de dag dat iemand er genoeg van had.

De checklist in één oogopslag

Loop deze negen signalen langs, verdeeld over drie groepen. Verderop staat per signaal de uitleg en hoe je het controleert. Dit is de versie om snel door te nemen.

Signalen rond wijzigen en onderhoud: voor gewone aanpassingen heb je een developer nodig; eenvoudige wijzigingen duren lang of kunnen iets breken; de onderhoudskosten stijgen in plaats van gelijk te blijven.

Signalen rond platform en mogelijkheden: je kunt niet bouwen wat het bedrijf nodig heeft; koppelingen zijn kwetsbaar of gaan stuk bij updates; prestatieproblemen blijven bestaan na een serieuze optimalisatieronde.

Signalen rond fundament en risico: het platform of framework wordt niet meer ondersteund of is onveilig; niemand kan de site veilig aanpassen; het bedrijf is de structuur van de site ontgroeid, niet alleen de look.

Kort gezegd lees je het zo: tel alleen de signalen waarvan je kunt vaststellen dat ze in de bouw zitten. Twee of meer maken een sterke zaak voor herbouw, en een paar zijn op zichzelf al doorslaggevend. Nul of één wijst meestal op een opfrisbeurt of een redesign. In het laatste deel lopen we de grensgevallen door.

Als de site moeilijk aan te passen is geworden

De eerste groep gaat over wat een wijziging kost. Een fundament dat zich verzet tegen gewone updates, werkt elke dag tegen het bedrijf in, hoe het er ook uitziet.

Voor gewone aanpassingen heb je een developer nodig. Kan het marketingteam geen tekst aanpassen, geen afbeelding vervangen of geen nieuwe pagina publiceren, en moet dat in de rij bij een developer? Dan staat de bouw werk in de weg dat vrij zou moeten zijn. Zo controleer je het: vraag wanneer iemand die geen developer is voor het laatst zelf een live pagina heeft aangepast. Is het eerlijke antwoord “dat kunnen ze niet” of “alleen bepaalde pagina’s”, dan zit de site zo vast aan developers dat herbouw vaak de schoonste oplossing is.

Eenvoudige wijzigingen duren lang of kunnen iets breken. Op een gezond fundament is een kleine wijziging ook echt klein. Duurt een kleine aanpassing steevast dagen, moet je hem testen op pagina’s die er niets mee te maken hebben, of heeft hij eerder elders iets stukgemaakt? Dan is de structuur kwetsbaar. Zo controleer je het: neem de laatste vijf wijzigingsverzoeken en meet hoe lang het duurde van vraag tot live. Noteer welke onverwacht iets anders braken. Gedragen kleine wijzigingen zich stelselmatig als grote, dan zit het probleem in de bouw en niet in de planning.

De onderhoudskosten stijgen in plaats van gelijk te blijven. Een gezonde site kost elk jaar ongeveer hetzelfde om draaiende te houden. Lopen het maandelijkse onderhoud en de moeite om hem stabiel te houden jaar op jaar op, dan takelt het fundament af en betaal je er rente over. Zo controleer je het: vergelijk wat het onderhoud dit jaar kostte met twee jaar geleden. Zie je een duidelijk stijgende lijn, met meer lapwerk, meer brandjes blussen en vaker “het is weer stuk”, dan is het fundament zelf de kostenpost.

Als het platform het bedrijf in de weg zit

De tweede groep gaat over mogelijkheden. Kan het platform wat het bedrijf nu nodig heeft, of is het een plafond geworden?

Je kunt niet bouwen wat het bedrijf nodig heeft. Het duidelijkste signaal over je platform is een lijst met dingen die je wilde en niet kon. Niet vanwege het budget, maar omdat het platform het niet toeliet. Zo controleer je het: schrijf de laatste drie dingen op waar het bedrijf om vroeg en die er niet kwamen. Lag de blokkade bij het platform en niet bij de planning, dan beperkt het platform je strategie. Dat is een probleem op het niveau van herbouw. Een bruikbare test: kan je developer op redelijke verzoeken “ja, dat kan” zeggen zonder te grimassen? Is het antwoord keer op keer nee, dan heeft het fundament geen ruimte meer.

Koppelingen zijn kwetsbaar of gaan stuk bij updates. Een moderne site praat met andere systemen, zoals een CRM, een commerce-backend en analytics. Die koppelingen moeten blijven werken. Gaan ze stuk zodra er iets wordt bijgewerkt, of is het aansluiten van een nieuwe tool elke keer een groot project, dan is de architectuur daar niet op gebouwd. Zo controleer je het: tel hoe vaak een koppeling het afgelopen jaar uit zichzelf stukging, en hoe lang het duurde om de laatste nieuwe koppeling aan te sluiten. Gaat het steeds opnieuw mis, dan zit het probleem in de architectuur.

Prestatieproblemen blijven bestaan na een serieuze optimalisatieronde. Dit signaal wordt het vaakst verkeerd gelezen. Traagheid voelt als iets visueels en het design krijgt de schuld. Het onderscheid dat telt: een site die traag is door niet-geoptimaliseerde afbeeldingen of te zware scripts, los je op zonder herbouw. Een site die na een echte optimalisatieronde nog steeds traag is, is traag door hoe hij gebouwd is. Zo controleer je het: laat iemand een grondige optimalisatieronde doen, met afbeeldingen, caching en scripts, en meet daarna opnieuw. Blijven de prestaties op hetzelfde plafond steken, dan ligt de grens in de architectuur. Dan heb je een probleem in het fundament, niet in de presentatie.

Als het fundament zelf het risico is

De derde groep gaat over risico dat in de basis van de site zit. Daar zijn de gevolgen het grootst en zie je er aan de voorkant het minst van.

Het platform of framework wordt niet meer ondersteund of is onveilig. Krijgen het CMS, het framework of de belangrijkste dependencies geen beveiligingsupdates meer, of draait de site op een versie die end-of-life is? Dan ben je kwetsbaar, en dat wordt met de tijd erger. Zo controleer je het: ga na of elk kernonderdeel van de stack nog actief beveiligingsupdates krijgt. Is het antwoord nee, dan is dit een van de signalen die op zichzelf al doorslaggevend zijn. Blijven patchen rond een basis zonder ondersteuning kost op termijn meer dan hem vervangen, en het risico krijg je nooit helemaal dicht.

Niemand kan de site veilig aanpassen. Een fundament dat je niet met vertrouwen kunt aanpassen, heeft het eigenlijk al half begeven. Je herkent het aan code zonder documentatie, een oorspronkelijke bouwer die niet meer bereikbaar is en geen testomgeving waar je wijzigingen uitprobeert voordat ze live gaan. Zo controleer je het: vraag of een wijziging ergens veilig getest kan worden voordat hij live gaat, en of iemand die nu beschikbaar is begrijpt hoe de site in elkaar zit. Houdt iedereen bij elke livegang de adem in, dan is dat een risico in de bouw, hoe de site er ook uitziet.

Het bedrijf is de structuur van de site ontgroeid. Soms is er technisch niets kapot, maar is het bedrijf van vorm veranderd: nieuwe diensten, nieuwe doelgroepen, een ander model. De structuur van de site kan dat niet uitdrukken. Je ziet het aan nieuwe soorten content, een sitemap die wezenlijk anders moet, of onderdelen waar de huidige informatiearchitectuur geen plek voor heeft. Zo controleer je het: schets de site die het bedrijf nu nodig heeft en leg de structuur naast wat er staat. Zit het verschil in de structuur en niet in de buitenkant, dan kom je dichter bij herbouw, en dan dicht je dat gat met een fundament dat de komende jaren kan dragen. Een rebrand alleen telt hier niet. Een echte verandering in wat de site moet doen wel.

Zo lees je de checklist

Pas voordat je gaat tellen eerst de ene regel toe die de checklist eerlijk houdt: stel vast dat elk signaal in de bouw zit en niet in de presentatie. Een site kan gedateerd ogen en eronder prima in orde zijn. Dat is een kwestie van uiterlijk, en een opfrisbeurt lost het op. Gaat het alleen om hoe de site eruitziet, kijk dan naar wat nu de standaard is in design en gebruikservaring in plaats van naar herbouw. Alleen signalen die je kunt herleiden tot hoe de site gebouwd en onderhouden wordt, tellen mee.

Met dat filter erop is het lezen eenvoudig. Bij nul of één vastgesteld signaal in de bouw is het eerlijke antwoord meestal een opfrisbeurt of een redesign, geen herbouw. Wie dan herbouwgeld uitgeeft, vervangt een fundament dat zijn werk deed. Bij twee of meer is er een sterke zaak dat het fundament zelf de beperking is. Een redesign daarbovenop schildert dan een muur waar al scheuren in zitten. Een paar signalen zijn ook alleen al doorslaggevend: een platform zonder ondersteuning en beveiligingsupdates, of een site die niemand veilig kan aanpassen. Allebei zijn het blijvende risico’s waar redesignwerk niet aan komt. Het bredere punt, dat onafhankelijk UX-onderzoek van Nielsen Norman Group goed onderbouwt, is dat je het grote project kiest op basis van bewijs en niet van frustratie. Veel problemen staan op zichzelf en los je op met iets kleiners. Laat het diepere probleem zich dus eerst bewijzen, voordat je de diepere oplossing betaalt.

Houden twee of meer van deze signalen stand nadat je hebt vastgesteld dat ze in de bouw zitten? Dan is het moment daar voor een scopinggesprek. Vóórdat er een budget ligt, niet erna. Flatline werkt precies op die grens tussen een cosmetisch en een structureel probleem, als Framer Enterprise Partner. Ons werk aan corporate websites gaat uit van wat het fundament echt kan dragen, niet van hoe de huidige site eruitziet. Wijst jouw checklist verder dan een likje verf, dan is de volgende vraag waar een herbouw tegen bestand moet zijn. Die vraag breng je beter bewust in kaart voordat het werk wordt afgebakend.

Veelgestelde vragen

Wat zijn de signalen dat een website opnieuw gebouwd moet worden?

De betrouwbare signalen zitten in de bouw, niet in het beeld: voor gewone aanpassingen heb je een developer nodig, eenvoudige wijzigingen zijn traag of riskant, de onderhoudskosten stijgen, het platform houdt tegen wat het bedrijf nodig heeft, koppelingen zijn kwetsbaar, de prestaties blijven na optimalisatie op een plafond steken, de stack wordt niet meer ondersteund of is onveilig, niemand kan de site veilig aanpassen en het bedrijf is de structuur ontgroeid. Uiterlijk is het minst betrouwbare signaal. Een site kan gedateerd ogen en gezond zijn, of modern ogen en nauwelijks te onderhouden.

Heb ik een herbouw nodig of is een redesign genoeg?

Kijk of het probleem zit in hoe de site eruitziet en is ingedeeld, of in hoe hij gebouwd is. Is het fundament gezond en zit het probleem in het beeld of in de opbouw van de gebruikservaring, dan past een opfrisbeurt of redesign. Houdt het platform mogelijkheden tegen, zijn wijzigingen traag of riskant, zet de architectuur een plafond op de prestaties of wordt de stack niet meer ondersteund? Dan is het fundament het probleem en is herbouw het eerlijke antwoord. Stel per signaal vast dat het in de bouw zit voordat je het meetelt.

Heeft een trage of gedateerde website een herbouw nodig?

Niet per se. Een gedateerde look is een kwestie van uiterlijk, en die lost een opfrisbeurt op. Traagheid door niet-geoptimaliseerde afbeeldingen of scripts los je op zonder herbouw. Traagheid wijst pas op herbouw als hij een serieuze optimalisatieronde overleeft. Dan zit de beperking in hoe de site gebouwd is, niet in hoe hij is ingesteld. Optimaliseer dus eerst grondig en meet opnieuw, voordat je snelheid als signaal in de bouw behandelt.

Bij hoeveel signalen is een herbouw van je website gerechtvaardigd?

Twee of meer signalen waarvan je kunt vaststellen dat ze in de bouw zitten, maken een sterke zaak voor herbouw. Een paar zijn op zichzelf al doorslaggevend, zoals een platform zonder ondersteuning of met beveiligingslekken, of een site die niemand veilig kan aanpassen. Dat zijn blijvende risico’s die een redesign niet oplost. Nul of één wijst meestal op een opfrisbeurt of redesign. Het aantal zegt pas iets als je van elk signaal hebt gecontroleerd of het in de bouw zit en niet alleen in het uiterlijk.

Is een herbouw van je website slecht voor je SEO?

Alleen als je de migratie slordig aanpakt. Het grootste risico is URL’s veranderen zonder ze te mappen. De oplossing: koppel elke oude URL aan de nieuwe tegenhanger en zet permanente redirects (301), die het grootste deel van de rankingwaarde doorgeven aan het nieuwe adres. Behoud de pagina’s die al ranken, houd de URL-structuur gelijk waar het kan, werk interne links bij en houd na de lancering je posities in Google in de gaten. Goed uitgevoerd helpt een herbouw je rankings op termijn meestal juist, door een schonere structuur en betere prestaties.

De kern

• De signalen die een herbouw rechtvaardigen, zitten in de bouw en niet in het beeld. Een site kan gedateerd ogen en gezond zijn, of er strak uitzien en nauwelijks te onderhouden zijn. Uiterlijk is daarom het minst betrouwbare signaal.

• Controleer drie groepen: is de site moeilijk aan te passen geworden, houdt het platform tegen wat het bedrijf nodig heeft, en is het fundament zelf een blijvend risico?

• Elk signaal kun je zelf controleren. Meet de doorlooptijd van je laatste vijf wijzigingsverzoeken, schrijf de laatste drie dingen op die je niet kon bouwen, optimaliseer en meet de prestaties opnieuw, en ga na of de stack nog beveiligingsupdates krijgt en of je wijzigingen veilig kunt testen.

• Stel per signaal vast dat het in de bouw zit voordat je het meetelt. Traagheid die na optimalisatie verdwijnt, of een site die alleen gedateerd oogt, vraagt om een opfrisbeurt of redesign, niet om herbouw.

• Twee of meer vastgestelde signalen in de bouw maken een sterke zaak voor herbouw. Een platform zonder ondersteuning of een site die niet aan te passen is, kan op zichzelf al doorslaggevend zijn. Bij nul of één is een kleiner project meestal het eerlijke antwoord.

Herbouw is te vaak de juiste keuze om taboe te zijn, en te vaak de verkeerde om de standaard te zijn. Welke van de twee het bij jou is, ontdek je niet door beter naar de buitenkant te kijken, want daar ligt het zwakste bewijs. Je ontdekt het door te kijken hoe de site zich gedraagt als je hem wilt aanpassen, uitbreiden en erop wilt kunnen vertrouwen. Loop de negen signalen langs, stel bij elk vast dat het in de bouw zit, en tel. Is de uitkomst laag, dan heb je jezelf net de kosten bespaard van een probleem dat je niet had. Is hij hoog, dan heb je nu het bewijs om het echte probleem af te bakenen, voordat iemand geld uitgeeft op basis van een gok.