Waarom werkt een link op mijn laptop wel, maar geeft hij een 404 op de server?

Uw bestandssysteem tijdens het ontwikkelen negeert waarschijnlijk hoofdletters in bestandsnamen, terwijl de productieserver Logo.PNG en logo.png wél uit elkaar houdt. De live site kan bovendien een ander basispad, een andere routering of een andere set gegenereerde bestanden gebruiken. Controleer de exacte URL, de bestandsnaam op de server en de productieconfiguratie.

Gebruik ik absolute of relatieve paden voor interne links?

Laat uw CMS of framework ze waar mogelijk genereren. Hardgecodeerde URL’s met een ontwikkel- of testdomein erin zijn kwetsbaar, en diepe ../-ketens breken zodra pagina’s verhuizen. Root-relatieve URL’s zoals /images/logo.png werken prima voor een website die vast in de root van het domein staat; een applicatie die misschien onder een padvoorvoegsel terechtkomt, bouwt URL’s beter op vanuit een geconfigureerd basispad.

Hoe vind ik gebroken links voordat bezoekers ze vinden?

Crawl de gebouwde site of de testomgeving vóór de release, en crawl daarna de live site. Controleer links, afbeeldingen, scripts, stylesheets, downloads, doorverwijzingen en formulierdoelen — niet alleen de homepage. De eerste ronde vangt fouten vroeg af; de tweede controleert de echte server en configuratie.

Overleven uw links en bestandspaden de livegang?

Een link die perfect werkt op uw laptop kan dood zijn zodra hij de server bereikt. De hostnaam in een URL is niet hoofdlettergevoelig — Example.COM en example.com komen op dezelfde plek uit — maar ga er nooit zomaar van uit dat dat ook geldt voor het pad erachter: een link naar /Photos/Logo.PNG kan de hele ontwikkeling lang werken en in productie een 404 geven, omdat het echte pad /photos/logo.png is.

Drie verschillende regels

De verwarring komt van drie lagen die zich elk anders gedragen:

Domeinnamen zijn per definitie niet hoofdlettergevoelig.
URL-paden behandelt u het best als hoofdlettergevoelig. Of /Photos/ en /photos/ echt verschillen, hangt af van wat het verzoek afhandelt — statische bestanden op een gewone Linux-host zijn hoofdlettergevoelig, terwijl een CMS of framework paden kan normaliseren of volgens eigen regels routeren.
Bestandssystemen verschillen per besturingssysteem: de meeste Windows- en macOS-machines waarop ontwikkeld wordt, negeren hoofdletters standaard; de Linux-servers achter de meeste hosting doen dat niet.

Vertrouw niet op een vergevingsgezinde ontwikkelomgeving of een vergevingsgezind CMS. Gebruik één consistente vorm in kleine letters voor openbare URL’s, mappen en bestandsnamen — team-photo.webp, nooit Team Photo.WEBP — en houd het bij letters, cijfers en koppeltekens: spaties en speciale tekens hebben URL-codering nodig en gaan makkelijk fout in links en scripts.

De valkuil van hernoemen met alleen hoofdletters

Op een ontwikkelmachine die hoofdletters negeert, verandert het hernoemen van Logo.PNG naar logo.png niets wat het systeem kan zien — versiebeheer en deploytools registreren de wijziging dus mogelijk nooit, en de server houdt de oude naam. Hernoem via een tussennaam, zodat de wijziging echt bestaat:

git mv Logo.PNG logo-temp.png
git mv logo-temp.png logo.png

Controleer daarna of op de server alleen het bestand met het juiste hoofdlettergebruik staat.

Paden die breken wanneer er iets verhuist

Zelfs met het juiste hoofdlettergebruik breken links zodra het adres waarvan ze uitgaan verandert:

Hardgecodeerde absolute URL’s (https://localhost/... of een testdomein) gaan zo mee naar productie en wijzen naar de verkeerde plek.
Kwetsbare relatieve paden (../../assets/...) breken zodra een pagina naar een andere mapdiepte verhuist.
Root-relatieve paden (/images/logo.png) zijn robuust voor een site die vast in de domeinroot staat — en falen wanneer dezelfde applicatie later onder een voorvoegsel zoals /shop/ wordt aangeboden. Herbruikbare applicaties bouwen URL’s beter op vanuit een geconfigureerd basispad; een bedrijfswebsite die vast in de root staat, mag met een gerust hart root-relatieve paden gebruiken.
Ontbrekende build-output — een gegenereerd CSS-bestand, script of afbeelding dat lokaal bestaat, maar buiten versiebeheer valt of bij de livegang wordt overgeslagen.
Afsluitende schuine strepen — /products en /products/ kunnen één bron zijn, een doorverwijzing, of twee verschillende routes. Kies één canonieke vorm en verwijs de andere consequent door.

En zijn er al URL’s met hoofdletters gepubliceerd? Kies dan de canonieke variant in kleine letters en stuur de oude varianten er met een 301-doorverwijzing naartoe — centraal afgedwongen in de server of de applicatie, niet als een stapel handgeschreven regels — in plaats van meerdere schrijfwijzen als duplicaten 200 OK te laten antwoorden.

Test voor en na de livegang

Eén keer de homepage laden bewijst niets. Crawl de gebouwde site of de testomgeving vóór de release, en crawl daarna de live site — links, afbeeldingen, stylesheets, scripts, downloads, doorverwijzingen en formulierdoelen — want alleen productie heeft het echte bestandssysteem, de echte routering en de echte configuratie.

Kern: de server vergeeft hoofdletters in de hostnaam, maar verder weinig — houd paden consequent in kleine letters, laat de configuratie uw URL’s bouwen, hernoem met zorg en controleer bij elke livegang de echte links op de live site.

Wat u moet doen

Kies een conventie met alleen kleine letters voor elke bestandsnaam, map en URL-slug — alleen letters, cijfers en koppeltekens.
Laat het framework of CMS de URL’s genereren, met omgevingsspecifieke basispaden in de configuratie, niet hardgecodeerd.
Hernoem wijzigingen die alleen hoofdletters betreffen via een tussennaam, zodat versiebeheer en de deploy ze echt oppikken.
Serveer één canonieke vorm — verwijs varianten met hoofdletters of een afsluitende schuine streep centraal door, in plaats van duplicaten een 200 te laten teruggeven.
Crawl de gebouwde site vóór de release en de live site na de livegang, inclusief assets en doorverwijzingen, niet alleen links.