Een website zonder PHP: wat verandert er echt?

Begin bij wat je klant moet kunnen doen

Stel je een interieurbouwer voor. Een bezoeker wil zien welk werk het bedrijf maakt, of de stijl aansluit en hoe een eerste gesprek verloopt. De site heeft projecten, diensten, werkwijze, vragen en een contactmogelijkheid nodig. Dat zijn concrete functies. Een openbare winkelmand, forum en uitgebreid ledenstelsel horen niet automatisch bij die behoefte.

Voor een rijschool kan de volgorde anders zijn. De bezoeker wil informatie over lessen, praktische afspraken en een proefles. Een dakdekker moet onderscheid kunnen maken tussen een dringende vraag en een geplande renovatie. Deze voorbeelden zijn denkmodellen, geen beschreven klantresultaten. Ze laten zien waarom de benodigde functies het vertrekpunt moeten zijn.

Maak een lijst met acties in gewone taal. Niet een headless platform met edgefuncties, maar een project toevoegen, een offerteaanvraag ontvangen en een medewerker toegang geven. Technische termen komen later. Wanneer de functie helder is, kun je beoordelen welk onderdeel daarvoor nodig is en welk onderdeel alleen extra beheer oplevert.

Dat geeft ook een betere briefing voor websitebouw. Je koopt geen stapel softwareonderdelen. Je wilt een website waarop mensen begrijpen wat je doet en hun volgende stap eenvoudig kunnen zetten. De inrichting moet dat ondersteunen, ook wanneer je zelf weinig tijd hebt om ermee bezig te zijn.

Vier lagen die je uit elkaar wilt houden

Wij gebruiken bij een eerste architectuurgesprek graag vier lagen: inhoud, levering, handelingen en beheer. Dit is ons eigen beslismodel. Het is geen verplichte technische standaard, maar het helpt om een groot onderwerp overzichtelijk te maken.

Inhoud bestaat uit tekst, afbeeldingen en de indeling van pagina's. Levering gaat over hoe die pagina's bij bezoekers terechtkomen. Handelingen zijn dingen zoals een aanvraag versturen of inloggen. Beheer gaat over wie wijzigingen publiceert, toegang krijgt en problemen oplost. Eén leverancier kan meerdere lagen verzorgen, maar ze blijven inhoudelijk verschillend.

De woorden PHP-vrij beschrijven niet automatisch alle vier. Ze kunnen betekenen dat alleen de publieke pagina's zonder PHP worden geleverd. Een beheersysteem op een andere locatie kan wel PHP gebruiken. Vraag daarom altijd waarop de uitspraak betrekking heeft: de voorkant, de hele applicatie of ook alle aangesloten systemen.

Vooraf gebouwde pagina's zijn een echte optie

Cloudflare beschrijft bijvoorbeeld een manier om statische bestanden samen met een Worker te publiceren. Bestanden kunnen rechtstreeks worden geleverd, terwijl een Worker aanvullende logica afhandelt. Dat is een concreet platformvoorbeeld, geen bewijs dat iedere site op dat platform op dezelfde manier is gebouwd. Cloudflare Static Assets, gecontroleerd 21 oktober 2026

In een eenvoudig ontwerp schrijf je een dienstpagina één keer en wordt daarvan een publiek bestand gemaakt. Bezoekers krijgen dat bestand. Verandert de tekst, dan volgt een nieuwe publicatie. Een contactformulier kan daarnaast een afzonderlijke functie aanroepen. Zo hoeft het lezen van de dienstpagina niet dezelfde technische route te gebruiken als het versturen van een aanvraag.

Onze ontwerpvoorkeur is om die routes begrijpelijk te houden. Een bedrijf dat zelden inhoud wijzigt heeft andere behoeften dan een redactie die dagelijks tientallen stukken publiceert. Een publicatieproces dat voor het ene bedrijf rust geeft, kan voor het andere bedrijf onhandig zijn. Eenvoud moet bij de werkzaamheden passen.

Een statische site is ook niet per definitie een site die jij niet kunt aanpassen. Er kan een beheerinterface achter zitten die uiteindelijk een nieuwe publicatie maakt. Vraag om een demonstratie van de complete handeling: tekst aanpassen, controleren, publiceren en zo nodig terugzetten. Een schermafbeelding van een editor laat nog niet die hele route zien.

