Website livegangchecklist: wat controleer je voor en na publicatie? (2026)

Een livegang is pas controleerbaar wanneer je vooraf weet welke routes, formulieren en afhankelijkheden je test. Doorloop een korte lijst voor de publicatie en herhaal dezelfde controles na de wijziging.

Stappenplan

1. Zet het venster en herstelbesluit klaar

Leg eigenaar, contactroute, tijdvenster en terugvalbesluit vast. Als je verhuist, gebruik dan eerst migreren zonder downtime.

Spreek af wie de publicatie uitvoert, wie de uitkomst beoordeelt en wie bereikbaar blijft zolang je controleert. Zet erbij wat je terugdraait als een kernroute afwijkt: de vorige release, een redirectregel of een configuratiewijziging. Een back-up is nuttig, maar is geen besluit over wanneer en hoe je hem gebruikt. Kies een moment waarop je de routes rustig kunt testen en leg bekende geplande afhankelijkheden vast.

2. Controleer het bedoelde domein en HTTPS

Open het hoofddomein en de belangrijkste variant volgens je eigen beleid. Een browser gebruikt TLS om de verbinding te beveiligen, maar een waarschuwing vraagt altijd onderzoek van naam, certificaat en keten. Lees de MDN-uitleg over TLS voordat je certificaatinstellingen wijzigt.

Open de URL niet alleen vanuit een eerder geopende tab. Gebruik ook een schone browsercontext of een tweede apparaat, zodat je minder leunt op lokale cache en sessies. Controleer dat de bedoelde domeinvariant opent, dat je niet onverwacht op een testomgeving uitkomt en dat de browser geen certificaatwaarschuwing toont. Een waarschuwing los je niet op door bezoekers door te laten klikken; stop en volg de SSL-foutroute.

3. Test kernpaden en redirects

Open homepage, belangrijke landingspagina's, een bestaande oude URL en contactpagina. Google beschrijft hoe redirects bij siteverhuizingen gecontroleerd kunnen worden; dit is geen belofte over indexatie of rankings.

Maak de lijst vooraf klein maar betekenisvol. Neem een pagina met de belangrijkste uitleg, een route met een actie, een oude URL die je bewust hebt verplaatst en een pagina met media of een bijzondere component. Controleer wat je bezoeker ziet én waar een redirect uitkomt. Een redirect naar de homepage kan technisch werken en inhoudelijk toch onlogisch zijn. Leg onverwachte status, bestemming of fouttekst vast voordat je iets wijzigt.

4. Test de contactroute met veilige gegevens

Volg het contactformulier controleren. Controleer zowel zichtbare bevestiging als afgesproken ontvangst, zonder echte klantgegevens te versturen.

Gebruik een veilig herkenbaar testbericht en een vooraf afgesproken ontvanger. Controleer verplichte velden en één foutpad, niet alleen de groene bedankmelding. Heeft de publicatie invloed op meetcode, cookiekeuze of mailkoppeling, beoordeel dan alleen of die onderdelen op de gekozen route functioneren. Stuur geen klantinformatie, wachtwoorden of sleutels mee om een test “echt” te laten lijken.

5. Leg uitkomst en vervolg vast

Noteer alleen tijd, route, verwachte uitkomst en eigenaar. Kijk daarna naar DNS zonder uitval als het domein of de hosting wijzigde.

Zet elke uitkomst naast de vooraf beschreven verwachting. Een onverwachte fout is niet iets om in dezelfde minuut met extra wijzigingen te overschrijven. Beslis eerst of de afwijking een blokkade is, wie die onderzoekt en of de terugvalroute nodig is. Doorloop na een kleine correctie opnieuw de routes die ermee kunnen samenhangen, in plaats van alleen de pagina waarop je de fout zag.

Verandert de publicatie vooral navigatie, pagina-indeling of contentstructuur, vergelijk de gekozen routes dan ook met redesign zonder verkeersverlies voordat je vervolgwijzigingen inzet.

Wil je na een stabiele livegang een specifiek snelheidsignaal onderzoeken, houd die vervolgmeting afgebakend met de eerste Core Web Vitals-controle in plaats van alle technische onderdelen tegelijk te wijzigen.

Besliskader tijdens de livegang

Gebruik een simpele drie-kleurenbeslissing. Groen betekent dat alle afgesproken kernroutes functioneren en de eigenaar de uitkomst heeft bevestigd. Oranje betekent dat er een beperkte afwijking is zonder blokkade voor de gekozen route, met een duidelijke eigenaar, tijdelijke maatregel en hertestmoment. Rood betekent dat een bezoeker niet kan bereiken, lezen, navigeren of contact opnemen zoals afgesproken, dat HTTPS een waarschuwing geeft of dat een redirect naar een onjuiste bestemming leidt. Bij rood stop je vervolgpublicaties en kies je herstel of gerichte diagnose.

Neem niet alleen technische signalen mee. Een pagina die opent maar verouderde contactgegevens, een onjuiste knoptekst of een verdwenen juridische link toont, kan voor de bezoeker eveneens onbruikbaar zijn. De checklist is geen volledige audit; hij maakt het besluit rond een concrete wijziging controleerbaar. Breid de set routes uit als de publicatie meer functionaliteit raakt dan oorspronkelijk gepland.

Herstel, hertest en overdracht

Bij herstel zet je de vooraf gekozen, kleinst mogelijke wijziging terug en noteer je tijd en reden. Controleer daarna het domein, de belangrijkste route en het contactpad opnieuw. Vermijd het tegelijk aanpassen van DNS, content en serverinstellingen: daarmee verlies je het verband tussen oorzaak en uitkomst. Als de oorzaak niet duidelijk is, laat de verantwoordelijke eigenaar het volgende onderzoek bepalen.

Sluit pas af met een kort overdrachtsbericht: wat ging live, welke routes zijn getest, wie keurde ze goed, welke afwijking is open en wanneer volgt een eventuele hertest. Gebruik die notitie bij een volgende website-audit, zodat de controle geen losse mondelinge herinnering wordt.

Praktijkcheck vlak na publicatie

Werk na de publicatie van buiten naar binnen. Open eerst het bedoelde domein in een schone browsercontext, ga dan naar de belangrijkste landingspagina en volg van daaruit de kernactie. Test daarna één oude URL als die is gewijzigd en het contactformulier met het veilige testbericht. Laat de aangewezen eigenaar de ontvangst bevestigen. Noteer een groen resultaat alleen wanneer de route als geheel klopt, niet wanneer één scherm goed oogt. Zo blijven technische, inhoudelijke en organisatorische controles samen zichtbaar.

Zet een duidelijke eindtijd voor het eerste controlevenster. Aan het einde vat je de uitkomsten samen en benoem je wie eventuele oranje punten opvolgt. Een open punt zonder eigenaar is geen overdracht. Een rode afwijking zonder herstelkeuze is evenmin een afgeronde livegang, ook niet als de homepage beschikbaar blijft.

Veelgemaakte fouten

• Een livegang zonder eigenaar doen. Dan is er niemand die een afwijking beslist.
• Alleen cache zien. Controleer ook in een schone browsercontext.
• Redirects vergeten. Oude relevante URL's kunnen nog gebruikt worden.
• Echte persoonsgegevens testen. Gebruik een herkenbaar, veilig testbericht.
• Doorwerken bij een onbekende fout. Stop, leg vast en volg het herstelpad.

Officiële bronnen

MDN over TLS · Google over siteverhuizingen

Wil je een livegang met een heldere controle- en herstelrol voorbereiden, stel je vraag via WhatsApp.