Zum Inhalt springen 
Ich aktiviere All-Inkl SSL in wenigen Minuten, erzwinge HTTPS sauber und beseitige typische Stolpersteine wie Mixed Content direkt im Anschluss. Diese Anleitung zeigt Schritt für Schritt, wie ich das Zertifikat im KAS einschalte, Weiterleitungen korrekt setze und die Verschlüsselung technisch wie SEO-seitig vollständig absichere.
Zentrale Punkte
- Let’s Encrypt bei All-Inkl im KAS aktivieren und Schloss prüfen
- HTTPS erzwingen per Weiterleitung und HSTS korrekt einsetzen
- Mixed Content zuverlässig finden und ersetzen
- Zertifikatskette testen und alte Protokolle abschalten
- SEO-Folgen mit Search Console und Sitemap klären
Warum HTTPS mit All-Inkl sofort Wirkung zeigt
Mit einem aktiven Zertifikat sorge ich für eine verschlüsselte Verbindung zwischen Browser und Server, wodurch Formulare, Logins und Zahlungsdaten geschützt bleiben. Gleichzeitig steigere ich das Vertrauen, weil moderne Browser das Schloss-Symbol sichtbar einblenden und Warnungen ausblenden. Für Shops und viele APIs gilt eine verschlüsselte Auslieferung längst als Pflicht, und auch Redaktionen sichern Anmeldebereiche und Kontaktformulare ab. Google bewertet sichere Seiten positiv, was langfristig Sichtbarkeit und Klickrate stützt. Wer heute SSL auslässt, riskiert Abbrüche, Fehlermeldungen und weniger Conversions, obwohl die Aktivierung bei All-Inkl sehr schnell gelingt.
Voraussetzungen und Vorbereitung im KAS
Ich stelle zuerst sicher, dass Domain und Hosting bei All-Inkl liegen und die DNS-Einträge korrekt auf das Paket zeigen. Wenn ich DNS-Anpassungen vorgenommen habe, warte ich auf die Verteilung, damit die Zertifikatsprüfung zuverlässig durchläuft. Ein Admin-Login zum KAS (Kundenadministrationssystem) sollte bereitstehen, ebenso die Hauptdomain sowie benötigte Subdomains. Vor größeren Änderungen an WordPress exportiere ich die Datenbank und mache eine Dateisicherung, damit ich notfalls schnell zurück kann. Danach starte ich die eigentliche Aktivierung ohne Zeitverlust.
All-Inkl SSL aktivieren: Schritt für Schritt
Ich melde mich im KAS an und wähle die betreffende Domain aus der Übersicht. Im Bearbeiten-Dialog öffne ich den Reiter „SSL-Schutz“ und klicke erneut auf Bearbeiten, um die Optionen zu sehen. Im Tab „Let’s Encrypt“ bestätige ich den Hinweis und stoße die Ausstellung an; wenige Minuten später steht das Zertifikat bereit und die Seite lädt über HTTPS. Zur Kontrolle öffne ich die Seite im privaten Fenster, leere den Cache und schaue auf das Schloss-Symbol links von der URL. Für vertiefende Schritte hilft mir die kurze All-Inkl Let’s Encrypt Anleitung beim Abgleich meiner Einstellungen.
HTTPS erzwingen: Weiterleitungen richtig setzen
Nach der Aktivierung leite ich sämtlichen HTTP-Traffic auf HTTPS um, sonst bleibt die Seite über beide Protokolle erreichbar. Die Umleitung setze ich üblicherweise per .htaccess mithilfe einer Rewrite-Regel auf 301, alternativ nutze ich das All-Inkl-Backend für komfortable Weiterleitungen. Ich kontrolliere gleichzeitig, ob www und ohne www einheitlich auf mein bevorzugtes Ziel laufen, um doppelte Inhalte zu vermeiden. Sobald die Seite vollständig ohne gemischte Inhalte läuft, aktiviere ich HSTS (Strict-Transport-Security) und minimiere damit die Angriffsfläche für Downgrade-Angriffe. Den Erfolg prüfe ich mit einem frischen Browser-Start oder per Kommandozeile, damit keine lokalen Caches das Ergebnis verfälschen.
Praxis: .htaccess-Regeln und HSTS sicher setzen
Damit die Umstellung sauber greift, lege ich klare Regeln in der .htaccess an. Zwei typische Varianten für die Kanonisierung:
1) von http und www auf https ohne www:
RewriteEngine On
# auf https erzwingen
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# www entfernen
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
2) von http und non-www auf https mit www:
RewriteEngine On
# auf https erzwingen
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# www erzwingen
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
HSTS aktiviere ich erst, wenn keine Mixed-Content-Fehler mehr auftreten. Ich starte konservativ und erhöhe die Dauer stufenweise:
<IfModule mod_headers.c>
# 5 Minuten zum Testen
Header always set Strict-Transport-Security "max-age=300"
</IfModule>
Wenn alles stabil läuft, setze ich eine längere Gültigkeit und optional Subdomains sowie Preload:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
Wichtig: Preload sollte ich nur aktivieren, wenn wirklich jede Subdomain zuverlässig via HTTPS erreichbar ist, da Browser den Eintrag langfristig cachen.
Mixed Content sicher beseitigen
Eine häufige Ursache für Warnungen sind hart verlinkte http-Ressourcen wie Bilder, Skripte oder Stylesheets. Ich ersetze solche Verweise konsequent durch https oder setze relative Pfade, damit die Inhalte unabhängig vom Protokoll korrekt geladen werden. In WordPress korrigiere ich die Adressen in den Einstellungen und prüfe Pagebuilder, Menüs, Widgets und Theme-Optionen auf versteckte URLs. Für größere Bestände setze ich gezielt Tools ein, etwa Suchen-und-Ersetzen in der Datenbank oder passende Plugins, die interne Verlinkungen umstellen. Als kompakter Einstieg führt mich die Anleitung SSL in 5 Schritten durch die typischen Baustellen ohne lange Umwege.
Fehlersuche: Browser, Konsole und Kommandozeile
Ich öffne die Entwicklerwerkzeuge des Browsers und prüfe die Konsole auf Mixed-Content-Warnungen sowie den Sicherheits-Tab. Dort sehe ich blockierte Ressourcen und deren Herkunft. Für die serverseitige Prüfung helfen mir ein paar Kommandos:
# HTTP sollte 301 auf HTTPS liefern
curl -I http://example.com/
# HTTPS-Antwortheader prüfen (HSTS, CSP, Caching)
curl -I https://example.com/
# Zertifikatskette inspizieren
openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -issuer -subject -dates
Mit curl erkenne ich schnell, ob falsche 302-Weiterleitungen, Ketten oder Schleifen existieren. Stimmen Statuscodes, Ziel-URL und Header, ist die Basis korrekt. Bei Caching-Problemen leere ich Browser- und Server-Caches sowie ggf. CDN-Caches, bevor ich erneut teste.
Zertifikatskette und Protokolle prüfen
Nach der Umstellung teste ich die Zertifikatskette mit einem SSL-Checker, damit keine Zwischenzertifikate fehlen. Ich achte auf eine korrekte Kette bis zur vertrauenswürdigen Stammstelle, denn sonst erscheinen Browserwarnungen trotz gültigem Zertifikat. Zusätzlich werte ich die unterstützten Versionen aus und deaktiviere veraltete Protokolle wie TLS 1.0 und 1.1. Wo verfügbar, bevorzuge ich TLS 1.3 und sichere Cipher-Suites, die Perfect Forward Secrecy unterstützen. Ein abschließender Qualitätstest zeigt mir Note, Kette, Protokolle und mögliche Schwachpunkte auf einen Blick.
Subdomains, Alias-Domains und Weiterleitungsmatrix
Ich plane vorab, welche Hosts es gibt und wie sie kanonisiert werden. Typische Kandidaten: www, die nackte Domain, cdn-, img– oder blog-Subdomains, Staging/Dev-Hosts sowie Alias-Domains. Meine Matrix definiert:
- welche Hostnamen aktiv HTTPS ausliefern,
- welche Ziel-Domain als kanonisch gilt,
- welche Hosts intern auf andere Pfade umleiten (z. B. /blog),
- welche Subdomains ausgenommen sind (z. B. dev nur via Basic-Auth).
Für Wildcard-Zertifikate decke ich alle Subdomains einer Zone ab. Bei Let’s Encrypt erfordert das in der Regel DNS-Validierung. Arbeitet eine Alias-Domain nur als Weiterleitung auf die Hauptdomain, genügt ein Zertifikat für das Ziel; wird die Alias-Domain selbst ausgeliefert, braucht sie ein eigenes Zertifikat oder ein SAN-Eintrag. Ich halte die Zahl der Weiterleitungssprünge minimal, idealerweise ein einziger 301 von jeder Eingangs-URL zur Ziel-URL.
WordPress sauber auf HTTPS umstellen
Ich setze in WordPress die Website-Adresse und die WordPress-Adresse auf https, lösche Caches und prüfe die Startseite samt Unterseiten. Widgets, Menüs und Pagebuilder-Felder kontrolliere ich einzeln, weil dort oft alte Pfade abgelegt sind. Externe Einbindungen wie YouTube, Schriftarten und Tracking-Skripte rüste ich auf https um, damit der Browser keine Inhalte blockiert. Nutze ich ein CDN, passe ich die Endpunkte an und stelle die Auslieferung auf https, inklusive korrekt hinterlegter Zertifikate. Erst wenn alles störungsfrei lädt, setze ich HSTS und erhöhe die Gültigkeitsdauer Schritt für Schritt.
WordPress: Praxisbefehle und Stolpersteine
Für größere Sites beschleunige ich die Umstellung mit WP-CLI und beachte Besonderheiten bei serialisierten Daten:
# Basis-URLs setzen
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
# Suchen & Ersetzen über alle Tabellen (GUID-Spalte aussparen)
wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid
# Admin-Bereich absichern
wp config set FORCE_SSL_ADMIN true --raw
Ich ändere GUIDs in der Datenbank nicht, da sie als unveränderliche Identifikatoren dienen. In Themes prüfe ich Bild-URLs in CSS (Hintergrundbilder) und hart codierte Skript- oder Font-Quellen. Bei Pagebuildern achte ich auf globale Einstellungen, die Protokolleigenschaften vererben. Nach der Umstellung leere ich alle Caches (Seite, Objekt-Cache, CDN) und regeneriere ggf. Thumbnails, falls Bildpfade neu aufgebaut werden.
Erweiterte Zertifikate und CSR bei All-Inkl
Für Projekte mit speziellen Anforderungen kann ich ein Wildcard-, OV- oder EV-Zertifikat einsetzen und im KAS einbinden. Dafür erstelle ich einen CSR, lasse ihn beim Anbieter signieren und importiere Zertifikat, Privatkey und Zwischenzertifikate im SSL-Schutz-Tab. Ein Wildcard-Zertifikat deckt beliebige Subdomains einer Zone ab und eignet sich, wenn viele Subdomains im Einsatz sind. Für die meisten Websites reicht Let’s Encrypt mit guter Kompatibilität und kurzer Ausstellungszeit, weshalb ich damit meist starte. Wechsel oder Upgrade plane ich erst, wenn organisatorische Validierung oder besondere Darstellung im Browser gewünscht ist.
Sicherheit nach der Umstellung erhöhen
Zusätzlich zur Umleitung setze ich, sobald alles sauber läuft, HSTS mit angemessener Max-Age und optionaler Preload-Registrierung. Ich aktiviere OCSP-Stapling, damit Browser Revocation-Daten schneller erhalten und weniger Abfragen an externe Stellen nötig sind. Eine strikte Content Security Policy mit „upgrade-insecure-requests“ hilft dabei, vergessene http-Verweise automatisch auf https zu heben. Cookies markiere ich mit Secure und SameSite, damit Sitzungen geschützt bleiben und weniger Angriffsfläche bieten. Wo verfügbar, nutze ich HTTP/2 oder HTTP/3, um Latenzen zu reduzieren und die Seite flotter auszuliefern.
Content Security Policy und Header-Härtung
Ich gehe Header-strukturiert vor und rolle restriktive Policies schrittweise aus. Ein sanfter Start ist upgrade-insecure-requests, danach definiere ich Quellen explizit:
<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "geolocation=(), microphone=()"
</IfModule>
Mit einer strikten CSP (default-src 'self' plus gezielte Ausnahmen) verhindere ich das Nachladen unerwünschter Ressourcen. Report-Only eignet sich für Tests, bevor ich blockiere. Ich dokumentiere Ausnahmen, um spätere Audits zu vereinfachen.
Automatische Verlängerung und Monitoring
Let’s Encrypt Zertifikate laufen üblicherweise etwa 90 Tage, und All-Inkl übernimmt die Verlängerung automatisch. Ich prüfe regelmäßig das Verfallsdatum im Browser oder per Monitoring, damit keine Überraschungen auftreten. Fällt mir ein Problem auf, starte ich die Erneuerung manuell und kontrolliere anschließend Kette, Protokolle und Weiterleitungen erneut. Zusätzlich überwache ich die Verfügbarkeit und reagiere auf Zertifikatswarnungen, bevor Besucher etwas merken. Ein kurzer Kalender-Eintrag erinnert mich an einen erneuten Check, selbst wenn die Automatik zuverlässig arbeitet.
CDN, Reverse Proxy und Caching-Fallen
Nutze ich ein CDN oder einen Reverse Proxy, stelle ich „Full (strict)“-ähnliche Modi sicher und hinterlege am Origin ein gültiges Zertifikat. Ich prüfe Header wie X-Forwarded-Proto, damit die Anwendung das korrekte Schema erkennt (wichtig für absolute URLs). Für die Cache-Strategie gilt: Nach HTTPS-Umstellung invalidiere ich den CDN-Cache vollständig, um gemischte Stände zu vermeiden. Ich achte darauf, dass keine doppelten Caches (z. B. Plugin + CDN) divergierende Versionen ausliefern. Bei Signatur-Mechanismen (Subresource Integrity) aktualisiere ich Hashes, wenn Ressourcen von http auf https verschoben wurden.
SEO-Schritte nach HTTPS: Search Console, Sitemap, Backlinks
Nach der Aktivierung füge ich die https-Property in der Search Console hinzu und reiche eine frische Sitemap ein. Interne Verlinkungen und Canonicals kontrolliere ich in Templates und Header, damit alles sauber auf https zeigt. Analytics, Ads und externe Tools prüfe ich auf korrekt hinterlegte Adressen, damit Tracking und Conversions vollständig bleiben. Große Projekte profitieren davon, Backlinks zu wichtigen Seiten aktualisieren zu lassen, um Umleitungs-Ketten zu sparen. Für den Überblick nutze ich gern den kompakten HTTPS-Leitfaden als Checkliste für die letzten Schritte.
Internationalisierung, Hreflang und strukturierte Daten
Bei mehrsprachigen Projekten stelle ich sicher, dass hreflang-Tags konsistent die https-Varianten referenzieren. Canonicals und Alternate-Beziehungen dürfen keine Protokoll-Mischungen enthalten. In strukturierten Daten (Schema) verwende ich bevorzugt absolute https-URLs und gleiche Logo-, Bild- und Publisher-Referenzen an. Die robots.txt bleibt erreichbar und enthält die https-Sitemap-URL. Weiterleitungen beeinflussen das Crawling-Budget; stabile 301-Ziele helfen, unnötige Sprünge zu vermeiden.
Hosting und Performance im Vergleich
Ein passendes Hosting vereinfacht die SSL-Integration, liefert aktuelle Server-Stacks und sorgt für kurze Ladezeiten. In unabhängigen Tests liegen Anbieter mit Fokus auf Sicherheit und Tempo vorn, was sich im Alltagsbetrieb klar bemerkbar macht. All-Inkl punktet mit einfacher Bedienung, verlässlichen Tools im KAS und guter Zertifikatsverwaltung. Wer hohe Performance sucht, achtet auf HTTP/2/3, schnelle SSDs und ein sauberes Caching-Konzept. Die folgende Tabelle zeigt eine kurze Einordnung der Anbieter mit ihren Stärken.
| Ranking | Anbieter | Besonderheit |
|---|---|---|
| 1 | webhoster.de | Schnell & Hochsicher |
| 2 | all-inkl.com | Zuverlässig, einfach |
| 3 | Strato | Gute Erreichbarkeit |
Rollback-Plan und sichere Migration
Ich plane einen Rollback, falls nach der Umstellung kritische Integrationen streiken. Dazu gehören: Backup vorab, klare Liste geänderter Einstellungen, deaktivierbare Header (HSTS zunächst mit kurzer max-age) und ein Zeitfenster für Tests außerhalb von Peak-Traffic. Ich kommuniziere Deployments intern, damit Redaktion und Marketing Caches und Tools neu verbinden. Nach Abschluss dokumentiere ich Redirects, Header und Zertifikatsdaten, um Wartung und Audits zu erleichtern.
Kurz zusammengefasst
Ich aktiviere All-Inkl SSL im KAS, erzwinge HTTPS konsequent und beseitige Mixed Content direkt nach der Umstellung. Danach prüfe ich Kette, Protokolle und Ciphers, schalte HSTS zugeschnitten ein und sorge für automatische Verlängerung. In WordPress aktualisiere ich Adressen, räume hart verdrahtete Pfade auf und passe externe Einbindungen an. Für die SEO-Seite ergänze ich die https-Property in der Search Console, reiche eine frische Sitemap ein und halte Canonicals sauber. So steht die Site schnell sicher, lädt performant und stärkt Vertrauen wie Sichtbarkeit gleichermaßen.
