Von HTTP auf HTTPS umstellen

Eine Website auf HTTPS umzustellen dauert technisch oft nur eine Stunde. Die Arbeit steckt im Aufräumen danach: alte Links, eingebundene Skripte über HTTP, eine Sitemap mit den alten Adressen. Wer dabei sauber vorgeht, verliert weder Besucher noch Sichtbarkeit in der Suche. Die folgende Reihenfolge hat sich bewährt.

Warum die Umstellung nicht warten sollte

Seit Chrome 68 vom Juli 2018 zeigt Chrome auf Seiten ohne HTTPS den Hinweis "Nicht sicher" ^[6]. Im Oktober 2025 hat das Chrome-Sicherheitsteam angekündigt, mit Chrome 154 im Oktober 2026 die Einstellung "Immer sichere Verbindungen verwenden" ab Werk einzuschalten. Chrome warnt dann, bevor es eine öffentliche Website ohne HTTPS lädt ^[7]. Für Besucher wird eine Seite ohne Verschlüsselung damit noch auffälliger als bisher.

Google fragt bei der Seitennutzererfahrung ausdrücklich, ob Seiten sicher ausgeliefert werden, und verweist auf den HTTPS-Bericht der Search Console ^[2]. Rechtlich verlangt § 19 Abs. 4 TDDDG von Anbietern digitaler Dienste, ihre Systeme nach dem Stand der Technik gegen unbefugte Zugriffe zu sichern, und nennt als Beispiel ein als sicher anerkanntes Verschlüsselungsverfahren ^[8]. Art. 32 DSGVO führt die Verschlüsselung personenbezogener Daten unter den Schutzmaßnahmen auf ^[9]. Spätestens mit einem Kontaktformular gehen solche Daten über deine Seite.

Vorbereitung

Bevor du etwas umschaltest, prüfst du drei Dinge. Das Zertifikat muss alle Namen enthalten, unter denen die Seite erreichbar ist, also meist die Domain mit und ohne www. Alle Dateien, die die Seite lädt, sollten über HTTPS erreichbar sein, auch die von fremden Diensten wie Schriften, Karten oder Videos. Und du brauchst eine Liste deiner wichtigsten Adressen, um nach dem Umstieg zu testen, ob jede richtig weiterleitet.

Entscheide vorher auch, ob die Website mit oder ohne www erreichbar sein soll. Die Umstellung ist ein guter Zeitpunkt, das festzulegen, denn dann leitest du ohnehin alle Adressen um. Alle vier Kombinationen aus http, https, mit und ohne www sollen am Ende auf dieselbe Fassung zeigen. Bei eingebundenen Diensten, die kein HTTPS anbieten, brauchst du Ersatz, bevor du umschaltest. Ein Video oder eine Karte, die über HTTP eingebunden ist, lädt auf der HTTPS-Seite sonst nicht mehr.

Das Zertifikat selbst richtest du so ein, wie es in SSL-Zertifikat installieren beschrieben ist. Kostenlos und mit automatischer Erneuerung geht das mit Let's Encrypt. Rufe danach die Seite über https:// auf und prüfe, ob sie vollständig lädt, bevor du die Weiterleitung einschaltest.

Die Weiterleitung einrichten

Jede alte HTTP-Adresse leitet dauerhaft auf dieselbe Adresse mit HTTPS weiter. Google empfiehlt dafür dauerhafte Weiterleitungen auf dem Server, etwa mit Status 301 oder 308, wenn das technisch möglich ist ^[1]. Jede Seite soll dabei auf ihr genaues Gegenstück zeigen. Wer alles auf die Startseite schickt, verliert die Signale der Unterseiten.

Bei Apache ist laut Dokumentation ein eigener virtueller Host für Port 80 der sauberste Weg. Er enthält nur die Zeile Redirect permanent "/" "https://www.example.com/" ^[10]. Hast du keinen Zugriff auf die Serverkonfiguration, bleibt die .htaccess-Datei. Dort nimmt man mod_rewrite ^[10]:

