Wozu ist die .htaccess? In dieser Datei sind die Regeln zur Konfiguration für den Server, ebd. des namens Apache. WordPress speichert hier die Anweisungen, die für die URL-Struktur zuständig ist. Ebenso für die Sicherheit und die Ladezeit der Website gibt es Regeln für die .htaccess Datei. – sofern diese nicht schon vom Host optimiert sind.

Das Thema .htaccess mit Vorbehalt. Fachleute sicher einiges zur Optimierung meines Artikels wie evtl. Berichtigung beitragen können. Originär @Bego von WordPress.org Support: „Deine .htaccess enthält einige sinnvolle Einstellungen; einige davon dürften aber auch nicht auf jedem Server sinnvoll sein.“

S. gleich mal .htaccess – Einführung. Es geht hier um das Verständnis zu Funktionsrelationen.

Für firmen Internetsurfer allgegenwärtig, nämlich die Autoren:

Die Artikel von AH  (Dr.Web) und DK (FastWP) stellen durchgehende Info, dessen sind hier „Funktion der Befehle (Snippets)“ als Merkzettel beinhaltet.

Die
🎼 h’t-a-cc-e-ss Datei – , so-in-etwa: h’t-ac’cess Datei, wie ht.access, im Slogan auch „ha’tǝ-datei“. Also, .htaccess (engl. hypertext access „Hypertext-Zugriff“).

Grundlegend:

Wo am Server gehört die .htaccess eingepflegt?

marc bei Dr.Web: Hallo, wenn meine WordPress-Installation in einem Unterverzeichnis liegt, z.B. /wordpress, lege ich die .htaccess dann dort rein oder in das Server-Rootverzeichnis / (und dann zusätzlich auch nochmal in /wordpress?)

Antwort AH: Die .htaccess muss immer in das Rootverzeichnis der WordPress-Installation. Also dahin, wo die Ordner wp-content, wp-admin, wp-includes liegen. Wenn eine Ebene höher dann ein weiterer Ordner /Beispiel mit einer anderen .htaccess liegt, hat das keine Auswirkungen.

Meine Anmerkung: Wenn die .htaccess eine Ebene höher ist als der „wordpress“ Ordner, also die .htaccess nicht in einem anderen Ordner, sondern im Serverrootverzeichnis liegt, ist diese für alle unteren Ordner wirksam (Beispiels die 6G Firewall wäre somit ab dem Serverrootverzeichnis für alle Unterordner wirksam). Diese .htaccess ist auch mit #Beginn WordPress … End WordPress zu erstellen. Weitere .htaccess erstellt sich von selbst im Root vom Ordner „wordpress“ mit #Beginn WordPress … #End WordPress – inwieweit dies und was zur Funktioalität gereicht, wäre auszuprobieren (s. Plug-in BBQ und 6G Firewall in .htaccess ⇔ dort Info Button anklicken).

Safety und speed: die optimale .htaccess

Eine optimale Kurzbeschreibung zum Thema finde ich im Titel „WordPress: Die optimale .htaccess“  mithin Beitrag von Carsten D. schließt mit den Worten: „Es muss ja nicht jeder das Rad immer wieder neu erfinden“, und auf die  .htaccess von AH leitet.

Die sog. ultimative* WordPress .htaccess
nach FastWP

* d. h. endgültig definitive (2018)

Meines Artikel versuche ich die ultimative .htaccess u. ff. nach FastWP aufzuschlüsseln, um ein wenig die Funktionsrelationen zu verstehen.

 Browser Caching – Performance  
 WP-Sicherheit 

Beginn zur .htaccess Datei hier folgenden Link: fastwp.de, gerade ist des Links auf den ersten Hinweis betreffs eigenen URL-Namen in <IfModule mod_rewrite.c> zu achten.

.htaccess

# GZIP
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>

<IfModule mod_headers.c>
Header append Cache-Control "public"
Header append Vary Accept-Encoding
Header set Connection keep-alive
Header unset ETag
FileETag None
</IfModule>

