.htaccess in Joomla

1. De basis

1.1 Wat is het .htaccess-bestand?

Het .htaccess-bestand (de naam betekent "hypertext access") is een configuratiebestand per map voor de Apache-webserver. Hiermee verander je hoe de server zich gedraagt voor een map en alles daaronder, zonder de hoofdconfiguratie van de server aan te raken. De punt aan het begin maakt het op Linux een verborgen bestand, en daarom tonen veel bestandsbeheerders het standaard niet.

Joomla gebruikt het voor vier hoofdtaken:

• Mooie SEF-URL's omzetten naar verzoeken die Joomla kan routeren.
• Een aantal van de meest voorkomende aanvalspatronen in de URL blokkeren.
• Een paar beveiligingsheaders en toegangsregels instellen.
• Vooraf ingepakte CSS en JavaScript serveren als die bestaan.

1.2 Waarom het als htaccess.txt wordt meegeleverd

Joomla installeert geen actief .htaccess-bestand. In plaats daarvan levert het een kant-en-klaar sjabloon met de naam htaccess.txt in de hoofdmap. Daar zijn twee redenen voor. Ten eerste is een verborgen bestand makkelijk over het hoofd te zien bij een upload. Ten tweede kan een .htaccess-bestand met rewriteregels de hele site stukmaken op een server die ze niet ondersteunt. Door het als gewone .txt mee te leveren, blijft het inactief tot je het zelf wilt gebruiken.

Om het te activeren, hernoem je het bestand:

htaccess.txt   →   .htaccess

Deze ene hernoeming is de stap die de meeste beginners vergeten. De twee bestanden zijn byte voor byte identiek; alleen de naam verschilt.

1.3 Waar het staat

Het bestand staat in de Joomla-hoofdmap, naast index.php en configuration.php:

public_html/
   index.php
   configuration.php
   htaccess.txt        ← het meegeleverde sjabloon
   .htaccess           ← het actieve bestand na het hernoemen
   web.config.txt      ← het IIS-equivalent (alleen Windows)

Apache leest .htaccess alleen als dat is toegestaan (zie hoofdstuk 11). Op de meeste shared hosting is dat standaard toegestaan, en juist daarom is .htaccess daar zo populair.

3. Het begin van het bestand: opties en headers

Voordat er iets wordt herschreven, stelt het meegeleverde bestand een paar serveropties en beveiligingsheaders in. Die draaien zelfs als mod_rewrite uitstaat.

3.1 FollowSymlinks en geen mappenlijsten

Options +FollowSymlinks
Options -Indexes

+FollowSymlinks laat Apache symbolische links volgen, wat mod_rewrite nodig heeft. De opmerkingen in het bestand waarschuwen dat sommige hosts verbieden dit in .htaccess te zetten; geeft je site een foutmelding, zet dan de regel in commentaar. -Indexes voorkomt dat Apache een automatische bestandslijst toont als een map geen indexbestand heeft, zodat bezoekers niet door je mappen kunnen bladeren.

Een tweede blok versterkt dezelfde gedachte voor de autoindex-module:

<IfModule mod_autoindex.c>
    IndexIgnore *
</IfModule>

3.2 De nosniff-header

Het bestand stelt voor elke respons een beveiligingsheader in:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

Dit vertelt de browser het content-type van een bestand niet te raden ("sniffen"). Zonder dit kan een browser een geuploade afbeelding als JavaScript behandelen en uitvoeren. De <IfModule>-omhulling betekent dat de regel alleen geldt als Apache's mod_headers geladen is, zodat het bestand nooit een fout geeft op een server zonder die module.

3.3 SVG-bestanden vergrendelen

SVG-afbeeldingen zijn XML en kunnen scripts bevatten. Het meegeleverde bestand blokkeert dat wanneer een SVG direct wordt geopend:

<FilesMatch "\.svg$">
  <IfModule mod_headers.c>
    Header always set Content-Security-Policy "script-src 'none'"
  </IfModule>
</FilesMatch>

Dit voorkomt dat inline-JavaScript draait wanneer iemand een SVG-bestand rechtstreeks uit je mediamap opent of het met een <object>-tag insluit. Het is een kleine maar echte verdediging tegen een kwaadaardige upload.

3.4 Het uitgecommentarieerde CORP- en COEP-blok

Net boven de SVG-regel bevat het bestand twee cross-origin-headers die standaard in commentaar staan:

#<IfModule mod_headers.c>
#    Header always set Cross-Origin-Resource-Policy "same-origin"
#    Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>

