WordPress
Understanding .htaccess auf 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 bedient jede Website mit einem leistungsstarken Webserver, der .htaccess nicht liest. Regeln, die Sie in diese Datei einfügen, haben daher keine Auswirkung: Diese Anleitung erklärt, was das für eine WordPress-Website bedeutet, und zeigt die KPanel-Einstellung, die stattdessen jede Aufgabe erfüllt.
Wenn Sie von einem gemeinsamen cPanel-Host gewechselt haben, war .htaccess wahrscheinlich der Ort, an dem Sie Weiterleitungen, HTTPS-Erzwingung, benutzerdefinierte Fehlerseiten und Bot-Blöcke eingerichtet haben. All diese Funktionen funktionieren auf Kapsule immer noch. Sie werden einfach in KPanel statt in einer Textdatei festgelegt, und da sie auf Serverebene angewendet werden, sind sie schneller und können Ihre Website durch einen Tippfehler nicht beschädigen.
Warum .htaccess hier nichts bewirkt
.htaccess ist eine Konfigurationsdatei pro Verzeichnis für den Apache-Webserver. Apache liest sie bei jeder einzelnen Anfrage neu, was sie praktisch macht und auch langsam.
Kapsule führt Apache nicht aus. Ihre Website wird von einem ereignisgesteuerten Webserver bereitgestellt, der seine Konfiguration beim Start einmal lädt. Das ist ein großer Teil des Grundes, warum Websites hier unter Last schneller reagieren. Dieser Server hat kein Äquivalent zu einer Außerkraftsetzungsdatei pro Verzeichnis und öffnet daher niemals .htaccess.
Das Hinzufügen von Regeln zu .htaccess auf einer Kapsule-Website schlägt stillschweigend fehl. Es gibt keine Fehler, keine Warnungen, und die Datei bleibt genau dort, wo Sie sie gelassen haben. Die Regeln werden einfach nie ausgeführt. Wenn Sie ein WordPress-Tutorial befolgen, das sagt "Fügen Sie dies zu Ihrer .htaccess hinzu", finden Sie stattdessen das KPanel-Äquivalent in der folgenden Tabelle.
Die gute Nachricht ist das Gegenteil der üblichen .htaccess-Horrorgeschichte: Ein Syntaxfehler in der Datei kann Ihre Website hier nicht lahm legen, da nichts sie parst.
Was ohne sie immer noch funktioniert
Permalinks. Der häufigste Grund, warum eine WordPress-Website auf Apache .htaccess benötigt, sind hübsche Permalinks. Auf Kapsule ist das Rewrite in die Serverkonfiguration Ihrer Website integriert, daher wird /2026/07/my-post/ direkt über WordPress aufgelöst, ohne dass überhaupt ein .htaccess-Block erforderlich ist. Wenn Permalinks 404er zurückgeben, liegt die Ursache woanders: siehe WordPress-Permalink-Probleme beheben.
WordPress schreibt in die Datei. WordPress und einige Plugins schreiben immer noch # BEGIN/# END-Blöcke in .htaccess, da sie Apache voraussetzen. Das ist harmlos. Die Datei existiert, ist beschreibbar, und Sie werden sie im Dateimanager sehen. Sie hat einfach keinen Leser.
Sicherheits-Plugins, die "gehärtete Sicherheit angewendet" melden. Plugins, die behaupten, xmlrpc.php oder wp-config.php durch Bearbeiten von .htaccess verriegelt zu haben, haben auf dieser Plattform tatsächlich nichts geschützt. Verwenden Sie stattdessen die Security-Registerkarte der Website, die die entsprechenden Regeln auf Serverebene anwendet.
KPanel-Äquivalente für gängige .htaccess-Regeln
Jede davon befindet sich auf der Website selbst: Websites, dann Ihre Website, dann die gezeigte Registerkarte.
| Was Sie in .htaccess geschrieben hätten | Wo es in KPanel lebt |
|---|---|
RewriteCond %{HTTPS} off um HTTPS zu erzwingen | Settings, dann Force HTTPS unter Behavior |
Redirect 301 /old /new | Advanced, dann Redirects |
ErrorDocument 404 /404.html | Advanced, dann Error pages |
AuthType Basic zum Schutz eines Ordners mit Passwort | Advanced, dann Password protection |
Require not ip 203.0.113.4 zum Blockieren einer Adresse | WordPress, dann Security |
RewriteCond %{HTTP_USER_AGENT} (BadBot) zum Blockieren von Crawlern | Performance, dann Crawlers |
DirectoryIndex index.php index.html | Settings, dann Directory index unter Serving |
mod_deflate / mod_expires für Komprimierung und Caching | Bereits aktiv. Komprimierung und Cache-Header werden auf dem Server gesetzt |
Zwei davon tun mehr als die .htaccess-Version jemals könnte. Umleitungen unterstützen exakte Pfade, Schrägstrich-Präfixe und Platzhalter wie /blog/*, und KPanel verifiziert die Umleitung nach dem Speichern live. Fehlerseiten werden mit ihrem wahren Statuscode bereitgestellt, sodass eine benutzerdefinierte 404-Seite immer noch ein echter 404 für Suchmaschinen ist, anstatt ein 200 mit einer Entschuldigung.

Die Datei suchen und lesen
Sie möchten sich .htaccess möglicherweise trotzdem ansehen, normalerweise um zu sehen, was ein Plugin hineingeschrieben hat, oder um Regeln zu kopieren, bevor Sie sie in KPanel neu erstellen.
Aus der WordPress-Registerkarte
- Melden Sie sich bei KPanel an und klicken Sie in der linken Seitenleiste auf Websites.
- Klicken Sie auf die gewünschte Website.
- Öffnen Sie die WordPress-Registerkarte und dann den Bereich wp-config.
- Scrollen Sie zum Panel
.htaccess. Der Inhalt wird schreibgeschützt angezeigt, mit einer Schaltfläche Edit, falls Sie etwas ändern müssen.
Aus dem Dateimanager
- Öffnen Sie die Website, dann Files, dann File Manager.
- Klicken Sie in der Symbolleiste auf Show Hidden. Dateien, die mit einem Punkt beginnen, sind standardmäßig verborgen.
.htaccesswird daher nicht angezeigt, bis Sie dies tun. - Klicken Sie auf
.htaccess, um sie im integrierten Editor zu öffnen.
Die Datei befindet sich im Stammverzeichnis Ihrer Website, neben wp-config.php und wp-content. Vollständige Details zum Editor und seinen Berechtigungssteuerelementen finden Sie unter Using the File Manager.
Erstellen Sie eine Sicherung, bevor Sie etwas im Website-Stammverzeichnis bearbeiten, auch eine Datei, die nicht gelesen wird. Es kostet nichts und bedeutet, dass Sie mit einem Klick zurück sind. Siehe Taking a Backup.
Der Standard-WordPress-Block
Zur Referenz: Dies ist der Block, den WordPress für sich selbst schreibt. Auf einem Apache-Host treibt er Permalinks an. Auf Kapsule ist er inaktiv, und das Löschen funktioniert nicht:
# 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
Lassen Sie ihn an Ort und Stelle, wenn Sie die Website später möglicherweise auf einen Apache-Host verschieben könnten. WordPress wird ihn beim nächsten Speichern Ihrer Permalink-Einstellungen ohnehin neu schreiben.
Wenn Sie Regeln migrieren
Wenn Sie eine Website von cPanel bringen, öffnen Sie die alte .htaccess, bevor Sie das alte Hosting stornieren, und arbeiten Sie sie Zeile für Zeile durch:
- Umleitungen. Erstellen Sie jede
RedirectoderRewriteRulein Advanced, dann Redirects neu. Eine Zeile pro Regel. Wählen Sie 301 für einen permanenten Umzug, 302 wenn die Änderung rückgängig gemacht werden könnte. - HTTPS-Erzwingung. Löschen Sie sie. Schalten Sie stattdessen Force HTTPS in den Settings der Website ein.
- IP-Blöcke. Erstellen Sie sie in WordPress, dann Security, in der IP-Blockierungsleiste neu.
- Caching- und Komprimierungsheader. Löschen Sie sie. Sie werden für Sie verwaltet, und alte
mod_expires-Regeln von einem alten Host sind eine häufige Quelle für verwirrtes Cacheverhalten. - Alles, das ein Plugin geschrieben hat. Ignorieren Sie es. Installieren Sie das Plugin auf der neuen Website neu und lassen Sie es sein eigenes Ding tun.
Ihre Migration behält die Datei selbst, sodass nichts verloren geht, während Sie die Liste durcharbeiten. Vollständige Migrations-Anleitung: Migrating a Website From cPanel.
Fehlerbehebung
"Ich habe eine Umleitung zu .htaccess hinzugefügt und es ist nichts passiert." Erwartet. Fügen Sie es in Advanced, dann Redirects hinzu. Die Spalte Status zeigt dort an, ob die Umleitung live verifiziert wurde.
"Ein Plugin sagt, meine Website ist gehärtet, aber ein Scanner ist anderer Meinung." Das Plugin hat .htaccess-Regeln geschrieben, die nicht gelesen werden. Überprüfen Sie die Security-Registerkarte der Website auf die Schutzmaßnahmen, die wirklich angewendet werden.
"Die .htaccess meines alten Hosts hatte Regeln, die ich nicht verstehe." Kopieren Sie sie nicht blind. Öffnen Sie ein Ticket mit der angehängten Datei und wir sagen Ihnen, welche ein Kapsule-Äquivalent haben und welche nur für einen gemeinsamen Apache-Host kompensiert wurden.
"Permalinks sind beschädigt." Das ist hier kein .htaccess-Problem. Gehen Sie zu Fixing WordPress Permalink Issues oder leeren Sie die Rewrite-Regeln aus der WordPress-Registerkarte der Website, dann Quick Actions, dann Flush Rewrites.