Anzeige
Der Agentur-Server: Das digitale Zuhause für deine Projekte.
↬ Jetzt testen ↬ Jetzt testen!
Andreas Hecht 20. März 2019

Die 12 nützlichsten .htaccess-Tricks für WordPress

Die Webserver-Konfigurationsdatei .htaccess ist eine der wichtigsten Dateien deiner Website-Installation. Viel kann diese oftmals noch unterschätzte Datei leisten. Sie kann zu einem wahren Performance-Schub einer Website ebenso beitragen, wie zu erhöhter Sicherheit. Immer wieder werden WordPress-Websites gehackt, weil kein Augenmerk auf die Sicherheit der Website gelegt wird. In diesem Artikel stelle ich meine eigene .htaccess-Datei vor, die ich im Laufe der Zeit immer weiter verfeinert und optimiert habe.

Die Vorbereitung

Zuerst einmal muss die Datei gefunden werden. Der folgende Screenshot zeigt, wo die Datei liegt. Regelmäßig sollte sie sich im Hauptverzeichnis deiner WordPress-Installation finden lassen, also dort, wo die Ordner wp-content, wp-admin usw. liegen.

Der Speicherort der .htaccess-Datei

Ganz wichtig ist es, vor dem Bearbeiten der .htaccess Datei ein Backup selbiger zu erstellen. Dazu kopiere die Datei einfach in einen neuen/anderen Ordner.

Eine Besonderheit unter Mac OS X: Der Mac sieht alle Dateien mit einem Punkt vor dem Dateinamen als Systemdateien an, also auch die .htaccess. Das bedeutet, dass er sie ausblendet, sobald du sie etwa auf den Desktop gezogen hast. Abhilfe schafft hier das kleine Dashboard Widget Hidden Files, mit dem man nach Belieben die versteckten Dateien ein- und wieder ausblenden kann.

Nach jeder Änderung an der .htaccess-Datei muss ein Refresh des Browsers durchgeführt werden, um feststellen zu können, ob die Webseite noch erreichbar ist. Schon bei nur einem fehlerhaften Zeichen wird die betreffende Webseite nicht mehr angezeigt werden. Die .htaccess ist sehr empfindlich. Sollte deine Webseite also nicht mehr darstellbar sein, lade bitte die Backup-Version wieder hoch. Das behebt den Fehler zumeist augenblicklich.

Die nun folgenden Code-Schnipsel füge bitte einfach an das Ende der .htaccess an.

Teil 1: Browser-Caching aktivieren

Kaum eine andere Tuning-Maßnahme bringt mit so wenig Aufwand so viel Ergebnis. Viele der größten Dateien deiner Webseite ändern sich im Grunde genommen nie. Deshalb ist es eine gute Idee, diese für eine lange Zeit in den Browser-Cache zu befördern. Dateien, wie zum Beispiel das CSS oder das JavaScript einer Webseite, werden dann nur beim ersten Besuch einmal vom Browser geladen. Bei jedem weiteren Besuch (oder aber auch beim Aufruf weiterer Seiten beim ersten Besuch) muss der Browser diese Dateien nicht mehr laden. Dementsprechend wird die Webseite viel schneller angezeigt.

Dateien, die sich im Allgemeinen eher selten ändern, zum Beispiel JavaScripts, bekommen einen weit in der Zukunft definierten Cache-Header. Feeds hingegen werden nur eine Stunde gecached, fast alle anderen Dateien hingegen einen Monat. Zu beachten ist, dass in der Datei statische HTML-Seiten für eine schnellere Auslieferung für eine Stunde (3.600 Sekunden) in den Speicher befördert werden. Wer das nicht möchte, setzt stattdessen ein access plus 0 seconds ein.

Wichtig zu erwähnen ist, dass ein keep-alive-Header gesendet wird. Das erlaubt dem Browser das gleichzeitige Laden mehrerer Dateien und sorgt für einen weiteren Performance-Schub.

Bitte beachten: Da auch das CSS zwischengespeichert wird, sollte man, wenn man öfter etwas daran ändert, entweder die Datei nach einer Änderung umbenennen, oder eine Versionierung implementieren. Ich bevorzuge die zweite Lösung, die ein Teil eines zukünftigen Artikels sein wird.

# ----------------------------------------------------------------
# Belässt die Dateien, die sich selten oder gar nicht ändern, für eine bestimmte Zeit im Browser-Cache
# ----------------------------------------------------------------

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Teil 2: Die komprimierte Auslieferung der Dateien

