Die Website lässt Sie kein Theme hochladen, weil die Datei zu groß ist. Suchmaschinen indexieren Admin-Seiten, die nicht in den Ergebnissen erscheinen sollten. Server-Logs zeigen Zugriffsversuche auf wp-config.php von unbekannten IPs. Drei Probleme, eine Lösung: die .htaccess-Datei, die bereits im Root-Verzeichnis Ihrer WordPress-Site liegt.

Sie haben sie wahrscheinlich beim Einrichten der sprechenden Permalinks gesehen. Doch die Fähigkeiten von .htaccess gehen weit darüber hinaus: Sie steuert Zugriff, Sicherheit, Weiterleitungen und Upload-Limits auf Server-Ebene. Und anders als Sicherheits-Plugins verursacht sie keine zusätzliche Last für PHP.

Nachfolgend vier praxisnahe Szenarien, mit denen jeder WordPress-Administrator konfrontiert wird. Jedes enthält sofort einsetzbaren Code, eine Erläuterung und eine Anleitung, wo genau er einzufügen ist. Der Code ist für Apache 2.4 geschrieben (die aktuelle Version Stand 2026), aber jedes Snippet enthält einen Kompatibilitätsblock für Apache 2.2, damit Sie sich nicht fragen müssen, ob es auf Ihrem Hosting funktioniert.

💡 Kurzüberblick:

• Datei-Upload-Limits über .htaccess und .user.ini für PHP-FPM erhöhen.
• Suchmaschinen-Indexierung auf Server-Ebene unterbinden.
• Verzeichnis-Browsing mit einer einzigen Zeile deaktivieren.
• wp-config.php mit moderner Apache-2.4-Syntax vor direktem Zugriff schützen.

1. Maximale Datei-Upload-Größe erhöhen

Sie versuchen, ein Theme oder Plugin zu installieren, und WordPress meldet einen Fehler: „Die hochgeladene Datei überschreitet die upload_max_filesize-Direktive in der php.ini." Das Standardlimit vieler Hoster liegt bei 2 MB oder 8 MB, und Ihr Theme-Archiv passt nicht hinein.

Sie können php.ini auf Shared Hosting nicht bearbeiten. Läuft Apache jedoch mit dem mod_php-Modul, können Sie das Limit direkt über .htaccess anheben. Öffnen Sie die Datei im Root Ihrer Site (per FTP oder über den Dateimanager Ihres Hosters) und fügen Sie am Ende Folgendes hinzu:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Die erste Direktive legt die maximale POST-Request-Größe fest, die zweite die maximale Größe für eine einzelne hochgeladene Datei. Beide Werte sollten übereinstimmen, oder post_max_size sollte etwas größer sein.

Prüfen Sie das Ergebnis: Gehen Sie ins WordPress-Admin-Panel, Medien → Neues hinzufügen. Das aktuelle Limit wird unten angezeigt.

Wichtig: Nutzt Ihr Hoster PHP-FPM (was 2026 die meisten tun), funktionieren die php_value-Direktiven in .htaccess nicht. Zur Prüfung: Werkzeuge → Website-Zustand → Info → Server. Achten Sie auf FPM in der Zeile „Server-Architektur". Bei solchem Hosting ändern Sie das Limit über eine .user.ini-Datei im Site-Root:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Das Format entspricht dem der php.ini, mit Gleichheitszeichen statt php_value. Die Änderungen greifen sofort, ein Server-Neustart ist nicht nötig. Existiert keine .user.ini-Datei im Root, legen Sie eine an.

2. Suchmaschinen-Indexierung unterbinden

Die Situation: eine Test-Site auf einer Subdomain, eine Staging-Kopie oder eine Landingpage, die nicht in den Ergebnissen von Google oder Yandex erscheinen soll. Eine einfache robots.txt mit Disallow: / kann von Suchmaschinen ignoriert werden: Sie ist eine Empfehlung, kein Verbot.

Die wasserdichte Methode ist, Bots auf Server-Ebene zu blockieren. Der klassische Ansatz mit SetEnvIfNoCase funktioniert in Apache 2.4 über das Kompatibilitätsmodul mod_access_compat, gilt aber als veraltet. Die moderne Methode leitet Bots mit leerem User-Agent über mod_rewrite um:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Hier passiert Folgendes: RewriteCond prüft den User-Agent jeder Anfrage. Erkennt die Bedingung die Schlüsselwörter bot, spider, crawler oder scanner (Groß-/Kleinschreibung wird durch das [NC]-Flag ignoriert), liefert der Server 403 Forbidden aus (das [F]-Flag).

