Het patroon is heel herkenbaar: uw homepage laadt prima, maar zodra u op een menu-item klikt krijgt u een 404-melding. Soms een kale Nginx-pagina met de tekst 404 Not Found, soms uw eigen foutpagina. Dat permalinks niet werken op Nginx komt bijna nooit door WordPress zelf, maar doordat de server niet weet dat hij mooie adressen moet doorsturen naar de juiste plek.

Wie eerder op een Apache-server werkte, zoekt reflexmatig naar het .htaccess-bestand. Dat heeft op Nginx geen enkel effect: die server leest dat bestand niet en zal het ook nooit doen. Vandaar dat u met de gebruikelijke oplossing niet verder komt.

Wat er onder de motorkap gebeurt

Een adres als /diensten/onderhoud/ verwijst niet naar een map of een bestand op uw server. Er staat daar helemaal niets. WordPress bouwt die pagina op het moment dat hij wordt gevraagd, op basis van wat er in de database staat.

Daarvoor moet elk verzoek dat geen bestaand bestand aanwijst, worden doorgestuurd naar index.php. Dat is de hele truc. Op Apache staat die instructie in .htaccess. Op Nginx hoort hij in het serverblok, in een bestand dat u alleen met beheerderstoegang tot de server kunt aanpassen.

Ontbreekt die instructie, dan gaat Nginx letterlijk zoeken naar een map met de naam diensten. Die is er niet, dus meldt hij netjes dat het niet bestaat. Vanuit de server gezien klopt dat antwoord volkomen.

Eerst vaststellen dat het hierom gaat

Loop deze drie controles langs voordat u iemand belt.

  1. Zet permalinks tijdelijk op de eenvoudige variant. Ga naar Instellingen en dan Permalinks, kies de optie met alleen een berichtnummer en sla op. Werken uw pagina’s nu wel, dan is de diagnose rond: het ligt aan het doorsturen, niet aan uw inhoud.
  2. Kijk welke server u draait. In het beheerscherm onder Gereedschap en dan Sitegezondheid, tabblad Info, onderdeel Server, staat de webserver vermeld. Staat daar nginx, dan bent u hier goed.
  3. Test één bestaand bestand. Roep een afbeelding uit uw mediabibliotheek rechtstreeks op. Laadt die wel, dan werkt de server op zich prima en gaat het echt alleen om adressen zonder bestand.

Let op het verschil met een 404 die pas ontstond na het wijzigen van uw permalinkstructuur. Dat is een ander probleem, met een andere oplossing; dat leest u in het artikel over 404-fouten na een gewijzigde permalinkstructuur.

Wat er in de configuratie hoort te staan

De kern is één blok dat zegt: probeer het gevraagde bestand, probeer anders de map, en stuur het anders door naar index.php met de originele parameters erachter. In Nginx-taal is dat een try_files-regel in het location-blok van uw site.

Daarnaast hoort er een blok te staan dat PHP-bestanden doorgeeft aan de PHP-verwerker, met een verwijzing naar de socket of de poort waarop die draait. Ontbreekt dat, dan krijgt u geen 404 maar een download van het bestand of een lege pagina.

Draait uw site in een submap, dan moet die submap in de regel worden meegenomen. Dat wordt vaak vergeten bij sites die eerst in de hoofdmap stonden en later zijn verplaatst.

Dit aanpassen kunt u alleen als u een eigen server of een VPS heeft. Bij gedeelde hosting heeft u die toegang niet, en dat is maar goed ook: één fout in dat bestand haalt alle sites op de machine onderuit.

Zo stelt u de vraag aan uw hostingpartij

Hier valt het meeste tijd te winnen. Een vage melding levert een vaag antwoord op. Stuur in plaats daarvan dit.

  • Het domein en de exacte pagina die de fout geeft, als volledig adres.
  • De constatering dat de homepage laadt en alle onderliggende pagina’s een 404 geven.
  • Het resultaat van de test met de eenvoudige permalinkstructuur: met berichtnummers werkt alles wel.
  • Het verzoek om in het Nginx-serverblok een try_files-regel op te nemen die onbekende adressen doorgeeft aan index.php.
  • De vermelding dat het om een WordPress-installatie gaat en of die in de hoofdmap of in een submap staat.

Met die vijf punten weet een beheerder precies wat hij moet doen. In de praktijk is dit binnen een halfuur geregeld; het is een standaardconfiguratie die op elke Nginx-server met WordPress hoort te staan.

Wanneer het niet aan Nginx ligt

Soms wijst alles naar de server terwijl er iets anders speelt. Vier situaties om uit te sluiten.

Er zit een aparte laag voor de server. Draait er OpenLiteSpeed of een cachelaag als Varnish, dan kan die de adressen anders afhandelen. De 404 komt dan van daar en niet van Nginx.

Alleen bepaalde pagina’s geven een fout. Werken uw berichten wel en uw producten niet, dan gaat het om de doorverwijsregels van dat ene contenttype. Ga in dat geval naar Instellingen en dan Permalinks en sla op zonder iets te wijzigen; dat schrijft de regels opnieuw weg.

Er is net verhuisd van Apache naar Nginx. Dan zijn er mogelijk ook doorverwijzingen uit uw oude .htaccess verdwenen die u wél nodig had, bijvoorbeeld naar oude adressen. Die moeten apart worden overgezet; hoe zo’n bestand is opgebouwd, staat in de uitleg over het htaccess-bestand.

Een beveiligingsplugin blokkeert bepaalde adressen. Zeldzaam, maar het komt voor bij regels die adressen met bepaalde woorden weren.

Een praktijkgeval

Een adviesbureau verhuisde naar een sneller VPS-pakket bij een Nederlandse aanbieder. De site was overgezet, het certificaat stond goed, de homepage laadde binnen een seconde. Alleen bleek na twee dagen dat geen enkele dienstenpagina bereikbaar was; de eigenaar had zelf alleen de homepage bekeken.

De oorzaak was één ontbrekende regel in de configuratie. Het herstel duurde tien minuten. De schade was groter dan de reparatie: twee dagen lang kwamen bezoekers uit zoekmachines op foutpagina’s terecht, en een deel van die pagina’s raakte tijdelijk uit de index.

Controleer na elke verhuizing meer dan de voorpagina

De les uit dat geval is simpel. Klik na een migratie minstens één pagina uit elk soort inhoud aan: een gewone pagina, een blogartikel, een categoriepagina, en bij een webshop ook een product en de winkelwagen. Dat kost vijf minuten en vangt precies dit soort fouten.

Bent u niet degene die de server beheert en krijgt u het van uw hostingpartij niet rond, dan helpt het om iemand te laten meelezen die weet welke regels erin horen. Dat soort hulp bij serverinstellingen die WordPress dwarszitten scheelt vooral discussietijd; bij WebMaintor sturen we in zulke gevallen de gewenste configuratie kant-en-klaar mee.

Uw eerstvolgende handeling: open een willekeurige subpagina van uw site in een privévenster. Krijgt u daar een 404 terwijl de homepage laadt, dan weet u nu precies welke vraag u vanmiddag stelt.