Viele Vorschläge für .htaccess Dateien, die im Netz zu finden sind, sind nur rudimentär und unvollständig. Alle denkbaren und wichtigen Datei-Formate werden durch meine .htaccess komprimiert ausgeliefert, damit ein wirklicher Geschwindigkeitsvorteil entsteht.

# ----------------------------------------------------------------
# Komprimierung
# ----------------------------------------------------------------

<IfModule mod_deflate.c>
# Insert filters / compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/vtt 
AddOutputFilterByType DEFLATE text/x-component
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/js
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/atom+xml 
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/ld+json 
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject 
AddOutputFilterByType DEFLATE application/x-font-ttf 
AddOutputFilterByType DEFLATE application/x-web-app-manifest+json 
AddOutputFilterByType DEFLATE font/opentype 
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon 

# Exception: Images
SetEnvIfNoCase REQUEST_URI \.(?:gif|jpg|jpeg|png|svg)$ no-gzip dont-vary

# Drop problematic browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</IfModule>

#Alternative caching using Apache's "mod_headers", if it's installed.
#Caching of common files - ENABLED
<IfModule mod_headers.c>
<FilesMatch "\.(ico|pdf|flv|swf|js|css|gif|png|jpg|jpeg|txt)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(js|css|xml|gz)$">
  Header append Vary Accept-Encoding
  </FilesMatch>
</IfModule>

# Set Keep Alive Header
<IfModule mod_headers.c>
  Header set Connection keep-alive
</IfModule>

# If your server don't support ETags deactivate with "None" (and remove header)
<IfModule mod_expires.c> 
  <IfModule mod_headers.c> 
  Header unset ETag 
  </IfModule> 
  FileETag None 
</IfModule>

Teil 3: Allgemeine Sicherheitseinstellungen

Der Grand­sei­g­neur des Webdesigns – Jeff Starr von Perishable Press – feilt bereits seit Jahren an seiner Blockliste für die .htaccess. Die neueste Version seiner Firewall, die 6G, ist ein Manifest der Sicherheit und wird gerne durch einige WordPress-Security-Plugins kopiert, weil sie so effektiv ist. Sie schützt unter anderem vor Cross-Site-Scripting und Schadcode-Implementierung über die Erweiterungen von URLs. Hackversuche werden trotz des minimalen Codes wirkungsvoll unterbunden und der Code arbeitet sehr effektiv.

# 6G FIREWALL/BLACKLIST
# @ https://perishablepress.com/6g/

# 6G:[QUERY STRING]
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
	RewriteCond %{QUERY_STRING} (127\.0\.0\.1) [NC,OR]
	RewriteCond %{QUERY_STRING} ([a-z0-9]{2000,}) [NC,OR]
	RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR]
	RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR]
	RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR]
	RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR]
	RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR]
	RewriteCond %{QUERY_STRING} (thumbs?(_editor|open)?|tim(thumb)?)\.php [NC,OR]
	RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC]
	RewriteRule .* - [F]
</IfModule>

# 6G:[REQUEST METHOD]
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} ^(connect|debug|move|put|trace|track) [NC]
	RewriteRule .* - [F]
</IfModule>

# 6G:[REFERRER]
<IfModule mod_rewrite.c>
	RewriteCond %{HTTP_REFERER} ([a-z0-9]{2000,}) [NC,OR]
	RewriteCond %{HTTP_REFERER} (semalt.com|todaperfeita) [NC]
	RewriteRule .* - [F]
</IfModule>