# CACHING
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} \.(jpg|jpeg|png|gif|ico|css|js)$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?fastwp\. [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?feedly\. [NC]
RewriteRule \.(jpg|jpeg|png|gif|ico|css|js)$ - [F,NC,L]
</ifModule>

# 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

Obige .htaccess-Datei aufschlüsseln

# GZIP IfModule mod_deflate.c und # CACHING mod_headers.c + (Browser Cache) IfModule mod_expires.c, siehe Browser-Cache richtig konfigurieren, fastwp.de.

• Zum Bowser-Cache passt evtl. diese Plug-in-Empfehlung: fastwp.de (Busted: Browser-Cache Reload erzwingen).

IfModule mod_rewrite.c „Hotlinking verbieten“, fastwp.de. Tool zum Überprüfen, und interner Hinweis zum Titel Hotlinking verbieten vs. Translation Website hapert Visualisierung darf nicht fehlen.

Nachfrage Host-Support

Erlaubt bitte die Durchsicht zur .htaccess anzufragen: inwiefern dies zu performen Funktioalität gereicht, oder ob man welches weglassen sollte.

Die Antwort:

… also generell würde ich Caching erst gar nicht benutzen, das mag manchmal helfen, oftmals hat es aber auch negative Auswirkungen. Unsere Systeme sind sicherlich auch so schnell genug.

deflate ist bereits soweit gesetzt und nicht nötig, der Rest kann bleiben und ist wohl WP-Standard. Hinsichtlich HTTP2 muss man nichts dazu optimieren, da tun wir schon alles machbare :)

↑ Inhalsverz. 

… und des Weiteren:

Dies stellt eine Übersicht für Gebrauch spezifischen Anforderungen.

Cache-Control Headers nutzen

 Browser Caching – Performance 

Cache-Control Headers nutzen, diesen Codes fastwp.de (im obigen Bereich).

.htaccess

<IfModule mod_headers.c>

<filesMatch ".(jpg|jpeg|png|gif|ico)$">
Header set Cache-Control "max-age=31536000, public"
</filesMatch>

<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>

Header set Cache-Control "max-age=3600, public"

</IfModule>

Fonts: Caching und Komprimierung

 Browser Caching und Komprimierung – Performance  

Für selbst gehostete Webfonts, hierzu Punkt drei nach fastwp.de

.htaccess

AddType font/ttf .ttf
AddType font/otf .otf
AddType font/woff .woff

ExpiresByType font/ttf "access plus 1 year"
ExpiresByType font/otf "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"

AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/woff

XML-RPC deaktivieren + XML-RPC aus dem HTTP-Header entfernen

 WP-Sicherheit  und   Performance 

Hierzu separater Beitrag in WordPress absichern.

Für die htaccess-Datei bleibt dessen Zusammenhangs:

.htaccess

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

↑ Inhalsverz. 

Schutz vor Script Injections Options +FollowSymLinks

 WP Sicherheit 

fastwp.de

Originär: Betrifft GET- und POST-Anfragen, welche meist sorgfältig geschützt sind, aber was ist mit den GLOBALS und _REQUEST-Variablen? Die werden meistens nicht sunderlich behandelt, weshalb folgender Befehl in der .htaccess für mehr Sicherheit sorgt. Dieser blockt Script Injections und Versuche, die entsprechenden Variablen zu verändern.

.htaccess

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Bemerkung: Dieses Snippet Options +FollowSymLink in der .htaccess-Datei Server-Rootverzeichnises erfolgt meiner Website ein Server-Error, wie ebenso in Ordner „wordpress“ befindlichen .htaccess-Datei ungeeignet, da zwar kein Error erfolgt, aber das jQuery Accordion Menü ungeeignet dargestellt ist –. des Letzterem logo.

Dateien wp-config.php und .htaccess vor Zugriff schützen

 WP-Sicherheit 

fastwp.de

