Contact
← Terug naar kennisbank HOSTING

404 Not Found — uitgelegd en opgelost

De meest herkende foutmelding op het web. "404 Not Found" betekent simpelweg: de server heeft geen idee wat je wil, op de URL die je opvroeg staat niets. Soms is dat correct (typo, verwijderde pagina). Soms een symptoom van iets groters — zoals een hosting-migratie waarbij WordPress' rewrite-regels zijn verdwenen, of een redirect die misging. Deze gids legt uit wanneer 404 normaal is, wanneer het een fix vraagt, en hoe je 404's preventief opspoort.

11 min lezen · Laatst gecheckt:

Wat je typisch in de browser ziet:

Not Found
The requested URL /pagina was not found on this server.

Apache/2.4.41 (Ubuntu) Server at voorbeeld.nl Port 443

Of een vriendelijker pagina van een CMS:

Oops! De pagina die je zoekt bestaat niet (meer).

Beide zeggen hetzelfde: de URL bestaat niet op de server. De server-status is 404 — dat zie je terug in je browser-devtools (F12 → Network-tab) en in het server access-log.

Wanneer is een 404 normaal?

Niet elke 404 is een fout om te repareren. Drie scenario's waarin 404 het juiste antwoord is:

  • Bezoeker typt een URL fout in de adresbalk → 404 is gepast.
  • Een externe site linkt naar een verwijderde pagina → 404 is OK, of upgrade naar 410 Gone als hij permanent weg is.
  • Een bot/crawler probeert random paths (admin/, wp-config.php, etc.) → 404 is correct (en hoort zo).

De vraag is: krijg jij 404's terwijl je weet dat de pagina bestaat? Dan zit er iets fout. De vijf meest voorkomende oorzaken:

De klassieker. WordPress heeft een rewrite-blok in .htaccess nodig om mooie URLs (/over-mij/) te vertalen naar index.php. Mist die blok → alles behalve de homepage geeft 404.

Wanneer dit gebeurt:

  • Na een hosting-migratie waarbij .htaccess niet is meegekopieerd
  • Na een mod_security- of WAF-rule die .htaccess heeft overschreven
  • Bij eerste install op een hoster die niet automatisch .htaccess aanmaakt
  • Bij Plesk waar je via FTP een .htaccess plakte die Plesk vervolgens overschreef

Fix: ga in WordPress naar Instellingen > Permalinks en klik Wijzigingen opslaan — zonder iets te wijzigen. WordPress probeert dan het rewrite-blok opnieuw weg te schrijven.

Werkt niet (geen schrijfrechten op .htaccess)? Plaats het handmatig:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Of gebruik mijn .htaccess builder — vink "Standaard WP rewrite-blok" aan en plak de output.

Oorzaak 2: Pagina is verwijderd of hernoemd

Logisch maar makkelijk over het hoofd te zien. Iemand verwijderde de pagina in WordPress, of hernoemde een slug van /over-mij/ naar /over-daniel/. Externe links blijven naar de oude URL wijzen → 404.

Fix: implementeer een 301-redirect van oude naar nieuwe URL. Dit kan via:

  • Een redirect-plugin (Redirection voor WordPress — gratis, default 301)
  • Direct in .htaccess: Redirect 301 /oude-pagina /nieuwe-pagina
  • Voor bulk-redirects (50+) gebruik je een spreadsheet en mijn .htaccess builder

Oorzaak 3: Bestand staat in de verkeerde directory

Statische bestanden (PDF, afbeeldingen, downloads) komen na een migratie soms in de verkeerde folder terecht. Verkeerde casing op Linux is ook een veelvoorkomende oorzaak: /Photos/foo.jpg bestaat niet als de map heet /photos/ (Windows is case-insensitive, Linux niet).

Fix: via SSH/FTP controleren of het bestand staat op de exacte URL die wordt opgevraagd. Hoofdletters tellen.

Oorzaak 4: Cache toont oude URLs (met name na verandering)

Cloudflare, server-cache (Varnish, Nginx FastCGI cache), of een page-cache-plugin (WP Rocket, W3 Total Cache) bewaart oude pagina's. Je verwijdert een URL, maar de cache serveert nog de gecachete versie — tot de cache verloopt of jij 'm purged.

Fix: Cloudflare > Caching > Purge Everything. Voor WordPress page-cache: cache flushen via plugin-instellingen.

Oorzaak 5: Custom redirect-rule die misging

