Domain und HTTPS für WordPress: Adressen, Zertifikate und Umleitungen

Eine WordPress-Website hat für ihre Besucher eine Adresse. Technisch können aber mehrere Varianten auf dieselbe Installation zeigen: mit oder ohne www, über HTTP oder HTTPS, manchmal zusätzlich unter einer alten Domain oder einer Vorschauadresse. Wenn diese Varianten unkoordiniert bleiben, entstehen doppelte URLs, Weiterleitungsschleifen, Probleme beim Anmelden oder Warnungen im Browser. Eine saubere Einrichtung legt deshalb eine Hauptadresse fest und stimmt Domainauflösung, Zertifikate, Webserver, WordPress und Suchmaschinenhinweise darauf ab.

Dieser Leitfaden beschreibt eine Website mit HTTPS ohne www als Hauptadresse. Das ist eine sinnvolle Konvention, aber kein allgemeiner Vorteil gegenüber einer korrekt eingerichteten www-Adresse. Entscheidend ist, dass alle beteiligten Einstellungen dieselbe Entscheidung abbilden. Vor Änderungen an einer bestehenden Installation benötigen Sie ein aktuelles Backup, Zugriff auf die Hostingverwaltung und einen Weg, die Einstellungen bei einem Fehler wiederherzustellen. Ein bloßer Zugang zum WordPress-Editor reicht für sämtliche hier beschriebenen Prüfungen nicht aus.

Domain, DNS und Hosting erfüllen unterschiedliche Aufgaben

Die Domain ist der registrierte Name. DNS beantwortet unter anderem die Frage, an welche Serveradresse eine Anfrage für diesen Namen gehen soll. Das Hosting nimmt die Anfrage entgegen und ordnet sie einer Website zu. Diese drei Ebenen können bei verschiedenen Unternehmen liegen. Der Umzug einer Website bedeutet deshalb nicht automatisch einen Domaintransfer, und eine Änderung der Webserveradresse bedeutet nicht automatisch, dass Ihre E-Mails künftig woanders ankommen sollen.

Die vier Adressvarianten bilden den frühen Prüfplan für eine Hauptadresse mit HTTPS ohne www. Die Tabelle beschreibt Sollzustände für eine Unterseite, keine behaupteten Messergebnisse.

Die Tabelle lässt sich seitlich verschieben.

1. 1Domain und DNS prüfen
2. 2Beide Namen zertifizieren
3. 3Hauptadresse in WordPress setzen
4. 4301 mit Pfad und Query prüfen
5. 5Canonical und Sitemap abgleichen

Für die Hauptdomain und www prüfen Sie die für den Webzugriff relevanten DNS-Einträge. Ein A-Eintrag verweist auf eine IPv4-Adresse, ein AAAA-Eintrag auf eine IPv6-Adresse. www kann über einen eigenen Adresseintrag oder einen CNAME eingerichtet sein.

Falls ein AAAA-Eintrag auf einen alten Server zeigt, kann die Website bei manchen Besuchern funktionieren und bei anderen falsch ankommen. Das wirkt zufällig, ist aber eine unterschiedliche Auswahl des Netzwerkwegs. Vergleichen Sie deshalb beide Adressfamilien mit der tatsächlich vorgesehenen Hostingumgebung.

Für die technische Grundlage hilft der Leitfaden zur WordPress-Hosting-Auswahl: Er trennt veröffentlichte Anforderungen von den im eigenen Paket tatsächlich verfügbaren Funktionen.

Mailbezogene Einträge wie MX, SPF, DKIM und DMARC haben einen eigenen Zweck. Bei einem Websiteprojekt lassen Sie sie unverändert, wenn keine Mailmigration geplant ist. Auch andere Subdomains dürfen nicht versehentlich verschwinden. Wer die komplette DNS-Zone durch eine voreingestellte Vorlage ersetzt, kann beispielsweise Kalenderdienste, externe Versanddienste oder eine bestehende Mailplattform unterbrechen. Erstellen Sie vor einer Änderung eine Übersicht der vorhandenen Einträge und notieren Sie ausdrücklich, welche davon zum aktuellen Auftrag gehören.

