WordPress: So stellst du deine Website auf HTTPS um

WordPress auf HTTPS, also ein SSL-Zertifikat umzustellen, wird im Netz gern als schwierig dargestellt. Was könnte nicht alles passieren. Dabei ist es recht einfach und für jeden machbar, der etwas Erfahrung mit WordPress mitbringt und das CMS selbst installieren kann. In diesem Artikel führe ich dich nach und nach durch die einzelnen, nötigen Schritte.
In diesem Beitrag gehen wir davon aus, dass du bereits ein SSL-Zertifikat besitzt und dieses deiner Domain zugewiesen wurde. In über 90 Prozent aller Fälle sollte das so sein.

Nur bei einem eigenen dedizierten Server musst du diese Arbeit noch selbst erledigen. Komplizierter ist nur die Erstellung und Zuweisung eines kostenlosen Let’s Encrypt-Zertifikats. Ich gehe jedoch von einem vollwertigen und kostenpflichtigen https aus. Bei meinem Hoster kostet es zum Beispiel 23,90 Euro jährlich und wird sofort der Domain zugeordnet.

Wir beschäftigen uns also im folgenden Beitrag damit, wie du deiner bestehenden WordPress-Installation klar machst, dass sie fortan unter https läuft:

Schritt 1: Logge dich in den Adminbereich deines WordPress ein

Nachdem du dich eingeloggt hast, gehe zum Menüpunkt »Einstellungen => Allgemein« und ändere dort die beiden eingetragenen Adressen auf die HTTPS-Version um. Du musst nur das eine kleine „s“ ergänzen.

Wenn das für dich nicht funktionieren sollte, dann existiert noch eine zweite Lösung, die WordPress-Adressen umzustellen. Logge dich per (S)FTP in dein Webhosting-Paket oder deinen Server ein, und ergänze dort folgenden Code in der wp-config.php:

<?php
/* Unterhalb des Tabellen-Präfix in die wp-config.php einfügen. */
define( 'WP_SITEURL',     'https://www.deinewebsite.de' );
define( 'WP_HOME',        'https://www.deinewebsite.de' );
define( 'WP_CONTENT_URL', 'https://www.deinewebsite.de/wp-content' );

Kopiere den Code unterhalb des Tabellen-Präfixes ein, speichere und lade die Datei wieder hoch. Nun hast du über HTTPS Zugriff zu deiner Website.

Schritt 2: Überschreibe alle URLs in der Datenbank

Die dynamischen URLs, wie diejenigen der Scripte und der Dateien sind bereits über HTTPS erreichbar. Nun geht es darum, auch die statischen URLs der Bilder im Beitrag auf SSL umzustellen. Dazu kannst du ein Plugin nutzen, komfortabler und sicherer jedoch geht es mit dem Database Search and Replace Script von interconnect/it.

Bevor du das Script jedoch nutzt, lege bitte ein vollständiges Datenbank-Backup in phpMyAdmin an. Man weiß ja nie…

Script-Download und Aufruf

Lade dir den Script-Ordner herunter, entpacke ihn, benenne ihn in »replace« um, und lade den kompletten Ordner (nicht nur die Dateien!) in das Root-Verzeichnis deiner WordPress-Installation. Rufe das Script nun auf, indem du deine Domain plus replace in die Adresszeile deines Browsers eingibst.

https://deinewebsite.de/replace
Nun solltest Du das Script sehen können.

Die Zugangsdaten deiner Datenbank sind bereits eingetragen, du musst nur noch im linken oberen Feld deine alte URL eintragen und im rechten Feld die Version mit HTTPS. Andere Einstellungen sind nicht nötig. Ein Klick auf »live run« ändert nun die URLs in der Datenbank.

Das Script ändert die nötigen Einträge nun in relativ kurzer Zeit um. Es kann sein, dass es zu Fehlermeldungen kommt, weil das Script versucht, die Ausführungszeit und das PHP-Memory-Limit zu erhöhen. Diese Meldungen können getrost ignoriert werden.

Sobald dieser Arbeitsschritt fertig ist, scrolle das Script etwas herunter, bis der »Delete«-Button erscheint und klicke ihn an. Der Ordner mit dem Script wird nun vom Server gelöscht. Belasse ihn auf keinen Fall online, denn er stellt ein großes Sicherheitsrisiko dar.