Ze staan uit omdat ze sites kunnen breken die terecht afbeeldingen, fonts of embeds van andere domeinen laden. Zet ze pas aan nadat je hebt getest dat elk extern bestand nog laadt. Ze zijn krachtig, maar niet veilig om blind aan te zetten.

5. Het gedeelte voor eigen redirects

Het bestand reserveert een duidelijk gemarkeerde ruimte voor je eigen redirectregels:

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

Dit blok is bewust leeg. Het is de juiste plek voor redirects op infrastructuurniveau die voordat PHP start moeten draaien. Een veelvoorkomend voorbeeld forceert een enkele canonieke host:

# Stuur www met een permanente 301 naar het kale domein
RewriteCond %{HTTP_HOST} ^www\.example\.test [NC]
RewriteRule (.*) https://example.test/$1 [R=301,L]

Zet het binnen dit gedeelte, zodat een Joomla-update die de SEF-regels vervangt je aanpassing niet per ongeluk wist. Voor redactionele redirects (een hernoemd artikel dat zijn oude link houdt) gebruik je liever Joomla's eigen Redirects-component, die redacteurvriendelijk is en een verhuizing van de site overleeft. Gebruik .htaccess voor regels op serverniveau, zoals HTTPS forceren of een canonieke host. Zie het Redirects-artikel voor het verschil.

7. Het kern-SEF-gedeelte

Dit is het hart van het bestand: de regels die mooie URL's daadwerkelijk naar Joomla routeren. Het bestaat uit drie delen.

7.1 De HTTP-Authorization-fix

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Sommige PHP-opstellingen (FastCGI) verwijderen de HTTP-header Authorization voordat PHP hem ziet. Joomla's Web Services API gebruikt die header om zijn bearer-token te lezen. Deze regel kopieert de header naar een omgevingsvariabele zodat de API hem toch vindt. Het doel - betekent "herschrijf de URL niet", alleen de variabele instellen.

7.2 De Web Services API routeren

RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* api/index.php [L]

Als het pad met /api/ begint, nog niet api/index.php is en niet overeenkomt met een echt bestand of map, herschrijft Apache het naar het API-toegangspunt api/index.php. Zo bereikt een verzoek als /api/index.php/v1/content/articles de headless API van Joomla. De [L]-flag betekent "laatste regel, stop hier".

7.3 De frontend routeren

RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

Dit is de regel die mooie URL's laat werken. De twee belangrijke voorwaarden zijn !-f ("geen echt bestand") en !-d ("geen echte map"). Samen zeggen ze:

Wijst het verzoek naar een echt bestand of map, serveer het dan direct. Anders, geef het door aan index.php en laat Joomla de route bepalen.

Daarom bereikt /over-ons Joomla en wordt het een pagina, terwijl /images/logo.png rechtstreeks van schijf wordt geserveerd en PHP nooit raakt.

7.4 Herschrijven versus redirecten

De SEF-regels hierboven zijn rewrites, en een rewrite is niet hetzelfde als een redirect. Het verschil telt zodra je je eigen regels toevoegt.

• Een rewrite is intern en onzichtbaar. De browser vraagt /over-ons, Apache serveert stilletjes index.php, en de adresbalk verandert niet. Zo bereiken mooie URL's Joomla.
• Een redirect is extern en zichtbaar. Apache vertelt de browser "ga in plaats daarvan naar deze andere URL", de browser doet een tweede verzoek, en de adresbalk verandert. Zo stuur je een oude URL naar een nieuwe.

Gebruik een rewrite als je wilt dat Joomla een vriendelijke URL afhandelt. Gebruik een redirect als een URL echt is verhuisd, en stuur de juiste statuscode: 301 voor een permanente verhuizing, 302 voor een tijdelijke.

7.5 Veelgebruikte rewrite-flags

De vierkante haken aan het eind van een RewriteRule of RewriteCond zijn flags die veranderen wat de regel doet. Het meegeleverde bestand gebruikt er meerdere; dit zijn de moeite waard om te kennen:

De flags lezen is de snelste manier om een onbekende regel te begrijpen. [R=301,L] betekent bijvoorbeeld "redirect permanent en stop", het standaardpaar voor een canonieke of HTTPS-redirect.

9. Compressie en caching

9.1 Vooraf ingepakte bestanden serveren (GZIP en Brotli)

Het laatste blok in het bestand is een prestatietruc. Als er een vooraf ingepakte .gz-kopie van een CSS- of JavaScript-bestand bestaat en de browser gzip accepteert, serveert Apache het kleinere bestand in plaats van het ter plekke in te pakken.