Vier Muster genügen, um alle großen Suchmaschinen zu blockieren: Googlebot, YandexBot, Bingbot, Yahoo Slurp und Dutzende weniger bekannte. Jeden Bot einzeln aufzulisten, ist sinnlos: Allein Google hat mehrere Dutzend User-Agent-Varianten für verschiedene Dienste (Suche, Bilder, Video, AdsBot).

Möchten Sie nur Yandex blockieren, Google aber unbehelligt lassen? Grenzen Sie das Muster ein:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Das ^-Symbol bedeutet „Anfang der Zeichenkette". Ohne dieses Zeichen würde die Regel auch Bots erfassen, die yandex irgendwo in der Mitte ihres User-Agent stehen haben.

Wichtig: Nutzt WordPress bereits mod_rewrite für sprechende Permalinks, existiert der RewriteEngine On-Block bereits in der .htaccess. Duplizieren Sie ihn nicht; fügen Sie die neuen RewriteCond und RewriteRule lediglich nach den bestehenden WordPress-Regeln, aber vor dem schließenden </IfModule>-Tag ein.

Prüfen Sie .htaccess nach Änderungen auf Fehler: Ein Tippfehler in den Direktiven legt die Site mit einem 500-Fehler lahm. Sie können die Syntax mit einem Online-Validator oder dem Befehl apachectl configtest prüfen (nicht auf allen Hosts verfügbar). Laden Sie vor jeder Bearbeitung ein Backup Ihrer aktuellen .htaccess herunter.

3. Verzeichnis-Browsing deaktivieren

Rufen Sie Ihre Site unter /wp-content/uploads/ auf. Sehen Sie statt eines 403-Fehlers eine Dateiauflistung, ist das Verzeichnis-Browsing aktiviert. Das ist ein Sicherheitsleck: Jeder kann Ihre Ordnerstruktur studieren, ein verwundbares Plugin finden oder ein hochgeladenes PDF-Dokument lesen.

Deaktiviert wird es mit einer einzigen Zeile in der .htaccess:

1
Options -Indexes

Fügen Sie sie am Anfang der Datei ein, vor den WordPress-Regeln. Versucht nun jemand, ein Verzeichnis ohne Index-Datei zu öffnen, liefert der Server 403 Forbidden.

Bei den meisten modernen Hostern ist diese Option standardmäßig aktiviert, aber prüfen Sie es trotzdem, insbesondere wenn die Site zwischen Servern umgezogen ist oder Sie mit einem VPS arbeiten, bei dem Apache manuell konfiguriert wurde.

4. Wp-config.php vor direktem Zugriff schützen

wp-config.php ist die wichtigste WordPress-Datei. Sie enthält Sicherheitsschlüssel, das Tabellen-Präfix und die Datenbank-Zugangsdaten: Datenbankname, Benutzer, Passwort und Host.

Die Datei selbst ist in PHP geschrieben und liefert beim direkten Öffnen im Browser eine leere Seite, weil die WordPress-Engine sie nicht ausführt. Ist die PHP-Verarbeitung auf dem Server jedoch vorübergehend deaktiviert (Konfigurationsfehler, Modul-Update), könnte der Inhalt von wp-config.php als Klartext ausgeliefert werden. Inklusive des Datenbank-Passworts.

Wir unterbinden den Zugriff über .htaccess. Die meisten Artikel im Internet bieten veraltete Apache-2.2-Syntax an, die in Apache 2.4.6 und höher nicht funktioniert. Hier die moderne Version mit Abwärtskompatibilität:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

Der IfModule-Block prüft, ob das Modul mod_authz_core vorhanden ist (eingeführt in Apache 2.4.6). Fehlt das Modul, greift die Apache-2.2-Syntax. Ist es vorhanden, wird die moderne Direktive Require all denied verwendet. Ein Code-Block funktioniert auf beiden Apache-Versionen.

Nach dem Hinzufügen der Regeln erhält jede Browser-Anfrage auf wp-config.php 403 Forbidden, selbst wenn der PHP-Handler nicht arbeitet. WordPress greift über das Dateisystem direkt auf die Datei zu, die Regel beeinträchtigt den Site-Betrieb also nicht.

Derselbe Ansatz gilt für jede vertrauliche Datei: Ersetzen Sie wp-config.php durch den benötigten Dateinamen, etwa phpinfo.php oder .env.

⁉️🤔 Häufig gestellte Fragen

Komme ich in WordPress ganz ohne.htaccess** aus?**

Ja, wenn Ihre Site unter Nginx statt Apache läuft. Nginx unterstützt .htaccess nicht; alle Regeln werden in der Server-Konfiguration gesetzt (nginx.conf oder eine Datei in sites-available/). Auf Shared Hosting kommt fast immer Apache zum Einsatz, und .htaccess ist verfügbar. Auf einem VPS mit Nginx werden die Regeln in den server {}-Abschnitt übertragen: Die Syntax ist anders, die Logik dieselbe. Das Nginx-Äquivalent zu Options -Indexes lautet beispielsweise autoindex off;.

