Website-offerte vergelijken: scope, oplevering en eigenaarschap (2026)

Een website-offerte vergelijk je eerlijker op afbakening, oplevering en eigenaarschap dan op losse bedragen. Vraag wat er wordt onderzocht, gebouwd, getest en overgedragen, en welke onderdelen buiten de opdracht vallen.

Stappenplan

1. Beschrijf de vraag vóór je vergelijkt

Maak duidelijk of je een audit, redesign, migratie, formulierroute of livegang nodig hebt. Gebruik de website-audit om kernpaden en huidige situatie te benoemen.

Beschrijf je vraag als een situatie en een gewenste controle, niet als een lijst losse functies. Bijvoorbeeld: “bezoekers moeten een dienst kunnen vinden en een aanvraag kunnen versturen” of “bestaande pagina's moeten tijdens een verhuizing bereikbaar blijven”. Noteer wat je al weet, welke route prioriteit heeft en wat je expliciet niet verwacht. Daardoor vergelijk je voorstellen op dezelfde opgave, zonder te doen alsof ieder project dezelfde omvang heeft.

2. Vergelijk scope regel voor regel

Vraag per voorstel naar pagina's, contentmigratie, redirects, formulieren, testmoment, documentatie, beheer en herstel. Een migratie zonder downtime vraagt andere voorbereiding dan alleen een visueel ontwerp.

Zet de antwoorden in een eigen matrix met dezelfde kolommen voor ieder voorstel: doel, betrokken pagina's, inhoud die wordt overgezet, technische wijzigingen, testscenario's, oplevering, overdracht en uitgesloten werk. Let op woorden als “inbegrepen” of “naar behoefte”: vraag welke concrete handeling daaronder valt. Een voorstel is vergelijkbaar wanneer je per regel kunt zien wie wat doet en hoe je de uitkomst controleert.

3. Vraag naar controlepunten, geen garanties

Google beschrijft crawlbare links als één technisch aandachtspunt. Vraag welke links, redirects en kernpaden worden gecontroleerd, niet om een positie- of verkeersgarantie.

Vraag bij een redesign of migratie welke bestaande URL's worden geïnventariseerd, hoe een nieuwe bestemming wordt gekozen en hoe redirects worden getest. Vraag ook hoe interne links, navigatie en een formulierroute worden nagelopen. Een technisch plan kan goed zijn zonder resultaatclaims. Een belofte over posities, aantallen bezoekers of omzet maakt de scope niet duidelijker en is niet iets dat een websitebouwer volledig beheerst.

4. Maak toegankelijkheid concreet

Vraag welke eerste controles op formulieren, toetsenbordbediening en inhoud worden gedaan. De W3C WAI-introductie helpt om het onderwerp te kaderen, maar maakt een offerte niet automatisch conform.

Vraag om een begrensde beschrijving: welke templates of gebruikerspaden worden bekeken, welke handmatige controles gebeuren en hoe bevindingen worden teruggekoppeld. Een automatische scan of een zin over “toegankelijk ontwerp” is geen volledige verklaring. Als je een formele beoordeling nodig hebt, benoem dan de gewenste norm, reikwijdte en onafhankelijke toets vooraf, zodat je die niet in een algemene bouwopdracht verstopt.

5. Leg overdracht en grenzen vast

Vraag wie domein, hosting, accounts, bronbestanden en documentatie beheert. Gebruik de eerste toegankelijkheidscheck voor een bescheiden, toetsbare scope.

Leg vast wie eigenaar blijft van domeinregistratie, hostingaccount, content, ontwerpbestanden en toegang tot noodzakelijke diensten. Vraag ook hoe overdracht eruitziet als de samenwerking stopt: welke documentatie ontvang je, wie kan de instellingen beheren en welke gegevens worden niet gedeeld. Dat gaat over continuïteit, niet over wantrouwen. Zonder eigenaarschap en overdracht kun je een fout of verhuizing later moeilijker controleren.

Besliskader: voorstel kiezen zonder op prijzen te sturen

Kies eerst het voorstel dat jouw vraag het scherpst afbakent. Een bruikbare scope benoemt doel, kernroutes, oplevering, testmoment, eigenaar en uitsluitingen. Vergelijk vervolgens risico: raakt het voorstel DNS, e-mail, betalingen, klantgegevens of veel bestaande URL's, en staat er een herstel- of escalatiepad bij? Een kleiner voorstel kan passend zijn als de route beperkt is; een groter voorstel kan nodig zijn wanneer de afhankelijkheden aantoonbaar breder zijn.

Gebruik drie uitkomsten. Groen: je begrijpt de werkzaamheden, grenzen, acceptatie en overdracht. Oranje: er is een redelijke aanpak maar één cruciaal onderdeel, bijvoorbeeld contentmigratie of beheer, is nog niet beschreven. Rood: het voorstel belooft brede resultaten zonder controlepunten, laat eigenaarschap open of mengt verschillende grote wijzigingen zonder herstelroute. Vraag bij oranje en rood om verduidelijking voordat je beslist.

Controle bij oplevering en herstel

Spreek vóór de start af welke kleine set routes je bij oplevering test. Denk aan de homepage, een belangrijke instappagina, een oude URL bij een verhuizing en een contactformulier met veilig testbericht. Leg vast wie de uitkomst accepteert en wat er gebeurt wanneer een kernroute afwijkt. Gebruik de livegangchecklist als een praktische basis voor dat moment.

Een herstelafspraak hoeft geen fictieve perfectie te beloven. Hij kan eenvoudig zeggen welke fout als blokkade geldt, wie hem beoordeelt, welke eerdere versie of configuratie beschikbaar is en hoe de hertest plaatsvindt. Bewaar besluiten en toegang niet uitsluitend in e-mail of een chat. Een kort overdrachtsdocument maakt de keuze later controleerbaar zonder opnieuw te moeten raden wat de oorspronkelijke scope was.

Praktijkcheck voordat je beslist

Leg de voorstellen naast dezelfde set vragen. Welk gebruikersprobleem wordt aangepakt, welke pagina's en systemen horen erbij, welke test wordt uitgevoerd, wat ontvang je bij oplevering en wie beheert de onderdelen daarna? Markeer antwoorden die concreet zijn en zet onduidelijke termen om in een vervolg-vraag. Vraag bijvoorbeeld niet “doen jullie SEO?”, maar “welke bestaande URL's en interne links controleren jullie bij deze wijziging, en hoe leggen jullie dat vast?” Zo stuur je op bewijs en overdracht.

Neem de beslissing niet onder tijdsdruk als een kritieke afhankelijkheid nog open is. Bij een migratie zonder DNS-eigenaar of een formulier zonder ontvanger is eerst verduidelijken verstandiger. Bewaar de gekozen scope en acceptatiepunten bij de opdracht, zodat je bij oplevering dezelfde verwachting kunt toetsen.

Veelgemaakte fouten

• Alleen een totaalregel vergelijken. Scopeverschillen blijven dan onzichtbaar.
• Een rankingbelofte accepteren als resultaat. Vraag naar uitvoerbare werkzaamheden.
• Eigenaarschap open laten. Dat belemmert later beheer en verhuizing.
• Toegankelijkheid als vinkje omschrijven. Vraag naar controles en beperkingen.
• Geen herstel- of acceptatiemoment afspreken. Dan is oplevering onduidelijk.

Officiële bronnen

Google over crawlbare links · W3C WAI-introductie

Wil je jouw vraag eerst helder afbakenen, stel je vraag via WhatsApp.