Wat een andere runtime wel vertelt

Cloudflare Workers gebruikt volgens de eigen documentatie V8-isolates om code uit te voeren. Dat is een andere uitvoeromgeving dan een traditionele PHP-runtime. De technieknaam helpt bij het beschrijven van een architectuur, maar zegt nog niet welke externe applicaties een specifieke Worker aanroept. Cloudflare: How Workers works, gecontroleerd 21 oktober 2026

Daaruit volgt een beperkte, technische conclusie: wanneer een gecontroleerde component geen PHP uitvoert en ook geen kwetsbare PHP-afhankelijkheid gebruikt voor de betreffende functie, zijn fouten in die PHP-runtime niet het aanvalspad van die component. Meer kun je uit alleen die vaststelling niet afleiden. Een andere runtime heeft eigen onderhoud en eigen risico's.

Dit onderscheid is belangrijk bij een offerte. De uitspraak wij gebruiken een andere technische opzet kan concreet en relevant zijn. De uitspraak daarom kan niets misgaan is veel groter en niet gerechtvaardigd. Vraag de bouwer liever welke onderdelen wegvallen, welke blijven en hoe die overblijvende onderdelen worden beheerd.

Lees bij twijfel ook Cloudflare en PHP-veiligheid. Een netwerkdienst vóór een server is een ander verhaal dan een applicatie die daadwerkelijk in een andere omgeving draait. Hetzelfde merk kan in beide situaties voorkomen, waardoor een logo alleen weinig duidelijk maakt.

Minder onderdelen is pas winst als de functies blijven werken

Een slanke site is aantrekkelijk wanneer hij precies doet wat nodig is. Maar een formulier verwijderen om minder code te hebben is geen verbetering als klanten daardoor nergens een aanvraag kunnen indienen. Veiligheid, gebruiksgemak en bedrijfswaarde moeten samen worden ontworpen.

Neem een offerteaanvraag als voorbeeld. De bezoeker vult iets in, krijgt een bevestiging en verwacht een reactie. Achter de schermen moet de informatie bij de juiste persoon terechtkomen. Een ontwerp dat alleen een mooi formulier toont, mist de helft van de taak. Vooraf bespreken wat ontvangst en opvolging betekenen voorkomt verrassingen.

Een geschikt ontwerp kan de gegevensverwerking beperken tot wat voor die aanvraag nodig is. Vraag niet om een compleet klantdossier wanneer een korte omschrijving voldoende is voor het eerste gesprek. Dat is een praktische ontwerpkeuze, geen vervanging voor een beoordeling van privacyverplichtingen bij jouw specifieke dienstverlening.

Maak voor iedere functie een klein acceptatievoorbeeld. Wat doet de bezoeker? Wat ziet hij daarna? Wat ontvangt jouw bedrijf? Wat gebeurt er bij een fout? Deze vier antwoorden zijn vaak nuttiger dan een lange technische productlijst. Ze geven zowel jou als de bouwer iets concreets om te controleren.

Het beheersysteem kan los van de publieke site staan

Een publiek leesbare website en de plek waar je inhoud beheert hoeven niet dezelfde omgeving te zijn. Dat kan zinvol zijn wanneer bezoekers alleen gepubliceerde informatie nodig hebben. De beheeromgeving blijft dan een aparte taak met eigen toegang en eigen publicatiestappen.

Die scheiding vraagt om duidelijke afspraken. Wie mag een concept zien? Wie mag een wijziging definitief publiceren? Wat gebeurt er als iemand per ongeluk een pagina verwijdert? En wie kan verder werken wanneer de vaste contactpersoon afwezig is? Zonder die antwoorden verplaatst de complexiteit zich alleen.

Vraag bij een demonstratie niet alleen naar het dagelijkse makkelijke werk. Laat ook een fout herstellen. Denk aan een verkeerde afbeelding of een verkeerd telefoonnummer. Een beheerproces wordt pas begrijpelijk wanneer je ziet hoe iemand terug kan naar een correcte toestand en hoe duidelijk is welke versie publiek staat.

