Een maatwerk website laten maken is zinvol als je ontwerp, contentbeheer of bezoekersroute eisen stelt die je bestaande oplossing onvoldoende ondersteunt. Je hoeft daarvoor niet alles opnieuw te bouwen. Een aangepast thema, een losse koppeling of een andere indeling kan genoeg zijn. Deze gids helpt je van die afweging naar een concrete opdracht, een controleerbare oplevering en werkbare afspraken voor daarna. Voor de technische keuzeroutes is er de vergelijking van WordPress, maatwerk en headless.

Wat maakt een website maatwerk?

Bij een maatwerk website laat je onderdelen ontwerpen en bouwen voor jouw situatie. Dat kan gaan om de vormgeving, de manier waarop een redacteur pagina’s samenstelt of een reserveringsproces dat met andere systemen samenwerkt. Het woord zegt op zichzelf weinig over prijs, snelheid of eigendom. Die moet je apart beoordelen en afspreken.

Een eigen ontwerp vraagt dus niet automatisch om een eigen CMS. Ook hoef je een werkend boekingssysteem niet te vervangen omdat je een nieuwe voorkant wilt. Benoem wat moet veranderen en wat behouden kan blijven. Dat maakt een voorstel beter te beoordelen dan een belofte dat de hele website ‘uniek’ wordt.

Eigendom is evenmin een gevolg van het etiket. Vraag welke onderdelen speciaal voor jou worden gemaakt, welke bestaande software je gebruikt en welke afspraken gelden als je later van leverancier wisselt.

Wanneer is maatwerk de moeite waard?

Begin bij een probleem dat je kunt laten zien. Bezoekers begrijpen niet welke dienst bij hen past. Je team voert dezelfde openingstijden op meerdere plekken in. Of klanten kunnen een reservering niet afronden op hun telefoon. Elk probleem vraagt eerst om een diagnose; de oplossing kan ook binnen je huidige website passen.

Situatie Onderzoek eerst Maatwerk wordt interessant als
Je merk komt niet goed over Teksten, fotografie en aanpassing van het bestaande ontwerp De gewenste presentatie niet goed past binnen de huidige bouwblokken
Medewerkers moeten veel dubbel invoeren Bestaande koppelingen en een duidelijkere bron voor gegevens Je eigen proces ontbreekt in de beschikbare oplossingen
Je hebt verschillende doelgroepen of talen Contentstructuur en afspraken over redactie Je aparte bezoekersroutes of beheerfuncties nodig hebt
De site reageert traag Metingen op echte pagina’s en oorzaken in beelden, scripts of hosting De beperkingen niet verantwoord binnen de huidige opzet zijn op te lossen

Meertaligheid, vindbaarheid en een herkenbare huisstijl zijn op zichzelf geen bewijs dat je alles op maat nodig hebt. Laat een bureau juist de lastigste eis voordoen. Kan een redacteur bijvoorbeeld een anderstalige dienstpagina publiceren zonder de verkeerde contactgegevens mee te nemen?

Weeg de extra bouw- en beheerkosten af tegen het probleem dat je oplost. Als niemand kan uitleggen wat een bezoeker of medewerker straks beter kan, is de opdracht nog te vaag. De vergelijking van WordPress, Webflow, Wix en Shopify helpt om ook bestaande platforms mee te nemen.

Wat zet je in een goede briefing?

Schrijf op wie de site gebruikt, welke vragen die persoon heeft en welke actie daarna moet lukken. ‘Meer aanvragen’ is een doel, maar nog geen beschrijving van de website. Welke aanvraag wil je ontvangen, welke informatie heeft een bezoeker nodig en wie behandelt die aanvraag intern?

Maak daarnaast een inventaris van je bestaande pagina’s. Geef aan welke inhoud actueel is, welke moet verdwijnen en waar nieuw materiaal nodig is. Vermeld ook bestanden en formulieren die buiten de hoofdnavigatie staan. Zo voorkom je dat een brochure of campagnepagina pas na de verhuizing wordt gemist.

Een bruikbare briefing bevat verder:

  • De functies die bij de eerste oplevering moeten werken, met een voorbeeld van een normale én een mislukte handeling.
  • De medewerkers die inhoud aanpassen en de rechten die zij nodig hebben.
  • De systemen die gegevens aanleveren of ontvangen, inclusief de contactpersoon voor toegang.
  • De persoon die teksten en ontwerp goedkeurt, en de momenten waarop die beschikbaar is.
  • De grenzen van de opdracht, zoals vertalingen, fotografie of een klantportaal dat pas later volgt.

Een scherm met ‘bedankt voor je aanvraag’ is bijvoorbeeld niet voldoende als het bericht nergens aankomt. Schrijf daarom op waar de aanvraag terechtkomt, wie een storing opmerkt en wat de bezoeker te zien krijgt wanneer verzenden mislukt.