Die Hauptadresse vor der Installation festlegen

Schreiben Sie die gewünschte Hauptadresse vollständig auf, beispielsweise https://example.de. Dazu gehören das Protokoll und die Entscheidung über www. Prüfen Sie außerdem, ob WordPress im Domainhauptverzeichnis oder unter einem Unterverzeichnis installiert werden soll. Eine Firmenwebsite unter / und eine zusätzliche Wissensdatenbank unter /wissen/ können bewusst getrennte Anwendungen sein. Ein versehentlich doppelt verwendetes Verzeichnis erzeugt dagegen Konflikte mit vorhandenen Dateien und Weiterleitungen.

In einer Hostingverwaltung suchen Sie zuerst nach der Domain und einem bereits vorhandenen Abonnement. Öffnen Sie die zugeordnete Dokumentwurzel und prüfen Sie, ob dort eine bestehende Website liegt.

Eine neue Installation darf diese nicht überschreiben. Ist der Name bereits vorhanden, aber für eine andere Nutzung eingerichtet, braucht es eine geklärte Zuordnung. Eine Datenbank mit ähnlichem Namen ist ebenfalls kein Beweis dafür, dass sie frei verwendet werden kann. Die sichere Entscheidung basiert auf Domain, Verzeichnis, Anwendung und Verantwortlichem zusammen.

Bei einem neuen Projekt richten Sie Hauptdomain und www derselben Website zu. www dient anschließend als alternative Eingangsadresse und wird dauerhaft zur Hauptadresse weitergeleitet. Interne Menüs und redaktionelle Links verwenden von Beginn an die Hauptvariante. Dadurch müssen Besucher innerhalb der Website nicht bei jedem Seitenwechsel erneut umgeleitet werden. Dieselbe Schreibweise sollte auch in Drucksachen und neu angelegten Profilen verwendet werden, soweit Sie deren Adressen selbst kontrollieren.

Warum das Zertifikat auch www abdecken muss

HTTPS beginnt mit einer verschlüsselten Verbindung und der Prüfung des Serverzertifikats. Erst danach kann der Server eine normale HTTP-Antwort mit einer Weiterleitung senden. Ruft jemand https://www.example.de auf, muss deshalb bereits für www ein gültiges Zertifikat vorliegen. Eine korrekt formulierte Weiterleitung auf https://example.de beseitigt keinen Zertifikatsfehler, der vor dieser Weiterleitung entsteht. Besucher sehen sonst eine Warnung, obwohl die endgültige Zieladresse grundsätzlich richtig eingerichtet ist.

Let’s Encrypt beschreibt verschiedene Verfahren, mit denen die Kontrolle über einen Domainnamen nachgewiesen wird. Bei HTTP-01 muss eine bestimmte Prüfdatei über den Webzugriff erreichbar sein. DNS-01 verwendet einen speziellen TXT-Eintrag und kann für andere Szenarien, etwa Wildcards, erforderlich sein. Das Zertifikat wird nicht allein deshalb ausgestellt, weil die Domain gekauft wurde. Fehlerhafte DNS-Ziele, Zugangssperren oder eine unpassende Serverzuordnung können die Validierung verhindern. Die konkrete Hostingintegration sollte diesen Ablauf nachvollziehbar anzeigen.

Ausstellung und automatische Verlängerung prüfen

Nach der Ausstellung öffnen Sie beide HTTPS-Adressen ohne eine Ausnahme für Zertifikatswarnungen. Prüfen Sie die Namen im Zertifikat, die Gültigkeitsdaten und die vollständige Zertifikatskette. Das Browsermenü zur Verbindungssicherheit hilft bei einer ersten Kontrolle. Eine Ausnahme dauerhaft zu speichern ist keine Reparatur. Ein selbstsigniertes Zertifikat kann in einer internen Testumgebung bewusst eingesetzt werden, ist für eine öffentliche Informationswebsite aber kein Ersatz für ein regulär vertrauenswürdiges Zertifikat.

