Waarom je training-opdracht “lokaal werkt”, maar online rommelig wordt

Je levert een kleine website in met index.html, een stylesheet en wat afbeeldingen. Op je laptop ziet alles er strak uit. Dan zet je het online (of iemand opent het via een andere mapstructuur) en ineens zijn er missende afbeeldingen, laadt je CSS niet, of werkt een link naar contact.html niet meer. Vaak is het niet je HTML of CSS die “slecht” is, maar je bestandsstructuur en de manier waarop een server jouw bestanden aanbiedt.

In training-opdrachten is dit het moment waarop je project volwassen moet aanvoelen: niet alleen code die in jouw eigen mapje draait, maar een site die logisch is ingericht en voorspelbaar werkt als iemand anders hem opent. Daar horen ook basisbegrippen bij die je in echte projecten constant tegenkomt: domein, hosting en public root.

In deze les leer je hoe je bestanden zo organiseert dat paden stabiel blijven, en wat er technisch gebeurt wanneer je site van “map op je laptop” naar “website op internet” gaat.

De woorden die je vanaf nu goed wilt gebruiken

Een website bestaat uit bestanden, maar zodra je hem publiceert, gaan er extra “lagen” meespelen: een server die bestanden uitserveert, een domeinnaam die naar die server wijst, en een vaste plek waar jouw site “start” (de root). Deze termen klinken groot, maar voor beginners zijn ze vooral handig om problemen snel te kunnen verklaren.

Belangrijke definities:

  • Bestandsstructuur: de mappen en bestanden van je project (bijv. index.html, assets/css/style.css, assets/images/logo.png).

  • Root / web root / document root: de map die de server ziet als “/”. Alles wat je via een URL opvraagt, wordt relatief aan deze map gezocht.

  • Domein: een menselijke naam (bijv. mijnsite.nl) die verwijst naar een server via DNS.

  • DNS: het “telefoonboek” van internet dat een domein naar een IP-adres vertaalt.

  • Hosting: de dienst/server die jouw sitebestanden opslaat en via HTTP/HTTPS aanbiedt.

  • URL vs pad: een URL (online) bevat domein + pad; een bestandspad (in je project) is hoe jouw bestanden intern georganiseerd zijn.

Je hebt al gezien hoe een browser via request → response → rendering in stukjes werkt: HTML laadt eerst, en daarna pas CSS, JavaScript en afbeeldingen via aparte requests. Hosting en bestandsstructuur bepalen of die requests op de juiste plek uitkomen. Als jouw structuur rommelig is, vraag je (onbedoeld) resources op die de server niet kan vinden — met 404 als gevolg.

Bestandsstructuur als “contract” tussen jouw HTML en de server

Een goede bestandsstructuur is niet alleen netjes; het is een technisch contract. Jouw HTML bevat href en src attributen die letterlijk worden omgezet in requests. De server kan alleen terugsturen wat op dat exacte pad bestaat binnen de web root. Dat is waarom een kleine wijziging, zoals een map hernoemen van assets naar Assets, lokaal “soms” niet opvalt maar online meteen breekt.

Een praktische standaard voor training-opdrachten is:

  • index.html in de root (startpunt van de site)

  • extra pagina’s naast index.html (bijv. contact.html, diensten.html)

  • één map assets/ met submappen:

  • assets/css/ voor stylesheets

  • assets/js/ voor scripts

  • assets/images/ voor afbeeldingen

Deze structuur werkt goed omdat je paden voorspelbaar blijven. Een link als assets/css/style.css betekent: “vanaf de map waar deze HTML staat, ga naar assets/css/.” Als jij later een pagina in een submap zet (bijv. pages/contact.html), dan verandert die berekening en moet je óf paden aanpassen, óf bewust kiezen voor een andere aanpak.

Veel beginners denken: “Als ik het bestand zie staan, moet het werken.” Maar de server ziet alleen wat er binnen de web root valt, en de browser vraagt exact wat jij opschrijft. Een bestand dat per ongeluk buiten de web root staat, bestaat voor de browser simpelweg niet. Dit verklaart ook waarom “alles staat in mijn zip” niet hetzelfde is als “het is correct geplaatst op hosting”.

[[flowchart-placeholder]]

Een paar best practices die direct fouten voorkomen:

  • Gebruik overal dezelfde mapnamen en hoofdletters (bijv. altijd assets, nooit wisselen met Assets).

  • Vermijd spaties en vreemde tekens in bestandsnamen (mijn foto.png is vragen om issues; mijn-foto.png is veiliger).

  • Test na elke verplaatsing van mappen/bestanden, omdat één move tientallen paden kan breken.

  • Houd je root “schoon”: zet daar alleen pagina’s die echt top-level zijn, plus de map assets/.

