Koppel de repository van mijn website aan dit domein, zet de gebouwde map
in de webroot en zorg dat hij na elke push vanzelf bijwerkt.
Je bouwt een site met Next.js, Astro, Eleventy of gewoon Vite, en het resultaat is een map met HTML, CSS en JavaScript. Die map moet op je hosting staan. De vraag is niet of dat kan, maar wat je precies in je repository zet en wie het bouwen doet.
De keuze die alles bepaalt
Een gedeelde hostingomgeving voert geen bouwstap uit en draait je project niet als Node-server. Hij levert bestanden uit. Dat betekent dat de gebouwde bestanden ergens vandaan moeten komen. Daar zijn drie werkwijzen voor.
| Werkwijze | Wat je koppelt | Voor wie |
|---|---|---|
| Bouwen op je eigen computer en de uitvoer meecommitten | De map met de gebouwde site, naar de webroot | Een site die je zelf bijwerkt, één persoon |
| Bouwen in een taak bij je git-provider en de uitvoer naar een aparte branch zetten | Die branch, naar de webroot | Een team, of als je niet wil dat gebouwde bestanden in je hoofdbranch staan |
| Broncode buiten de website zetten en op een eigen server bouwen en draaien | De broncode, buiten de webroot | Een project dat echt een Node-server nodig heeft |
De eerste is eerlijk gezegd de snelste manier om te beginnen. De tweede is waar je naartoe groeit zodra meer dan één persoon pusht. Hoe je de koppeling zelf maakt, staat in een GitHub-repository koppelen aan je website; de automatische bijwerking na elke push zet je aan met een webhook.
Next.js als statische export
Next.js kan zijn hele site als losse HTML-bestanden wegschrijven. Je zet dit in next.config.ts:
const nextConfig = {
output: "export",
trailingSlash: true,
};
Na next build staat het resultaat in de map out. Die map is wat je koppelt aan de webroot.
trailingSlash: true is geen detail. Zonder die regel schrijft Next voor de route /over-ons een bestand over-ons.html weg, en dan moet je webserver weten dat hij dat bestand moet pakken bij een adres zonder .html. Mét die regel krijg je over-ons/index.html, en dat levert elke webserver zonder verdere instellingen gewoon uit.
Wat je opgeeft bij een export
Dit is het stuk dat mensen verrast. Een statische export heeft geen server, dus alles wat per bezoeker iets moet beslissen, valt weg:
- Route handlers die iets met het verzoek doen, en server actions.
- Cookies lezen op de server.
redirects,rewritesenheadersuit je configuratie. Die regel je in de webserver, bijvoorbeeld in.htaccess.- Afbeeldingsoptimalisatie met de standaardlader van
next/image. Je zet een eigen lader in, of je optimaliseert je afbeeldingen vooraf. - Dynamische routes zonder
generateStaticParams, en alles wat na de bouw opnieuw gegenereerd moet worden.
Voor een bedrijfssite, een portfolio of een kennisbank is dat geen probleem: die weet bij het bouwen al wat er op elke pagina staat. Heb je een inlogscherm, een zoekfunctie die de server nodig heeft of een pagina die per bezoeker verschilt, dan is een statische export niet de goede keuze en wil je een server waar Node als dienst draait.
Twee instellingen die het verschil maken
Cache. De bestanden onder _next/static hebben een naam met een hash erin: wijzigt de inhoud, dan wijzigt de naam. Die mag je dus lang laten cachen. Je HTML juist niet, want die moet na een nieuwe deploy meteen vers zijn. Dat onderscheid zet je in .htaccess of je laat de assistent het doen.
Je 404. Een statische site heeft geen server die een nette foutpagina kiest. Verwijs in .htaccess naar de pagina die Next voor je heeft gebouwd:
ErrorDocument 404 /404/index.html
De valkuil: verwijderde bestanden blijven staan
Een deploy haalt de nieuwe versie op en zet die neer. Wat hij niet doet, is opruimen. Haal je een pagina uit je site, dan blijft het oude bestand op je hosting staan en blijft die pagina gewoon bereikbaar.
Bij een handgemaakte site valt dat op. Bij een statische export niet, want dan zijn het tientallen bestanden met namen die je zelf nooit hebt getypt. Het resultaat is een site waar een oude pagina nog leeft en door Google nog gevonden wordt.
Twee manieren om dat op te lossen. Zet in je bouwtaak dat de doelmap eerst leeg wordt gemaakt, of ruim na een deploy waarin je iets hebt verwijderd handmatig op. Vraag het de assistent gewoon:
Vergelijk de bestanden in de webroot met de bestanden in de laatste
deploy. Noem wat er in de webroot staat maar niet in de repository, en
laat het zien voordat je iets verwijdert.
Veelgemaakte fouten
"Ik zet mijn hele project in public_html." Dan staan je package.json, je configuratie en mogelijk een .env in de webroot. Kies buiten de website als doel voor broncode en koppel alleen de gebouwde map aan de webroot.
"Mijn .git-map is nu openbaar." Dat is hij niet: de webserver blokkeert die map. Maar een .env of een backupbestand in de webroot is dat wel, dus blijf kijken naar wat je meecommit.
"Ik bouw lokaal en push, maar de site verandert niet." Controleer of je de map met de gebouwde site hebt gecommit en niet per ongeluk hebt uitgesloten in .gitignore. Een lege deploy is bijna altijd een genegeerde map.
"Ik gebruik next start op mijn hostingpakket." Dat is geen gedeelde hosting maar een server. Op een eigen server kan het, als dienst met een herstartbeleid, nooit als los commando dat je in een terminal start.
"Na een deploy zie ik de oude pagina nog." Dat is cache, niet de deploy. Leeg de cache van je site en herlaad zonder cache in je browser voordat je gaat zoeken in de bestanden.