Die automatische Verlängerung benötigt einen dauerhaft funktionierenden Validierungsweg. Eine Vorschau mit Passwortschutz kann mit dem Verfahren des Hosters vereinbar sein, wenn die Zertifikatsprüfung auf Serverebene passend behandelt wird. Das darf nicht vorausgesetzt werden. Lassen Sie sich zeigen, wann die nächste Verlängerung vorgesehen ist und ob Fehler gemeldet werden. Ein gültiges Zertifikat am Tag der Abnahme beweist noch nicht, dass die Verlängerung nach einer späteren Umstellung von DNS oder Zugriffsschutz funktioniert.

Ein sinnvoller Betriebsvermerk hält fest, welcher Dienst das Zertifikat verwaltet, welche Namen enthalten sind und wer bei einer fehlgeschlagenen Verlängerung reagiert. Zugangsschlüssel für automatisierte DNS-Verfahren gehören in geschützte Zugangssysteme, nicht in einen Artikel, eine öffentlich erreichbare Sicherungsdatei oder das WordPress-Medienarchiv. Bei mehreren Websites ist es besonders wichtig, Verlängerungsprobleme einem konkreten Zertifikat zuordnen zu können, statt nur eine allgemeine Meldung über den Server zu erhalten.

WordPress-Adresse und Website-Adresse richtig verstehen

WordPress unterscheidet die Adresse seiner eigenen Dateien und die Adresse, unter der Besucher die Website aufrufen. In einer üblichen Installation im Hauptverzeichnis sind beide Werte identisch und lauten beispielsweise https://example.de. Bei einer bewusst eingerichteten Installation in einem eigenen Unterverzeichnis können sie unterschiedlich sein. Ändern Sie diese Werte deshalb erst, nachdem Sie die tatsächliche Verzeichnisstruktur verstanden haben. Eine falsche Adresse kann den Verwaltungszugang auf einen Ort umleiten, an dem keine Installation erreichbar ist.

Die offizielle WordPress-Dokumentation erläutert mehrere Wege zur Korrektur, darunter Einstellungen in der Datenbank und festgelegte Werte in der Konfiguration. Solche Eingriffe sind Wiederherstellungswerkzeuge und sollten mit einer Sicherung erfolgen. Schreiben Sie vor einer Änderung beide bisherigen Werte auf und testen Sie zunächst auf einer Kopie, wenn die Website bereits produktiv arbeitet. Hinter einem Reverse Proxy oder einer vorgelagerten Plattform muss WordPress außerdem richtig erkennen, ob die ursprüngliche Anfrage über HTTPS kam.

Für den normalen Redaktionsalltag ist ein einheitlicher Einstieg hilfreich: ein Lesezeichen zur Verwaltungsadresse unter der Hauptdomain, eine dokumentierte Loginadresse und keine wechselnden Zugänge über Servernamen. Cookies und Sitzungen beziehen sich auf Adresskontexte. Wenn Verwaltungsseiten zwischen www und Hauptdomain pendeln, kann ein scheinbar falsches Passwortproblem in Wahrheit eine uneinheitliche Weiterleitung sein. Prüfen Sie daher bei Loginproblemen zuerst die tatsächlich angezeigte URL und die Reaktion des Servers, bevor Sie Benutzerkonten mehrfach verändern.

Dauerhafte Umleitungen mit Pfad und Query einrichten

