WordPress-pagina geeft een 404 terwijl hij bestaat? Zo los je het op

De pagina staat in je dashboard. Status: gepubliceerd. Je klikt op Bekijken en krijgt “pagina niet gevonden”. Of erger: je homepage werkt, maar elke andere pagina geeft een 404.

De pagina is er wel. WordPress weet alleen niet dat deze URL bij deze pagina hoort. Dat komt bijna altijd door een van de oorzaken hieronder, en de eerste lost het vaakst op.

Stap 1: sla je permalinks opnieuw op

WordPress vertaalt een URL naar een pagina met een lijst regels die het in de database bewaart. Die lijst wordt niet bij elk verzoek opnieuw gemaakt. Komt er een nieuw type content bij, bijvoorbeeld doordat je een plugin activeert of een thema wisselt, dan ontbreken de regels ervoor tot iemand de lijst ververst.

Ga naar Instellingen, Permalinks en klik op Wijzigingen opslaan. Je hoeft niets te veranderen. Alleen opslaan bouwt de lijst opnieuw op. Met WP-CLI:

wp rewrite flush --hard

Stap 2: alleen de homepage werkt?

Dan komt het verzoek niet eens bij WordPress aan. Op een Apache-server regelt het bestand .htaccess in je hoofdmap dat elke URL naar WordPress gaat. Na een verhuizing of een beveiligingsplugin ontbreekt het nogal eens, of is het leeg.

Permalinks opslaan schrijft het bestand opnieuw, als WordPress er mag schrijven. Lukt dat niet, dan toont WordPress onderaan de Permalinks-pagina de regels die je zelf moet plaatsen. Voor een gewone installatie zijn dat deze:

# 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

Draait je site op Nginx, dan bestaat .htaccess niet en moet je hoster in de serverconfiguratie regelen dat onbekende URL’s naar index.php gaan. Kom je hier na een verhuizing, lees dan ook WordPress-site verhuizen zonder downtime.

Stap 3: klopt de slug wel?

Open de pagina in de editor en kijk naar de URL eronder. Staat er /contact-2/ in plaats van /contact/, dan was die slug al bezet. Vaak door een pagina in de prullenbak of door een geüploade afbeelding die ook contact heette. Bijlagen hebben in WordPress een eigen URL, en die pikken een slug net zo goed in.

Leeg de prullenbak, of hernoem de bijlage. Zet daarna de slug van je pagina terug.

Stap 4: botst de URL met iets anders?

Een pagina en een ander type content kunnen hetzelfde adres claimen. Heet je pagina projecten en heeft een plugin een berichttype met het archief /projecten/, dan wint het archief. Je pagina is dan onbereikbaar, ook al staat hij gewoon gepubliceerd.

Ook de volgorde telt. WordPress loopt de regels van boven naar beneden af en de eerste die past wint. Ik heb een keer een hele reeks onderwerppagina’s zien 404’en omdat een regel voor bijlagen eerder in de lijst stond en de URL wegkaapte. De oplossing zat in de volgorde waarin de code alles registreerde. Heb je een ontwikkelaar, dan is dit het moment om die erbij te halen.

Waar het meestal misgaat

• De pagina is een concept of privé. Jij ziet hem omdat je bent ingelogd. Een bezoeker krijgt een 404. Test altijd in een privévenster.
• Een geplande publicatie. De datum staat in de toekomst, dus de pagina bestaat nog niet voor de buitenwereld.
• Een cache die de 404 bewaart. Je hebt het opgelost, maar je cacheplugin of hoster serveert nog de foutpagina. Leeg de cache.
• De URL veranderd zonder doorverwijzing. De pagina bestaat, alleen niet meer op het oude adres. Links van buiten en Google komen op een 404 uit. Zet een 301 van oud naar nieuw.
• Een beveiligingsplugin die .htaccess herschrijft. Na elke wijziging van die plugin staat je WordPress-blok er weer niet in.

Tot slot

Begin altijd met permalinks opslaan. Dat kost tien seconden en lost het in de meeste gevallen op. Werkt alleen je homepage, kijk dan naar .htaccess. En blijft één pagina hardnekkig 404’en, dan zit er iets anders op zijn adres. Vind dat, en je hebt je pagina terug.