Wil je zelf bijna niets beheren, spreek dan af hoe je wijzigingen aanlevert en waar je de status ziet. Een centrale aanvraag kan prettig zijn, zolang persoonlijk contact niet verdwijnt. Een systeem moet korte lijnen ondersteunen, niet een eenvoudige vraag veranderen in een ingewikkeld ticketritueel.

Rechten blijven een belangrijke ontwerpkeuze

Ook zonder PHP moeten mensen toegang krijgen tot de onderdelen die zij beheren. Een ontwerper hoeft niet automatisch toegang tot facturen te hebben. Een redacteur hoeft niet de instellingen van het domein te kunnen veranderen. Een stagiair hoeft niet blijvend te kunnen publiceren nadat de samenwerking is afgelopen.

Onze voorgestelde aanpak begint met rollen in gewone taal. Wie schrijft, wie controleert en wie publiceert? Welke leverancier kan technische wijzigingen uitvoeren? Leg vervolgens vast hoe toegang wordt verstrekt en ingetrokken. Gebruik geen gedeeld document met wachtwoorden als vervanging voor een goede toegangsafspraak.

Bij de overdracht van een website hoort daarom meer dan een link naar een dashboard. Je wilt weten welke accounts er zijn, wie eigenaar is van de belangrijkste diensten en hoe je de samenwerking kunt veranderen. Dat voorkomt dat een eenvoudige site organisatorisch toch moeilijk te beheren wordt.

Dit zijn beoordelingsvragen voor een ontwerp, geen verklaring dat ieder platform ze standaard voor je oplost. Laat je leverancier uitleggen wat in het gekozen systeem mogelijk is. In de vragenlijst voor je bureau kun je deze onderwerpen als gesprekspunten gebruiken.

Externe diensten horen ook op de tekening

Een site kan voor kaartjes, formulieren, afspraken, betalingen of video afhankelijk zijn van andere diensten. Maak die verbindingen zichtbaar. Niet om elk onderdeel verdacht te maken, maar om te begrijpen wie een storing of wijziging moet oppakken.

Een fictief voorbeeld: de website is bereikbaar, maar de externe afsprakenpagina toont geen beschikbare momenten. De hoster van de website kan dan niet vanzelf de kalenderinstellingen corrigeren. Wanneer de afhankelijkheid vooraf is genoteerd, weet het team sneller welke partij naar de situatie moet kijken.

Beoordeel ook wat bezoekers zien wanneer een dienst niet beschikbaar is. Een lege ruimte zonder uitleg is onprettig. Een duidelijke alternatieve contactroute kan de taak alsnog mogelijk maken. De precieze oplossing hangt af van de functie; een alternatief moet passen bij de gegevens en handeling die je vraagt.

Maak daarnaast onderscheid tussen noodzakelijke functies en extra's. Een decoratieve video is niet hetzelfde als de enige aanvraagroute. Door die prioriteit vooraf te benoemen, kun je bij ontwerp en testen de meeste aandacht geven aan de onderdelen die het bedrijf en de bezoeker echt nodig hebben.

Een kleine architectuurkaart die je kunt invullen

Je hoeft geen ingewikkeld technisch diagram te tekenen. Begin met vijf vakken: bezoeker, publieke pagina, handeling, opslag en beheer. Trek alleen een lijn wanneer er daadwerkelijk informatie of een opdracht tussen die vakken gaat. Schrijf bij elke lijn wat er gebeurt.

Voor een eenvoudige dienstverlener kan de kaart er zo uitzien: een bezoeker leest een projectpagina, opent een formulier en verstuurt een vraag. Het systeem levert die vraag af op een afgesproken plek. Een medewerker behandelt de aanvraag. Een beheerder publiceert een wijziging wanneer een projecttekst moet worden bijgewerkt.

Voeg daarna de uitzonderingen toe. Wat gebeurt er wanneer het versturen mislukt? Wie ziet een fout? Kan iemand per ongeluk privé-informatie publiceren? Welke gegevens zijn alleen voor medewerkers bedoeld? Door uitzonderingen te bespreken wordt de kaart een praktisch werkinstrument in plaats van decoratie in een voorstel.

Dit schema is een eigen hulpmiddel voor het gesprek, geen vervanging voor technische documentatie. De leverancier moet de technische uitwerking nog maken. Als eigenaar helpt het je wel om te zien of het uiteindelijke systeem aansluit op wat je dacht te kopen.