Schritt 3: Änderungen der htaccess-Datei und der wp-config.php

.htaccess
In diesem letzten Schritt wird die .htaccess-Datei um einen wichtigen Punkt ergänzt. Der folgende Code bewirkt eine ständige 301-Weiterleitung von der HTTP- auf die HTTPS-Version deiner Website. Erstens ist deine Website dann nur noch über HTTPS zu erreichen, zweitens wird Google durch den Code mitgeteilt, dass keine HTTP-Version deiner Website mehr existiert.

# ----------------------------------------------------------------------
#  301 Redirekt von http auf https
# ----------------------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

wp-config.php
Das folgende Code-Snippet muss in die wp-config.php deines WordPress hinein, unterhalb des Tabellen-Präfixes.

<?php
// Login nur noch über SSL (https) möglich.define('FORCE_SSL_ADMIN', true);

Auf diese Weise ist nur noch ein Login über die HTTPS-Version möglich.

Die Alternative: Really Simple SSL

Ich persönlich finde es wichtig und richtig, stets genau zu wissen, wie etwas technisch funktioniert und wie ich selber zum Ergebnis kommen kann. Insofern sind für mich die bis hier geschilderten Schritte der Weg, den ich immer wieder gehen würde, wenn ich eine WordPress-Site auf HTTPS umstellen müsste.

Ich kann aber verstehen, wenn andere es sich so einfach wie möglich machen wollen. Und an dieser Stelle kommt das kostenlose WordPress-Plugin Really Simple SSL ins Spiel. Einmal installiert, leitet es dich assistentengestützt durch den Vorgang, bei dem du praktisch keine Fehler machen kannst und fünf Minuten später kannst du Erfolg vermelden.

Für die reine Umstellung reicht die kostenlose Version. Die Entwickler bieten für komplexere Problemlagen jedoch auch zu bezahlende Erweiterungen an.

Das Endergebnis

Du solltest nun, egal für welche Vorgehensweise du dich entschieden hast, auf der Startseite und auf allen Artikeln eine grüne Darstellung sehen.

Allerdings kann es durchaus sein, dass es noch Dateien gibt, die über HTTP kommen. Entweder wird das Schloss dann in Grau angezeigt, oder die Ressourcen werden vom Server gesperrt. Der Punkt Console in den Entwicklertools deines Browsers gibt darüber Auskunft und zeigt dir die Ressourcen an, die nicht verschlüsselt übertragen werden.

Unter Verwendung von Really Simple SSL hättest du dich bereits im Vorfeld darum gekümmert. Bei unserer Zu-Fuß-Variante kannst du es noch nachträglich erledigen.

Zumeist hat man diese Dateien selbst eingebunden, eventuell im Header oder Footer des Themes. Abhilfe schafft hier eine Einbindung der Datei mit //www.deine-datei.de ohne ein vorgesetztes HTTP oder HTTPS. Auf diese Weise wird immer – wenn möglich – die HTTPS-Version eingebunden und geladen.

Fazit: Das war nun wirklich nicht schwer, oder?

Genau nach dieser Anleitung vorgegangen, kann eigentlich nichts passieren und der Vorgang sollte in weniger als einer Stunde glücklich zu Ende gebracht sein. Wie ist es dir ergangen, hast du deine Website bereits auf HTTPS umgestellt?

---

WordPress und HTTP2: Das solltest du wissen

Im Mai 2015 wurde HTTP/2 als neuer Standard verabschiedet, um HTTP/1.1 abzulösen. Die möglichen Vorteile von HTTP/2 sind enorm, allerdings ist die Nutzbarkeit noch nicht ganz so einfach, wie angedacht. In diesem Artikel schauen wir kurz auf die Vorteile, die dieser Standard Seitenbetreibern bieten kann, und welche Voraussetzungen für eine Nutzung von WordPress und HTTP/2 erfüllt sein müssen.

Wie viele Artikel hast du schon zum Thema WordPress und die Ladegeschwindigkeit einer Website gelesen? Wenn es dir wie mir geht, wahrscheinlich sehr viele. Auch ich habe hier auf Dr. Web schon einige Artikel dazu veröffentlicht. Ein wichtiger Teil einer Performance-Optimierung ist der Server, ohne einen vernünftigen, mit einem modernen Betriebssystem ausgestatteten Server funktioniert keine Optimierung.