Hoe vergelijk je offertes en kosten?

Een paginatelling vertelt niet hoeveel werk er in een website zit. Veel pagina’s kunnen hetzelfde ontwerp gebruiken, terwijl één formulier meerdere systemen en uitzonderingen raakt. Vraag een uitsplitsing naar ontwerp, content, ontwikkeling, koppelingen, migratie en testen. Laat ook zien wat je eigen team moet aanleveren.

Vergelijk vervolgens dezelfde gebruiksperiode. Neem de bouwprijs, hosting, betaalde onderdelen, ondersteuning en verwachte wijzigingen mee. Noteer welke kosten vast zijn en welke veranderen door bezoekersaantallen, gebruik of extra redacteuren. Vraag bij een bedrag of btw en werkzaamheden van andere leveranciers zijn inbegrepen.

Een vaste prijs geeft duidelijkheid over een afgesproken pakket. Nieuwe wensen kunnen daarbuiten vallen. Werken op uren kan passen bij onderzoek waarvan de uitkomst nog openstaat, mits je afspreekt wanneer je voortgang en budget bespreekt. Geen van beide modellen vervangt een heldere omschrijving van het werk.

Vraag bij twijfel een klein onderzoek naar de onzekere functie voordat je de hele bouw vastlegt. Leg vast welk resultaat dat onderzoek moet opleveren: een werkende proef, een onderbouwde keuze of een aangepaste begroting. Meer over de prijsopbouw staat in wat een website laten maken kost.

Hoe lopen ontwerp, bouw en content samen?

Werk toe naar beslissingen die je kunt beoordelen. Eerst de inhoud en bezoekersroute, daarna een ontwerp met echte teksten en beelden, vervolgens een werkende versie. Dat hoeft geen starre volgorde te zijn: een technische proef kan juist vroeg nodig zijn om een ontwerpkeuze te toetsen.

Gebruik geen lege voorbeeldpagina als enige ontwerptest. Een lange titel, een ontbrekende foto en een alinea die in het Engels meer ruimte inneemt, laten zien of de opzet in de praktijk bruikbaar is. Kijk ook verder dan de homepage. Een zoekresultaat kan bezoekers rechtstreeks naar een dienst, nieuwsbericht of formulier brengen.

Laat je toekomstige redacteur tijdens de bouw al iets publiceren. Kan die een afbeelding kiezen, een fout herstellen en zien welke versie live staat? Een goede demonstratie door de bouwer is nog geen bewijs dat je team zelfstandig kan werken. Voor de visuele kant van het proces lees je over webdesign.

Maak de planning afhankelijk van concrete overdrachtsmomenten: toegang tot systemen, goedgekeurde teksten, vertalingen en testresultaten. Benoem wat er gebeurt als iets later komt. Een opleverdatum zonder zulke afhankelijkheden geeft weinig houvast.

Welke techniek en welk beheer passen bij je team?

De redactie moet aansluiten op hoe vaak en door wie de inhoud verandert. Een site waarvan elk artikel langs een marketeer en jurist moet, stelt andere eisen dan een bedrijfspagina die incidenteel wordt aangepast. Bespreek voorbeelden van publiceren, terugzetten en vertalen voordat je een CMS kiest.

WordPress en headless sluiten elkaar niet uit: de WordPress REST API kan content aan een aparte voorkant leveren. Dat maakt zo’n scheiding mogelijk, maar is op zichzelf geen reden om ervoor te kiezen. Vraag wat de extra onderdelen jouw team opleveren en wie ze beheert.

Hetzelfde geldt voor frameworks. Een naam op de offerte bewijst geen snelheid of lage onderhoudskosten. Laat uitleggen welke onderdelen op de server werken, welke externe diensten nodig zijn en hoe een wijziging bij bezoekers terechtkomt. De technische vergelijking staat in Astro, Next.js en WordPress.

Spreek bij hosting af wie updates uitvoert, storingen ontvangt en herstel regelt. Een hostingabonnement en een onderhoudsafspraak zijn verschillende zaken. Vraag ook of je een testomgeving krijgt en welke mogelijkheden er zijn om een mislukte wijziging terug te draaien.

Wat controleer je voordat de website livegaat?

Maak samen een acceptatielijst met taken die moeten slagen. Doorloop een aanvraag op mobiel, controleer de ontvangst en probeer ook ongeldige invoer. Test zoeken, menu’s en taalwissels met de definitieve inhoud. Een koppeling die alleen in de demonstratie werkt, is nog niet klaar voor overdracht.

