Die Website ist sowohl mit www als auch ohne www erreichbar, doch Suchmaschinen sehen zwei verschiedene Adressen mit identischem Inhalt. Seiten-Duplikate, verwässerte Linkpower, Verwirrung in der Search Console. Kommt Ihnen das bekannt vor?

Weder Grav noch WordPress lösen dieses Problem von Haus aus. Die .htaccess-Datei und genau ein Code-Block beheben alles in fünf Minuten. Nachfolgend finden Sie getestete Zeilen für Apache-Server: universell, ohne fest codierte Domains, mit HTTPS und ohne. Dazu eine Möglichkeit, die Weiterleitung über den Browser hinaus zu verifizieren.

💡 Kurzer Überblick:

• Wählen Sie eine kanonische Variante (mit www oder ohne) und ergänzen Sie eine universelle 301-Weiterleitung in der .htaccess
• Prüfen Sie die Weiterleitungskette per curl -I oder mit einem Online-Checker: Browser cachen 301er und können lügen
• Ein Code-Block löst gleichzeitig das www-Problem und erzwingt HTTPS

Warum Sie sich überhaupt zwischen www und non-www entscheiden müssen

Google bevorzugt keine der beiden Varianten; die offizielle Position ist seit Jahren unverändert. Aber Sie müssen sich für eine entscheiden und dabei bleiben. Ohne Weiterleitung werden www.site.ru/page und site.ru/page als unterschiedliche URLs indexiert, die Linkpower halbiert sich und die Analytics zählt denselben Traffic doppelt.

Wofür entscheiden? Für große Projekte ist www komfortabler: Cookies laufen nicht auf Subdomains wie cdn. und api. aus, und DNS-Einträge lassen sich einfacher konfigurieren. Für kleinere Sites gibt es kaum einen Unterschied. Orientieren Sie sich daran, was bereits indexiert ist: Geben Sie site:yourdomain.ru in die Suche ein und prüfen Sie, welche Variante häufiger in den Ergebnissen erscheint. Machen Sie diese zur kanonischen.

Technischer Hinweis: Grav generiert keine Weiterleitungen von selbst. WordPress tut dies nur, wenn siteurl in den Einstellungen explizit der gewünschten Variante entspricht, aber selbst das funktioniert inkonsistent. Die Lösung ist eine: mod_rewrite im Apache per .htaccess.

Wo die.htaccess liegt und wie Sie sie nicht beschädigen

Die .htaccess-Datei befindet sich im Wurzelverzeichnis der Site, neben index.php oder dem wp-admin-Ordner. Existiert die Datei nicht (Grav ohne fertiges Template, frisches Hosting), erstellen Sie eine Textdatei mit dem Namen .htaccess, der führende Punkt ist zwingend.

Laden Sie vor jeder Bearbeitung die aktuelle Version auf Ihren Rechner herunter. Ein Syntaxfehler in der .htaccess legt die Site sofort mit einem 500er-Fehler lahm. Eiserne Regel: eine Sicherungskopie lokal, eine weitere mit anderem Namen direkt auf dem Server (.htaccess.backup). So können Sie selbst ohne Zugang zum Admin-Panel wiederherstellen, per FTP oder über den Dateimanager des Hostings.

Für Grav und WordPress gilt dieselbe Regel: Enthält die Datei bereits RewriteEngine On, duplizieren Sie diese Zeile nicht. Fügen Sie den neuen Weiterleitungsblock danach ein. In der standardmäßigen Grav-.htaccess ist diese Zeile standardmäßig vorhanden.

301-Weiterleitung von www auf non-www: universeller Code

Der folgende Code funktioniert für jede Domain; Sie müssen example.com nicht manuell ersetzen. Praktisch, wenn Sie mehrere Sites betreuen oder Regeln zwischen Projekten übertragen. Ergänzen Sie die .htaccess nach RewriteEngine On:

1
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
2
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Zeile für Zeile: RewriteCond erfasst jeden Host, der mit www. beginnt, und speichert die Domain in Klammern. RewriteRule leitet die Anfrage auf denselben Pfad ohne www um und setzt die erfasste Domain per %1 ein. Der Flag R=301 bedeutet permanente Weiterleitung. L weist den Server an: „Stopp, keine weiteren Regeln anwenden." NC macht die Prüfung groß-/kleinschreibungsunabhängig.

Läuft die Site per HTTPS, ersetzen Sie http:// durch https:// in der RewriteRule. Besser noch: Verwenden Sie einen kombinierten Block, der sowohl www als auch HTTPS in einem Durchlauf löst:

1
RewriteCond %{HTTPS} off [OR]
2
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
3
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Die erste Bedingung greift bei HTTP-Anfragen, die zweite bei www. Wenn eine von beiden zutrifft ([OR]), geht die Anfrage an https://domain-without-www/path. Ein Block, zwei Probleme gelöst.

Umgekehrtes Szenario: von non-www auf www

Soll in der Adresszeile immer www stehen, verwenden Sie die spiegelbildliche Variante:

1
RewriteCond %{HTTP_HOST} !^www\. [NC]
2
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

Die Logik ist dieselbe, nur die Bedingung ist umgekehrt: Wenn der Host nicht mit www beginnt, fügen wir www. am Anfang hinzu. %{HTTP_HOST} setzt den aktuellen Host vollständig ein, anders als im vorherigen Block, wo wir www. per Klammererfassung entfernt haben.

Version mit HTTPS:

1
RewriteCond %{HTTPS} off [OR]
2
RewriteCond %{HTTP_HOST} !^www\. [NC]
3
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