Wichtige Dateien vor fremden Zugriff zu schützen. Die „wp-config.php“ und die „.htaccess“ sind wichtige Dateien, die man mit folgendem Befehl absichern kann:

.htaccess

# Dateien vor Zugriff schützen
<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>

<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>

<files readme.html>
Order Allow,Deny
Deny from all
</Files>

↑ Inhalsverz. 

Ordneransicht verbieten

 WP-Sicherheit 

Durchsuchen von Verzeichnissen deaktivieren.

Hier am Host „bplaced-Server“ nicht als „Options All -Indexes“, wie es meist empfohlen ist:

.htaccess

Options -Indexes

… ist funktionell.

WP Content schützen mit eigener .htaccess-Datei im Ordner „wp-content“

 WP-Sicherheit 

Für potenzielle Angreifer gibt es weitere Schlupflöcher. Dies kann auch im Ordner „wp-content“ geschehen, weshalb diese eigene .htacess-Datei erhalten sollte, welche selbst erstellt werden muss.  Des Ordners wp-content Problem ist, dass auch Plugins etc. auf Dateien zugreifen dürfen.

Auf Bilder, xml, sowie CSS-Dateien darf mit folgenden Befehl  weiterhin zugegriffen werden, alle anderen Anfragen werden geblockt. Das kann Uneinsichts Probleme verursachen, je nachdem welche Erweiterungen innerhalb von WordPress genutzt werden.

Ordner wp-content .htaccess

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

Bemerkung: Im Ordner „wp-content“ entsprechende .htaccess mit dessen Snippet funktioniert im Gesamten das „jQuery Accordion Menü“ nicht! – d. h. auch ohne js usw.

XXS Security, nosniff und mehr

 WP-Sicherheit 

Nächst, informativ: Punkt 7. Datei-Bearbeitung verhindern: fastwp.de. Der Link ist nicht mehr aktiv!

Um einfache XXS-Attacken abzuwehren, Clickjacking zu verhindern und ähnliches. Ein kleiner Rundumschutz:

.htaccess

# XXS Security, nosniff und mehr
<ifModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options: "nosniff"
</ifModule>

# WP-Include Dateien blocken
<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>

Block Bad Queries (BBQ) Plug-in

 WP-Sicherheit 

Siehe WordPress absichern – Entsprechendes in die .htaccess oder (besser, FastWP) das Plug-in anwenden.

↑ Inhalsverz. 

---

SEO

Implementierung von X-Robots-Tag mit Apache
für pdf-Dateien und Bilder

Das X-Robots-Tag kann man den HTTP-Antworten einer Website hinzufügen. Hierzu ist die .htaccess– und httpd.conf-Dateien zu verwenden (standarts auf Apache-basierten Webservern). Die Verwendung eines X-Robots-Tags in Verbindung mit HTTP-Antworten hat den Vorteil, dass Crawling-Anweisungen angeben werden, die für die gesamte Website gelten. Die Unterstützung regulärer Ausdrücke ermöglicht Flexibilität.

Wer zum Beispiel das X-Robots-Tag noindex, nofollow für alle PDF-Dateien auf einer Website der HTTP-Antwort hinzufügen möchte, folgende Snippet in die .htaccess- oder httpd.conf-Stammdatei der Website einfügen:

.htaccess

Files ~ "\.pdf$">
 Header set X-Robots-Tag "noindex, nofollow"
</Files>

Das X-Robots-Tag bei Nicht-HTML-Dateien wie z. B. Bilddateien kann man anwenden, bei denen die Verwendung von Robots-Meta-Tags nicht möglich ist. Beispiel für das Hinzufügen einer noindex-X-Robots-Tag-Anweisung für PNG-, JPEG-, JPG- und GIF-Bilddateien auf einer ganzen Website.

.htaccess

Files ~ "\.(png|jpe?g|gif)$">
 Header set X-Robots-Tag "noindex"
</Files>

Siehe, Google Search: Spezifikationen.

↑ Inhalsverz.