Neem toegankelijkheid mee in die controle. De eerste toegankelijkheidschecks van W3C helpen bij onder meer toetsenbordbediening, tekstalternatieven en contrast. Deze eerste controles zijn geen volledig toegankelijkheidsonderzoek; spreek apart af welke beoordeling je project nodig heeft.

Voor prestaties gebruikt Google onder meer Core Web Vitals. De goede grenzen zijn LCP maximaal 2,5 seconden, INP maximaal 200 milliseconden en CLS maximaal 0,1, beoordeeld op het 75e percentiel, apart voor mobiel en desktop. Een labtest vóór livegang vervangt geen meting bij echte bezoekers. Zie de officiële uitleg van Web Vitals.

Vraag om resultaten voor representatieve pagina’s met echte beelden en scripts, plus afspraken over wat er na livegang wordt gemeten. Goed scoren geeft geen garantie op een hoge zoekpositie, zoals Google over pagina-ervaring uitlegt. Een maatwerklabel doet dat evenmin.

Hoe verhuis je bestaande inhoud zonder verrassingen?

Beslis per bestaande pagina wat behouden blijft, wordt samengevoegd of vervalt. Leg bij gewijzigde adressen de bestemming vast en test de doorverwijzingen. Werk ook interne links bij. Google adviseert bij websiteverhuizingen zo’n overzicht van oude en nieuwe URL’s en permanente redirects waar nodig. Zoekposities kunnen tijdens verwerking schommelen.

Spreek een moment af waarop de inhoud wordt overgezet en bepaal wat er gebeurt met wijzigingen die daarna nog op de oude site worden gemaakt. Controleer downloads, afbeeldingen en formulieren afzonderlijk. Ze kunnen andere opslag of instellingen gebruiken dan gewone pagina’s.

Maak voor livegang duidelijk wie beslist of de verhuizing doorgaat, wie bereikbaar is bij een storing en wanneer terugzetten nodig is. Bij een formulier of reserveringssysteem moet ook bekend zijn wat er met inmiddels ontvangen gegevens gebeurt. Alleen de oude bestanden bewaren is daarvoor geen volledig plan.

Wat spreek je af over eigendom en overdracht?

Leg vast welke maatwerkcode wordt overgedragen en welke gebruiksvoorwaarden gelden voor bestaande onderdelen. ‘De code is en blijft van jou’ moet aansluiten op de concrete afspraken. Een CMS, lettertype, fotolicentie of abonnement kan eigen voorwaarden hebben; presenteer die onderdelen niet alsof je er automatisch alle rechten op krijgt.

Toegang is een apart punt. Maak een overzicht van domeinregistratie, hosting, contentbeheer en gekoppelde diensten, met de verantwoordelijke voor elk account. Documenteer hoe een andere beheerder de website kan aanpassen en uitbrengen, en hoe inhoud en bestanden beschikbaar komen bij vertrek.

Laat de overdracht ook uitvoeren: kan je team inloggen en een redactietaak afronden, en kan de beheerder met de documentatie verder? Het gaat om bruikbare toegang, niet alleen om een map met bestanden. De verdere afweging staat in onze uitleg over code-eigendom en afhankelijkheid van leveranciers.

Wat gebeurt er na de oplevering?

Wijs iemand aan die meldingen over fouten verzamelt en bepaalt welke wijziging voorrang krijgt. Maak onderscheid tussen een afwijking van de afgesproken oplevering, noodzakelijk technisch onderhoud en een nieuwe wens. Spreek af hoe je die categorieën behandelt en welke ondersteuning wanneer beschikbaar is.

Een back-up vraagt ook om een herstelprocedure. Leg vast welke inhoud en instellingen worden bewaard, wie herstel mag starten en hoe je controleert dat het werkt. Voor diensten van andere leveranciers moet duidelijk zijn welk deel van dat herstel zij verzorgen.

Bekijk na livegang of bezoekers de bedoelde taak kunnen afronden en of je team aanvragen kan verwerken. Gebruik die bevindingen om te verbeteren. Meer bezoek is niet hetzelfde als betere aanvragen, en een nieuwe website corrigeert niet vanzelf een onduidelijk aanbod.

Hoe begin je concreet?

Verzamel je belangrijkste pagina’s, de terugkerende problemen en één taak die straks aantoonbaar beter moet werken. Laat vervolgens beoordelen of een aanpassing van de bestaande site volstaat of dat nieuwe bouw nodig is. Vraag om een voorstel waarin je de scope, afhankelijkheden en oplevercontrole kunt terugvinden.

Wil je die afweging met ons maken? Bekijk onze aanpak voor maatwerk websites laten maken of plan een gesprek. Neem ook mee wie de website na oplevering gaat beheren; die keuze hoort vanaf het begin bij de opdracht.