Eine permanente Umleitung teilt dem Browser mit, dass die bisherige Adresse dauerhaft an eine andere Stelle führt. Für die hier geplante Normalisierung verwenden Sie 301. Der Webserver sollte jede alternative Variante möglichst direkt zur vollständigen Hauptadresse führen. Aus http://www.example.de/ratgeber/?thema=backup wird https://example.de/ratgeber/?thema=backup. Der Pfad /ratgeber/ und der Queryparameter thema=backup bleiben erhalten. Eine pauschale Weiterleitung sämtlicher Anfragen zur Startseite würde diese Information verlieren.

Die Regel gehört an die passende Stelle der Hostingkonfiguration. In Plesk, einem Webserver und einem WordPress-Plugin gleichzeitig ähnliche Regeln einzubauen, erschwert die Fehlersuche. Legen Sie fest, welche Ebene für HTTPS und die Hauptdomain verantwortlich ist. WordPress kann darüber hinaus seine eigenen Permalinks normalisieren. Diese Aufgaben müssen zusammenpassen. Eine vorgeschaltete Plattform, die HTTPS beendet, benötigt eine andere Erkennung als ein Server, der HTTPS direkt verarbeitet; blind kopierte Regeln können dadurch Schleifen auslösen.

Testen Sie mindestens die vier Kombinationen aus HTTP oder HTTPS und Hauptdomain oder www. Fügen Sie jeweils einen vorhandenen Unterpfad und einen harmlosen Queryparameter hinzu. Bei der Hauptadresse erwarten Sie den Inhalt ohne unnötige Umleitung; bei Alternativen die permanente Weiterleitung auf denselben Inhalt. Nutzen Sie für die Kontrolle ein frisches Browserfenster und gegebenenfalls eine technische Headerprüfung, weil Browser 301-Antworten zwischenspeichern können. Ein alter gespeicherter Zustand kann sonst eine korrigierte Regel verdecken.

Bestehende Links und Medienadressen bereinigen

Bei der Umstellung einer älteren Website genügt die Änderung der beiden Grundeinstellungen häufig nicht. Inhalte, Menüs, Widgets, Themeoptionen und Plugins können vollständige alte URLs gespeichert haben. Diese Verweise müssen gezielt geprüft werden. Eine Weiterleitung hilft zwar bei einem alten Link, verursacht aber eine zusätzliche Anfrage. Bei eingebundenen Ressourcen kann eine falsche Adresse außerdem Sicherheitsprobleme oder Darstellungsfehler auslösen. Suchen Sie deshalb nach dem alten Protokoll, der alten www-Variante und gegebenenfalls nach einer ehemaligen Vorschauadresse.

Nach einer Bereinigung leeren Sie die betroffenen Caches und kontrollieren repräsentative Seiten. Dazu gehören Seiten mit Galerien, eingebetteten Dateien und besonderen Inhaltsblöcken. Wenn ein Theme Dateien erst nach einer Neuberechnung seiner Einstellungen erzeugt, muss dieser Schritt ebenfalls erfolgen. Bewahren Sie eine wiederherstellbare Sicherung vor der Bereinigung auf. Eine Liste der vorgenommenen Änderungen hilft später zu unterscheiden, ob eine fehlende Datei bereits vor der HTTPS-Umstellung beschädigt war oder durch die neue Konfiguration entstand.

Mixed Content an seiner Ursache beheben

Mixed Content entsteht, wenn eine über HTTPS geladene Seite Ressourcen über unverschlüsseltes HTTP anfordert. Das kann ein Bild, ein Skript, eine Schrift oder ein eingebetteter Inhalt sein. Browser behandeln verschiedene Ressourcentypen unterschiedlich und können Anfragen aktualisieren oder blockieren. Verlassen Sie sich deshalb nicht darauf, dass ein einzelner Browser die Seite optisch noch richtig anzeigt. Kontrollieren Sie die Entwicklerkonsole und die tatsächlich angeforderten URLs, damit der Fehler auch auf anderen Geräten verschwindet.

