Uw website geeft opeens een Internal Server Error, of laadt helemaal niets meer. Geen wit scherm met foutmelding, geen WordPress-melding, alleen een kale serverpagina. Vaak vlak nadat iemand een beveiligingsplugin heeft geactiveerd, een cacheplugin heeft ingesteld, of “een regeltje” heeft toegevoegd om www-adressen door te sturen.

In zulke gevallen is een beschadigd .htaccess-bestand de verdachte nummer één. Het is een klein tekstbestand met grote gevolgen: de server leest het bij elke aanvraag, en één verkeerd teken is genoeg om alles te blokkeren. Wilt u uw htaccess in WordPress herstellen, dan hoeft u gelukkig niet te begrijpen wat er allemaal in staat. U hoeft alleen te weten hoe een schone versie eruitziet en waar u die neerzet.

Wat .htaccess doet en waarom het zo kwetsbaar is

Het bestand staat in de hoofdmap van uw site en bevat instructies voor de Apache-webserver. WordPress gebruikt het vooral voor de permalinks: elk adres wordt doorgestuurd naar index.php, waarna WordPress de juiste inhoud opzoekt. Daarnaast zetten plugins er allerlei regels in: caching, browsercache, beveiligingsblokkades, redirects, IP-filters, compressie.

Het bestand is kwetsbaar om drie redenen. Ten eerste is de syntaxis streng; een ontbrekende sluitregel of een typefout geeft direct een error 500. Ten tweede schrijven meerdere plugins naar hetzelfde bestand, waardoor ze elkaars regels kunnen overschrijven of dubbel zetten. Ten derde: wie het via FTP bewerkt, doet dat vaak in een editor die stilletjes de tekencodering of regeleinden verandert.

Draait uw site op Nginx of LiteSpeed? Nginx negeert .htaccess volledig; daar zit de oorzaak dus ergens anders. LiteSpeed leest het wél, net als Apache.

Stap 1: vaststellen dat .htaccess de boosdoener is

Voordat u iets vervangt, wilt u zeker weten dat u aan het juiste bestand zit. Dat test u in een minuut:

  1. Verbind via FTP of de bestandsbeheerder van uw hostingpaneel met de hoofdmap van de site (de map met wp-config.php).
  2. Zet in de instellingen van uw FTP-programma het tonen van verborgen bestanden aan; bestanden die met een punt beginnen zijn standaard onzichtbaar.
  3. Hernoem .htaccess naar .htaccess-oud. Verwijder het niet.
  4. Laad de homepage opnieuw.

Werkt de homepage weer, dan is de diagnose rond. Dat de onderliggende pagina’s nu een 404 geven, is normaal: zonder .htaccess weet de server niet hoe hij nette adressen moet verwerken. Dat lost u in de volgende stap op. Blijft de fout ook zonder het bestand bestaan, zet dan de oude naam terug en zoek verder; de oorzaak zit dan in PHP, een plugin of de server. Ons overzicht van oorzaken van een error 500 helpt u daarbij.

Stap 2: een schone versie terugzetten

De eenvoudigste weg loopt via WordPress zelf. Kunt u nog inloggen op het beheer, ga dan naar Instellingen → Permalinks en klik op Wijzigingen opslaan. WordPress maakt dan een nieuw .htaccess aan met alleen zijn eigen standaardregels. Klaar.

Lukt inloggen niet, maak dan zelf een nieuw, leeg tekstbestand met de naam .htaccess en plak daarin de standaardinhoud voor een gewone (niet-multisite) installatie:

# 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

Upload dit bestand naar de hoofdmap. Let op een paar details: de bestandsnaam heeft geen extensie (dus niet .htaccess.txt), gebruik een kale teksteditor zoals Kladblok of een code-editor, en staat WordPress in een submap, pas dan RewriteBase en het pad in de laatste regel aan.

Stap 3: uitzoeken wat er fout stond

Nu de site weer draait, is het verleidelijk om het oude bestand te vergeten. Doe dat niet; de regels die erin stonden hadden een functie, en de plugin die ze schreef gaat ze mogelijk opnieuw schrijven. Open .htaccess-oud en kijk naar de blokken. Plugins markeren hun regels meestal met # BEGIN naam en # END naam. Veel voorkomende fouten:

  • Een blok dat wel begint maar niet eindigt, bijvoorbeeld omdat de upload halverwege afbrak.
  • Regels die verwijzen naar een module die op deze server niet bestaat, zoals mod_expires of mod_deflate, zonder de beschermende IfModule-regel eromheen.
  • Twee keer hetzelfde WordPress-blok, vaak na een verhuizing.
  • Een handmatig toegevoegde redirect met een typefout, zoals RewriteRule zonder doel.
  • Rare tekens aan het begin van het bestand door een editor die een byte-order mark toevoegt.

Zet de blokken die u nodig heeft één voor één terug in het nieuwe bestand en laad de site na elke toevoeging opnieuw. Zodra de fout terugkomt, weet u welk blok de schuldige is. Vaak is het eenvoudiger om de betreffende plugin zijn regels opnieuw te laten schrijven via de eigen instellingen, in plaats van ze te plakken.

Voorkomen dat het opnieuw gebeurt

Een paar gewoontes die in de praktijk veel gedoe schelen:

  • Bewaar altijd een kopie van .htaccess voordat u een plugin activeert die er iets aan verandert (cache, beveiliging, redirects).
  • Bewerk het bestand niet in Word of een tekstverwerker.
  • Laat maximaal één plugin redirects beheren en één plugin caching.
  • Zet het bestand na het herstellen op leesrechten 644; sommige beveiligingsplugins zetten het op 444, waarna WordPress zelf niet meer kan schrijven en de permalinkfix niet werkt.
  • Neem het bestand op in uw back-ups. Niet elke back-upplugin doet verborgen bestanden standaard mee.

Een boekhoudkantoor in Breda stond een halve dag offline nadat een medewerker via een online tutorial een “hotlink protection”-regel had toegevoegd met een ontbrekend vierkant haakje. De hoster zag niets aan de server, want de server deed precies wat het bestand vroeg: alles weigeren. Zulke situaties zijn typisch werk voor een bugfixingdienst: het herstel zelf duurt tien minuten, het uitzoeken welke regels wél terug moeten wat langer.

Conclusie

Een corrupt .htaccess-bestand klinkt ernstig, maar hoort bij de storingen die u zelf kunt oplossen: hernoemen, een schone versie plaatsen, permalinks opslaan. Neem daarna wel de tijd om het oude bestand te bekijken, zodat u niet volgende week dezelfde error 500 ziet. En bewaar voortaan een kopie voordat u een plugin de regels laat aanpassen.