Das wäre wie gegen Windmühlen kämpfen. Da wir alle nicht Don Quijote sind, sollten wir solche Dinge gar nicht erst anfangen.

Was ist HTTP und wofür braucht man es?

Grundsätzlich ist HTTP (Hypertext Transfer Protocol) ein Weg, wie ein Webserver und ein Browser miteinander kommunizieren. HTTP ist also die Sprache, in sich Server und Browser miteinander unterhalten.

Ich werde in diesem Artikel nicht tief in die Materie eintauchen, wenn du mehr darüber erfahren möchtest, schau dir den Artikel auf Wikipedia dazu an. Zum ersten Mal tauchte HTTP im Jahre 1991 als Version 0.9 auf, sozusagen in der Jura des Internets.

Viel ist seitdem geschehen. Früher bestanden die Websites nur aus wenig mehr als etwas Hintergrundfarbe, ein bis zwei Grafiken, die im HTML verlinkt waren und viel Text. Die Websites damals waren nur einige KB groß, heute sind die Websites dagegen Schwergewichte mit zum Teil einigen MBs.

Gut beobachten kann man die Entwicklung der Websites am Beispiel von Dr. Web.

Heute ist die tatsächliche Anzahl von Dateien, die zusammen eine Website bilden, sehr stark angestiegen. Früher waren nur einige wenige Dateien zu laden, heute sind es dutzende, die es zu laden gilt. Dieser Fortschritt verschärft die Einschränkungen, die das alte Protokoll HTTP/1 mit sich bringt. Das Resultat ist eine erhöhte Latenz – oder auch Langsamkeit einer modernen Website.

Das wiederum erforderte die Entwicklung von HTTP/2. HTTP/2 kann durchaus als Evolution des alten Protokolls angesehen werden, denn das Hauptziel war das Verringern der Latenz und damit eine erhöhte Ladegeschwindigkeit mit modernen Web-Browsern.

Die Limitierung von HTTP/1

Heute müssen die Browser zur Darstellung einer Website dutzende, manchmal sogar hunderte von Dateien laden, damit eine Website dargestellt werden kann. Folgendes wird zur Darstellung geladen:

• Das HTML der Website
• Die Stylesheets (CSS)
• Das JavaScript
• Die Bilder
• Die Videos
• Externe Dateien für Google Analytics, Werbung und ähnliches
• Social-Sharing-Lösungen

Das große Problem bei HTTP/1 ist, dass der Browser für jede einzelne Datei, die im HTML, CSS und JavaScript erwähnt wird, eine Anfrage zu erstellen. Das können durchaus auch hunderte von Anfragen und Verbindungen sein. Hunderte von HTTP-Requests sind durchzuführen, was eine Website ganz schön langsam machen kann.

Speed-Optimierung unter HTTP/1

Aus dieser Limitierung heraus wurde ein spezielles Konzept erschaffen, wie man Websites trotz dieser Einschränkungen schneller machen konnte. Dateien wurden gebündelt, um Anfragen zu reduzieren, die Größe wurde durch Komprimierung reduziert und Grafiken zu einem Sprite zusammengefasst. HTTP/2 soll diese Probleme lösen und andere Wege anbieten.

Der Unterschied zwischen HTTP/1 und HTTP/2

Für die genaue Spezifikation von HTTP/2 besuche bitte das HTTP/2 GitHub FAQ. HTTP/2 wurde entwickelt, um von Maschinen und nicht von Menschen lesbar zu sein. Daher ist das neue Protokoll auch binär, denn das optimiert den Prozess der Kommunikation zwischen dem Browser und dem Server.

Es ist zudem weniger Fehleranfällig und kann Dinge wie Leerzeichen, Leerzeilen, Zeilenenden, Großschreibung und ähnliches besser interpretieren.

Der große Unterschied zwischen den beiden Protokollen sind jedoch die Verbindungen. HTTP/1 erlaubt nur eine einzige Verbindung zur Zeit, HTTP/2 kann jedoch mehrere Verbindungen gleichzeitig bearbeiten, da es nach dem Multiplexverfahren arbeitet.

• HTTP/1 muss für jede einzelne Datei eine Anfrage stellen
• HTTP/1 lädt eine Datei nach der anderen
• HTTP/2 hingegen kann mit einer Verbindung viele Dateien laden
• HTTP/2 erlaubt mehrere Verbindungen gleichzeitig