Wanneer PHP behouden een verstandige keuze kan zijn

Een bestaand systeem hoeft niet te verdwijnen alleen omdat een andere techniek beschikbaar is. Misschien werkt je redactie prettig met de huidige omgeving, zijn er belangrijke koppelingen of is er veel maatwerk dat goed wordt onderhouden. Dat zijn relevante argumenten om mee te nemen.

Beoordeel de werkelijke kosten van een wijziging. Niet alleen het bouwen van pagina's, maar ook het overzetten van inhoud, controleren van formulieren, opnieuw instellen van rechten en begeleiden van medewerkers. Een migratie die een probleem oplost maar drie belangrijke taken beschadigt, is geen eenvoudige vooruitgang.

Een beheerder kan voorstellen de bestaande omgeving eerst op orde te brengen en de architectuur later te heroverwegen. Dat kan een redelijke volgorde zijn. De actuele updateaanpak staat in PHP updaten en controleren. De onderhoudslagen worden uitgelegd bij WordPress, PHP en plug-ins.

Het doel is niet om een bepaalde techniek principieel te verbieden. Het doel is een omgeving die past bij je functies, budget en mogelijkheden voor onderhoud. Daar hoort ook bij dat je kunt uitleggen waarom een onderdeel er is en wie ervoor verantwoordelijk is.

Wanneer een lichtere site aantrekkelijk kan zijn

Een lichtere opzet is het onderzoeken waard wanneer je vooral informatie publiceert, bezoekers een duidelijke contactroute nodig hebben en je weinig behoefte hebt aan een groot openbaar beheersysteem. Denk aan diensten, projecten, werkgebieden en praktische uitleg. De inhoud mag uitgebreid zijn; licht gaat over de inrichting, niet over een gebrek aan informatie.

Voor een bedrijf zonder webshop kan een goed opgebouwde verzameling dienst- en projectpagina's voldoende zijn. Daar kunnen nuttige artikelen bij horen die echte vragen beantwoorden. Je hoeft geen ingewikkelde winkelsoftware te beheren als er niets online wordt afgerekend. Andersom verdient een echte verkoopfunctie wel een inrichting die daarop is berekend.

Vraag om een vergelijking op basis van jouw taken. Laat een leverancier dezelfde nieuwe projectpagina toevoegen in beide voorgestelde werkwijzen, of beschrijven hoe dat in de praktijk wordt geregeld. Vergelijk vervolgens het aantal overdrachten, de duidelijkheid voor medewerkers en het herstelpad bij een fout.

Dat gesprek kan ook bij een beperkt budget. In een website voor 75 euro per maand bespreken we de verhouding tussen prijs, scope en beheer. De maandprijs alleen bepaalt niet of een technische keuze geschikt is. Wat je nodig hebt en wat er wordt afgesproken zijn minstens zo belangrijk.

Het verschil tussen snel laden en goed functioneren

Een vooraf gebouwde pagina kan onderdeel zijn van een snelle site, maar een snel eerste scherm is niet de hele ervaring. Een bezoeker moet ook kunnen navigeren, lezen en handelen. Te zware afbeeldingen, onduidelijke knoppen of een vastlopende externe functie kunnen het gebruik alsnog onaangenaam maken.

Maak daarom een echte gebruikersroute onderdeel van de beoordeling. Begin op mobiel bij een dienstpagina, open een project, ga naar contact en rond de aanvraag af. Controleer niet alleen het eindscherm maar ook de ontvangst bij het bedrijf. Een korte route maakt vaak meer duidelijk dan een presentatie met alleen technische scores.

Voor technische SEO zijn de bereikbaarheid en presentatie van belangrijke inhoud aparte aandachtspunten. Een nieuwe techniek is niet automatisch een beter zoekresultaat. Het moet voor bezoekers en zoekmachines duidelijk blijven welke pagina welk onderwerp behandelt.

Als je overstapt, bescherm je bestaande URL's en inhoud. Het uitgewerkte proces staat in overstappen zonder onnodig SEO-verlies. Een andere architectuur is geen vrijbrief om alle oude pagina's op de homepage te laten eindigen.

Onderhoud blijft nodig, ook als je weinig ziet

