WordPress
.htaccess begrijpen op KapsuleHost
Kapsule serves every website with a high performance web server that does not read .htaccess, so rules you add to that file have no effect: this guide explains what that means for a WordPress site…
Kapsule serveert elke website met een high performance web server die .htaccess niet leest, dus regels die je aan dat bestand toevoegt hebben geen effect: deze gids legt uit wat dat betekent voor een WordPress site en toont de KPanel instelling die elk werk doet in plaats daarvan.
Als je bent verhuisd van een shared cPanel host, .htaccess was waarschijnlijk waar je redirects, HTTPS forcing, aangepaste foutpagina's en botblokkeringen plaatste. Al die dingen werken nog steeds op Kapsule. Ze worden gewoon ingesteld in KPanel in plaats van in een tekstbestand, en omdat ze op serverniveau worden toegepast, zijn ze sneller en kunnen ze je site niet breken met een typefout.
Waarom .htaccess hier niets doet
.htaccess is een per-directory configuratiebestand voor de Apache web server. Apache leest het bij elk verzoek opnieuw, wat het handig maakt en ook wat het langzaam maakt.
Kapsule voert Apache niet uit. Je site wordt bediend door een event driven web server die zijn configuratie eenmaal bij het opstarten laadt, wat een groot deel is van de reden waarom sites hier sneller reageren onder belasting. Die server heeft geen equivalent van een per-directory override bestand, dus het opent .htaccess nooit.
Regels toevoegen aan .htaccess op een Kapsule site mislukt stilzwijgend. Niets geeft een fout, niets waarschuwt, en het bestand blijft precies waar je het hebt achtergelaten. De regels worden gewoon nooit uitgevoerd. Als je een WordPress tutorial volgt die zegt "voeg dit toe aan je .htaccess", zoek in plaats daarvan het KPanel equivalent in de tabel hieronder.
Het goede nieuws is het omgekeerde van het gebruikelijke .htaccess gruwelverhaal: een syntaxisfout in het bestand kan je site hier niet naar beneden halen, omdat niets het parseert.
Wat werkt nog zonder het
Permalinks. De enige meest voorkomende reden waarom een WordPress site .htaccess nodig heeft op Apache zijn mooie permalinks. Op Kapsule is de herschrijving ingebouwd in de serverconfiguratie van je site, dus /2026/07/my-post/ wordt opgelost via WordPress zonder .htaccess blok. Als permalinks 404's retourneren, is de oorzaak iets anders: zie WordPress-permalinkproblemen oplossen.
WordPress schrijft naar het bestand. WordPress en sommige plugins schrijven nog steeds # BEGIN/# END blokken in .htaccess omdat ze Apache aannemen. Dat is onschadelijk. Het bestand is echt, het is schrijfbaar, en je ziet het in de bestandsbeheerder. Het heeft gewoon geen lezer.
Beveiligingsplugins die "hardening applied" rapporteren. Plugins die beweren xmlrpc.php of wp-config.php te hebben vergrendeld door .htaccess te bewerken, hebben eigenlijk niets op dit platform beschermd. Gebruik het tabblad Security van de site, dat gelijkwaardige regels op serverniveau toepast.
KPanel-equivalenten voor veelvoorkomende .htaccess-regels
Elk van deze bevindt zich op de site zelf: Websites, dan je site, dan het getoonde tabblad.
| Wat je zou hebben geschreven in .htaccess | Waar het leeft in KPanel |
|---|---|
RewriteCond %{HTTPS} off om HTTPS af te dwingen | Settings, dan Force HTTPS onder Behavior |
Redirect 301 /old /new | Advanced, dan Redirects |
ErrorDocument 404 /404.html | Advanced, dan Error pages |
AuthType Basic om een map met wachtwoord te beveiligen | Advanced, dan Password protection |
Require not ip 203.0.113.4 om een adres te blokkeren | WordPress, dan Security |
RewriteCond %{HTTP_USER_AGENT} (BadBot) om crawlers te blokkeren | Performance, dan Crawlers |
DirectoryIndex index.php index.html | Settings, dan Directory index onder Serving |
mod_deflate / mod_expires voor compressie en caching | Al ingeschakeld. Compressie- en cache-headers zijn ingesteld op de server |
Twee hiervan doen meer dan de .htaccess versie ooit kon. Redirects ondersteunen exacte paden, trailing-slash-voorvoegsels en wildcards zoals /blog/*, en KPanel verifieert de redirect live nadat je het hebt opgeslagen. Foutpagina's worden bediend met hun echte statuscode, dus een aangepaste 404-pagina is nog steeds een echte 404 voor zoekmachines in plaats van een 200 met een verontschuldiging erop.

Het bestand zoeken en lezen
Je wilt misschien nog steeds .htaccess bekijken, meestal om te zien wat een plugin er in heeft geschreven of om regels eruit te kopiëren voordat je ze opnieuw maakt in KPanel.
Vanuit het WordPress-tabblad
- Meld je aan bij KPanel en klik op Websites in de linkerzijbalk.
- Klik op de site die je wilt.
- Open het tabblad WordPress, vervolgens de sectie wp-config.
- Blader naar het
.htaccesspaneel. De inhoud wordt alleen-lezen weergegeven, met een Edit knop als je deze wilt wijzigen.
Vanuit de bestandsbeheerder
- Open de site, dan Files, dan File Manager.
- Klik op Show Hidden in de werkbalk. Bestanden die met een punt beginnen, zijn standaard verborgen, dus
.htaccessverschijnt niet totdat je dit doet. - Klik op
.htaccessom het in de ingebouwde editor te openen.
Het bestand bevindt zich in de root van je site, naast wp-config.php en wp-content. Volledige details over de editor en de machtigingsbesturingselementen staan in De bestandsbeheerder gebruiken.
Maak een back-up voordat je iets in de site root bewerkt, zelfs een bestand dat niet wordt gelezen. Het kost niets en het betekent dat je met één klik terug bent. Zie Een back-up maken.
Het standaard WordPress-blok
Ter referentie, dit is het blok dat WordPress voor zichzelf schrijft. Op een Apache host drijft het permalinks. Op Kapsule is het inert, en het verwijderen ervan zal niets breken:
# 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
Laat het op zijn plaats als je de site later mogelijk naar een Apache host wilt verplaatsen. WordPress zal het toch opnieuw schrijven volgende keer wanneer je je permalinkinstellingen opslaat.
Als je regels migreert
Wanneer je een site van cPanel meebrengt, open je de oude .htaccess voordat je de oude hosting annuleert en werk je er regel voor regel doorheen:
- Redirects. Recreeer elke
RedirectofRewriteRulein Advanced, dan Redirects. Één rij per regel. Kies 301 voor een permanente move, 302 als de wijziging kan terugdraaien. - HTTPS forcing. Verwijder het. Zet in plaats daarvan Force HTTPS in de Settings van de site aan.
- IP blokken. Recreeer in WordPress, dan Security, in het IP-blokkeringspaneel.
- Caching en compressie headers. Verwijder ze. Ze worden voor je afgehandeld, en verouderde
mod_expiresregels van een oude host zijn een veelvoorkomende oorzaak van verwarrend cache gedrag. - Alles wat een plugin heeft geschreven. Negeer het. Installeer de plugin opnieuw op de nieuwe site en laat het zijn gang gaan.
Je migratie behoudt het bestand zelf, dus niets gaat verloren terwijl je de lijst doorwerkt. Volledige migratie-walkthrough: Een website van cPanel migreren.
Probleemoplossing
"Ik heb een redirect aan .htaccess toegevoegd en er gebeurde niets." Verwacht. Voeg het toe in Advanced, dan Redirects. De statuskolom daar vertelt je of de redirect live is geverifieerd.
"Een plugin zegt dat mijn site is verhard, maar een scanner is het oneens." De plugin schreef .htaccess regels die niet worden gelezen. Controleer het tabblad Security van de site voor de beveiliging die werkelijk wordt toegepast.
"De .htaccess van mijn oude host had regels die ik niet begrijp." Kopieer ze niet blindelings over. Open een ticket met het bestand bijgevoegd en we vertellen je welke een Kapsule equivalent hebben en welke ooit alleen compenseerden voor een shared Apache host.
"Permalinks zijn verbroken." Dit is hier geen .htaccess probleem. Ga naar WordPress-permalinkproblemen oplossen, of flush de rewrite regels vanuit het tabblad WordPress van de site, dan Quick Actions, dan Flush Rewrites.