# 6G:[REQUEST STRING]
<IfModule mod_alias.c>
	RedirectMatch 403 (?i)([a-z0-9]{2000,})
	RedirectMatch 403 (?i)(https?|ftp|php):/
	RedirectMatch 403 (?i)(base64_encode)(.*)(\()
	RedirectMatch 403 (?i)(=\\\'|=\\%27|/\\\'/?)\.
	RedirectMatch 403 (?i)/(\$(\&)?|\*|\"|\.|,|&|&?)/?$
	RedirectMatch 403 (?i)(\{0\}|\(/\(|\.\.\.|\+\+\+|\\\"\\\")
	RedirectMatch 403 (?i)(~|`|<|>|:|;|,|%|\\|\{|\}|\[|\]|\|)
	RedirectMatch 403 (?i)/(=|\$&|_mm|cgi-|muieblack)
	RedirectMatch 403 (?i)(&pws=0|_vti_|\(null\)|\{\$itemURL\}|echo(.*)kae|etc/passwd|eval\(|self/environ)
	RedirectMatch 403 (?i)\.(aspx?|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$
	RedirectMatch 403 (?i)/(^$|(wp-)?config|mobiquo|phpinfo|shell|sqlpatch|thumb|thumb_editor|thumbopen|timthumb|webshell)\.php
</IfModule>

# 6G:[USER AGENT]
<IfModule mod_setenvif.c>
	SetEnvIfNoCase User-Agent ([a-z0-9]{2000,}) bad_bot
	SetEnvIfNoCase User-Agent (archive.org|binlar|casper|checkpriv|choppy|clshttp|cmsworld|diavol|dotbot|extract|feedfinder|flicky|g00g1e|harvest|heritrix|httrack|kmccrew|loader|miner|nikto|nutch|planetwork|postrank|purebot|pycurl|python|seekerspider|siclab|skygrid|sqlmap|sucker|turnit|vikspider|winhttp|xxxyy|youda|zmeu|zune) bad_bot
	
	# Apache < 2.3
	<IfModule !mod_authz_core.c>
		Order Allow,Deny
		Allow from all
		Deny from env=bad_bot
	</IfModule>

	# Apache >= 2.3
	<IfModule mod_authz_core.c>
		<RequireAll>
			Require all Granted
			Require not env bad_bot
		</RequireAll>
	</IfModule>
</IfModule>

Teil 4: Wichtige Sicherheitseinstellungen für WordPress

Die allgemeine Beliebtheit des Content-Management-Systems WordPress ist leider der Grund dafür, dass es sich immer öfter den Hackversuchen böswilliger Mitmenschen ausgesetzt sieht. Mit einigen Zeilen Code in der .htaccess kann man dem vorbeugen. Kommt dann noch eine Absicherung des Administrator-Zugangs der Website hinzu, kann man die Site als sicher ansehen, wenn man die Basics wie das rechtzeitige Update von WordPress, Theme und Plugins beherrscht.

a) Schutz des Administrator-Bereichs

Wie man den Admin-Zugang einer WordPress-Website per .htaccess und .htpasswd wirkungsvoll absichert, haben wir bereits beschrieben. Ebenfalls wird die potenziell unsichere XML-RPC-Schnittstelle von WordPress mit diesem Code völlig abgeschaltet. Wer die Schnittstelle nutzen möchte, weil er zum Beispiel mit der neuen WordPress-Desktop-App arbeitet, muss den Bereich des Codes auskommentieren. Das geschieht mit einer vorgesetzten Raute (#) pro Code-Zeile. Die Absicherung des Adminbereichs ist bereits vorbereitet, wenn du diese Form der Sicherheit nicht nutzen möchtest, dann kommentiere diesen Bereich aus.

# ----------------------------------------------------------------
# Schutz des Administrator-Bereichs. Wenn der .htaccess/.htpasswd Schutz genutzt werden soll, auskommentieren UND PFAD ANPASSEN
# ----------------------------------------------------------------

#<Files wp-login.php>
#AuthName "Admin-Bereich"
#AuthType Basic
#AuthUserFile dein/pfad/zur/.htpasswd 
#require valid-user
#</Files>

b) Zugriff von außen auf .htaccess Datei verbieten

Damit die wichtige Serversteuerungs-Datei .htaccess keinesfalls von außerhalb des (S)FTP Zugangs erreichbar und damit verändert werden kann, verbieten wir als erstes den Zugriff darauf.

# Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
<FilesMatch "(\.htaccess)">
  Order deny,allow
  Deny from all
</FilesMatch>

c) Bild-Hotlinking verbieten

Das sogenannte Hotlinking von Bildern kann zum echten Problem werden. Hierbei laden andere Menschen die Bilder aus deiner Webseite nicht herunter, um sie dann anschliessend zu verlinken, sondern es wird nur der Pfad zu deinem Bild angegeben. Dies kann deine Webseite verlangsamen und wichtige Bandbreite stehlen. Die externe Verlinkung der Bilder kannst du mit dem folgenden Code jedoch ganz leicht verhindern.

Der Platzhalter deinewebseite.com muss durch die URL deiner Webseite ersetzt werden. Ganz unten ist der Pfad zu einer Grafik zu finden, die anstatt des verlinkten Bildes angezeigt wird. Diese Grafik kann durch jede andere ersetzt werden.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?deinewebseite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?deinewebseite.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://i.imgur.com/g7ptdBB.png [NC,R,L]

Bitte beachten: Solltest du einen externen Feedanbieter, wie zum Beispiel Feedburner, benutzen, könnte es sein, dass keine Bilder im Feed landen.

d) IP-Adressen dauerhaft bannen

Es kann schon mal vorkommen, dass man spezielle IP-Adressen einfach bannen möchte. Sei es, weil derjenige versucht hat, den Administrationsbereich zu hacken, oder aber, weil er vielleicht nur böswillige (Spam) Kommentare hinterlässt. Wenn du die IP-Adresse desjenigen herausgefunden hast, nutze folgenden Code um ihn für immer, zumindest unter dieser IP-Adresse, auszusperren.

<Limit GET POST>
order allow,deny
deny from 123.456.78.9
deny from 987.654.32.1
allow from all
</Limit>

Bitte beachten: Die IP-Adressen im obigen Code müssen natürlich noch angepasst werden. Diese Änderung gehörte einstmals zum Standard-Repertoire, ist jedoch mit Inkrafttreten der DSGVO deutlich schwieriger umzusetzen, da du IP-Adressen nicht mehr standardmäßig erfassen darfst.

e) Include-Only-Dateien blocken

Etliche, wirklich wichtige Dateien sollten niemals zugänglich sein, außer von WordPress selbst. Auch davor kann man sich mit folgendem Code schützen.

Bitte beachten: Für eine WordPress-Multisite-Installation funktioniert der Code nicht.

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

f) Separate Htaccess schützt den Wp-Content-Ordner

Der WordPress Ordner wp-content ist der wichtigste Ordner, da er deineThemes, die Plugins und Bilder, gecachte Dateien usw. enthält. Für Hacker ist dieser Ordner das Hauptangriffsziel, deshalb sollte er gut geschützt sein.

Erstelle eine separate .htaccess Datei, füge den folgenden Code hinein und lade die Datei in den wp-content Ordner hoch (www.deinewebseite/wp-content/).

Order deny,allow
 Deny from all
 <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
 Allow from all
 </Files>

g) Die XML-RPC Schnittstelle abschalten

Die XML-RPC Schnittstelle in WordPress dient dazu, WordPress mit externen Programmen verwalten zu können; zum Beispiel, um Artikel zu veröffentlichen oder Kommentare zu bearbeiten. Zu den Programmen gehören unter anderem die mobilen Anwendungen für iOS, Android und Co, aber auch die WordPress-Desktopanwendung.

Die Schnittstelle kann aber auch für DDoS-Angriffe genutzt werden, die dafür sorgen, dass deine Webseite lahm gelegt wird. Mit einem kurzen Eintrag in die .htaccess schaltest du die Schnittstelle komplett ab:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Diesen Eintrag solltest du allerdings nur verwenden, wenn deine Webseite keine Blog-Funktionalität hat, da auch keine Trackbacks mehr durch gelassen werden. Solltest du einen Blog betreiben oder dein WordPress mit mobilen Anwendungen betreiben wollen, nutze den folgenden Code, um die Schnittstelle abzusichern:

<IfModule mod_setenvif.c>
  <Files xmlrpc.php>
    BrowserMatch "Poster" allowed
    BrowserMatch "WordPress" allowed
    BrowserMatch "wp-iphone" allowed
    BrowserMatch "wp-android" allowed
    Order Deny,Allow
    Deny from All
    Allow from env=allowed
  </Files>
</IfModule>

Im Beispiel-Code sind Zeile für Zeile folgende Clients freigegeben:

  • Poster
  • WordPress-Blogs
  • WordPress for iOS
  • WordPress for Android

Nicht benötigte Freigaben gehören zeilenweise entfernt. Neue User-Agents können hinzugefügt und somit freigeschaltet werden.

Teil 5. PHP – Fehlermeldungen unterdrücken

Dies ist ein ganz wichtiger Punkt, denn sobald PHP eine Fehlermeldung heraus gibt, wird damit auch der Dateipfad sichtbar. Sergej Müller schreibt zu diesem Problem:

In WordPress-Blogs ist es recht simpel, einen PHP-Fehler (indirekt) zu erzeugen, um an die Fehler-Ausgabe inklusive Pfad heran zu kommen. Dafür muss man weder Administrator noch Experte sein. Durch einen direkten Aufruf bestimmter WordPress-Core- wie Plugins-Dateien in der Adresszeile des Browsers werden PHP-Fatal-Fehler generiert (weil notwendige und referenzierte WordPress-Funktionen fehlen).Erlauben Server- bzw. PHP-Einstellungen die Darstellung von Fehlern, erscheinen Fehler der Anwendung im Browser. Kaum jemand kann etwas mit der Fehlerausgabe anfangen, für Angreifer ist es jedoch eine sehr wertvolle Information, um nach Hintertüren zu suchen und diese auszunutzen.

Mit einem simplen Eintrag in der .htaccess Datei löst du das Problem:

php_flag display_errors Off

Download der kompletten .htaccess Datei

Die komplette .htaccess Datei runtergeladen (ZIP, 4kB)

Fazit

Mit dieser .htaccess Datei sind wir schon ziemlich nahe am Optimum. Die Datei ist eine hervorragende Grundlage, in der nur noch einige kleine, seitenspezifische Details ergänzt werden müssen (vermutlich). Mir und meiner Website leistet diese Datei sehr gute Dienste, und, ich hoffe stark, dir auch. Die Datei ist zudem so aufgebaut, dass es keine nervigen Probleme mehr bei Google Page Speed Insights gibt. Falls jemand von euch der Meinung ist, es gäbe da noch Verbesserungsbedarf, dann schreibe er/sie bitte einen Kommentar. Auch ich lerne gerne noch dazu :-)

Links zum Thema:

Andreas Hecht

Andreas Hecht

entwickelt WordPress-Websites und bietet dir einen Website Sicherheit Service und einen Performance Service für deine Website. Außerdem ist er Spezialist für Onpage SEO und bringt Deine Website in die Top-Suchergebnisse von Google. Auf seinem Blog schreibt er über WordPress, SEO und Content SEO.

10 Kommentare

  1. Wow! Direkt unter meinen wertvollsten Lesezeichen gespeichert. Eine Frage hätte ich allerdings. Was ist, wenn man die Datei bereits aktiviert wurde und nachträglich Änderungen erwünscht sind? FTP über den Server? Das finde ich ich weniger optimal. Denn man müsste zunächst schauen, wo diese sich befindet. Falls Ihr hier einen Tipp hättet wäre ich Euch sehr dank bar. Danke noch mal für den Tollen Beitrag!

  2. Danke, sehr interessant. Werde ich versuchen so umzusetzen!

  3. Hallo und vielen Dank! Habe 7 Tipps davon erfolgreich umgesetzt.

    Leider erhalte ich bei
    # PHP – Fehlermeldungen unterdrücken
    php_flag display_errors Off

    einen 500 internal server error.

    Sobald ich die Zeile in der .htaccess auskommentiere, funktioniert alles. (Zumindest habe ich bisher keine weiteren Fehler entdeckt ..)

    Feli

    • @Feli: Bei mir war’s das Gleiche. Ich würde den Support des Webhosts kontaktieren und die beste Methode erfragen, um die PHP-Fehlermeldung zu deaktivieren. Bei meinem Host, DomainFactory, lässt sich das z. B. erreichen, indem man im Kundenmenü die Konfigurationsdatei php.ini erstellt und darin die Fehlermeldung abschaltet. Eine Sache von fünf Minuten. Die lohnen sich – ich habe auf einer meiner WP-Sites tatsächlich schon mitbekommen, dass ein Schnüffler mittels PHP-Fehlermeldung den Pfad herausgefunden hat.

  4. Oft ist es sinnvoll, statt einer einzelnen IP besser gleich die gesamte IP-Range eines Providers zu sperren (auf “Besuch” aus Russland oder der Ukraine können die Meisten wohl verzichten).

    In diesem Fall erweist sich das Sperren über CIDR (Classless Inter Domain Routing) als nützlich, z.B.:

    deny from 188.143.128.0/17 #Russian Federation
    deny from 94.154.192.0/18 #Ukraine

  5. “Separate Htaccess schützt den Wp-Content-Ordner”

    Nach hinzufügen dieser Datei in meinen Content Ordner, wurden einige Icons und die Schriftarten auf meiner Webseite nicht mehr geladen.
    Habe deshalb diese .htacces wieder entfernt

  6. Perfekt zusammengefasst, vielen Dank. Konnte ich gerade direkt so umsetzen.

  7. Options -Indexes
    fehlt noch für die htaccess

Schreibe einen Kommentar zu Jan Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.