Liegt die Ressource auf Ihrer eigenen Website, korrigieren Sie die gespeicherte Adresse und prüfen Sie den neuen Abruf. Bei einem externen Dienst muss dieser eine passende HTTPS-Adresse anbieten. Ist das nicht der Fall, ersetzen oder entfernen Sie die Einbindung. Ein Plugin, das sämtliche sichtbaren URLs beim Ausliefern überschreibt, kann Symptome kaschieren, während fehlerhafte Daten weiterhin gespeichert bleiben. Für eine dauerhaft gepflegte Website ist die Korrektur an der Herkunft der Adresse meist besser nachvollziehbar.

Ein fehlendes Video nach einer Umstellung kann andere Ursachen haben als ein Zertifikat. Prüfen Sie neben der Browserwarnung auch Datenschutzblockaden, Dateiberechtigungen und eine möglicherweise geänderte Einbettungsadresse. Die Reihenfolge spart Arbeit: zuerst die konkrete fehlerhafte Anfrage ansehen, dann ihre Quelle bestimmen, schließlich genau diese Quelle korrigieren. Eine vollständige Neuinstallation von WordPress oder ein Wechsel des Themes wäre für einen einzelnen unsicheren Medienlink ein unnötig großer Eingriff.

Canonical, Sitemap und interne Verlinkung abstimmen

Ein Canonical-Hinweis nennt Suchmaschinen die bevorzugte Adresse eines Inhalts. Er ersetzt keine technische Weiterleitung und ist keine garantierte Anweisung. Für eine normale Detailseite verweist er auf deren eigene vollständige Hauptadresse. Eine Domainnormalisierung ist widersprüchlich, wenn der Server auf die Hauptdomain umleitet, die Seite aber weiterhin www als Canonical ausgibt. Prüfen Sie daher die tatsächlich ausgelieferte Seite und nicht nur eine Einstellung im SEO-Plugin.

Auch die Sitemap verwendet die Hauptadresse und enthält nur die vorgesehenen öffentlichen URLs. Interne Links sollten direkt auf diese URLs zeigen. Wenn zwei Plugins unterschiedliche Sitemaps oder Canonical-Tags erzeugen, schaffen Sie eine eindeutige Zuständigkeit. Kontrollieren Sie eine Tarifseite, einen Ratgeber und eine Übersichtsseite, weil unterschiedliche Vorlagen verschiedene Metadaten erzeugen können. Hinweise zur gesamten Inhaltsstruktur finden Sie im Ratgeber zur SEO für KI-erstellte Websites.

Eine geschützte Entwicklungsfassung bleibt bis zur Freigabe von der öffentlichen Indexierung fern. Ein robots.txt-Verbot allein ist kein Zugriffsschutz. Ein Passwortschutz verhindert, dass beliebige Besucher den Entwurf lesen können; zusätzliche Indexierungshinweise unterstützen die technische Abgrenzung. Vor der Veröffentlichung prüfen Sie bewusst, welche Schutzmechanismen entfernt werden und welche bleiben. Die Freigabe eines anderen Projekts ist dafür keine Freigabe. Domain, Inhalte und verantwortliche Entscheidung müssen zum konkreten Websiteprojekt gehören.

HSTS erst nach einer stabilen HTTPS-Einrichtung erwägen

HSTS ist ein Sicherheitsheader, der Browsern mitteilt, die Domain für eine bestimmte Zeit nur über HTTPS aufzurufen. Er kann die konsequente Verwendung verschlüsselter Verbindungen unterstützen. Die Entscheidung beeinflusst aber auch die Fehlerbehebung: Ein Browser, der die Vorgabe gespeichert hat, lässt sich nicht einfach durch eine Rückkehr zu HTTP auf eine vorübergehende Ersatzseite führen. Nutzen Sie HSTS deshalb erst, wenn Zertifikate, Umleitungen und die automatische Verlängerung zuverlässig funktionieren.

