Website vernieuwen: van audit tot livegang in 7 stappen

Een website vernieuwen is het opnieuw opbouwen van een bestaande site: de structuur, de content, de interface en vaak ook de technische basis, meestal op hetzelfde domein en met een redirectplan dat de opgebouwde vindbaarheid behoudt. Precies op dat laatste punt loopt het bij de meeste projecten mis.

Het visuele deel plant iedereen in. De onderdelen die bepalen of het project zichzelf terugverdient zijn een stuk minder zichtbaar: waarop de huidige site gevonden wordt, welke pagina's daadwerkelijk aanvragen opleveren, waar elk oud adres straks uitkomt en wie tekent voordat de knop om gaat.

Deze gids doorloopt de volledige cyclus in 7 stappen en beantwoordt eerst de drie vragen die voor elke opdracht komen: wat een vernieuwing omvat, wat bureaus er in 2026 voor rekenen en hoe lang het duurt.

Een vernieuwing raakt vier lagen tegelijk: de informatiestructuur, de content, de interface en de technische basis. Eén laag opnieuw bouwen en dat een vernieuwing noemen levert een mooiere site op die precies dezelfde cijfers draait als de oude. De omvang wordt bepaald door de lagen die je aanraakt, niet door hoe anders de homepage eruitziet.

Informatiestructuur. Het pagina-overzicht, de navigatie, de URL-structuur en de relaties tussen pagina's. Dit is de laag die posities verschuift, en de laag die in briefings het vaakst ontbreekt.

Content. Geen kopie van oude teksten in nieuwe sjablonen. Een vernieuwing is het logische moment om pagina's die niemand leest op te ruimen, drie overlappende dienstenpagina's samen te voegen en een propositie te herschrijven die sinds de vorige bouw is afgedreven.

Interface. Opmaak, typografie, componentenbibliotheek, responsive gedrag, toegankelijkheid. De zichtbare laag, waarop opdrachtgevers het project beoordelen.

Technische basis. Hosting, CMS, rendering, prestatiebudget, analytics, formulierafhandeling. Wie deze laag verandert, voert een technische migratie uit, met een eigen risicoprofiel.

Drie klussen heten vaak een vernieuwing zonder het te zijn. Een themawissel raakt alleen de interface. Een tekstupdate raakt alleen de content. Een CMS-wissel verplaatst de technische basis met behoud van het ontwerp. Alle drie zijn zinvol werk, maar geen ervan repareert een site die om structurele redenen aanvragen misloopt.

Een volledige vernieuwing is nodig als het probleem structureel is, en een opfrisbeurt volstaat als het cosmetisch is. De praktische toets: schrijf op wat er misgaat en vraag je af of het oplossen daarvan het pagina-overzicht of de navigatie moet veranderen. Zo ja, dan is het een vernieuwing. Zouden nieuwe foto's en scherpere teksten het gat dichten, dan haalt een opfrisbeurt hetzelfde in een fractie van de tijd en het budget.

Signalen die op een volledige vernieuwing wijzen: de site kan de pagina's niet aan die je nu nodig hebt om te verkopen, de navigatie is aangegroeid en niemand vindt nog iets, mobiel wordt gerepareerd in plaats van ontworpen, het CMS blokkeert de marketingafdeling bij het publiceren, of de technische basis maakt prestatiewerk onmogelijk. Signalen die op een opfrisbeurt wijzen: gedateerde vormgeving, oude teksten, zwakke actieknoppen, te dunne dienstenpagina's.

De dure vergissing werkt beide kanten op. Vernieuwen waar een opfrisbeurt volstond kost budget en zet opgebouwde vindbaarheid zonder reden terug. Opfrissen waar de structuur het probleem is geeft het bekende resultat: een kwartaal lang mooier, en daarna dezelfde cijfers.

Offertes voor het vernieuwen van een website vallen in drie schijven uiteen, en de spreiding binnen elke schijf is groot genoeg om één gemiddeld bedrag waardeloos te maken. De bedragen hieronder zijn Europese richtwaarden uit bureau-offertes van juli 2026, geen prijslijst van Vezert. Wat een offerte binnen zijn schijf beweegt: het aantal pagina's, hoeveel content geschreven moet worden in plaats van meegenomen, en of er koppelingen zijn.

