Nieuwe website lanceren: de checklist voor livegang en de eerste 90 dagen

Een lanceerchecklist voor je website is de geordende lijst met controles die een team uitvoert voor, tijdens en na de livegang van een nieuwe site: content nalezen, formulieren, analytics en toestemming, SEO en redirects, snelheid, toegankelijkheid, beveiliging, de DNS-overstap zelf en de eerste weken monitoring. Hij bestaat omdat de meeste lanceerproblemen goedkoop te vinden zijn op de testomgeving en duur worden zodra Google de verkeerde versie heeft gecrawld.

Deze checklist is geschreven voor teams die een nieuwe website lanceren of een vernieuwde bedrijfssite live zetten, zelf of met een bureau, en voor iedereen die wil weten hoe je een website online zet zonder het verkeer te verliezen dat de oude site had opgebouwd. Hij volgt de drie fases waarin je echt werkt: vóór de livegang, de lanceerdag en de eerste 90 dagen daarna. Bij elk punt staat wat je controleert en, waar het ertoe doet, met welke tool je ziet of het goed is.

Vervangt de nieuwe site een oude? Lees dan het stuk over redirects twee keer. Die stap bepaalt of het zoekverkeer van de oude site meegaat.

Een bruikbare checklist voor livegang dekt drie fases. De controles vóór de lancering gebeuren op de testomgeving (staging) en bepalen of de site klaar is. De lanceerdag is de overstap zelf: DNS, caches en indexeringssignalen. De controles na de lancering lopen ongeveer 90 dagen en bevestigen dat wat op staging werkte ook werkt met echt verkeer, echte browsers en echte zoekmachinecrawlers. Veel gepubliceerde checklists stoppen bij de publicatieknop, daarom krijgt de derde fase hier een eigen deel.

De tabel hieronder is de korte versie en werkt als sjabloon dat je zo in je projecttool kunt zetten. Geef elke regel een eigenaar met een naam. Een taak die bij "het team" ligt, ligt meestal bij niemand, en dat is precies de taak die op de ochtend van de lancering nog openstaat.

Contentcontroles zijn het minst technische deel van een checklist voor een nieuwe website, en het deel dat bezoekers als eerste zien. Lees elke pagina op staging, niet in de editor van het CMS, want templates veranderen hoe tekst afbreekt en hoe afbeeldingen worden bijgesneden. Controleer prijzen, telefoonnummers, adressen, openingstijden en bedrijfsgegevens tegen de bron, en vervang elke placeholder, elke alinea lorem ipsum en elke testafbeelding. Kapotte interne links en knoppen die nergens heen gaan neem je in dezelfde ronde mee.

Content en correctie

• Elke pagina heeft een eigen title-tag, een eigen meta description en precies één H1
• Afbeeldingen hebben een alt-tekst die beschrijft wat erop staat en zijn gecomprimeerd (WebP of AVIF)
• Het copyrightjaar, de links naar social media en het logo dat naar de homepage linkt werken allemaal
• De Open Graph-afbeelding en -titel zien er goed uit als je een link deelt in Slack, LinkedIn of WhatsApp
• Een eigen 404-pagina stuurt bezoekers terug naar de hoofdonderdelen

Formulieren en e-mailbezorging

Een formulier dat verzendt, is maar half getest. De andere helft is of de meldingsmail aankomt bij de persoon die moet reageren. Verstuur elk formulier met realistische gegevens en kijk daarna in de inbox, in de spammap en in het CRM of de spreadsheet waar de lead hoort te landen.

Verstuur formuliermeldingen via een geauthenticeerd domein of een transactionele e-maildienst, niet via de standaard mailfunctie van de webserver. Sinds februari 2024 eisen de afzenderrichtlijnen van Gmail dat elke afzender SPF of DKIM instelt, en dat afzenders van meer dan 5.000 berichten per dag beide gebruiken en een DMARC-record publiceren. Een contactformulier haalt dat volume nooit, maar niet-geauthenticeerde mail van een nieuw domein belandt veel vaker in de spam. Niemand merkt het tot een klant belt met de vraag waarom er nooit iemand heeft gereageerd.

