KapsuleHost bedient elke website met een high performance webserver 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 elke taak in plaats daarvan uitvoert.
Als je bent overgestapt van een gedeelde cPanel-host, was .htaccess waarschijnlijk de plek waar je redirects, HTTPS-afdwinging, aangepaste foutpagina's en bot-blokkades instelde. Al die dingen werken nog steeds op KapsuleHost. Ze worden alleen 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 door een typefout.
Waarom .htaccess hier niets doet
.htaccess is een configuratiebestand per directory voor de Apache-webserver. Apache leest het bij elk afzonderlijk verzoek opnieuw, wat het handig maakt en tegelijk ook traag.
KapsuleHost draait geen Apache. Je site wordt bediend door een event-driven webserver die zijn configuratie eenmalig laadt bij het opstarten, wat een groot deel verklaart van waarom sites hier sneller reageren onder belasting. Die server heeft geen equivalent van een overschrijvingsbestand per directory, dus hij opent .htaccess nooit.
Het toevoegen van regels aan .htaccess op een KapsuleHost-site mislukt stilzwijgend. Er verschijnt geen fout, er wordt geen waarschuwing gegeven, 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 dan in plaats daarvan het KPanel-equivalent op in de tabel hieronder.
Het goede nieuws is het omgekeerde van het gebruikelijke .htaccess-horrorverhaal: een syntaxisfout in het bestand kan je site hier niet platleggen, omdat niets het verwerkt.
Wat nog steeds werkt zonder dat bestand
Permalinks. De meest voorkomende reden waarom een WordPress-site .htaccess nodig heeft op Apache, is fraaie permalinks. Op KapsuleHost is de herschrijving ingebouwd in de serverconfiguratie van je site, dus /2026/07/my-post/ wordt via WordPress opgelost zonder enig .htaccess-blok. Als permalinks 404's teruggeven, ligt de oorzaak ergens anders: zie Problemen met WordPress-permalinks oplossen.
WordPress dat naar het bestand schrijft. WordPress en sommige plugins schrijven nog steeds # BEGIN/# END-blokken naar .htaccess omdat ze Apache veronderstellen. Dat is onschadelijk. Het bestand is echt, het is beschrijfbaar en je ziet het in de bestandenbeheerder. Het heeft alleen geen lezer.
Beveiligingsplugins die melden dat "hardening is toegepast". Plugins die beweren xmlrpc.php of wp-config.php te hebben beveiligd door .htaccess te bewerken, hebben op dit platform in werkelijkheid niets beschermd. Gebruik het tabblad Beveiliging van de site zelf, dat de equivalente regels op de server toepast.
KPanel-equivalenten voor veelvoorkomende .htaccess-regels
Elk van deze vind je op de site zelf: Websites, dan je site, dan het getoonde tabblad.
| Wat je in .htaccess zou hebben geschreven | Waar het zich in KPanel bevindt |
|---|---|
RewriteCond %{HTTPS} off om HTTPS af te dwingen | Instellingen, dan HTTPS afdwingen onder Behavior |
Redirect 301 /old /new | Instellingen, dan Omleidingen |
ErrorDocument 404 /404.html | Instellingen, dan Foutpagina's |
AuthType Basic om een map met een wachtwoord te beveiligen | Instellingen, dan Wachtwoordbeveiliging |
Require not ip 203.0.113.4 om een adres te blokkeren | WordPress, dan Beveiliging |
RewriteCond %{HTTP_USER_AGENT} (BadBot) om crawlers te blokkeren | Prestaties, dan Crawlers |
DirectoryIndex index.php index.html | Instellingen, dan Directory-index onder Serving |
mod_deflate / mod_expires voor compressie en caching | Al ingeschakeld. Compressie- en cacheheaders worden op de server ingesteld |
Twee van deze doen meer dan de .htaccess-versie ooit zou kunnen. Redirects ondersteunen exacte paden, trailing-slash-voorvoegsels en wildcards zoals /blog/*, en KPanel verifieert de redirect live nadat je hebt opgeslagen. Foutpagina's worden geserveerd met hun echte statuscode, zodat een aangepaste 404-pagina voor zoekmachines nog steeds een echte 404 is in plaats van een 200 met een excuusboodschap erop.
Het bestand vinden en bekijken
Mogelijk wil je toch .htaccess bekijken, meestal om te zien wat een plugin erin heeft geschreven of om regels eruit te kopiëren voordat je ze in KPanel opnieuw aanmaakt.
Vanuit het tabblad WordPress
- Meld je aan bij KPanel en klik op Websites in de linkerzijbalk.
- Klik op de gewenste site.
- Open het tabblad WordPress, daarna de sectie wp-config.
- Scrol naar het paneel
.htaccess. De inhoud wordt alleen-lezen getoond, met een knop Edit als je iets moet wijzigen.
Vanuit de bestandenbeheerder
- Open de site, dan Instellingen, dan Bestandenbeheerder.
- Klik op Verborgen tonen in de werkbalk. Bestanden die met een punt beginnen zijn standaard verborgen, dus
.htaccessverschijnt pas nadat je dit hebt gedaan. - 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 rechtenbeheerfunctie vind je in De bestandenbeheerder gebruiken.
Maak een back-up voordat je iets wijzigt in de root van de site, zelfs een bestand dat niet wordt gelezen. Het kost niets en het betekent dat je met één klik terug kunt. Zie Een back-up maken.
Het standaard WordPress-blok
Ter referentie, dit is het blok dat WordPress zelf wegschrijft. Op een Apache-host stuurt het permalinks aan. Op KapsuleHost is het inactief, en het verwijderen ervan zal niets kapotmaken:
# 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 staan als je de site later misschien naar een Apache-host verplaatst. WordPress schrijft het toch opnieuw de volgende keer dat je je permalinkinstellingen opslaat.
Als je regels aan het migreren bent
Wanneer je een site overzet vanuit cPanel, open dan het oude .htaccess voordat je de oude hosting opzegt en werk het regel voor regel door:
- Redirects. Maak elke
RedirectofRewriteRuleopnieuw aan in Instellingen, dan Omleidingen. Eén rij per regel. Kies 301 voor een permanente verhuizing, 302 als de wijziging mogelijk wordt teruggedraaid. - HTTPS-afdwinging. Verwijder het. Schakel in plaats daarvan HTTPS afdwingen in bij de Instellingen van de site.
- IP-blokkades. Maak ze opnieuw aan in WordPress, dan Beveiliging, in het paneel voor IP-blokkering.
- Caching- en compressieheaders. Verwijder ze. Ze worden voor je afgehandeld, en verouderde
mod_expires-regels van een oude host zijn een veelvoorkomende bron van verwarrend cachegedrag. - Alles wat een plugin heeft geschreven. Negeer het. Installeer de plugin opnieuw op de nieuwe site en laat hem zijn eigen werk doen.
Bij je migratie blijft het bestand zelf behouden, dus er gaat niets verloren terwijl je de lijst doorwerkt. Volledige migratiehandleiding: Een website migreren vanuit cPanel.
Probleemoplossing
"Ik heb een redirect toegevoegd aan .htaccess en er gebeurde niets." Verwacht. Voeg hem toe in Instellingen, dan Omleidingen. De kolom Status daar vertelt je of de redirect live is geverifieerd.
"Een plugin zegt dat mijn site gehard is, maar een scanner is het daar niet mee eens." De plugin heeft .htaccess-regels geschreven die niet worden gelezen. Controleer het tabblad Beveiliging van de site voor de beveiligingen die daadwerkelijk zijn toegepast.
"De .htaccess van mijn oude host bevatte regels die ik niet begrijp." Kopieer ze niet blindelings over. Open een ticket met het bestand als bijlage en wij vertellen je welke daarvan een KapsuleHost-equivalent hebben en welke alleen ooit compensatie waren voor een gedeelde Apache-host.
"Permalinks zijn kapot." Dit is hier geen .htaccess-probleem. Ga naar Problemen met WordPress-permalinks oplossen, of maak de herschrijfregels leeg via het tabblad WordPress van de site, dan Snelle acties, dan Herschrijvingen leegmaken.