Een kleine zakelijke vernieuwing van tien tot twintig pagina's op een bestaand CMS met overgenomen content ligt doorgaans tussen €6.000 en €15.000. Een middelgrote B2B-vernieuwing met nieuwe structuur, nieuwe commerciële teksten en een migratieplan ligt doorgaans tussen €15.000 en €35.000. Een complexe vernieuwing met CMS-wissel, meerdere talen of een CRM-koppeling begint rond €35.000 en loopt regelmatig door tot boven €80.000.

Vier posten verklaren het grootste deel van het verschil tussen twee offertes voor wat op hetzelfde project lijkt:

• Contentproductie. Bestaande teksten meenemen is goedkoop. Veertig pagina's schrijven is een project op zich en wordt vaak apart begroot of helemaal niet aangeboden.
• Migratiewerk. URL-mapping, het inrichten van de redirects en de controle na livegang zijn echte ontwikkeluren. Een offerte die ze niet noemt heeft ze óf stilzwijgend opgenomen óf uitgesloten.
• Koppelingen. Elk aangesloten systeem, CRM, ERP, reserveren of betalen, brengt analyse, bouw en testwerk mee.
• Aantal talen. Elke extra taal vermenigvuldigt content, testwerk en de redirectkaart.

Voor een uitsplitsing per post behandelt ons artikel over wat een website kost hetzelfde terrein voor nieuwbouw, en onze prijzen tonen de startpunten waarmee wij werken.

Het vernieuwen van een website duurt afhankelijk van de omvang tussen 4 en 20 weken, en de factor die de planning het sterkst beïnvloedt is niet het ontwerp en niet de bouw. Het is de content. Projecten die uitlopen, lopen bijna altijd uit doordat teksten, fotografie of productdata te laat kwamen, niet doordat de bouw langer duurde.

De tabel hieronder toont waargenomen doorlooptijden, geen toezeggingen. Reken op de bovenkant als de teksten bij aanvang nog niet geschreven zijn.

Stap 1 bepaalt wat de vernieuwing in het bedrijf moet veranderen, in cijfers. Stap 2 brengt in kaart wat de huidige site al goed doet, zodat je dat niet per ongeluk sloopt. Beide gebeuren voordat iemand een ontwerpprogramma opent, en ze overslaan is de duurste sluiproute van het hele traject.

Stap 1: doelen. Een bruikbaar doel noemt een cijfer en een richting: gekwalificeerde aanvragen via de site, kosten per contact, aandeel bezoekers dat een dienstenpagina bereikt, de tijd die marketing nodig heeft om een pagina te publiceren. Een doel als moderner ogen valt na livegang niet te toetsen, waardoor het project nooit geslaagd of mislukt kan worden genoemd.

Noteer de huidige waarde van elk cijfer vóór de start. Wat je vandaag niet meet, kan de vernieuwing niet verbeteren, en dan is de eerste taak meetbaarheid in plaats van ontwerp.

Stap 2: de audit. Drie inventarisaties, die alle drie later terugkomen:

• Vindbaarheid. Welke URL's geïndexeerd zijn, op welke zoekopdrachten ze verschijnen, welke pagina's organische bezoeken binnenhalen. Deze export wordt in stap 7 de redirectkaart, dus maak hem nu en niet als de oude site al weg is.
• Gedrag. Welke pagina's bezoek krijgen, welke converteren, waar sessies stoppen. Pagina's die converteren worden beschermd, wat het ontwerpteam er ook van vindt.
• Techniek. Prestaties gemeten aan de Core Web Vitals, toegankelijkheid, mobiele weergave, gebroken links, onnodig geïndexeerde pagina's.

Onze gids voor een website-audit beschrijft de procedure volledig. Volgens de documentatie van Google over de Core Web Vitals weerspiegelen deze waarden de werkelijke bezoekerservaring en geen laboratoriumomstandigheden, en daarom hoort een vernieuwing ze vooraf en achteraf vast te leggen in plaats van op een synthetische score te vertrouwen.

Content en structuur bepalen of de nieuwe site verkoopt, en het zijn de twee stappen die opdrachtgevers het liefst naast het ontwerp laten lopen. Dat kan niet. Wie sjablonen bouwt zonder pagina-overzicht gokt naar wat die sjablonen moeten dragen, en de gok komt tijdens de bouw aan het licht, op het slechtst denkbare moment.