Das Server-Push Verfahren von HTTP/2

Das Server-Push-Verfahren ist eine Funktion, bei der der Server in der Tat weiß, welche Dateien der Browser benötigt, bevor dieser die Dateien tatsächlich anfragt. Der Server schiebt dann die Dateien an den Browser, ohne darauf zu warten, dass der Browser sie erbittet. Das gestaltet den gesamten Prozess der Anzeige einer Website wesentlich schneller als bisher.

Weitergehende Informationen unter Apache.org/Server Push

Wer mit dem Server-Push-Verfahren experimentieren möchte, findet hier ein kostenloses WordPress Plugin. HTTP/2 Server Push.

Darum ist HTTP/2 wesentlich effizienter

• Es kann die Verbindung zwischen dem Client und dem Server schneller erzeugen
• Die Verbindung zwischen Browser und Server ist effizienter und damit schneller
• Dateien und Ressourcen werden gleichzeitig übertragen
• Dateien können per Server-Push an den Browser geschoben werden
• Es können mehr Dateien gleichzeitig geladen und angezeigt werden

Die Online-Demo: der Unterschied zwischen HTTP/1 und HTTP/2

Wie kann ich HTTP/2 mit meiner Website einsetzen?

Ob du HTTP/2 bereits nutzen kannst, hängt ganz und gar von deinem Webhoster ab. Das neue Protokoll ist ein Teil des Server-Betriebssystems (Apache, NGINX oder ILS) und muss daher von deinem Hoster eingepflegt werden.

Solltest du einen eigenen Server haben, dann kannst du jederzeit auf HTTP/2 upgraden und selbst für Aktualität sorgen.

So nutzt du HTTP/2 mit deiner Website

Theoretisch sollte HTTP/2 mit jedem Browser ohne spezielle Konfigurationen nutzbar sein. Soweit die Theorie. In der Praxis schaut das leider ganz anders aus, denn die großen Browser-Hersteller haben sich dazu entschlossen, den Support für das neue Protokoll nur über TLS (HTTPS) zu ermöglichen. Hier eine aktuelle Liste von Browsern, die bereits HTTP/2 unterstützen:

Du benötigst also ein SSL-Zertifikat für deine Domain, denn nur mit einer SSL-Verschlüsselung wirst du in den Genuss des High-Speed Protokolls kommen.

Neue Wege gehen bei der Optimierung auf Speed

Die alten Wege der Speed-Optimierung funktionieren bei Einsatz von HTTP/2 nicht mehr, du würdest Potenzial verschenken. Der tägliche Einsatz des Protokolls heißt jedoch nicht, dass keine Dateien mehr zusammengefasst werden sollten, sondern nur, dass genau überlegt werden solle, welche Dateien nicht zusammengefasst werden.

Der mögliche Vorteil des gleichzeitigen Ladens vieler Ressourcen kann auch zu einer langsameren Website führen, wenn nun alle Dateien einfach nicht zusammengefasst und komprimiert werden. JavaScript in einer Datei komprimiert von – zum Beispiel – Autoptimize ausliefern zu lassen resultiert in einer schnelleren Ladezeit, weil die Datei durch optimiertes Caching nur einmal geladen wird, wenn eine entsprechende .htaccess-Datei vorliegt.

Als optimal hat sich nach extrem vielen Tests mein Weg für fortgeschrittene User zur Speed-Optimierung erwiesen. Hier die Links zur Serie:

Google forciert HTTPS

Es ist vor allem Google mit seiner Initiative „HTTPS everywhere“ zu verdanken, dass sichere Verbindungen als Standard zunehmend eine größere Rolle spielen. Spätestens die Ankündigung Googles im Jahr 2014, HTTPS als Rankingfaktor einzuführen, hat für eine größere Aufmerksamkeit für das Thema gesorgt. Allerdings hat Google selbst erklärt, dass derzeit nur ein Prozent der weltweiten Suchanfragen von diesem Rankingfaktor betroffen seien. Aber der Konzern hat ebenso mitgeteilt, dass er HTTPS als Rankingfaktor jederzeit deutlich höher bewerten könnte, um den Wechsel von HTTP zu HTTPS anzuregen.