Analytics moet op de lanceerdag live en gecontroleerd zijn, want gegevens die je in de eerste week niet hebt verzameld, krijg je later niet terug. Een tag plakken is niet genoeg. Bepaal welke acties als succes tellen (formulierinzendingen, offerteaanvragen, telefoontjes, aankopen), markeer ze in GA4 als key events en test ze een voor een in DebugView of Tag Assistant vóór de DNS-overstap, zolang je nog rustig kunt bijsturen.

Heeft de site bezoekers uit de EU, dan moeten de cookiebanner en analytics samenwerken. Google eist dat sites die gebruikers uit de EER met zijn tags meten, toestemming vragen en die doorgeven via consent mode, dat twee parameters, ad_user_data en ad_personalization, aan de oorspronkelijke opslagsignalen toevoegde. In Nederland vraagt artikel 11.7a van de Telecommunicatiewet toestemming voor tracking cookies, en de Autoriteit Persoonsgegevens schrijft in haar richtlijnen voor heldere cookiebanners dat weigeren net zo makkelijk moet zijn als accepteren en dat vakjes niet vooraf aangevinkt mogen zijn. Tags mogen dus geen analytics- of advertentiecookies plaatsen voordat de bezoeker akkoord geeft. Test beide routes in een privévenster en controleer of weigeren de cookies echt tegenhoudt.

Checklist voor tracking

• GA4-property aangemaakt, met het verkeer van je eigen kantoor uitgefilterd
• Key events gedefinieerd voor elke conversie die voor het bedrijf telt
• Search Console-property geverifieerd vóór de lancering, bij voorkeur als domeinproperty
• Heatmap- of sessie-opnametools vermeld in de cookiebanner en de privacyverklaring
• Afspraken over UTM-namen voor de aankondiging van de lancering en eventuele campagnes

De meeste SEO-problemen op de lanceerdag komen van staginginstellingen die mee naar productie gaan. Een stagingsite is meestal verborgen voor zoekmachines, en dat moet ongedaan worden gemaakt op het moment dat de site live gaat. Volgens de documentatie van Google over het blokkeren van indexering kan Google de noindex-regel van een pagina die in robots.txt is geblokkeerd helemaal niet lezen. Controleer de twee instellingen dus samen en niet los van elkaar.

Indexeringssignalen

• Verwijder noindex-metatags en X-Robots-Tag-headers die voor staging waren ingesteld
• robots.txt op het live domein mag geen Disallow: / bevatten en kan met een Sitemap:-regel naar de sitemap verwijzen
• Elke pagina heeft een canonical tag die naar zichzelf op het live domein verwijst, niet naar de staging-URL
• Eén versie van het domein (HTTPS, met of zonder www) is de hoofdversie en de andere redirecten daarheen
• Gestructureerde gegevens slagen voor de Test voor uitgebreide resultaten van Google

XML-sitemap

Genereer een sitemap met alleen live, indexeerbare, canonieke URL's. De sitemaprichtlijnen van Google leggen de grens van één bestand bij 50.000 URL's of 50 MB ongecomprimeerd en vermelden dat Google de waarden priority en changefreq negeert. Daar hoef je dus niet aan te schaven. lastmod gebruikt Google alleen als die waarde consequent klopt.

Redirects vanaf de oude site

Vervangt de nieuwe site een oude, dan is het redirectplan het belangrijkste document van het project. Crawl de oude site, exporteer de URL's samen met de pagina's die backlinks of zoekverkeer hebben, en koppel elke URL aan de dichtstbijzijnde nieuwe tegenhanger. De handleiding van Google voor sitemigraties vraagt om permanente redirects aan de serverkant (301 of 308), geen redirectketens, geen massale redirects naar de homepage, en de redirects minstens een jaar te laten staan. Onze gids over websitemigratie en de SEO-migratiechecklist lopen stap voor stap door het koppelen.

Meertalige sites