Domein, DNS en hosting: wie doet wat (en wat niet)

Wanneer je site online staat, zijn er grofweg drie rollen: de naam (domein), de routebeschrijving (DNS) en de plek waar je bestanden wonen (hosting). Beginners gooien die vaak op één hoop (“het domein doet raar”), maar ze hebben elk een eigen taak. Als je dat onderscheid scherp hebt, debug je niet meer blind.

Denk in deze keten:

  1. Iemand typt je domein in (bijv. mijnsite.nl).
  2. DNS vertaalt dat domein naar een IP-adres (de serverlocatie).
  3. De browser maakt verbinding met die server en vraagt bijvoorbeeld / of /index.html op.
  4. De hosting-server zoekt in de web root naar het juiste bestand en geeft een response.
  5. Daarna volgen extra requests naar jouw assets, opnieuw relatief aan diezelfde root.

Belangrijk: een domein “host” niets. Het is alleen een naam. Hosting is waar je site draait en waar je files staan. DNS is de koppeling ertussen. In training-opdrachten kom je vaak een situatie tegen waarbij DNS nog “niet doorgelopen” is of per ongeluk naar de verkeerde server wijst. Dan upload je keurig je bestanden, maar kom je toch op een oude pagina uit, of op een standaard “welcome”-pagina van de host.

Onderstaande tabel helpt je die rollen uit elkaar te houden.

Categorie Domein DNS Hosting (webserver)
Wat is het? Een naam voor je site (mensvriendelijk). Een vertaalsysteem dat domeinen koppelt aan IP-adressen/records. De plek waar je sitebestanden staan en via HTTP/HTTPS worden geserveerd.
Wat kan er misgaan? Domein verlopen of verkeerd gespeld; dan kom je nergens. Records wijzen naar verkeerde server; wijzigingen hebben soms tijd nodig om overal zichtbaar te zijn. Bestanden staan in verkeerde map (niet in web root), verkeerde hoofdletters, of serverconfig blokkeert toegang.
Hoe zie je het effect? Browser kan domein niet vinden, of je komt op een andere site uit. Je komt op de verkeerde server uit (bijv. oude site, placeholder, of fout). HTML laadt misschien wel, maar CSS/afbeeldingen geven 404, of je krijgt 403 voor bepaalde mappen.
Wat jij meestal beheert Registratie en instellingen bij registrar. Instellen van records (A/AAAA/CNAME), vaak via registrar/host. Upload van projectstructuur, en zorgen dat de web root klopt.

Een typische misconceptie is: “Als mijn index.html online opent, is hosting goed.” In werkelijkheid kan alleen de eerste request goed gaan. Als jouw index.html verwijst naar assets/css/style.css maar die map staat verkeerd, krijg je dezelfde situatie als eerder: HTML 200, CSS 404, en de rendering ziet er “stuk” uit.

Web root, index-bestand en paden: waarom online anders voelt dan lokaal

Lokaal open je vaak een bestand direct: dubbelklik op index.html, en de browser toont het. Online open je geen bestand “op schijf”, maar een pad vanaf de web root. Dat verschil voelt subtiel, maar het is de bron van veel verwarring rond paden, zeker bij links tussen pagina’s en bij assets.

Op een server betekent / meestal: “serveer het standaard startbestand”, vaak index.html. Als jij dus naar mijnsite.nl/ gaat, verwacht de server dat er in de web root een index.html staat. Staat die in een submap (bijv. project/index.html), dan kan de server hem niet automatisch vinden en krijg je óf een fout, óf een directory listing, óf een hosting-placeholder.

Daarnaast zijn paden online vaak strenger:

  • Hoofdletters tellen bijna altijd (Linux-hosting is doorgaans case-sensitive).

  • Relatieve paden worden berekend vanaf de locatie van het HTML-bestand dat je open hebt.

  • “Even snel een mapje extra” kan alle links breken als je niet consequent bent.

Een goed mentaal model: je HTML is een routekaart voor de browser. Elke verwijzing wordt een request. De server kan alleen antwoorden binnen de web root en met exact dezelfde naam. Als je dat contract respecteert, maakt het niet uit wie jouw site opent of waar hij gehost staat: de browserflow blijft voorspelbaar.

Hier zijn veelvoorkomende valkuilen in training-opdrachten:

  • Pitfall: contact.html staat in pages/ maar je linkt naar contact.html vanuit index.html. Resultaat: 404.

  • Pitfall: Logo.png geüpload, maar je HTML vraagt logo.png. Resultaat: afbeelding mist online.

  • Pitfall: je uploadt alleen HTML en vergeet assets/. Resultaat: “werkt, maar zonder styling/afbeeldingen”.

  • Misconceptie: “De server vindt het wel.” Resultaat: je zoekt het probleem in CSS terwijl de request simpelweg faalt.