Was tun, wenn die Site nach einer Änderung der.htaccess mit einem 500-Fehler abstürzt?

Spielen Sie umgehend das Backup der .htaccess ein, das Sie vor der Bearbeitung erstellt haben (Sie haben doch eines erstellt, oder?). Verbinden Sie sich per FTP, löschen Sie die geänderte .htaccess und laden Sie das gesicherte Original hoch. Die Site ist sofort wieder erreichbar. Ein 500-Fehler nach einer .htaccess-Bearbeitung wird fast immer durch einen Tippfehler in einer Direktive oder ein Konstrukt verursacht, das Ihre Apache-Version nicht unterstützt.

Warum funktioniert php_value in der.htaccess bei meinem Hoster nicht?

Höchstwahrscheinlich nutzt Ihr Hoster PHP-FPM statt mod_php. Prüfen Sie: Werkzeuge → Website-Zustand → Info → Server. Erscheint FPM in der Zeile „Server-Architektur", wird php_value in .htaccess ignoriert. Verwenden Sie eine .user.ini-Datei im Site-Root (siehe Abschnitt 1) oder kontaktieren Sie den Support Ihres Hosters. Auf einem VPS werden Limits im PHP-FPM-Pool (www.conf) geändert, das erfordert jedoch Zugriff auf die Server-Konfiguration.

Wie überprüfe ich, ob die.htaccess tatsächlich greift?

Der einfachste Test ist die Regel aus Abschnitt 3 (Options -Indexes). Rufen Sie /wp-content/uploads/ vor und nach dem Hinzufügen auf. War vorher eine Dateiauflistung zu sehen und jetzt ein 403-Fehler? Die Datei funktioniert. Eine andere Methode: Fügen Sie eine Zeile mit einem absichtlichen Syntaxfehler in .htaccess ein und öffnen Sie die Site. Ein 500-Fehler bestätigt, dass Apache .htaccess liest. Entfernen Sie die Testzeile sofort nach der Prüfung.

Kann ich den Code aus diesem Artikel bedenkenlos auf einer Live-Site verwenden?

Ja, alle bereitgestellten Snippets wurden unter Apache 2.4 (der aktuellen Version Stand 2026) getestet und enthalten Kompatibilitätsblöcke für Apache 2.2. Die einzige zwingende Voraussetzung: Laden Sie vor jeder .htaccess-Bearbeitung die aktuelle Version der Datei auf Ihren Rechner herunter. Diese Fünf-Sekunden-Operation spart Ihnen im Fall eines Tippfehlers stundenlange Wiederherstellung. Und bearbeiten Sie .htaccess nicht über Plugins; nutzen Sie ausschließlich FTP oder den Dateimanager Ihres Hosters: Ein Plugin könnte Escaping hinzufügen, das die Syntax zerstört.

Worin unterscheidet sich der Ansatz zum Schutz von wp-config.php in diesem Artikel von dem, was andere Seiten schreiben?

Die meisten Artikel kopieren Apache-2.2-Syntax: Order allow,deny und Deny from all. Diese Direktiven gehören zum Modul mod_access_compat, das in Apache 2.4 veraltet ist und auf modernen Servern deaktiviert sein kann. Unser Snippet verwendet Require all denied aus dem Modul mod_authz_core, dem aktuellen Standard für Apache 2.4.6 und höher. Gleichzeitig erhält der <IfModule>-Block die Funktionsfähigkeit auf älteren Servern.

Was Sie jetzt in Ihre.htaccess-Konfiguration aufnehmen sollten

Die .htaccess-Datei ist kompakt, aber mächtig. Von den vier beschriebenen Techniken schließen zwei Sicherheitslücken mit minimalem Aufwand: das Deaktivieren des Verzeichnis-Browsings und der Schutz von wp-config.php. Das sind eine Zeile und ein Code-Block, die Sie sofort hinzufügen können, und sie beeinträchtigen den Site-Betrieb nicht.

Das Erhöhen des Upload-Limits hilft jedes Mal, wenn WordPress sich weigert, ein Theme oder Plugin hochzuladen. Und das Unterbinden der Indexierung auf Server-Ebene ist die letzte Verteidigungslinie für private und Test-Sites.

Bewahren Sie vor jeder Bearbeitung ein Backup der .htaccess auf. Ein Syntaxfehler legt die Site augenblicklich lahm, und genauso augenblicklich ist er behoben, wenn Sie eine Kopie zur Hand haben. Mit dieser Regel im Hinterkopf wird .htaccess von einer furchteinflößenden Datei zu einem funktionierenden Werkzeug.