Op sites met meer dan één taal heeft elke pagina hreflang-annotaties nodig die alle taalversies noemen, inclusief zichzelf, en elke versie moet terugverwijzen. Volgens de documentatie van Google over gelokaliseerde versies worden annotaties die maar één kant op wijzen genegeerd. Voeg een x-default toe voor de taalkeuzepagina of de standaardpagina.

Snelheid los je het makkelijkst op vóór de lancering, zolang de templates nog openliggen. De Core Web Vitals van Google geven duidelijke doelen. Web.dev definieert een goede ervaring, gemeten op het 75e percentiel van het aantal paginaladingen op mobiel en desktop, als een Largest Contentful Paint van 2,5 seconden of minder, een Interaction to Next Paint van 200 milliseconden of minder en een Cumulative Layout Shift van 0,1 of minder. INP verving in 2024 First Input Delay als Core Web Vital.

Vóór de lancering heb je alleen labgegevens. Draai PageSpeed Insights en Lighthouse met het mobiele profiel op de homepage en op één pagina van elk templatetype (dienstpagina, artikel, contactpagina, productpagina). Pak eerst de zware onderdelen aan: ongecomprimeerde hero-afbeeldingen, lettertypen die uit meerdere bronnen komen, en chat- of trackingscripts die de main thread blokkeren. Onze gids over een high-performance website bouwen gaat dieper op de oplossingen in.

Toegankelijkheidsfouten komen veel voor en zijn meestal makkelijk te vinden. Het WebAIM Million-rapport 2026 vond detecteerbare WCAG 2-fouten op 95,9% van de een miljoen best bezochte homepages: tekst met te weinig contrast op 83,9% daarvan, ontbrekende alt-tekst op 53,1% en ontbrekende formulierlabels op 51%. Automatische tools zoals axe of WAVE vinden de meeste daarvan op staging in een paar minuten per template.

Automatische scans missen veel, dus doe er een handmatige ronde bij. Tab met het toetsenbord door elke template, controleer of de focusrand zichtbaar is en zorg dat de cookiebanner, menu's en pop-ups zonder muis te sluiten zijn. WCAG 2.2 niveau AA is het gebruikelijke doel. In Nederland is de European Accessibility Act omgezet in de Implementatiewet toegankelijkheidsvoorschriften producten en diensten, die sinds 28 juni 2025 geldt. Volgens de Rijksoverheid vallen onder meer webshops en mobiele apps eronder; micro-ondernemingen die diensten leveren zijn vrijgesteld. Onze gids over de WCAG-richtlijnen zet de controles per component op een rij.

Beveiliging vóór de lancering is vooral configuratie. Het SSL-certificaat moet elke hostnaam dekken die je gebruikt, met en zonder www, en zichzelf automatisch vernieuwen, en elk HTTP-verzoek moet naar HTTPS redirecten. Security headers stel je in een uur in en ze dichten veelvoorkomende gaten: Strict-Transport-Security, een Content-Security-Policy (zie de CSP-gids van MDN), X-Content-Type-Options en een Referrer-Policy. Controleer ze met een externe scanner in plaats van te vertrouwen op het hostingpaneel.

• Beheerdersaccounts hebben unieke wachtwoorden en tweestapsverificatie, en standaardaccounts zijn verwijderd
• Het CMS, de plug-ins en de dependencies draaien op actuele versies
• Automatische back-ups lopen, staan buiten de server opgeslagen, en er is één keer een herstel getest
• Formulieren hebben spambescherming, zoals een honeypotveld, rate limiting of een CAPTCHA
• Uptime-monitoring waarschuwt een persoon met een naam, niet een gedeelde inbox die niemand leest

Juridische pagina's en bedrijfsgegevens

Een website die persoonsgegevens verzamelt, via een contactformulier of analytics, heeft een privacyverklaring nodig: artikel 13 van de AVG verplicht je bezoekers te informeren over wie je bent, welke gegevens je verwerkt, waarom en hoe lang. Zet daarnaast een cookiebeleid online. Bied je diensten of producten online aan, dan verplicht artikel 3:15d van het Burgerlijk Wetboek je om je naam, vestigingsadres, e-mailadres, KvK-nummer en, als je btw-plichtig bent, je btw-identificatienummer makkelijk en permanent vindbaar te maken. De meeste bedrijven zetten die gegevens in de footer van elke pagina. De privacyverklaring moet de tools noemen die echt op de site draaien, dus schrijf haar pas als de keuzes voor analytics, chat en embeds vastliggen.