Darüber hinaus hat Google seinem Browser Chrome ein derzeit noch standardmäßig deaktiviertes „Feature“ verpasst, welches nicht sichere Websites – also solche, die nur per HTTP ausgegeben werden – mit einem rot durchgestrichenem Vorhängeschloss kennzeichnet. Schon jetzt kannst du über „chrome://flags“ dieses Feature aktivieren. Suche in den Einstellungen einfach nach „Nicht sicheren Ursprung als nicht sicher markieren“.

Einstellungen für nicht sichere Verbindungen
Sollte Chrome diese Einstellung einmal standardmäßig aktivieren, würden alle einfachen HTTP-Verbindungen mit diesem Warnhinweis gekennzeichnet, während HTTPS-Verbindungen wie auch jetzt bereits mit einem grünen Vorhängeschloss gekennzeichnet würden. Besucher deiner Website könnten von dem Warnhinweis abgeschreckt werden und eine potenziell unsichere oder nicht vertrauenswürdige Website vermuten.

JavaScript-APIs nur für sichere Verbindungen

Die Kennzeichnung unsicherer Verbindungen ist jedoch nicht das einzige, was HTTP von HTTPS in deinem Browser unterscheidet. Moderne JavaScript-APIs, die beispielsweise den Zugriff auf Webcam und Mikrofon erlauben, lassen sich im Chrome und anderen Browsern ausschließlich per HTTPS ausführen.

Kamerazugriff nur per HTTPS möglich
Seit der Version 50 von Chrome ist es im Übrigen auch nicht mehr möglich, die Geolocation-API über eine unsichere Verbindung auszuführen. Konnte man den Standort eines Nutzers bislang über eine einfache HTTP-Verbindung auslesen, ist fortan zwingend HTTPS erforderlich.

Nicht auszuschließen ist, dass Google Chrome künftig weitere APIs nur in Kombination mit einer sicheren Verbindung ausführt. Angekündigt ist bereits, die Orientation- sowie die Fullscreen-API demnächst ebenfalls nur noch per HTTPS zuzulassen.

Kostenlose Zertifikate per „Let’s Encrypt“

Ein Grund gegen sichere Verbindungen war bislang für viele sicherlich der finanzielle Aspekt. Denn eine HTTPS-Verbindung gibt es nicht ohne Zertifikat. Und diese lassen sich Provider beziehungsweise die Aussteller solcher Zertifikate gut bezahlen. Mit der Initiative „Let’s Encrypt“ erstellst du dir jedoch ganz kostenfrei ein Zertifikat für deine Domains.

Und da die Zertifikate von „Let’s Encrypt“ mittlerweile von allen großen Browsers akzeptiert werden, besteht auch nicht die Gefahr, dass dein Browser einen Warnhinweis wegen eines unbekannten Ausstellers ausgibt. Die ersten Provider haben das Erstellen von „Let’s Encrypt“-Zertifikaten bereits in ihre Tarife übernommen, so dass du schnell und unkompliziert zu einer sicheren Verbindung für deine Website kommst.

Let’s Encrypt verspricht Zertifikate für alle und das noch vollkommen kostenlos. Das Projekt wird unter anderem von Mozilla, Facebook und Cisco gesponsert. Jeder Webmaster kann sich eigene Zertifikate für seine Domain erstellen, wenn der Server die technischen Voraussetzungen erfüllt.

Fazit

Der Einsatz von HTTP/2 lohnt sich definitiv, auch wenn du ein SSL-Zertifikat für die Website erwerben musst. Ein kostenfreies Zertifikat von Let’s Encrypt ist jedoch auch völlig ausreichend! Der Geschwindigkeitszuwachs kann enorm sein, je nach bereits vorhandenem Konzept für die Geschwindigkeits-Optimierung. Bei stark auf Performance getrimmten Websites, deren Server bereits PHP 7 einsetzen, ist der Zuwachs an Speed jedoch nur marginal, trotz Splitting von zu ladenden Dateien.

Neue Sicherheitseinstellungen in Chrome können schon bald dazu führen, dass kein Weg mehr an HTTPS vorbeiführt. Und dank „Let’s Encrypt“ gibt es eine kostenlose und – je nach Provider – einfache Möglichkeit, deine Website auch im Sinne des Datenschutzes deiner Besucher sicherer zu machen.

(Artikelbild: Depositphotos)

(Der Beitrag erschien erstmals im Juni 2016 und wird seitdem regelmäßig aktualisiert, zuletzt am 10.02.2020.)