<IfModule mod_headers.c>
    # Serveer een met gzip ingepakt CSS-bestand als het bestaat en de client gzip accepteert.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

    # Hetzelfde voor JavaScript.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

    # Stuur het juiste content-type en voorkom dubbele compressie.
    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1,E=no-brotli:1]
    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1,E=no-brotli:1]
</IfModule>

Twee details zijn belangrijk. De flags no-gzip en no-brotli voorkomen dat Apache een al ingepakt bestand een tweede keer inpakt, wat het zou beschadigen. Een FilesMatch-blok stelt vervolgens Content-Encoding: gzip in en voegt Vary: Accept-Encoding toe, zodat proxy's de ingepakte en niet-ingepakte versies apart cachen.

De opmerking in het bestand waarschuwt dat als je host CSS en JS al inpakt, dit blok een fout met dubbele compressie geeft (ERR_CONTENT_DECODING_FAILED in de browserconsole). Zie je dat, zet dan het GZIP-gedeelte in commentaar. Dit blok helpt alleen als je daadwerkelijk .css.gz- en .js.gz-bestanden genereert; zonder die doet het simpelweg niets.

9.2 Browsercaching met mod_expires

Vooraf inpakken maakt de eerste download kleiner; browsercaching voorkomt de download bij het volgende bezoek helemaal. Met mod_expires vertel je browsers hoe lang ze statische bestanden moeten bewaren. Dit zit niet in het meegeleverde bestand, dus voeg je het toe in je eigen blok:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg            "access plus 1 year"
    ExpiresByType image/png             "access plus 1 year"
    ExpiresByType image/webp            "access plus 1 year"
    ExpiresByType image/svg+xml         "access plus 1 year"
    ExpiresByType font/woff2            "access plus 1 year"
    ExpiresByType text/css              "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Gangbare duren zijn een jaar voor afbeeldingen en fonts, die zelden veranderen, en een maand voor CSS en JavaScript. Lange vervaltijd werkt het best als je bestandsnamen geversioneerd zijn (bijvoorbeeld style.4f2a.css): een gewijzigd bestand krijgt een nieuwe naam, zodat de browser het nieuwe ophaalt in plaats van een verouderde kopie uit de cache te serveren. Joomla's eigen mediaversionering helpt hierbij door een versie-query aan zijn bestanden toe te voegen.

11. Onder de motorkap (ontwikkelaarsblik)

11.1 Wanneer Apache het bestand leest

Apache controleert bij elk verzoek op .htaccess, en leest niet alleen het bestand in de doelmap maar ook dat in elke bovenliggende map tot aan de documenthoofdmap. Dit is flexibel: je kunt zonder servertoegang regels in elke map zetten. Het is ook de prijs: die bestandslezingen gebeuren bij elk afzonderlijk verzoek.

11.2 AllowOverride bepaalt alles

Of Apache .htaccess uberhaupt leest, hangt af van de AllowOverride-directive in de hoofdconfiguratie:

<Directory /var/www/html>
    AllowOverride All      # lees .htaccess en pas de directives toe
</Directory>

Staat AllowOverride op None, dan negeert Apache het bestand volledig, en doen je rewriteregels niets, hoe correct ze ook zijn. Op een server die je zelf beheert is het snellere patroon om AllowOverride None te zetten en de regels naar de virtuele host te verplaatsen, zodat Apache niet meer naar het bestand zoekt:

# Dezelfde Joomla-regels, maar in de <VirtualHost> in plaats van .htaccess
<Directory /var/www/html>
    Options +FollowSymlinks -Indexes
    AllowOverride None
    # ... plak hier de RewriteRule-blokken ...
</Directory>

Dit haalt de bestandslezingen per verzoek weg en is op schaal meetbaar sneller. Op shared hosting heb je deze keuze zelden, dus daar blijft .htaccess.

11.3 Hoe de server doorgeeft aan Joomla

Na het herschrijven leest Joomla het verzoek uit de $_SERVER-superglobal die Apache vult. Een paar waarden bepalen hoe Joomla URL's bouwt en HTTPS detecteert:

11.4 De API-route testen

Omdat het bestand /api/ naar api/index.php routeert en de Authorization-header behoudt, kun je met een enkel verzoek bevestigen dat de Web Services API werkt:

curl -H "X-Joomla-Token: <jouw-token>" \
     https://example.test/api/index.php/v1/content/articles

Een JSON-lijst met artikelen betekent dat zowel de rewrite als de Authorization-fix werken. Een 404 op diezelfde aanroep betekent meestal dat .htaccess niet actief is of dat AllowOverride uitstaat.

11.5 Achter een reverse proxy of CDN