Bei nginx bekommt der server-Block für Port 80 eine return-Anweisung mit dem Code 301 und der Zieladresse, zum Beispiel return 301 https://www.example.com$request_uri; ^{[11, 13]}. In Plesk heißt die Einstellung "Redirect from http to https" und richtet eine dauerhafte 301-Weiterleitung ein ^[12]. Mehr zu Regeln in der .htaccess steht unter Die .htaccess-Datei: Weiterleitungen und Regeln.

Gemischte Inhalte beheben

Lädt eine HTTPS-Seite Dateien über HTTP, spricht man von gemischten Inhalten (Mixed Content). Browser teilen sie in zwei Gruppen. Bilder, Audio und Video ruft der Browser von sich aus über HTTPS ab. Skripte, Stylesheets, iframes, Schriften und Abrufe per fetch blockiert er dagegen ^[3]. Fehlt ein Stylesheet, sieht die Seite kaputt aus; fehlt ein Skript, funktionieren Menüs oder Formulare nicht.

Die Lösung ist, jede Adresse im Code auf https:// oder auf relative Pfade umzustellen. Das betrifft Vorlagen, Inhalte in der Datenbank, Einstellungen des CMS mit der Adresse der Website und eingebundene Dienste. Die Entwicklerkonsole des Browsers zeigt Warnungen zu jeder Datei, die hochgestuft oder blockiert wurde ^[3]. Für Fälle, die du nicht sofort an der Quelle beheben kannst, gibt es den Antwortkopf Content-Security-Policy: upgrade-insecure-requests. Er lässt den Browser alle Anfragen über HTTPS stellen, auch die blockierbaren ^[3]. Als Dauerlösung ersetzt er die saubere Korrektur nicht, weil Dateien, die es unter HTTPS nicht gibt, dann einfach fehlen.

Adressen mit IP-Nummer statt Domainnamen blockiert der Browser, auch bei Bildern ^[3]. Wenn ein Bild mit einer IP-Adresse im Pfad verschwindet, liegt es daran.

Links, Canonical-Tags und Sitemap

Google behandelt den Wechsel von HTTP auf HTTPS als Umzug mit geänderten Adressen ^[1]. Damit die Suchmaschine die neuen Adressen schnell übernimmt, passt du alle Stellen an, die noch auf die alten zeigen:

• interne Links in Menüs, Texten und Vorlagen auf https:// umstellen,
• das Canonical-Tag jeder Seite auf ihre eigene HTTPS-Adresse setzen,
• eine Sitemap mit den neuen Adressen erzeugen und in der Search Console einreichen,
• in der Search Console die HTTPS-Fassung der Website bestätigen, wenn du nicht schon eine Domain-Property nutzt.

Eine Adressänderung in der Search Console brauchst du für diesen Wechsel nicht, die ist nur für einen Umzug auf eine andere Domain gedacht. Nach Googles Angaben dauert es bei kleinen und mittleren Websites einige Wochen, bis die meisten Seiten umgezogen sind. Die Weiterleitungen sollen so lange wie möglich bestehen bleiben, in der Regel mindestens ein Jahr ^[1]. Wie Weiterleitungen und Canonical-Tags in der Suche wirken, erklärt unser SEO-Projekt unter Weiterleitungen und SEO: 301, 302 und 410 und Canonical-Tag: doppelte Inhalte steuern.

In Content-Management-Systemen steht die Adresse der Website meist an einer zentralen Stelle in den Einstellungen. Stellst du sie dort auf https:// um, erzeugt das System neue Links automatisch richtig. Adressen, die schon in Beiträgen und Seiten gespeichert sind, ändert das aber nicht. Die musst du in der Datenbank ersetzen, am besten mit einem Werkzeug, das dein CMS dafür vorsieht, und nach einer Sicherung.

Links von anderen Websites auf deine alten HTTP-Adressen funktionieren über die Weiterleitung weiter. Bei wichtigen Partnern, Verzeichnissen und deinen eigenen Profilen in sozialen Netzen lohnt es sich trotzdem, die Adresse zu ändern.

