Zum Inhalt springen 
WordPress HTTPS schützt Anmeldedaten, Kontaktformulare und Cookies und hilft mir, Ranking und Conversion zu steigern. In dieser Anleitung zeige ich dir den kompletten Wechsel von HTTP auf HTTPS in WordPress – mit Zertifikat, URL‑Umstellung, 301‑Weiterleitungen, Mixed‑Content‑Fix und sauberen SEO‑Schritten.
Zentrale Punkte
- SSL korrekt aktivieren und Domain abdecken
- URLs in WordPress umstellen
- 301 Weiterleitungen erzwingen
- Mixed Content gezielt beheben
- SEO nachziehen und prüfen
Warum HTTPS für WordPress zählt
Ohne Verschlüsselung können Angreifer Sessions kapern oder Formulare auslesen, daher sichere ich die gesamte Übertragung zwischen Browser und Server mit TLS ab. HTTPS verhindert Warnhinweise im Browser, erhöht das Vertrauen und stärkt Signale, die Suchmaschinen positiv bewerten. Viele APIs, Zahlungsdienste und Browser‑Features benötigen ohnehin sichere Verbindungen. Zudem profitiere ich von HTTP/2 bzw. HTTP/3, die unter TLS schneller laden und Parallelisierungen ermöglichen. Ein sauberer Wechsel auf HTTPS beugt Duplicate‑Content vor, weil ich alle Varianten auf eine eindeutige Kanone (Canonical) lenke.
Backup und SSL‑Zertifikat vorbereiten
Bevor ich Einstellungen anfasse, sichere ich Dateien und Datenbank vollständig, damit ich jederzeit zur Sicherung zurückkehren kann. Danach bestelle oder aktiviere ich ein Zertifikat – häufig reicht Let’s Encrypt ohne Zusatzkosten, alternativ nehme ich ein DV/OV/EV‑Zertifikat je nach Anforderung. Viele Hoster stellen einen Assistenten bereit, der Zertifikate automatisiert ausstellt und verlängert. Falls du eine Schritt‑für‑Schritt‑Hilfe brauchst, nutze dieses Tutorial zum kostenlosen SSL einrichten. Ich prüfe danach, ob die Zertifikatskette vollständig ist und ob sowohl www‑ als auch Apex‑Domain (ohne www) durch das Zertifikat abgedeckt sind; Subdomains wie staging oder cdn berücksichtige ich ebenfalls und halte ihre Gültigkeit im Blick.
Zertifikatswahl und Schlüssel-Management
Über die erste Aktivierung hinaus beachte ich einige Details, die in vielen Anleitungen fehlen: Benötige ich ein Wildcard‑Zertifikat (*.domain.tld) für viele Subdomains oder reicht ein SAN‑Zertifikat mit mehreren expliziten Hostnamen? Für Performance setze ich, wo möglich, auf ECDSA‑Zertifikate (elliptische Kurven) statt klassischer RSA‑Schlüssel – sie sind kleiner und beschleunigen den TLS‑Handshake. Den privaten Schlüssel schütze ich streng (Dateirechte 600, nur Servernutzer), und ich dokumentiere die Renewal‑Kette: Läuft die automatische Verlängerung wirklich durch, auch wenn ein CDN oder Reverse Proxy vorgeschaltet ist? Bei ACME‑Challenges prüfe ich, ob Weiterleitungen, Rate Limits oder Wartungsseiten die Validierung stören. Zudem aktiviere ich OCSP‑Stapling und moderne Protokolle (TLS 1.2/1.3) direkt im Webserver, damit Browser Zertifikatsprüfungen schneller abhandeln.
WordPress‑URLs umstellen
Ich melde mich im Dashboard an und öffne Einstellungen → Allgemein, dann setze ich „WordPress‑Adresse (URL)“ und „Website‑Adresse (URL)“ auf https://. Nach dem Speichern melde ich mich erneut an, falls die Sitzung neu startet. Anschließend lösche ich Browser‑Cache und, falls vorhanden, den Cache meines Caching‑Plugins, damit Besucher sofort die sichere Variante erhalten. Widgets, Menüs und harte Links schaue ich mir danach an, denn dort können noch http‑Verweise stehen. Für Medien in Beiträgen editiere ich einzelne Inhalte oder plane eine saubere Suche in der Datenbank (siehe unten).
Login und Admin absichern
Für den Admin‑Bereich erzwinge ich TLS mit einer kleinen Ergänzung in der wp-config.php. Dafür füge ich oberhalb der Zeile „/* That’s all, stop editing! */“ Folgendes ein und lade die Datei hoch:
define('FORCE_SSL_ADMIN', true);
Dadurch laufen Login, Cookies und das gesamte Backend strikt über HTTPS. Wenn ein Reverse Proxy oder eine CDN‑Schicht vorgeschaltet ist, stelle ich sicher, dass WordPress den Header „X‑Forwarded‑Proto: https“ korrekt interpretiert. Andernfalls behandelt die Anwendung die Verbindung fälschlich als unsicher und setzt Cookies ohne Secure‑Flag.
Weitere sichere WordPress‑Konstanten und Proxy‑Erkennung
Wenn ich die URLs im Backend nicht erreichen kann (z.B. Loop durch Plugins), setze ich temporär in der wp‑config.php explizite Konstanten und heble so fehlerhafte Einstellungen aus:
define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');
Hinter Proxys ergänze ich außerdem eine Erkennung, damit is_ssl() korrekt greift:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Das verhindert falsche Mixed‑Content‑Generierung im Backend und sorgt dafür, dass Auth‑Cookies konsequent mit dem Secure‑Attribut ausgeliefert werden.
301‑Redirects in .htaccess einrichten
Damit alle Anfragen dauerhaft auf die sichere Version gehen, richte ich eine Weiterleitung von http auf https ein. In einer klassischen Apache‑Umgebung öffne ich die .htaccess im WordPress‑Stamm und ergänze die Regeln oberhalb des WordPress‑Blocks:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Bei Nginx erfolgt die Weiterleitung in der Server‑Konfiguration (server { listen 80; return 301 https://$host$request_uri; }). Für Details, Varianten und Fehlersuche findest du eine klare Anleitung zur HTTPS Weiterleitung. Wichtig: Ich halte die Redirect‑Kette kurz, also http→https und ggf. www→non‑www oder umgekehrt in einem Sprung, damit keine unnötigen Hops die Ladezeit erhöhen.
Saubere Redirect‑Strategie ohne Schleifen
Neben der Basisweiterleitung setze ich Konsistenzregeln: Entweder www oder non‑www – nie beides. Bei Apache löse ich das in einem Schritt mit Host‑Prüfung:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]
Ich erhalte dabei Query‑Strings (UTM‑Parameter) automatisch, reduziere Redirects auf einen Hop und vermeide Schleifen, indem ich keine konkurrierenden Regeln im Plugin oder CDN aktiviere. Wenn ein Edge‑Proxy „Flexible SSL“ nutzt (Browser→CDN verschlüsselt, CDN→Origin unverschlüsselt), wechsle ich auf „Full (strict)“, damit sowohl zum Besucher als auch zum Origin TLS erzwungen ist – sonst drohen Loop‑Probleme und gemischte Protokolle.
Mixed Content erkennen und beheben
Nach dem Redirect prüfe ich die Seite mit den Browser‑Tools auf „Mixed Content“, also Inhalte, die noch per http geladen werden. Häufig betroffen sind Bilder, Fonts, Skripte oder Stylesheets in Themes, Page Buildern oder Widgets. Ich korrigiere hart eingetragene URLs, indem ich sie im Editor, im Customizer oder in den Plugin‑Einstellungen auf https ändere. Tools wie „Really Simple SSL“ helfen kurzfristig, besser ist jedoch eine dauerhafte Bereinigung der Quellen. Blockierte Inhalte verursachen Styling‑Fehler oder ausgeblendete Funktionen, daher räume ich alles auf, bis der Browser keine Warnungen mehr zeigt.
Mixed‑Content‑Profi‑Checkliste
- Ich aktiviere testweise die CSP‑Direktive
upgrade-insecure-requestsim Report‑Only‑Modus, um zu sehen, was der Browser automatisch auf https hochstuft – anschließend bereinige ich die Quellen dauerhaft. - Fonts und externe Styles benötigen oft CORS‑Header; ohne
Access-Control-Allow-Originerscheinen sie als blockiert. - CSS‑Hintergrundbilder mit absoluten http‑Links erkenne ich in Developer‑Tools und ersetze sie durch relative Pfade oder https.
- iframes (z.B. Karten, Videos) müssen ebenfalls https sprechen, sonst blendet der Browser sie aus.
- In Themes vermeide ich hart codierte Pfade und nutze Funktionen wie
home_url(),site_url(),plugins_url()undcontent_url(), damit WordPress die korrekte Basis‑URL liefert.
Schritt‑für‑Schritt‑Übersicht
Die folgende Tabelle fasst alle Aufgaben der Umstellung kompakt zusammen und hilft mir, die Reihenfolge einzuhalten.
| Schritt | Empfehlung/Erläuterung |
|---|---|
| Backup erstellen | Vor jeder Änderung vollständige Sicherung von Dateien und Datenbank |
| SSL‑Zertifikat einrichten | Let’s Encrypt oder kostenpflichtige Variante beim Hoster aktivieren |
| URLs anpassen | Im Backend unter Einstellungen → Allgemein auf https setzen |
| Redirects setzen | .htaccess bzw. Nginx‑Serverblock für 301 auf HTTPS konfigurieren |
| Mixed Content prüfen | Harte http‑Links in Inhalten, Themes und Plugins ersetzen |
| Datenbank ersetzen | Mit Backup und seriösem Tool alle http‑Vorkommen austauschen |
| Google/SEO aktualisieren | Search Console Property, Sitemap, Analytics und Canonicals anpassen |
Datenbank‑URLs sauber ersetzen
Manchmal schlummern http‑Links in Widgets, Shortcodes oder benutzerdefinierten Feldern, daher setze ich ein erprobtes Tool wie „Better Search Replace“ ein. Ich suche nach „http://deinedomain.de“ und ersetze mit „https://deinedomain.de“, zunächst im Dry‑Run, dann echt mit Backup. Bei Serienumbenennungen per WP‑CLI nutze ich „wp search-replace“, was bei großen Seiten deutlich schneller ist. Serialisierte Arrays und Objekte müssen korrekt behandelt werden, daher verlasse ich mich auf Tools, die damit sauber umgehen. Nach dem Austausch prüfe ich Stichproben im Frontend und in wichtigen Layouts.
Datenbank: Was ich nicht blind ersetze
Ich fasse die GUID‑Spalte in der wp_posts nur an, wenn ich die Domain tatsächlich ändere. Der reine Protokollwechsel auf https erfordert in der Regel keine Änderung der GUIDs, da sie primär als eindeutige Kennung dienen. Ebenso prüfe ich vor einem globalen Replace, ob Plugins externe Endpunkte (Webhooks, APIs) mit http referenzieren – diese aktualisiere ich lieber gezielt und teste den Rückkanal. Bei großen Projekten plane ich eine kurze Content‑Freeze‑Phase, damit während des Search‑Replace keine neuen Beiträge mit alten Schemen entstehen. Mit WP‑CLI sichere ich mir Geschwindigkeit und Reproduzierbarkeit:
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise
SEO‑Checks nach der Umstellung
Nach dem Wechsel erstelle ich in der Search Console eine neue Property mit https und reiche eine aktualisierte Sitemap ein. Interne Links, Canonical‑Tags, hreflang‑Referenzen und Open‑Graph‑Tags prüfe ich auf https. Tracking‑Snippets (Analytics, Tag Manager, Pixel) müssen ebenfalls die gesicherte Adresse nutzen. In SEO‑Plugins kontrolliere ich Redirect‑Regeln und stelle sicher, dass keine „weichen 404er“ entstehen. Wenn Social‑Share‑Zähler wichtig sind, teste ich, wie das Tool mit der neuen Adresse umgeht.
Feeds, Robots und Canonicals feinjustieren
Ich überprüfe, ob RSS/Atom‑Feeds über https erreichbar sind und valide ausliefern. In einer statisch gepflegten robots.txt passe ich ggf. Sitemap‑Pfade auf https an. Canonical‑URLs setze ich konsistent absolut mit https, damit Suchmaschinen Signale eindeutig interpretieren. hreflang‑Paare (mehrsprachige Sites) dürfen sich nicht im Protokoll unterscheiden, sonst entsteht Inkonsistenz.
Caching, CDN und Performance unter HTTPS
HTTPS lohnt sich auch für die Geschwindigkeit, denn HTTP/2/3 ermöglichen Multiplexing und Header‑Kompression über eine Verbindung. Ich achte auf TLS‑Session‑Resumption, OCSP‑Stapling und moderne Cipher‑Suites, was die Handshakes beschleunigt. Ein CDN liefert statische Assets näher am Besucher aus, muss jedoch konsistent auf https laufen. In Caching‑Plugins aktiviere ich, falls vorhanden, die Option „Cache für HTTPS“ und leere alte Artefakte. Anschließend messe ich mit Tools wie Lighthouse und vergleiche die Zeiten vor und nach dem Wechsel.
CDN/Proxy‑Besonderheiten
Bei vorgeschaltetem CDN setze ich immer „Full (strict)“ zum Origin, lade das Zertifikat dort hoch oder nutze ein Origin‑Zertifikat und lasse nur https ausliefern. Ich prüfe, ob das CDN Redirects cached (sonst sehe ich alte Zustände) und leere die Edge‑Caches nach der Umstellung. Brotli‑Kompression, HTTP/3/QUIC und 0‑RTT können zusätzlich helfen – wichtig ist aber, dass keine seitenweiten Regeln mehr http‑Ressourcen injizieren. Schließlich sende ich den korrekten Client‑IP‑Header (z.B. X‑Forwarded‑For) durch und konfiguriere den Webserver, damit Logs die echte Besucher‑IP zeigen.
HSTS und weitere Sicherheitsheader
Wenn die Seite vollständig auf HTTPS läuft, aktiviere ich HTTP Strict Transport Security (HSTS), damit Browser ausschließlich die HTTPS‑Variante aufrufen. Den Header setze ich z.B. so: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload – aber nur, wenn wirklich alle Subdomains sicher erreichbar sind. Zu Chancen und Fallstricken empfehle ich dir den Leitfaden HSTS aktivieren. Zusätzlich setze ich Security‑Header wie X‑Content‑Type‑Options, X‑Frame‑Options und eine straffe Content‑Security‑Policy, die https‑Quellen erlaubt. Diese Header stärken Schutzschichten gegen Content‑Injection, Clickjacking und MIME‑Sniffing.
Sicherheitsheader feinjustieren
Zusätzlich zu HSTS ergänze ich eine pragmatische Header‑Konfiguration: Referrer-Policy: strict-origin-when-cross-origin begrenzt die Weitergabe sensibler Pfade, Permissions-Policy schränkt Browser‑APIs ein (z.B. Kamera, Mikrofon), und eine maßvolle CSP mit default-src 'self' https: verhindert ungewollte Fremdquellen. Ich beginne mit Report‑Only, sammle Verstöße und verschärfe dann die Richtlinien. So verhindere ich, dass Security‑Header die Seite ungewollt „zerbrechen“.
Tests, Monitoring und Fehlersuche
Ich teste die Umstellung in einem privaten Fenster und auf Mobilgeräten, damit keine alten Cookies oder Caches stören. Das Protokoll der Browser‑Konsole zeigt Mixed‑Content‑Warnungen und blockierte Ressourcen schnell. Mit „curl -I http://deinedomain.de“ kontrolliere ich, ob ein 301 auf die https‑Version erfolgt und ob weitere Ketten auftreten. Danach überwache ich Fehlerlogs auf dem Server sowie 404‑Reports im SEO‑Plugin oder in der Search Console. Wenn einzelne Plugins nicht mehr laden, prüfe ich ihre externen Abhängigkeiten und aktualisiere sie auf die neueste Version.
Go‑Live‑Kontrolle und laufendes Monitoring
- Ich aktiviere vor dem Umschalten optional einen kurzen Wartungsmodus, um konsistente Redirects und Caches aufzubauen.
- Zertifikatsablauf stelle ich unter Beobachtung (Alarme), damit keine bösen Überraschungen entstehen.
- Ich beobachte in den ersten Tagen die 404‑Rate, Ranking‑Kurven, Crawl‑Statistiken sowie Core Web Vitals, um früh gegenzusteuern.
- Für Kampagnen prüfe ich, ob UTM‑Parameter über die 301‑Weiterleitung vollständig erhalten bleiben.
Besonderheiten bei Multisite, Proxy und Staging
Bei Multisite stelle ich die Netzwerk‑Adresse auf https um und passe Mappings an, damit alle Sites eine einheitliche Weiterleitung nutzen. Hinter Load Balancern oder CDNs muss der Webserver den „X‑Forwarded‑Proto“ Header beachten, sonst denkt WordPress, die Verbindung sei unsicher und setzt falsche URLs. Für Staging‑Systeme verwende ich eigene Zertifikate oder schütze sie per Basic Auth, damit Suchmaschinen sie nicht indexieren. Nach dem Live‑Wechsel schalte ich Caches wieder zu, wärme sie auf und beobachte die Last. In Umgebungen mit eigenen Proxys oder Firewalls dokumentiere ich alle Änderungen, damit spätere Deployments die Konfiguration übernehmen.
Multisite- und Commerce‑Details, die oft fehlen
In Multisite‑Setups aktualisiere ich pro Site die siteurl und home Werte, besonders wenn Domain‑Mapping im Spiel ist. Falls ein sunrise.php oder spezielle Mapping‑Plugins arbeiten, prüfe ich, ob sie https‑aware sind. In Shops (z.B. WooCommerce) setze ich „Kasse“ und „Mein Konto“ konsequent auf https, teste Zahlungs‑ und Webhook‑Rückläufe sowie Thank‑You‑Pages. Zahlungsanbieter und Versand‑APIs erfordern häufig aktualisierte Callback‑URLs – ich passe sie an und verifiziere die Signaturprüfung nach dem Wechsel.
Häufige Stolperfallen und schnelle Lösungen
Fehlerhafte Zertifikate sorgen für rote Warnschilder – ich prüfe daher Ausstellungszeitraum, Kette und ob alle Domains im Zertifikat enthalten sind, damit die Verbindung ohne Unterbrechung läuft. Fehlende 301‑Weiterleitungen erzeugen doppelte Inhalte; ich reguliere das mit klaren, kurzen Regeln und vermeide mehrere Hops. Mixed Content kommt oft aus hart codierten Theme‑Dateien; hier ersetze ich http‑Schemen oder nutze schemalose URLs („//…“) an den passenden Stellen. Externe Dienste, die noch http referenzieren, sperren Anfragen; hier aktualisiere ich Webhooks, Endpunkte und Keys. Wenn ein Plugin die Umstellung nicht verträgt, teste ich ein Update oder tausche es gegen eine Lösung, die HTTPS vollständig unterstützt.
Zusammenfassung: Sicher auf HTTPS gewechselt
Ich starte mit einem vollständigen Backup, aktiviere das Zertifikat, stelle WordPress‑URLs auf https um, erzwinge 301‑Weiterleitungen und räume Mixed Content konsequent auf. Danach ersetze ich verbliebene http‑Einträge in der Datenbank, aktualisiere SEO‑Einstellungen und messe die Performance. HSTS und Security‑Header erhöhen die Sicherheit weiter, sofern alle Subdomains sauber auf https reagieren. Für Hosting setze ich auf Anbieter mit gutem Support, automatischer Verlängerung und schneller TLS‑Bereitstellung wie webhoster.de, was die Arbeit spürbar erleichtert. So bleibt die Seite sicher, schnell und sichtbar – genau das erwarte ich von einer nachhaltigen HTTPS‑Umstellung.