Stap 3: content. Begin bij het overzicht uit de audit en geef elke bestaande pagina één van vier uitkomsten: ongewijzigd houden, herschrijven, samenvoegen met een andere pagina, of opruimen. Opruimen is de beslissing die wordt vermeden, en meestal de meest waardevolle. Een site van zestig pagina's waarvan er twaalf alles opleveren wordt overzichtelijker, goedkoper in onderhoud en duidelijker voor zoekmachines zodra de andere achtenveertig zijn samengevoegd.

Schrijf daarna wat ontbreekt. De meeste projecten ontdekken hier dat de dienstenpagina's nooit over prijzen hebben gesproken, dat er geen bewijs is buiten een balk met logo's, en dat de propositie op de homepage het bedrijf beschrijft in plaats van het probleem van de klant.

Stap 4: structuur. Het overzicht wordt een navigatieboom en een URL-schema. Twee regels besparen later veel gedoe: behoud de bestaande URL overal waar de pagina ongewijzigd blijft, en bepaal de URL van elke nieuwe pagina vóórdat sjablonen worden gebouwd, niet erna. Onze gids over websitestructuur laat zien hoe je die boom bouwt, en het artikel over website-architectuur en zoekzichtbaarheid legt uit waarom de vorm ervan bepaalt wat er scoort.

Ontwerp en bouw maken de vernieuwing zichtbaar, en daar betalen de eerdere stappen zich uit of melden zich luidruchtig. Zijn de teksten geschreven en is de structuur akkoord, dan is deze fase uitvoering. Zijn ze dat niet, dan is dit de fase waarin het project daarachter komt, en elke ontdekking kost hier een veelvoud van wat ze in stap 3 had gekost.

Stap 5: ontwerp en prototype. Er worden sjablonen ontworpen, geen pagina's. Een zakelijke site heeft er doorgaans zes tot tien nodig: homepage, dienstenpagina, klantcase, artikel, overzichtspagina, contact, juridisch, plus wat het bedrijf specifiek vraagt. Elk sjabloon wordt één keer ontworpen en hergebruikt, en dat houdt de bouw voorspelbaar.

Prototypeer de routes die ertoe doen voordat de bouw begint. Het pad van een dienstenpagina naar een verzonden aanvraag verdient een test met echte mensen zolang aanpassen nog goedkoop is. De mobiele navigatie ook, want daar verliezen de meeste zakelijke sites stilletjes hun bezoekers.

Stap 6: bouw. Ontwikkeling op de goedgekeurde sjablonen, content geladen, formulieren en meting aangesloten, prestatiebudget bewaakt tijdens het bouwen in plaats van achteraf getoetst. Toegankelijkheid hoort hier ook: contrast, focusstatussen en semantische structuur achteraf inbouwen kost een veelvoud van meteen goed doen.

Een veelgestelde vraag hoort in deze fase thuis: bouw je de nieuwe site naast de oude? Meestal wel. Een aparte omgeving laat je alles afmaken en testen terwijl de huidige site gewoon blijft draaien. De voorwaarde is dat die omgeving niet indexeerbaar is, anders concurreert hij met de site die je wilt behouden.

Eén beslissing uit deze fase reikt ver voorbij de bouw. Volgens Google Search Central voert Googlebot JavaScript uit, maar die rendering is uitgesteld en afhankelijk van beschikbare capaciteit: content die pas na uitvoering in de browser bestaat, loopt meer kans gemist te worden. Stapt de vernieuwing over op een JavaScript-framework, dan is server-side rendering voor contentpagina's geen voorkeur meer maar een eis.

Livegang is een vindbaarheidsmoment, niet alleen een deployment. Elke URL die verandert moet bewust ergens uitkomen, en die koppeling maak je vóór de omschakeldag in plaats van hem achteraf te reconstrueren uit 404-rapporten. Dit is de stap waar het verschil tussen een zorgvuldige en een slordige vernieuwing binnen weken zichtbaar wordt in het verkeer.

De volgorde die werkt:

