Na de overdracht van een website moet uw bedrijf bij de juiste accounts kunnen, de afgesproken bestanden kunnen vinden, begrijpen hoe wijzigingen op de live website terechtkomen en weten wie problemen oplost. Vraag om een schriftelijke inventaris, controleer die met uw eigen geautoriseerde toegang en leg vast wat nog openstaat voordat u het project afsluit.
Deze checklist voor websiteoverdracht is bedoeld voor bedrijven die een nieuwe website ontvangen of overstappen naar een ander onderhoudsteam. De checklist gaat over praktisch beheer en continuïteit. Welke materialen, rechten en diensten u hoort te ontvangen, hangt af van uw overeenkomst. Een uitnodiging voor een account of een map met bestanden geeft op zichzelf geen uitsluitsel over intellectuele eigendomsrechten.
1. Spreek af wat de overdracht omvat
Begin bij de offerte en de definitief afgesproken projectomvang. Maak een lijst van de pagina's, talen, integraties en bewerkbare materialen die worden opgeleverd. Maak onderscheid tussen de live website en de bronbestanden, ontwerpbestanden, contentexports en diensten van derden. Een website die met een gehoste editor is gebouwd, kan een ander exportproces hebben dan maatwerkcode. Vraag daarom wat een andere geautoriseerde leverancier nodig zou hebben om juist deze website te onderhouden.
Noteer de overdrachtsdatum, de exacte versie die wordt geaccepteerd en de verantwoordelijke persoon per onderdeel. Gaat het werk na de lancering door, vermeld dan op welke versie de documentatie betrekking heeft. Een opname van een oude editor of een archief van vóór de laatste correctie kan misleidend zijn, ook als alle verwachte mappen aanwezig zijn.
Gebruik drie eenvoudige statussen: ontvangen en gecontroleerd, ontvangen maar niet gecontroleerd, en openstaand. 'Per e-mail verstuurd' is niet hetzelfde als 'bruikbaar voor het ontvangende team'. Voeg een acceptatienotitie toe die de controle beschrijft, zoals het openen van het ontwerpbestand in de afgesproken toepassing of het inloggen op het hostingaccount met de bedoelde rol.
Kies de vorm van oplevering op tijd
Bewaar een beknopte inventaris op een gedeelde plek waar het bedrijf toegang toe kan houden. Sla ondersteunende bestanden op in duidelijk benoemde mappen, waar nodig met een versie of datum. Maak van de inventaris geen wachtwoorddocument. Leg vast waar inloggegevens worden beheerd en wie toegang kan verlenen, en bewaar geheime gegevens in een passend beveiligd systeem.
2. Controleer accounts, domein en facturatieverantwoordelijkheden
Breng de domeinregistrar, DNS-provider, hostingdienst, website-editor of coderepository in kaart, evenals alle diensten voor formulieren, boekingen of e-mail waarvan de website afhankelijk is. Dit kunnen afzonderlijke accounts zijn. Dat u een pagina kunt bewerken, betekent niet automatisch dat u het domein kunt verlengen, het facturatiecontact kunt wijzigen of de website kunt herstellen.
Leg per account vast welke organisatie verantwoordelijk is, welke gebruiker is uitgenodigd, welk machtigingsniveau geldt, wie de verlenging of het abonnement beheert en wie het herstelcontact is. Gebruik individuele uitnodigingen als het platform die ondersteunt. Controleer of de juiste mensen met hun eigen accounts kunnen inloggen en de taken kunnen uitvoeren die bij hun rol horen. Volg het proces van de aanbieder voor multifactorauthenticatie en accountherstel; voorkom dat één gedeeld beheerderswachtwoord rondgaat.
Vraag het huidige team uit te leggen welke DNS-records de website ondersteunen en welke voor e-mail of andere diensten dienen. Bewaar vóór een afgesproken wijziging een gedateerde vastlegging van de configuratie. Cloudflare beschrijft hoe u DNS-records importeert en exporteert; andere aanbieders hebben hun eigen beheerfuncties. Een geëxporteerde lijst met records is nuttig bewijsmateriaal, maar geen volledige back-up van alle diensten die aan het domein zijn gekoppeld.
Bij een overdracht hoeft u niet alle diensten naar een andere aanbieder te verhuizen. Is een verhuizing nodig, spreek dan eerst het ontvangende account, de afhankelijkheden, de planning en de controles af. Zeg de bestaande dienst niet op alleen omdat er een nieuwe uitnodiging is binnengekomen. Bevestig wie de volgende verlenging betaalt en waar belangrijke berichten terechtkomen, vooral als de oorspronkelijke contactpersoon het project verlaat.
3. Maak een inventaris die u daadwerkelijk kunt controleren
De onderstaande tabel is een startpunt. Vervang de voorbeelden door uw eigen systemen en de afgesproken op te leveren onderdelen. Wijs aan elke rij een verantwoordelijke persoon en een status toe. Valt een onderdeel buiten de projectomvang, leg dat dan expliciet vast met de volgende actie, in plaats van het stilzwijgend als opgeleverd te beschouwen.
| Vast te leggen onderdeel | Op te vragen bewijs | Controle door het ontvangende team |
|---|---|---|
| Domein, DNS en hosting | Accountlocaties, rollen, verlengingscontact en vastgelegde configuratie | Geautoriseerde personen kunnen de diensten vinden en de benodigde instellingen bekijken |
| Broncode of editor van de website | Repository of werkruimte, geaccepteerde versie en publicatie-instructies | Het ontvangende team kan het project openen en de live versie herkennen |
| Content en ontwerpmaterialen | Afgesproken bewerkbare bestanden, exports, overzicht van materialen en licentieverwijzingen | Bestanden openen correct en eventuele gebruiks- of bewerkingsbeperkingen zijn vastgelegd |
| Formulieren en integraties | Bestemmingen, verantwoordelijke accounts, afhankelijkheden en veilige testprocedure | Een afgesproken test toont het bedoelde traject zonder echte klanten te benaderen |
| Back-ups en herstel | Locatie, inhoud en datum van de back-up, en herstelinstructies | Een veilige hersteldemonstratie omvat de relevante onderdelen van de website |
| Support en openstaand werk | Contactkanaal, omvang, dekkingsperiode en lijst met problemen | Elk onopgelost punt heeft een afgesproken vervolgactie en een verantwoordelijke persoon |
Vraag om bewijs dat u na het gesprek opnieuw kunt bekijken. Een korte opname kan een gebruikelijke contentwijziging toelichten; een uitgeschreven commando of publicatiestappenplan kan een technisch beheerder helpen. Geen van beide mag geheime sleutels zichtbaar maken. De inventaris moet naar deze materialen verwijzen en aangeven wie ze bijwerkt wanneer de website verandert.
Controleer toegang tot de broncode los van publicatietoegang
Een coderepository en een hostingaccount hebben verschillende functies. Als de overdracht van een repository is afgesproken, controleer dan daarna de integraties en machtigingen. GitHub vermeldt dat webhooks, secrets en deploy keys gekoppeld blijven aan een overgedragen repository. Een overdracht vervangt dus niet de controle van wie en wat nog handelingen in het project kan uitvoeren.
4. Maak bestanden en herstelinstructies bruikbaar
Vraag de in uw overeenkomst genoemde materialen op in een formaat waarmee het ontvangende team kan werken. Denk aan bewerkbare paginacontent, originele afbeeldingen, goedgekeurde logobestanden, ontwerpdocumenten en broncode. Maak een lijst van externe lettertypen, stockbeelden, plug-ins en andere afhankelijkheden, met de account- of licentiegegevens die nodig zijn om voortgezet gebruik te verduidelijken. Ga er niet van uit dat alle materialen van derden zonder beperkingen kunnen worden overgedragen of hergebruikt.
Vraag bij maatwerk om de ondersteunde runtime, installatie-instructies voor afhankelijkheden, het buildcommando, de namen van configuratievariabelen en het proces voor het bekijken van een wijziging in een preview en het publiceren ervan. Houd daadwerkelijke geheime waarden buiten de algemene documentatie. Een bekwame beheerder moet kunnen zien welke instellingen bij een testomgeving horen en welke verbinding maken met live diensten.
Leg vast wat een back-up omvat. De WordPress-documentatie legt uit dat voor een gebruikelijk herstel van WordPress zowel de database als de bestanden nodig zijn. Vraag bij een ander platform de leverancier om de vergelijkbare afhankelijkheden te beschrijven. Een schermafbeelding, een broncodearchief of een export van paginatekst kan nuttig zijn, maar mag niet als een volledig herstelplan worden aangeduid zonder de beperkingen ervan toe te lichten.
Spreek af wie back-ups maakt, waar ze worden opgeslagen, hoelang ze worden bewaard en hoe het herstel wordt gecontroleerd. Vraag om een demonstratie in een veilige omgeving, waarbij zorgvuldig met klantgegevens wordt omgegaan. Leg vast wat is hersteld en wat buiten de oefening viel. Gebruik de live website niet voor een geïmproviseerde hersteltest en ga er niet van uit dat een ongetest archief elke storing zal oplossen.
5. Doorloop een korte acceptatiecontrole
Gebruik voor de controle de eigen geautoriseerde accounts van het ontvangende team. Zoek de geaccepteerde websiteversie, open de editor of het project, vind de supportinstructies en demonstreer een gebruikelijke wijziging in een preview- of testomgeving. Het doel is vast te stellen of de volgende beheerder de website kan bedienen met de opgeleverde materialen, zonder afhankelijk te zijn van uitleg die alleen in het hoofd van de leverancier zit.
Controleer een paar werkelijke klanttrajecten: een dienstbeschrijving lezen, navigeren op een telefoon, de contactmogelijkheid bereiken en de afgesproken bevestigings- en foutmeldingen bekijken. Gebruik een veilige testopzet voor formulieren, boekingen en betalingen. Spreek testadressen en bestemmingen vooraf af, zodat de overdrachtsoefening geen berichten naar echte klanten verstuurt of onbedoelde bestellingen aanmaakt.
Controleer of ook de accounts voor zoekprestaties en metingen de juiste toegangsrechten hebben, voor zover ze zijn inbegrepen. Google Search Console onderscheidt eigenaren, gebruikers met volledige rechten en gebruikers met beperkte rechten, en legt uit hoe verificatietokens het geverifieerde eigenaarschap beïnvloeden. Een controle van Search Console-machtigingen staat los van toegang tot de website zelf. Leg de betreffende property en rol vast, zonder toegang te beschouwen als bewijs dat Google elke pagina heeft geïndexeerd.
Een hypothetische overdracht aan een adviesbureau
Stel dat een adviesbureau een website met vijf pagina's ontvangt. De manager kan tekst bewerken, maar verlengingsberichten gaan nog naar een vorige leverancier en de bestemming van het formulier is niet gedocumenteerd. Het team legt beide hiaten vast, bevestigt het facturatiecontact via het proces van de aanbieder en documenteert het formuliertraject met een afgesproken test. De manager herhaalt vervolgens een bewerking in de preview met behulp van de opgeleverde instructies. Dit is een voorbeeld van de werkwijze, geen verslag van een klantresultaat.
6. Leg support vast en controleer resterende toegang
Schrijf op wat er na de acceptatie gebeurt. Wie handelt een storing, een niet-werkend formulier, een contentwijziging of een abonnementsverlenging af? Maak onderscheid tussen het corrigeren van afgesproken oplevergebreken, nieuwe functies en doorlopend onderhoud. Vermeld de afgesproken contactmethode, de dekkingsperiode, eventuele kosten en toezeggingen over reactietijden. Leid uit het bestaan van een supportadres niet af dat er dag en nacht toezicht is.
Houd een korte lijst van openstaand werk bij met het probleem, de impact, de volgende actie, de verantwoordelijke persoon en de datum voor herbeoordeling. Bepaal welke problemen acceptatie blokkeren en welke later op basis van een expliciete afspraak kunnen worden afgehandeld. Is bijvoorbeeld een boekingsintegratie nog niet beschikbaar, leg dan de alternatieve route voor klanten vast en wie bepaalt wanneer de definitieve integratie klaar is.
Controleer vertrekkende medewerkers en partners, uitnodigingen, integratietokens en herstelcontacten nadat het ontvangende team de continuïteit heeft vastgesteld. Behoud alleen de toegang die nodig is voor het afgesproken vervolgwerk. Stem het verwijderen of vernieuwen van toegangsgegevens af met de technisch verantwoordelijke, zodat het opschonen niet onverwacht het publiceren, formulieren of een andere afhankelijke dienst stillegt. Bewaar een overzicht van de beslissingen zonder daarin geheime waarden op te slaan.
7. Neem overdrachtseisen op in de websitebriefing
Een bruikbare overdracht spreekt u het gemakkelijkst af voordat het werk begint. Neem de beoogde redacteuren, interne technische kennis, benodigde bestanden, inrichting van accounts en supportbehoeften op in de projectbriefing voor uw website. Combineer deze inventaris bij een bestaande website die van leverancier wisselt met een beoordeling voor een herontwerp, zodat de verantwoordelijkheid voor bestaande diensten zichtbaar blijft.
Controleer vóór het afsluiten van het project of de inventaris overeenkomt met de afspraken, de benodigde toegang werkt, de opgeleverde bestanden openen, de veilige acceptatiecontrole is vastgelegd en openstaand werk een verantwoordelijke heeft. Bewaar de geaccepteerde versie en de overdrachtsnotities bij elkaar. Zo heeft de volgende beheerder een praktisch vertrekpunt wanneer er een wijziging of probleem opkomt.
De websitedienst van Digital Studio begint bij EUR 2.190 voor de eenmalige bouw van maximaal vijf pagina's met aangeleverde content, responsive ontwerp, een SEO-basis, één formulier voor potentiële klanten en lancering op uw domein. Specifieke overdrachtsmaterialen, verhuizingen, training en doorlopende support moeten voor uw project schriftelijk worden afgesproken; deze checklist voegt ze niet toe aan het gepubliceerde pakket. Beschrijf uw website en overdrachtsbehoeften, zodat de projectomvang kan worden besproken voordat het werk begint.