De lanceerdag hoort saai te zijn. Kies een doordeweekse ochtend waarop de developer en de contentverantwoordelijke de rest van de dag allebei beschikbaar zijn, en vermijd vrijdagmiddag. Bevries contentwijzigingen op de oude site een dag van tevoren, zodat daar niets verschijnt wat de nieuwe site niet heeft. Werk de stappen daarna in deze volgorde af en vink ze een voor een af.

1. Verlaag een of twee dagen van tevoren de TTL van de DNS-records die je gaat wijzigen (300 seconden is een gangbare waarde). Resolvers bewaren een record zo lang als de TTL die ze kregen, dus dit helpt alleen als je het vooraf doet.
2. Maak een laatste back-up van zowel de oude als de nieuwe site.
3. Deploy en zet daarna de DNS of de hostingconfiguratie om.
4. Leeg elke cachelaag (CDN, server, CMS), zodat niemand een verouderde of stagingversie te zien krijgt.
5. Controleer robots.txt en de noindex-status op het live domein.
6. Crawl de lijst met oude URL's om de redirects te bevestigen en open de 20 pagina's met het meeste verkeer met de hand.
7. Dien de XML-sitemap in via Search Console en draai URL-inspectie op de homepage en de belangrijkste dienstpagina's. Is het domein zelf veranderd, gebruik dan de tool voor adreswijziging, die Google alleen bedoelt voor verhuizingen tussen domeinen of subdomeinen.
8. Verstuur een echt testformulier en controleer of zowel de e-mail als het GA4-key event binnenkomen.
9. Zet uptime-monitoring aan en verhoog de TTL weer zodra de nieuwe opzet stabiel draait.

Reken op vertraging voordat de zoekresultaten bijtrekken. Volgens Google kan crawlen een paar dagen tot een paar weken duren, en dezelfde URL opnieuw aanvragen versnelt niets. Na een sitemigratie kunnen de posities een tijd schommelen terwijl Google de redirects verwerkt.

De eerste maand draait om wat de stagingreview heeft gemist. Echte bezoekers komen binnen via browsers, apparaten en routes die niemand heeft getest, en crawlers vinden oude URL's die niemand heeft gekoppeld. Kijk de eerste twee weken om de paar dagen in Search Console en daarna wekelijks. Problemen die je in deze periode oplost, kosten weinig. Dezelfde problemen in maand vier hebben al verkeer en leads gekost.

Search Console en 404's

• Let in het rapport Pagina-indexering op stijgende aantallen bij "Niet gevonden (404)", "Uitgesloten door noindex-tag" en "Pagina met omleiding"
• Redirect 404-URL's met backlinks of verkeer naar de juiste nieuwe pagina's
• Controleer of de sitemap zonder fouten als verwerkt wordt getoond
• Vergelijk de vertoningen voor je belangrijkste zoekopdrachten met de nulmeting van de oude site

Analytics en conversies

• Vergelijk het aantal conversies in GA4 met wat echt in het CRM of de inbox is binnengekomen, en zoek uit waar het verschil vandaan komt voordat iemand de cijfers gebruikt
• Zoek naar landingspagina's met een opvallend hoog exitpercentage op mobiel
• Controleer het toestemmingspercentage. Precies 0% of precies 100% acceptatie betekent dat er iets verkeerd is ingesteld

Prestatiegegevens uit het veld

Labscores van vóór de lancering zijn een voorspelling. Veldgegevens komen van echte Chrome-gebruikers via het Chrome UX Report, dat gegevens over een doorlopende periode van 28 dagen samenvoegt. Het eerste bruikbare Core Web Vitals-rapport komt dus ongeveer een maand na de lancering, en een site met weinig verkeer heeft misschien nooit genoeg gegevens voor resultaten per pagina. Dan vullen gegevens op originniveau of je eigen real-user monitoring het gat.

