Was ist eine .htaccess und wie funktioniert sie?
Wer eine Website auf einem Apache-Webserver betreibt – und das ist bei Shared Hosting die große Mehrheit – hat mit der .htaccess eine direkte Schnittstelle zur Serverkonfiguration. Ganz ohne Root-Zugang, ganz ohne Serverneustart.
Der Name steht für „Hypertext Access" und die Datei selbst ist eine schlichte Textdatei. Was sie besonders macht: Sie wirkt ab dem Moment, in dem sie in ein Verzeichnis gelegt wird – und gilt automatisch auch für alle Unterordner. Der Apache-Server scannt bei jedem Seitenaufruf sämtliche Verzeichnisebenen nach einer .htaccess und wendet die gefundenen Direktiven sofort an.
Wichtig zu verstehen: Die .htaccess ist kein Allheilmittel. Für maximale Performance sollten Direktiven, die du dauerhaft benötigst, in die zentrale httpd.conf des Servers wandern – denn die .htaccess wird bei jedem Request neu ausgelesen. Für Shared-Hosting-Umgebungen ohne direkten Serverzugang ist sie aber unverzichtbar.
Der Punkt vor dem Dateinamen ist kein Zufall. In Unix-Systemen kennzeichnet er versteckte Dateien – sie werden bei normaler Verzeichnisansicht nicht angezeigt. Das schützt sie etwas vor unbeabsichtigtem Überschreiben, bedeutet aber auch: In manchen FTP-Clients musst du das Anzeigen versteckter Dateien explizit aktivieren.
Erstellen, bearbeiten und hochladen
Die .htaccess erstellst du mit jedem beliebigen Texteditor – Notepad, VS Code, Sublime. Das Prinzip ist immer gleich: neue Textdatei öffnen, Befehle eintragen, als .htaccess speichern.
Unter Windows: der typische Fallstrick
Windows interpretiert Dateinamen mit vorangestelltem Punkt anders als Linux. Explorer lässt es schlicht nicht zu, einer Datei einen Namen zu geben, der nur aus .htaccess besteht. Der Workaround: Im Texteditor „Datei speichern unter" wählen, den Dateinamen .htaccess. eingeben (mit Punkt am Ende – Windows entfernt ihn automatisch), und als Dateityp „Alle Dateien" auswählen. Alternativ: VS Code oder Notepad++ – dort funktioniert es problemlos.
Hochladen per FTP
Nach der lokalen Erstellung lädst du die Datei per FTP in das gewünschte Verzeichnis – in der Regel das Root-Verzeichnis deiner Website. Stelle im FTP-Client sicher, dass versteckte Dateien angezeigt werden, damit du kontrollieren kannst, ob der Upload erfolgreich war. Beim Transfer-Modus: ASCII, nicht Binary – das erhält die Zeilenumbrüche korrekt.
Immer Backup anlegen! Bevor du die bestehende .htaccess veränderst, lade die aktuelle Version herunter. Ein einziger Syntaxfehler kann alle Seiten des betroffenen Verzeichnisses mit einem 500 Internal Server Error lahmlegen. Mit einer gespeicherten Kopie bist du in Sekunden wieder online.
HTTPS-Zwangsweiterleitung – Sicherheit und SEO in einem
HTTPS ist seit Jahren kein Nice-to-have mehr. Google bevorzugt verschlüsselte Seiten im Ranking, Browser markieren HTTP-Seiten als „nicht sicher", und seit der DSGVO ist die Verschlüsselung der Datenübertragung auch rechtlich relevant. Die .htaccess-Weiterleitung von HTTP auf HTTPS ist deshalb eine der ersten Konfigurationen, die auf jeder Website stehen sollte.
Die zuverlässigste Methode mit mod_rewrite:
# HTTP auf HTTPS weiterleiten (301 Permanent)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Diese drei Zeilen genügen für die meisten Server. Der 301-Status signalisiert Suchmaschinen dabei: Diese Weiterleitung ist dauerhaft – übertrage alle SEO-Werte auf die HTTPS-Version.
Auf manchen Servern – etwa wenn eine Reverse-Proxy-Schicht davor sitzt – greift %{HTTPS} nicht zuverlässig. In diesem Fall hilft die alternative Bedingung:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Möchtest du anschließend prüfen, ob dein SSL-Zertifikat korrekt eingerichtet ist und ob HSTS aktiv ist, schau dir unseren kostenlosen SSL & HTTPS Checker an – er zeigt dir TLS-Version, Zertifikatslaufzeit und alle relevanten Sicherheitsparameter auf einen Blick.
Wer WordPress betreibt, findet weiterführende Hinweise zur SSL-Migration und den notwendigen WordPress-internen Anpassungen im Beitrag über die vollständige HTTPS-Umstellung für WordPress-Websites.
301-Weiterleitungen richtig einrichten
Domains wechseln, Seiten werden umbenannt, Kategorien reorganisiert – Weiterleitungen sind im Alltag eines jeden Webprojekts unvermeidlich. Die .htaccess bietet dafür zwei Ansätze: den einfachen Redirect-Befehl und den flexibleren Weg über mod_rewrite.
Einzelne Seiten weiterleiten
# Einfache Seitenweiterleitung (301)
Redirect 301 /alte-seite.html /neue-seite.html
# Auf externe Domain weiterleiten
Redirect 301 /alte-seite.html https://www.neue-domain.de/neue-seite/Gesamte Domain weiterleiten
# Kompletten Umzug auf neue Domain
RewriteEngine On
RewriteRule ^(.*)$ https://www.neue-domain.de/$1 [R=301,L]www zu non-www (oder umgekehrt)
Für eine saubere Canonical-URL-Strategie sollte deine Website konsequent eine Domain-Variante nutzen. Suchmaschinen behandeln www.example.de und example.de als zwei verschiedene URLs.
# www entfernen (non-www erzwingen)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
# www erzwingen
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]SEO-Hinweis: Nutze ausschließlich 301-Weiterleitungen für dauerhafte Umleitungen. Der 302-Status signalisiert eine temporäre Weiterleitung – SEO-Werte werden dabei nicht übertragen. Viele Webmaster machen diesen Fehler und wundern sich, warum Rankings nach einem Relaunch einbrechen.
Sicherheits-Header mit .htaccess setzen
Moderne Browser unterstützen eine Reihe von HTTP-Sicherheits-Headern, die gängige Angriffsvektoren wie Cross-Site-Scripting (XSS), Clickjacking oder unsichere Ressourcen aktiv blockieren. Per .htaccess lassen sich diese Header serverseitig für alle Antworten setzen – ohne Programmieraufwand.
# Sicherheits-Header für moderne Websites
<IfModule mod_headers.c>
# Clickjacking verhindern
Header always set X-Frame-Options "SAMEORIGIN"
# XSS-Schutz aktivieren
Header always set X-XSS-Protection "1; mode=block"
# MIME-Sniffing verhindern
Header always set X-Content-Type-Options "nosniff"
# Referrer-Datenweitergabe einschränken
Header always set Referrer-Policy "strict-origin-when-cross-origin"
# HTTPS erzwingen (HSTS) – 1 Jahr, inkl. Subdomains
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# Content Security Policy (Basis)
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
</IfModule>Diese Header sind eine der einfachsten und wirkungsvollsten Maßnahmen für die Website-Sicherheit. Wer sich um mehr als nur die Serverebene kümmert, findet in unserem Beitrag über WordPress-Sicherheit weitere Schichten des Schutzes – von der Login-Absicherung bis zur wp-config.php-Härtung.
Ob deine aktuellen Sicherheits-Header korrekt gesetzt sind, kannst du mit dem kostenlosen Security Headers Checker überprüfen – inklusive Bewertung und konkreten Verbesserungshinweisen.
Browser-Caching für bessere Ladezeiten
Statische Ressourcen – Bilder, CSS, JavaScript, Schriften – ändern sich bei den meisten Websites selten. Trotzdem lädt der Browser sie bei jedem Besuch neu, wenn kein Caching konfiguriert ist. Das kostet wertvolle Millisekunden, schadet dem PageSpeed Score und verschwendet Bandbreite auf beiden Seiten.
Per .htaccess gibst du dem Browser vor, wie lange er bestimmte Dateitypen lokal zwischenspeichern soll:
<IfModule mod_expires.c>
ExpiresActive On
# Bilder – 1 Jahr
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
# Schriften – 1 Jahr
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
ExpiresByType application/font-woff "access plus 1 year"
# CSS und JavaScript – 1 Monat
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
# HTML – kein Caching (immer aktuell)
ExpiresByType text/html "access plus 0 seconds"
</IfModule>
# Cache-Control Header ergänzend setzen
<IfModule mod_headers.c>
<FilesMatch "\.(webp|jpg|jpeg|png|gif|svg|woff2|woff)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Tipp: Cache-Busting bei CSS/JS-Updates
Wenn du CSS oder JavaScript mit langen Cache-Zeiten auslieferst, müssen Besucher bei einem Update warten bis der Cache abläuft – oder manuell leeren. Die elegante Lösung: Versionsnummern im Dateinamen oder als Query-String: style.css?v=2.1. Der Browser erkennt eine neue Datei und lädt sie frisch.
Individuelle Fehlerseiten
Die Standardfehlerseiten des Apache-Servers sind technisch korrekt, aber optisch eine Katastrophe. Ein Besucher, der auf eine nicht existierende Seite landet und eine kahle Serverfehlermeldung sieht, ist verloren. Eine eigene 404-Seite mit Suchfunktion, Navigation und einem freundlichen Hinweis hält ihn auf der Website.
# Eigene Fehlerseiten definieren
ErrorDocument 404 /404.html
ErrorDocument 403 /403.html
ErrorDocument 500 /500.html
ErrorDocument 503 /503.htmlDie Fehlerseiten selbst sind normale HTML-Dateien, die du im Root-Verzeichnis ablegst. Sie sollten keine externen Ressourcen nachladen die ebenfalls fehlen könnten – also CSS und JavaScript am besten inline einbinden oder per absoluter URL referenzieren.
Zugriffsschutz und Hotlinking verhindern
IP-basierte Zugriffsbeschränkung
Staging-Umgebungen, Administrationsseiten oder interne Tools sollten nur für bestimmte IP-Adressen erreichbar sein. Per .htaccess lässt sich das sauber lösen:
# Nur bestimmte IPs zulassen, alle anderen sperren
Order deny,allow
Deny from all
Allow from 192.168.1.100
Allow from 203.0.113.0/24Verzeichnisauflistung deaktivieren
Enthält ein Verzeichnis keine index.html oder index.php, zeigt der Apache-Server standardmäßig alle darin enthaltenen Dateien als Liste an. Das ist ein erhebliches Sicherheitsrisiko. Ein einzelner Befehl verhindert das:
# Verzeichnislisting deaktivieren
Options -IndexesHotlinking von Bildern blockieren
Hotlinking bedeutet: Eine fremde Website bindet deine Bilder direkt über deren URL ein – und du trägst die Bandbreitenkosten. Mit mod_rewrite lässt sich das effektiv verhindern:
# Hotlinking von Bildern verhindern
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?deinedomain\.de [NC]
RewriteRule \.(jpg|jpeg|png|webp|gif|svg)$ - [F,NC]Das [F] sorgt für einen 403 Forbidden – der Hotlink liefert nichts aus. Optional kannst du - durch den Pfad zu einem Platzhalter-Bild ersetzen, das stattdessen angezeigt wird.
Verzeichnisse mit Passwort schützen
Für geschützte Bereiche ohne den Aufwand eines vollständigen Login-Systems ist die HTTP Basic Authentication per .htaccess eine praktische Lösung. Sie eignet sich für Staging-Seiten, interne Dokumentationen oder temporäre Bereiche.
Du benötigst zwei Dateien: die .htaccess im zu schützenden Verzeichnis und eine .htpasswd-Datei mit den verschlüsselten Passwörtern.
# .htaccess – im zu schützenden Verzeichnis
AuthType Basic
AuthName "Geschuetzter Bereich"
AuthUserFile /absoluter/pfad/zum/.htpasswd
Require valid-userDie .htpasswd enthält Benutzernamen mit gehashtem Passwort. Niemals Klartext – das Format ist benutzername:$apr1$.... Generatoren dafür findest du online, oder du nutzt das Apache-Tool htpasswd auf der Kommandozeile.
Lege die .htpasswd idealerweise außerhalb des öffentlichen Web-Roots ab, damit sie nicht direkt über eine URL abrufbar ist.
Einschränkung beachten: HTTP Basic Authentication überträgt die Anmeldedaten Base64-kodiert – nicht verschlüsselt. Nutze sie daher ausschließlich in Kombination mit HTTPS. Ohne SSL sind Zugangsdaten im Netzwerk lesbar.
Häufige Fehler und wie du sie vermeidest
Die 6 häufigsten .htaccess-Fehler
- Syntaxfehler durch fehlende Leerzeichen – Apache ist bei der Formatierung streng. Zwischen Direktive und Wert muss ein Leerzeichen stehen, keine Tabs an falschen Stellen.
- mod_rewrite nicht aktiviert – Auf manchen Servern ist mod_rewrite deaktiviert. Wende dich an deinen Hoster oder füge
RewriteEngine Onexplizit ein. - Endlosschleife bei Weiterleitungen – Wenn Bedingungen sich gegenseitig auslösen, entsteht eine Redirect-Loop. Browser zeigen dann „ERR_TOO_MANY_REDIRECTS". Prüfe, ob deine Bedingungen die bereits weitergeleitete URL ausschließen.
- Relative statt absoluter Pfad bei AuthUserFile – Der Pfad zur .htpasswd muss absolut angegeben werden, also
/var/www/html/.htpasswd, nicht.htpasswd. - HSTS zu früh aktiviert – HSTS mit langer max-age ist schwer rückgängig zu machen. Wenn dein SSL-Zertifikat ausläuft und du nicht rechtzeitig verlängerst, ist deine Website für Besucher gesperrt. Teste HSTS zuerst mit kurzer Laufzeit.
- Zu restriktive Content Security Policy – Eine falsch konfigurierte CSP blockiert eigene Skripte und Stylesheets. Immer mit Browser-Devtools prüfen und schrittweise aufbauen.
Häufige Fragen zur .htaccess
RewriteEngine On, RewriteCond %{HTTPS} off und RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] leitest du alle HTTP-Anfragen dauerhaft auf HTTPS um. Diese drei Zeilen kommen ins Root-Verzeichnis deiner Website. Der 301-Status sorgt dafür, dass Suchmaschinen alle SEO-Werte auf die HTTPS-Version übertragen..htaccess – mit Punkt voran. Als Dateityp „Alle Dateien" wählen, damit kein .txt angehängt wird. Anschließend per FTP-Client mit ASCII-Transfermodus ins Zielverzeichnis hochladen. Wichtig: Im FTP-Client das Anzeigen versteckter Dateien aktivieren.mod_expires und korrekte Cache-Control-Header zählen zu den von Google empfohlenen Maßnahmen für bessere Core Web Vitals. Statische Ressourcen die aus dem Cache geladen werden, sparen HTTP-Requests und reduzieren die Ladezeit erheblich – besonders für Wiederholungsbesucher.