Verwenden Sie einen der vier Blöcke, je nachdem, welcher zu Ihrer kanonischen Domain-Variante und dem Vorhandensein von HTTPS passt. Zwei Blöcke hintereinander sind unnötig und erzeugen einen zusätzlichen Hop in der Weiterleitungskette.

So überprüfen Sie, ob die Weiterleitung funktioniert

Verlassen Sie sich nicht auf den Browser; er cached 301-Weiterleitungen und zeigt selbst nach Bearbeitung der .htaccess das alte Bild. Drei Wege, um die Wahrheit herauszufinden:

• curl** -I.** Im Terminal: curl -I http://www.example.com. Eine korrekte Antwort beginnt mit HTTP/1.1 301 Moved Permanently, und der Location:-Header enthält die Ziel-URL. Prüfen Sie beide Varianten, mit www und ohne.
• Online-Checker. Redirect Checker oder HTTP Status Code Checker: URL einfügen, die vollständige Weiterleitungskette und den endgültigen Antwortcode einsehen.
• Google Search Console. Nach der Änderung der kanonischen Domain gehen Sie in die Property-Einstellungen und geben die bevorzugte Version an. Das ersetzt nicht die .htaccess, gibt der Suchmaschine aber ein zusätzliches Signal.

Ein separater Tipp für Grav: Leeren Sie nach der Bearbeitung der .htaccess den CMS-Cache über Admin → Konfiguration → Performance → Cache leeren. Grav cached Seiten aggressiv, und ohne Leerung greift die Weiterleitung für bereits generierte Kopien möglicherweise nicht.

⁉️🤔 Häufig gestellte Fragen

Welche Variante ist besser für SEO, mit www oder ohne?

Google sagt offiziell: Es gibt keinen Unterschied. Entscheiden Sie sich für eine und bleiben Sie dabei. Der entscheidende Faktor ist Konsistenz: interne Links, Sitemap und Canonical-Tags sollten auf eine Variante verweisen. Laut einer Ahrefs-Umfrage nutzen etwa 55% der Top-100-Sites die non-www-Version, aber beide Varianten ranken gleich gut.

Was passiert, wenn Sie gar keine Weiterleitung einrichten?

Suchmaschinen sehen zwei unabhängige Duplikat-Seiten. Die Linkpower teilt sich auf, Seiten konkurrieren in den Ergebnissen miteinander und Analytics-Berichte verteilen denselben Traffic auf zwei Hosts. Nach einigen Monaten das typische Bild: die Hälfte der Seiten mit www indexiert, die Hälfte ohne, Rankings instabil.

Geht es auch ohne.htaccess?

Ja, aber die Alternativen sind entweder komplexer oder langsamer. WordPress-Plugins wie Redirection und Rank Math arbeiten auf PHP-Ebene; jede Anfrage durchläuft den WordPress-Core, was Last erzeugt. Für stark frequentierte Sites ist .htaccess auf Apache-Ebene spürbar schneller. Für Grav existieren praktisch keine Weiterleitungs-Plugins, daher bleibt .htaccess der primäre Weg. Auf NGINX-Servern ist das Äquivalent die return 301-Direktive im server {}-Block.

Muss die Weiterleitung für jede Seite einzeln eingerichtet werden?

Nein, die bereitgestellten Regeln sind universell; sie gelten automatisch für alle URLs der Site. Ein Block deckt die Startseite, interne Seiten, Bilder und CSS-Dateien ab. Separate Weiterleitungen von alten auf neue URLs werden zusätzlich mit Redirect 301 /old-page /new-page-Zeilen konfiguriert, haben aber nichts mit dem www-Problem zu tun.

500er-Fehler nach Bearbeitung der.htaccess, was tun?

Kopieren Sie .htaccess.backup per FTP oder den Dateimanager des Hostings zurück; die Site ist sofort wieder erreichbar. Prüfen Sie den Code auf Tippfehler: ein fehlendes Leerzeichen, ein überflüssiger Schrägstrich, nicht passende Klammern. Fügen Sie Regeln einzeln hinzu und testen Sie nach jeder Änderung. Und bearbeiten Sie .htaccess niemals im Live-Betrieb ohne eine aktuelle Sicherung zur Hand.

Die Weiterleitung funktioniert, aber Google zeigt in den Ergebnissen weiterhin die alte Version. Warum?

Die Neuindexierung dauert von einigen Tagen bis zu ein paar Wochen. Stellen Sie sicher, dass die Canonical-Tags auf den Seiten auf die gewählte Variante verweisen und die Sitemap URLs ohne den alten Host enthält. In der Search Console können Sie über das URL-Prüftool einen erneuten Crawl anfordern; das beschleunigt den Prozess, garantiert aber keine sofortigen Ergebnisse.

Welche Variante einrichten: das kurze Fazit

Ist die Site neu, nehmen Sie non-www und HTTPS. Weniger Zeichen in der Adresszeile, leichter mündlich durchzugeben, keine Cookie-Probleme mit Subdomains. Für die meisten Projekte ist das mehr als ausreichend.

Bereits mit www indexiert? Ändern Sie nichts, was funktioniert. Richten Sie eine Weiterleitung von non-www auf www ein, aktualisieren Sie die Canonical-Tags und machen Sie weiter.

Der gesamte Ablauf: .htaccess öffnen, einen der vier oben genannten Blöcke ergänzen, den CMS-Cache leeren, per curl -I verifizieren. Fünf Minuten, und Duplikate sind aus der Suchlandschaft verschwunden. Weitere .htaccess-Techniken sind im Leitfaden zur Serverkonfiguration zusammengestellt; sehen Sie hinein, wenn Sie eine Site umfassend konfigurieren.