Lokaal, staging en productie: waar test je een website met Claude Code?

Je website werkt op je computer, maar betekent dat ook dat bezoekers de nieuwe versie zien? Meestal nog niet. Een lokale werkversie, een gedeelde preview en de productieomgeving hebben verschillende doelen. Om een wijziging goed te controleren, moet je weten welke versie je bekijkt en welke diensten eraan gekoppeld zijn.

Deze gids legt de drie omgevingen uit en geeft je een werkwijze om een website met Claude Code te beoordelen vóór en na publicatie. Je hoeft daarvoor niet meteen een ingewikkelde infrastructuur op te zetten. Begin met een helder overzicht van je project.

1. Wat betekenen lokaal, staging en productie?

Lokaal is de versie die je op je eigen computer draait. Je gebruikt die tijdens het bouwen en aanpassen. Een adres zoals http://localhost:3000 verwijst doorgaans naar een dienst op het apparaat waarop je de browser gebruikt. Dat is geen gewone publieke link die je zomaar naar een klant kunt sturen.

Preview of staging is een omgeving waarin je een versie kunt beoordelen voordat ze op het hoofddomein staat. Een preview kan bij een afzonderlijke wijziging horen; staging wordt vaak gebruikt als naam voor een vaste controleomgeving. De precieze indeling hangt af van je hosting en projectafspraken.

Productie is de versie die je echte bezoekers gebruiken. Bij een gebruikelijke website is dat de site op je hoofddomein. Een wijziging die alleen lokaal is opgeslagen, staat daar niet automatisch.

Vercel onderscheidt bijvoorbeeld standaard Local, Preview en Production. Een previewdeployment is bedoeld voor controle en samenwerking vóór de wijziging op het productiedomein terechtkomt. Dat is een concreet platformvoorbeeld; controleer hoe jouw project de omgevingen heeft ingericht. (Vercel: omgevingen)

2. Maak een overzicht van URL, versie en diensten

Een omgevingsnaam vertelt nog niet alles. Een website op een testadres kan een echte mailbox gebruiken. Een lokale versie kan verbonden zijn met een productie-database. Daarom is alleen naar de URL kijken onvoldoende voordat je formulieren of andere acties probeert.

Maak voor elke omgeving een fiche met:

• Adres: welke URL gebruik je om de website te bekijken?
• Versie: welke wijziging of deployment hoort bij dat adres?
• Gegevens: welke database of inhoudsbron wordt gebruikt?
• Externe acties: waar komen mails, aanvragen en andere berichten terecht?
• Testafspraken: welke handelingen zijn toegestaan en hoe worden ze afgevangen?
• Toegang: wie kan de omgeving bekijken en aanpassen?

Noteer de namen of de functie van instellingen, zonder geheime sleutels in je briefing te plakken. Laat iemand die de configuratie begrijpt bevestigen welke diensten werkelijk aangesloten zijn.

Vercel documenteert dat omgevingen eigen instellingen kunnen hebben. Een vooraf gecontroleerde productiebuild kan juist productie-instellingen gebruiken; die is dus niet vanzelf gescheiden van echte diensten en gegevens. (Vercel over staging en productieconfiguratie)

3. Gebruik lokaal voor kleine, gerichte controles

Begin lokaal wanneer je een tekst, indeling of component aanpast. Bekijk de relevante pagina en voer de afgesproken controle uit. Een kop die op mobiel wordt afgesneden vraagt bijvoorbeeld om controle op een smal én breed scherm.

Leg ook vast hoe het project gestart en gebouwd wordt. Een ontwikkelserver helpt je tijdens het aanpassen; een productiebuild controleert een andere stap in het proces. Gebruik de commando’s die het project voorschrijft en laat fouten zichtbaar rapporteren.

Voor een bestaande website is een bruikbare volgorde:

1. Bekijk de huidige pagina en beschrijf de gewenste wijziging.
2. Laat de betrokken bestanden en bestaande afspraken onderzoeken.
3. Voer de afgesproken aanpassing uit.
4. Controleer de pagina lokaal met echte inhoud.
5. Voer de relevante technische checks uit.