Iemand zette een redirect in .htaccess of in een redirect-plugin die per ongeluk te breed is — bv. een rule die alle URLs vanaf /blog/ redirect naar een externe site, maar de regex was zo opgesteld dat 't ook normale blog-posts trof.

Fix: gebruik mijn redirect tracer om te zien waar de keten landt. Soms zie je dat een "404" eigenlijk een verkeerde redirect is die je doorstuurt naar een niet-bestaande URL.

Diagnose-stappen in volgorde

  1. Krijg je 404 op één URL of op alles behalve homepage? Alles → permalinks-blok mist (oorzaak 1). Eén URL → pagina verwijderd of typo (oorzaak 2/3).
  2. Heb je recent gewijzigd? Hosting-migratie, plugin-update, redirect-plugin geïnstalleerd? Dat is je eerste verdachte.
  3. Open browser-devtools (F12) → Network-tab. Zie je een echte 404, een 301 die naar 404 leidt, of een 200 met een lege pagina (= soft 404)?
  4. Check je server access_log: tail -f access.log | grep " 404 ". Toont real-time alle 404's met referrer.
  5. Test in incognito + andere browser: sluit cache + cookies uit als oorzaak.

404 vs. 410 Gone — voor SEO

Beide vertellen "deze URL bestaat niet", maar er is een belangrijk SEO-verschil:

  • 404 Not Found: Google denkt: "misschien tijdelijk weg, kom later terug". Houdt de URL maandenlang in de index.
  • 410 Gone: Google denkt: "permanent weg, verwijder uit index". Sneller (typisch binnen 2 weken).

Voor permanent-verwijderde pagina's (bv. uitgefaseerde producten in een webshop): gebruik 410. Voor onbedoelde fouten (verkeerde URL, verwijderde pagina die je terug wil): houd op 404 zodat je 'm later kunt herstellen.

410 in .htaccess:

Redirect 410 /oude-pagina

Een goede 404-pagina bouwen

Een saaie standaard-404 verliest je bezoekers. Een goede 404-pagina:

  • Verklaart in mensentaal: niet "Resource not found in the URI namespace" maar "Deze pagina bestaat niet (meer)"
  • Toont 3–5 populaire alternatieven: meest-bekeken artikel, populairste tool, contact-link
  • Heeft een zoekbalk als je veel content hebt
  • Match je site-stijl — geen kale Apache-foutpagina
  • Logt 404's zodat je patronen ziet (welke URLs vaak fout gaan)

Bekijk mijn eigen 404-pagina als voorbeeld — daar zit ook een Konami-code easter egg in voor wie 'm vindt.

Veelgestelde vragen

Waarom geeft mijn WordPress 404 op alles behalve de homepage?

Bijna altijd ontbreekt het WordPress-rewrite-blok in je .htaccess of de mod_rewrite-module is uit. Ga in WordPress naar Instellingen > Permalinks en klik op "Wijzigingen opslaan" (zonder iets te wijzigen) — WordPress probeert dan het rewrite-blok opnieuw weg te schrijven. Werkt dat niet, plaats het handmatig (snippet hierboven).

Wat is het verschil tussen een 404 en een 410 Gone?

404 zegt "niet gevonden, misschien tijdelijk". 410 zegt "permanent weg, vergeet 'm maar". Voor SEO is 410 een sterker signaal: Google verwijdert een 410-URL sneller uit de index dan een 404. Gebruik 410 voor pagina's die permanent verwijderd zijn.

Hoe weet ik welke 404's bezoekers krijgen?

Drie bronnen: (1) Google Search Console > Pagina's > "Niet gevonden (404)" toont URLs die Google probeerde maar 404 kreeg. (2) Je server's access_log filteren op " 404 " geeft alle 404's met referrer. (3) Plugins zoals Redirection (WordPress) loggen 404's en suggereren automatisch redirects.

Moet ik alle 404's redirecten?

Nee. Alleen 404's met inkomende links of zoekverkeer verdienen een 301 naar een logische opvolger. Een 404 voor /random-typo is gewoon een 404 — prima. Te veel onlogische redirects (alle 404's naar de homepage) is slechte UX en Google ziet het als "soft 404" wat ook niet helpt.

Mijn 404-pagina ziet er saai uit — heeft dat impact?

Op bezoekers wel, op SEO direct niet. Een goede 404 toont links naar populaire content, een zoekbalk, en persoonlijke uitleg. Bezoekers die op een 404 belanden klikken vaker door als er duidelijke alternatieven staan.