Een rustige website kan de indruk geven dat er niets achter gebeurt. Toch kunnen er wijzigingen nodig zijn in afhankelijkheden, publicatieprocessen, accounts of koppelingen. Het nuttige onderscheid is niet onderhoud tegenover geen onderhoud, maar welke onderhoudstaken er overblijven en hoe ze zijn georganiseerd.

Vraag wat onder het afgesproken beheer valt. Wie behandelt een melding van een leverancier? Wie controleert een aanpassing aan een formulierdienst? Hoe wordt een wijziging eerst getest? Wie laat jou weten dat er iets met gevolgen voor je bedrijf verandert? Dat zijn normale vragen voor een langlopende samenwerking.

Spreek ook af welke documentatie je als eigenaar krijgt. Een kort overzicht van onderdelen, verantwoordelijkheden en toegang is vaak al waardevol. De volledige code hoeft niet in ieder statusbericht te staan. Het gaat erom dat beslissingen en wijzigingen later te begrijpen zijn.

Voor herstel blijft een passend plan nodig. Lees back-ups en hersteltests om het verschil te zien tussen een kopie bewaren en aantonen dat je ermee verder kunt. Een architectuurkeuze vervangt dat gesprek niet.

Een praktische vergelijking voor je offertegesprek

Leg twee voorstellen naast elkaar en beantwoord per voorstel dezelfde vragen. Welke functies zijn inbegrepen? Welke taken voer je zelf uit? Welke diensten worden apart betaald? Wie heeft toegang? Hoe verloopt een wijziging en wat gebeurt er als je wilt stoppen of overstappen?

Vermijd een vergelijking waarin de ene leverancier alleen de bouwprijs noemt en de andere een volledig beheertraject. Dat zijn verschillende pakketten. Vraag om de kosten en verantwoordelijkheden over dezelfde periode en bij hetzelfde gebruik. Zo kun je zien waar een verschil vandaan komt.

Maak vervolgens één proefscenario. Je wilt een nieuw project publiceren, een afbeelding vervangen en de contactpersoon aanpassen. Laat uitleggen hoe dat werkt en wat eventueel buiten de afspraak valt. Een klein concreet scenario haalt meer onduidelijkheid uit een offerte dan een lange lijst met bekende softwaremerken.

Wij bespreken liever zulke taken dan een algemene belofte van toekomstbestendigheid. Een website is bruikbaar voor de toekomst wanneer je haar op een begrijpelijke manier kunt onderhouden en aanpassen. Welke technische vorm daarbij past, bepalen de functies en de afspraken die je werkelijk nodig hebt.

Wat je bij oplevering in handen wilt hebben

Maak de oplevering tastbaar. Vraag om een overzicht van de gepubliceerde pagina's, de belangrijkste functies en de partij die elk onderdeel beheert. Leg vast waar wijzigingsverzoeken naartoe gaan en welke toegang jij zelf ontvangt. Controleer met de bouwer een voorbeeld van een gewone wijziging en van een herstelactie.

Een kleine site verdient dezelfde duidelijkheid als een groot platform. Je hoeft geen technisch handboek van honderd pagina's te krijgen, maar je wilt wel weten hoe je verder kunt. Een helder overdrachtsdocument is voor jou bruikbaarder dan een lijst met technologieën waarvan niemand uitlegt wat ze in jouw website doen.

Bewaar ook de gemaakte keuzes. Waarom is een bepaalde functie extern geregeld? Waarom publiceer je inhoud via de beheerder? Wanneer zou het zinvol zijn die afspraak opnieuw te bekijken? Zulke antwoorden helpen wanneer je bedrijf groeit. Een toekomstgerichte inrichting is geen bevroren eindpunt, maar een begrijpelijk systeem dat je later gericht kunt aanpassen.

Veelgestelde vragen

Verder lezen of je situatie bespreken

De kennisbank bevat aanvullende uitleg. Binnen deze reeks kun je verder met de PHP-waarschuwing, Cloudflare en PHP, AI en websitebeveiliging en vragen aan je webbureau.

Wil je de mogelijkheden voor jouw bedrijf vergelijken, plan dan een gesprek. Bekijk vooraf gerust wie wij zijn, onze prijzen of de uitleg over WordPress-onderhoud. Je hoeft geen techniek te kiezen voordat duidelijk is wat je website moet doen.