Veel Joomla-sites staan achter een CDN of reverse proxy zoals Cloudflare. Het .htaccess-bestand draait nog steeds op de oorsprongsserver, maar het verzoek is eerst door een andere laag gegaan, en dat verandert twee dingen.

Ten eerste beeindigt de proxy vaak HTTPS en praat daarna met je server over gewoon HTTP. Apache ziet HTTPS als uit, dus een kale "Forceer HTTPS"-rewrite kan eindeloos blijven hangen: de bezoeker komt via HTTPS bij de proxy, je server ziet HTTP en redirect naar HTTPS, de proxy stuurt het weer als HTTP door. De oplossing is de doorgestuurde header te controleren in plaats van HTTPS:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Ten tweede zet je Achter loadbalancer = Ja in Globale configuratie → Server, zodat Joomla het doorgestuurde protocol vertrouwt en https://-links correct bouwt. Zonder dit krijg je mixed-content-waarschuwingen of redirectlussen, zelfs als de .htaccess-regel zelf klopt.

13. SEO en metadata

Het .htaccess-bestand vormt SEO al voordat een extensie dat doet. Zoekmachines belonen sites die snel, veilig en consistent zijn, en alle drie beginnen hier:

• Mooie URL's: met het bestand actief en URL-herschrijven aan zijn paden kort en leesbaar, wat zowel gebruikers als crawlers prettiger vinden.
• Een canonieke host: gebruik het eigen-redirectsblok om HTTPS te forceren en kies www of het kale domein, en redirect daarna de ander met een 301. Dezelfde pagina op twee hosts serveren splitst de rankingsignalen.
• Juiste statuscodes: een permanente verhuizing moet 301 teruggeven, geen 302. De flags [R=301,L] zijn belangrijk om linkwaarde door te geven.
• Snelheid: het GZIP-blok en lange cacheheaders verbeteren Core Web Vitals, die Google's ranking voeden.

Niets hiervan heeft een SEO-extensie nodig. Het is configuratie die je eenmaal in het bestand en in de globale configuratie instelt, en die op elke pagina rendeert.

15. Beste praktijken

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

• Hernoem htaccess.txt naar .htaccess voordat je URL-herschrijven aanzet.
• Zet je eigen regels alleen in het "Custom redirects"-blok, zodat updates ze niet wissen.
• Bewaar een back-up van je actieve .htaccess voordat je het bewerkt.
• Stel bij een installatie in een submap RewriteBase in op het mappad.
• Forceer HTTPS en een canonieke host met [R=301,L], en stem het af met Joomla's Forceer HTTPS.
• Pakt de host bestanden al in, zet dan het GZIP-blok in commentaar.
• Verplaats op een server die je zelf beheert de regels naar de virtuele host en zet AllowOverride None voor snelheid.
• Blokkeer back-ups van configuration.php, .env en .git voor het web.
• Gebruik Joomla's Redirects-component voor redactionele redirects; gebruik .htaccess voor regels op serverniveau.
• Behandel de exploit-blokkerende regels als een basis, geen vervanging voor updates en een echte firewall.

17. Samenvatting

Het .htaccess-bestand is het invloedrijkste tekstbestand in een Apache-Joomla-site, en toch verbergt het zich achter een punt en wordt het bewust inactief geleverd. Zodra je weet wat elk blok doet, is het niet langer mysterieus:

• Activeren: hernoem htaccess.txt naar .htaccess en zet daarna URL-herschrijven aan.
• Routeren: het SEF-gedeelte stuurt alles wat geen echt bestand of map is naar index.php, en /api/-verzoeken naar api/index.php.
• Verdediging: het blokkeert veelvoorkomende URL-exploits, stelt de nosniff-header in en vergrendelt SVG-scripts.
• Snelheid: het kan vooraf ingepakte bestanden serveren en laat je cache- en HTTPS-regels toevoegen.
• Overdraagbaarheid: het is een Apache-functie; LiteSpeed leest het, maar Nginx en IIS hebben hun eigen configuratie nodig.

Geeft je Joomla-site 404's nadat je mooie URL's aanzet, breekt de CSS na een upload, of verlies je je eigen regels na een update, dan ligt de oorzaak bijna altijd in dit ene bestand. Een zorgvuldige blik op de rewriteregels, de RewriteBase en de AllowOverride-instelling vindt het probleem meestal snel. Het is precies het soort stille fundamentwerk dat een Joomla-site jarenlang snel, veilig en betrouwbaar houdt, en het loont om het een keer goed te doen in plaats van er op elke pagina mee te vechten.