Die Option includeSubDomains erstreckt die Vorgabe auf Subdomains. Das kann unerwartet alte Anwendungen oder separate Dienste betreffen. Prüfen Sie daher das gesamte relevante Namensinventar, bevor Sie diese Option aktivieren. Eine Aufnahme in eine Preloadliste ist ein weiterer eigener Schritt mit langfristigen Folgen und gehört nicht beiläufig in eine Standardinstallation. Für die Grundfunktion einer Website sind ein gültiges Zertifikat und eine richtig getestete HTTPS-Weiterleitung zunächst die entscheidenden Bausteine.

Abnahme und laufende Kontrolle dokumentieren

Auch Fehlerseiten und besondere Anfragen testen

Erweitern Sie den Prüfplan um einen absichtlich nicht vorhandenen Pfad. Ein Aufruf von http://www.example.de/nicht-vorhanden/ soll zunächst auf dieselbe Hauptadresse umgeleitet werden und dort eine passende Fehlerantwort liefern. Wenn stattdessen die Startseite mit einer Erfolgsmeldung erscheint, werden verlorene Seiten schwerer erkennbar. Besucher brauchen eine verständliche Fehlerseite mit hilfreicher Navigation; Suchmaschinen benötigen den dazu passenden Status. Eine Domainweiterleitung darf deshalb nicht pauschal jeden unbekannten Pfad als gültige Startseite behandeln.

Queryparameter dienen unterschiedlichen Zwecken. Ein Suchbegriff, ein Filter oder ein freigegebener Kampagnenparameter kann für das Ziel relevant sein und bleibt bei der Normalisierung erhalten. Ob eine konkrete Parameterseite selbst indexierbar sein soll, ist eine separate redaktionelle und technische Entscheidung. Das lässt sich nicht zuverlässig durch das pauschale Entfernen aller Parameter in der www-Weiterleitung lösen. Schreiben Sie für komplexere Websites auf, welche Parameter Funktionen steuern und welche lediglich die Herkunft eines Besuchs dokumentieren.

Bei Formularen und Programmierschnittstellen ist außerdem die Anfragemethode wichtig. Eine permanente 301-Weiterleitung kann bei manchen Clients eine ursprünglich gesendete POST-Anfrage in eine GET-Anfrage umwandeln. Für solche Anwendungen müssen Entwickler den gewünschten Ablauf gesondert prüfen; eine methodenerhaltende Weiterleitung kann dort erforderlich sein. Der hier beschriebene 301-Plan bezieht sich auf normale Seitenaufrufe. Bestehende Zahlungsrückmeldungen, Webhooks oder Schnittstellen dürfen nicht ungeprüft durch eine neue allgemeine Regel umgeleitet werden.

Testen Sie schließlich Downloads und Bilder, deren URLs außerhalb von WordPress verlinkt sein können. Eine Broschüre unter einem alten www-Link sollte weiterhin an der korrekten Stelle abrufbar sein. Ein Download, der nun Anmeldung verlangt, ist kein erfolgreicher öffentlicher Umleitungsfall. Die Prüfung mit abgemeldeten Browsern zeigt diesen Unterschied. Für geschützte Dokumente gilt dagegen der vorgesehenen Zugriffsschutz; eine Domainnormalisierung darf ihre Berechtigungen nicht verändern. So bleibt die Abnahme auf die tatsächlichen Aufgaben der Website bezogen.

Nach Änderungen an Hosting, DNS, Proxy oder Cache wiederholen Sie die betroffenen Prüfungen. Überwachen Sie außerdem den Ablauf des Zertifikats und kontrollieren Sie eine gemeldete Verlängerungsstörung zeitnah. Für die Rückkehr nach einer fehlerhaften Änderung brauchen Sie die gesicherte Konfiguration und ein verwendbares Backup; dazu gehört der Plan zur WordPress-Wiederherstellung. Die übrige WordPress-Sicherheit bleibt eine eigene Aufgabe, denn HTTPS schützt den Übertragungsweg und korrigiert keine unsicheren Plugins oder gestohlenen Zugänge.