HSTS als letzter Schritt

Mit HTTP Strict Transport Security (HSTS) sagt die Website dem Browser, dass er sie künftig nur noch über HTTPS aufrufen soll. Das geschieht über den Antwortkopf Strict-Transport-Security mit einer Gültigkeit in Sekunden (max-age). Der Zusatz includeSubDomains dehnt die Regel auf alle Subdomains aus ^[4]. Ein Browser beachtet den Kopf nur, wenn er ihn über eine verschlüsselte Verbindung empfängt ^[4].

HSTS gehört ans Ende der Umstellung, wenn alles über HTTPS läuft. Hast du includeSubDomains gesetzt und eine Subdomain hat noch kein Zertifikat, ist sie für Besucher mit gespeicherter Regel nicht mehr erreichbar. Plesk weist vor dem Einschalten ausdrücklich darauf hin, dass das Zertifikat über die ganze max-age-Dauer gültig bleiben muss, auch für Subdomains und Webmail ^[12]. Fang deshalb mit einer kurzen Dauer an und verlängere sie, wenn nichts klemmt.

Noch einen Schritt weiter geht die HSTS-Preload-Liste, die in die Browser eingebaut ist. Für die Aufnahme verlangt hstspreload.org ein max-age von mindestens 31536000 Sekunden, also einem Jahr, dazu includeSubDomains und den Zusatz preload. Die Aufnahme lässt sich nur schwer rückgängig machen, und eine Entfernung braucht Monate, bis sie bei den Nutzern ankommt ^[5]. Den Begriff erklärt das Glossar unter HSTS.

Nach dem Umstieg prüfen

Ruf deine Testliste mit http:// auf und prüfe, ob jede Adresse in einem Schritt auf ihre HTTPS-Fassung springt. Ketten aus mehreren Weiterleitungen, etwa erst auf www und dann auf HTTPS, lassen sich meist in einer Regel zusammenfassen. Sieh dir in der Entwicklerkonsole einige typische Seiten auf Warnungen zu gemischten Inhalten an. Mit dem SSL-Check prüfst du Zertifikat und Laufzeit von außen. In den Wochen danach zeigt die Search Console, ob die HTTPS-Adressen in den Index wandern und die alten verschwinden.

1. Organisation Site moves with URL changes (Google Search Central). Google LLC. Stand 2026. abgerufen am 29.10.2026
2. Organisation Understanding page experience in Google Search results. Google LLC. Stand 2026. abgerufen am 29.10.2026
3. Organisation Mixed content (MDN Web Docs). Mozilla Foundation. Stand 2026. abgerufen am 29.10.2026
4. Gesetz RFC 6797: HTTP Strict Transport Security (HSTS). IETF. Stand 11.2012. abgerufen am 29.10.2026
5. Organisation HSTS Preload List Submission. Chromium-Projekt. Stand 2026. abgerufen am 29.10.2026
6. Organisation A milestone for Chrome security: marking HTTP as "not secure". Google LLC. Stand 24.07.2018. abgerufen am 29.10.2026
7. Organisation HTTPS by default. Google LLC, Chrome Security Team. Stand 28.10.2025. abgerufen am 29.10.2026
8. Gesetz § 19 Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG). Bundesministerium der Justiz. Stand 2026. abgerufen am 29.10.2026
9. Gesetz Art. 32 Datenschutz-Grundverordnung (Textausgabe). Intersoft Consulting (dsgvo-gesetz.de). Stand 2026. abgerufen am 29.10.2026
10. Organisation Redirecting and Remapping with mod_rewrite: Forcing HTTPS. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
11. Organisation Module ngx_http_rewrite_module. nginx. Stand 2026. abgerufen am 29.10.2026
12. Organisation Securing Connections with the SSL It! Extension (Plesk Obsidian Customer Guide). Plesk. Stand 2026. abgerufen am 29.10.2026
13. Organisation Module ngx_http_core_module: Embedded Variables. nginx. Stand 2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.