1. Bevries de URL-inventaris. Geïndexeerde URL's uit Search Console, een volledige crawl van de huidige site, de geldende sitemaps, pagina's met organische bezoeken of conversies, en pagina's waar externe links naartoe wijzen.
2. Wijs elke URL een bestemming toe. Elke oude URL krijgt een besluit: behouden, doorverwijzen, samenvoegen met een andere pagina, of bewust verwijderen.
3. Zet permanente redirects in één hop. Volgens Google Search Central geeft een permanente redirect aan dat de verhuizing definitief is, en ketens verspillen crawlbudget. Oud wijst rechtstreeks naar nieuw, nooit via een tussenadres.
4. Genereer de taalverwijzingen opnieuw. Op een meertalige site moeten hreflang-annotaties naar de nieuwe canonieke URL's wijzen en elkaar over en weer noemen. De Google-documentatie over gelokaliseerde versies legt de eisen vast.
5. Controleer op staging en daarna opnieuw in productie. Staging hoort vóór aanvang op noindex te staan en bij livegang vrijgegeven te worden. Die twee schakelaars omdraaien is een van de gangbaarste manieren om een maand te verliezen.
6. Houd de redirects in stand. Google adviseert minstens een jaar, en er is geen reden ze daarna weg te halen zolang de oude adressen nog verkeer krijgen of links dragen.

Twee punten verdienen een heldere formulering, omdat de meeste checklists ze verkeerd weergeven. Een tijdelijke redirect geeft signalen wel degelijk door: de reden om de permanente te gebruiken is dat die de verhuizing als definitief meldt, niet dat de andere waarde zou lekken. En Google publiceert geen getal voor hoe lang een terugval duurt, alleen dat schommelingen te verwachten zijn zolang de signalen zich consolideren. Elk artikel met een vast aantal weken citeert de ervaring van een leverancier, geen documentatie.

De volledige procedure, met de specificatie van de mappingtabel en de monitoring erna, staat in onze SEO-migratiechecklist.

Websitevernieuwingen mislukken om een beperkt aantal terugkerende redenen, en bijna allemaal worden ze vóór livegang beslist. Het patroon is constant: projecten die misgaan zijn die waarin het ontwerp begon voordat de content en de URL-inventaris bestonden, waardoor elke volgende stap een onafgemaakt besluit erfde.

Vier faalpatronen die het benoemen waard zijn:

• Het ontwerp stuurde het project. Sjablonen werden goedgekeurd voordat iemand wist wat erin moest, en de tekst werd in de opmaak geperst in plaats van andersom.
• De oude site gold als waardeloos. Pagina's die aanvragen opleverden werden opgeruimd omdat ze gedateerd oogden, zonder eerst de cijfers te bekijken.
• Migratie kwam als laatste. De redirectkaart werd in de laatste week samengesteld, uit een onvolledige lijst, door wie toevallig tijd had.
• Er werd vooraf niets gemeten. Zonder nulmeting valt niet vast te stellen of de nieuwe site beter is, en de volgende vernieuwing start weer op gevoel.

Checklist vóór livegang. Geen enkel punt hoort op de omschakeldag zelf te worden afgevinkt:

1. Elke geïndexeerde URL staat met een vastgelegd besluit in de mappingtabel.
2. Redirects zijn ingericht, lossen in één hop op en zijn getest tegen de echte lijst.
3. Interne links wijzen naar definitieve URL's, niet via een redirect. Controleer zowel de content zelf als navigatie en knoppen: die staan apart opgeslagen, en de tweede ronde is de ronde die men vergeet.
4. Canonical-tags verwijzen naar de nieuwe URL's en hreflang-annotaties noemen elkaar.
5. Staging staat op noindex, productie niet. Controleer beide ná de deployment, niet ervoor.
6. Sitemaps opnieuw gegenereerd en ingediend, met kloppende wijzigingsdatums.
7. Analytics, doelen en formuliermeting vuren op de nieuwe sjablonen. Test een echte inzending.
8. Prestaties en toegankelijkheid gemeten op de nieuwe pagina's tegen de nulmeting.
9. Titels en koppen behouden de betekenis waarmee pagina's scoorden. Alle titels in één keer herschrijven verandert waarvoor een pagina relevant is.
10. Er is een monitoringplan voor de weken na livegang, met een naam erbij.

Na livegang stopt het werk niet, het verandert van vorm. Ons artikel over optimalisatie na lancering beschrijft wat je in welke volgorde in de gaten houdt. Wil je de hele cyclus liever bij een team leggen dat hem regelmatig draait, dan is dat precies ons werk aan bedrijfswebsites.