In de tweede maand heb je genoeg gegevens om van repareren naar verbeteren te gaan. De vraag verschuift van "is er iets kapot?" naar "waar haken bezoekers af, en waarom?" Gebruik de rapporten over conversiepaden en landingspagina's om de twee of drie pagina's te kiezen die het zwaarst wegen voor leads, en bekijk met heatmaps of sessie-opnames hoe mensen ze gebruiken voordat je iets verandert.

Verander één ding tegelijk en meet het tegen de nulmeting, want van wijzigingen in één batch weet je niet welke het effect had. Is er genoeg verkeer, draai dan een echte A/B-test volgens de cyclus uit de A/B-testgids van de Nielsen Norman Group: een hypothese, één variabele, een vaste maatstaf en genoeg tijd om tot een uitkomst te komen. Op B2B-sites met weinig verkeer is een zuivere voor-en-navergelijking over een aantal weken vaak het eerlijke alternatief. Onze gids over conversieoptimalisatie gaat verder.

Typische verbeteringen in deze periode:

• Kortere formulieren, zonder de velden die sales nooit gebruikt
• Duidelijkere calls-to-action in het eerste scherm op mobiel
• Paginasecties in een andere volgorde op basis van scrolldiepte
• Interne links vanuit blogartikelen naar de dienstpagina's die ze ondersteunen
• Dunne pagina's uitgebreid of samengevoegd tot sterkere pagina's

Waar AI-tools helpen

AI-tools zijn goed in de analysehelft van deze cyclus: sessie-opnames samenvatten, zoekopdrachten groeperen, afwijkingen in analytics signaleren en testvarianten opstellen. Voor de beslishelft heb je nog steeds iemand nodig die het bedrijf, de marges en de klanten kent. Gebruik AI om sneller van gegevens naar een hypothese te gaan, en houd een persoon verantwoordelijk voor wat er live gaat.

De meeste mislukte lanceringen lopen stuk op het proces, niet op de techniek. Bijna elk probleem gaat terug op iets wat op staging klopte en in productie niet meer, of op een taak waarvan iedereen dacht dat een ander hem had gedaan. Elk van de fouten hieronder voorkom je goedkoop met een eigenaar met een naam en een test. Ontdek je ze een maand later via een daling in leads, dan zijn ze duur.

• Een noindex-tag of robots.txt-blokkade van staging die mee naar productie ging
• Geen redirectplan, of redirects die allemaal naar de homepage wijzen
• Analytics geïnstalleerd maar key events nooit getest, waardoor de conversiegegevens van de eerste maand ontbreken
• Een cookiebanner die trackers laadt voordat de bezoeker akkoord heeft gegeven
• Formuliermeldingen die wekenlang ongemerkt in de spam belanden
• Laat op vrijdag live gaan terwijl niemand tot maandag beschikbaar is
• De lancering zien als het einde van het project, zonder review op dag 30 of dag 90 in de agenda

Een website-analyse rond drie maanden na de lancering vangt op wat erdoor is geglipt, en onze gids over websiteonderhoud behandelt het vaste werk daarna.

Een lanceerchecklist werkt als hij geordend is, elke regel een eigenaar heeft en hij ook echt wordt afgemaakt. De controles vóór de lancering bepalen of de site klaar is. De lanceerdag is een korte reeks omzettingen die je eerst op staging oefent. In de 90 dagen daarna merk je of de site zijn werk doet met echte bezoekers. Leg de nulmeting vast, geef elke regel een eigenaar en zet de reviews op dag 30 en dag 90 in de agenda voordat je live gaat.

Als Vezert een bedrijfswebsite of een landingspagina bouwt, hoort een checklist als deze bij de oplevering. Na de lancering dekken onze pakketten voor websiteonderhoud prestatiemonitoring, beveiligingsupdates en contentondersteuning, en onze SEO-diensten nemen indexering, redirects, content en interne links voor hun rekening. De actuele prijzen staan op de prijzenpagina.