De gids over een bestaande website aanpassen met Claude Code werkt die aanpak verder uit. Let erop dat een lokaal geslaagde controle nog niet bewijst dat de gedeelde of live versie dezelfde instellingen en inhoud gebruikt.

4. Gebruik een preview voor beoordeling en samenwerking

Een preview maakt het mogelijk om een concrete versie te delen met iemand die je lokale project niet draait. Geef bij die link aan welke onderdelen gewijzigd zijn en welke feedback je zoekt. Zo voorkom je dat de review uitgroeit tot een nieuwe, onbegrensde opdracht.

Gebruik bijvoorbeeld deze eigen reviewfiche:

Controleversie: [preview-URL]
Wijziging: [welke pagina of functie is aangepast]

Controleer:
[de afgesproken bezoekersroute of zichtbare uitkomst]

Inhoud die klaar is:
[bevestigde teksten en beelden]

Open punten:
[wat nog niet klaar is]

Externe acties:
[welke diensten zijn afgevangen of veilig ingesteld]
Voer geen echte betaling of verzending uit.

Geef per bevinding de pagina, de stappen,
het huidige resultaat en de gewenste uitkomst.

Behandel een previewlink als een link naar werk dat mogelijk nog niet voor publiek bedoeld is. Controleer wie toegang heeft als er vertrouwelijke informatie op staat. Deel een veilige versie met passende gegevens.

Wil je formulieren beoordelen, gebruik dan de gids over een websiteformulier veilig testen. Voor inhoudelijke of visuele opmerkingen helpt de gids over feedback geven aan Claude Code.

5. Spreek af wat er naar productie mag

Een werkmap kan meer bevatten dan de wijziging die je wilt publiceren. Er kunnen andere aanpassingen, tijdelijke bestanden of nog niet goedgekeurde teksten in staan. Vraag daarom welke versie wordt gepubliceerd en welke bestanden daar deel van uitmaken.

Leg ook vast of het project automatisch publiceert na een bepaalde handeling. Bij sommige workflows kan een wijziging naar een productiebranch een deployment starten. De betekenis van “opslaan”, “committen” en “publiceren” hangt dus af van de inrichting van jouw project.

Een bruikbare opdracht voor Claude Code benoemt het doel en de grens:

Bereid publicatie voor van [afgesproken wijziging].
Lees eerst de projectafspraken en deploymentinstructies.

Controleer welke versie en bestanden worden gepubliceerd.
Neem alleen de afgesproken wijziging mee.
Controleer build, types en de relevante projectchecks.
Benoem ontbrekende instellingen of fouten.

Het doelproject en domein zijn: [bevestigde bestemming].
Publiceer uitsluitend wanneer de afgesproken controles slagen
én de publicatie voor deze wijziging is toegestaan.

Controleer na publicatie de echte URL en rapporteer de uitkomst.

Gebruik de projectdocumentatie voor de werkelijke commando’s. Kopieer geen deploymentcommando uit een ander project zonder het doel en de gevolgen te controleren.

6. Controleer ook de echte liveversie

Open na publicatie de publieke URL. Kijk of je de verwachte wijziging ziet, of afbeeldingen laden en of de relevante links naar de juiste bestemming gaan. Herhaal de bezoekersroute binnen de afgesproken veilige grenzen.

• ☐ Ik weet welke versie op het hoofddomein staat.
• ☐ De afgesproken wijziging is zichtbaar op de juiste pagina.
• ☐ Teksten en afbeeldingen zijn de goedgekeurde versies.
• ☐ Relevante links en navigatie werken.
• ☐ De weergave is gecontroleerd op een smal scherm.
• ☐ Er staan geen tijdelijke testgegevens of open markeringen publiek.
• ☐ Problemen worden geregistreerd met de URL en concrete waarneming.

Voor een nieuwe website kun je daarna de SEO-checklist vóór lancering en de mobiele websitechecklist gebruiken. Gaat iets anders dan verwacht, bepaal dan eerst welke versie en configuratie je bekijkt voordat je opnieuw wijzigingen laat uitvoeren.

Met een overzicht van je omgevingen wordt je opdracht aan Claude Code duidelijker. Neem het adres, de toegestane acties en de gewenste controle op in de gratis briefing voor Claude Code, zodat bouwen, beoordelen en publiceren een herkenbare werkwijze krijgen.