Twee opdrachten-scenario’s: zo pak je het aan zonder gokken

Voorbeeld 1: Bedrijfswebsite met 3 pagina’s en gedeelde assets

Je maakt een bedrijfswebsite met index.html, diensten.html en contact.html. Je wil dat alle pagina’s dezelfde header, typografie en spacing hebben via één assets/css/style.css. In een training-review is dit precies waar bestandsstructuur “kwaliteit” uitstraalt: een reviewer ziet in één oogopslag waar je assets zitten en verwacht dat jouw paden overal consistent zijn.

Stap voor stap werkt dit het meest stabiel:

  1. Je zet alle pagina’s op hetzelfde niveau: de root (naast index.html).
  2. Je zet al je ondersteunende bestanden in assets/ met vaste submappen.
  3. Je koppelt in elke HTML dezelfde stylesheet met exact dezelfde casing: assets/css/style.css.
  4. Je test één keer bewust: open diensten.html en contact.html ook direct, en kijk of alle assets nog laden.

De impact is direct: als één pagina styling heeft en een andere niet, is dat zelden “CSS die anders werkt” en bijna altijd een padverschil. Het voordeel van deze aanpak is dat je wijzigingen (bijv. nieuwe kleur of font) maar op één plek hoeft te doen. De beperking is dat je discipline nodig hebt: zodra je tóch een pagina in een submap stopt, moet je je padstrategie herzien, anders ontstaan er stille 404’s.

In workflow-termen helpt dit ook bij inleveren: je zip of upload wordt eenvoudiger te controleren. Alles wat nodig is, zit in één root-structuur en de server hoeft niets te “raden”.

Voorbeeld 2: Eventsite met sprekersfoto’s, iconen en veel requests

Je bouwt een eventsite met een sprekersgrid (bijv. 12 sprekers) en gebruikt foto’s uit assets/images/speakers/ plus iconen uit assets/images/icons/. Deze opdracht versterkt één realiteit uit de browserflow: één pagina kan tientallen requests veroorzaken. Als je een mapnaam verkeerd hebt, breken niet één maar veel resources tegelijk.

Een robuuste aanpak ziet er zo uit:

  1. Je kiest een consequente naamgeving: speaker-anna-jansen.jpg, speaker-mohammed-ali.jpg, zonder spaties.
  2. Je houdt alle afbeeldingen in één duidelijke boom: assets/images/speakers/ en assets/images/icons/.
  3. Je verwijst vanuit HTML exact naar die paden, en je verandert die structuur daarna niet meer “vlak voor inleveren”.
  4. Je controleert online of op een andere machine bewust op hoofdlettergevoeligheid: komt speaker-Anna.jpg ergens stiekem voor?

Het voordeel: je maakt je project schaalbaar. Een reviewer kan makkelijk zien: “Ah, alle speakers staan bij elkaar,” en jij kunt zonder chaos nieuwe sprekers toevoegen. De beperking: hoe meer assets, hoe groter de kans op kleine typefouten die grote visuele gaten veroorzaken (lege blokken, broken icons). Daarom is voorspelbare structuur hier geen luxe maar een vereiste.

Ook organisatorisch is dit belangrijk: in een teamsetting (of zelfs alleen met een docentreview) voorkom je discussie over waar iets “hoort”. Je structuur wordt een gedeelde taal, net als je code.

Een checklist in je hoofd: wat moet altijd kloppen?

Als je deze les herleidt tot een paar vaste ideeën, dan gaat het om voorspelbaarheid: voor de browser, voor de server, en voor iedereen die je opdracht bekijkt.

  • Bestandsstructuur is functionaliteit: paden bepalen of requests slagen, niet alleen of het “netjes” oogt.

  • Domein, DNS en hosting hebben aparte rollen: naam, koppeling, en serverplek; verwissel je die, dan debug je op de verkeerde laag.

  • Web root bepaalt wat “/” betekent: upload je in de verkeerde map, dan kan je site bestaan maar toch onvindbaar zijn.

  • Online is strenger dan lokaal: hoofdletters en exacte namen maken het verschil tussen 200 en 404.

Je fundament als webbouwer

  • Je organiseert websites als een set pagina’s + assets met stabiele paden, zodat requests consistent slagen.

  • Je begrijpt browsergedrag via request → response → rendering, en koppelt “kapotte styling” aan concrete oorzaken zoals 404 door paden of casing.

  • Je kunt domein, DNS en hosting uit elkaar houden en daardoor gerichter verklaren waar een probleem ontstaat.

Met dit fundament voelen je training-opdrachten niet meer als “bestanden die toevallig werken”, maar als kleine, echte websites die betrouwbaar te publiceren en te beoordelen zijn.

Last modified: Tuesday, 10 March 2026, 3:33 PM