Wie Sie ihre Website mit HTTPs sicherer machen können.

Trotz der zahlreichen Vorteile der Umstellung auf HTTPs, viele SEOs und Webmaster haben bisher die Umstellung nicht realisiert. Für diejenigen, die sich durch die Aussicht auf einen Wechsel zu HTTPs eingeschüchtert fühlen, habe ich diesen Beitrag geschrieben.

In der Vergangenheit bin ich naiverweise davon ausgegangen, dass viele Webmaster vor dem Hintergrund der vielen Vorteile, recht zeitnah realisieren würden. Dies war aber nicht der Fall.

Mittlerweile habe ich mit Hunderten von Geschäftsinhabern und SEOs über Upgrades gesprochen, Dutzende von Upgrades durchgeführt und Dutzende von Problemen behoben. Ich habe erkannt, dass es immer noch eine große Hürde für Geschäftsinhaber und SEOs gibt: HTTPs. Das größte Hindernis bei HTTP/2 ist, dass die meisten Browser dieses neue Protokoll nur über eine sichere Verbindung unterstützen, was bedeutet, dass Sie ihre Websites auf HTTPs migrieren müssen.

Es sollte niemanden schockieren, dass Google und viele andere das Internet sicherer machen wollen. Google kündigte schon vor einiger Zeit HTTPs als Rankingsignal an und Sie haben begonnen, sichere Seiten über ungesicherte Seiten zu indizieren. Sie haben sogar ihren eigenen Leitfaden „Securing your website with HTTPs“, den ich jedem auf diesem Weg empfehlen möchte.

Doch bei all dem Drang zu seinem sichereren Web bleibt die Tatsache bestehen, dass weniger als 0,1% der Website bisher als sicher eingestuft werden können.

Es scheint, als ob jeder versucht, den Wechsel so einfach wie möglich zu gestalten, indem er Eintrittsbarrieren wie die Kosten beseitigt. Let`s Encrypt bietet kostenlose Zertifikate an. Viele Website-Hosts und CDNs bieten auch kostenlose Sicherheitszertifikate an, um die Leute zu ermutigen, den Wechsel vorzunehmen, aber die Leute bewegen sich immer noch nicht.

Warum auf HTTPs umstellen?

Google nennt mehrere Gründe für den Wechsel zu HTTPs in seinem Website-Migationshandbuch:

Daten, die über HTTPs gesendet werden, werden über das Transport Layer Security Protocol (TLS) gesichert, das drei wichtige Schutzschichten bietet:

Verschlüsselung der ausgetauschten Daten, um sie vor Lauschangriffen zu schützen. Das heißt, während der Benutzer auf einer Website surft, kann niemand seine Gespräche „hören“, seine Aktivitäten über mehrere Seiten verfolgen oder seine Informationen stehlen.

Datenintegrität: Daten können während der Übertragung weder absichtlich noch anderweitig verändert oder beschädigt werden, ohne entdeckt zu werden.

Authentifizierung: Beweist, dass ihre Benutzer mit der beabsichtigten Website kommunizieren. Es schützt vor Man-in-the-Middle-Angriffen und schafft Vertrauen bei den Anwendern, was sich in weiteren Geschäftsvorteilen niederschlägt.

Es gibt aber noch weitere Vorteile, wie z.B. die bereits erwähnte Steigerung des Google-Rankings.

Die Umstellung auf HTTPs hilft auch beim Verlust von Empfehlungsdaten, die entstehen, wenn der Empfehlungswert im Header beim Wechsel von einer sicheren auf eine ungesicherte Website verloren geht. Analyseprogramme schreiben den Traffic ohne den Empfehlungswert als direkt zu, was zu einen großen Teil den sogenannten „dark traffic“ ausmacht.

Die Umstellung verhindert auch viele schlechte Dinge, wie z.B. wenn AT&T Anzeigen in ihre Hotspots einspeist. Sie wären nicht in der Lage gewesen, diese Anzeigen auf einer Website mit HTTPs einzuspeisen.

Schützt HTTPs meine Website?

Menschen hören HTTPs als sicheres Protokoll und Sie denken, dass dies ihre Website schützt. Tatsache ist, dass ihre Website nicht geschützt ist und Sie können immer noch anfällig für eine oder mehrere der folgenden Situationen sein:

  • Downgrade-Angriffe.
  • SSL/TLS-Schwachstellen.
  • Heatbleed oder Logjam.
  • Hacks einer Website, eines Servers oder eines Netzwerkes.
  • Software-Schwachstellen.
  • Brute-Force-Angriffe.
  • DDOS-Angriffe.

Umschalten von HTTP auf HTTPs.

Beginnen Sie mit einem Testserver. Das ist wichtig, weil Sie damit alles richtig machen und testen können, ohne es in Echtzeit zu vermasseln. Selbst wenn Sie den Wechsel ohne einen Testserver durchführen, gibt es fast nichts, von dem Sie sich nicht erholen können, aber es ist immer noch die beste Praxis, einen Plan zu haben und alles vorzeitig testen zu lassen.

Durchsuchen Sie die aktuelle Website, damit Sie den aktuellen Zustand der Website kennen und vergleichen können.

Lesen Sie die Dokumentation zu ihrem Server oder CDN für HTTPs. Ich habe viele lustige CDN-Probleme, aber es kann auch einfach sein.

Holen Sie sich ein Sicherheitszertifikat und installieren Sie es auf dem Server. Dies hängt von ihrer Hosting-Umgebung und sem Server-Setup ab, so dass ich nicht mehr ins Detail gehen kann, aber der Prozess in der regel gut dokumentiert.

Referenzen im Inhalt aktualisieren. Dies kann in der Regel durch ein Suchen und Ersetzen in der Datenbank erfolgen. Sie möchten alle Verweise auf interne Links aktualisieren, um HTTPs oder relative Pfade zu verwenden.

Referenzen in Vorlagen aktualisieren. Je nachdem, wie Sie es einsetzen, kann dies mit Git oder einfach Notepad++ geschehen, aber Sie sollten sicherstellen, dass Verweise auf Skripte, Bilder, Links und so weiter entweder HTTPs oder relative Pfade verwenden.

Kanonische Tags aktualisieren. Die meisten CMS-Systeme übernehmen das für Sie, wenn Sie den Wechsel vornehmen, aber überprüfen Sie das noch einmal, denn das ist nicht immer der Fall.

Aktualisieren Sie hreflang-Tags, wenn ihre Website sie verwendet oder andere Tags wie OG-Tags für diese Angelegenheit. Die meisten CMS-Systeme werden sich darum kümmern, aber es ist am besten für den Fall der Fälle.

Aktualisieren Sie alle Plugins/Module/Add-Ons, um sicherzustellen, dass nichts kaputt geht und dass nichts unsichere Inhalte enthält. Ich suche häufig, dass die interne Suche und die Formulare fehlen.

Eventuell müssen CMS-spezifische Einstellungen geändert werden. Bei großen CMS-Systemen sind diese in aller regel in Migrationsleitfäden gut dokumentiert.

Crawlen Sie die Seite, um sicherzustellen, dass Sie keine Links verpasst haben und nichts kaputt ist. Sie können jeden unsicheren Inhalt in einen der Screaming-Frog-Berichte exportieren, wenn dies der Crawler ist, den Sie verwenden.

Stellen Sie sicher, dass alle externen Skripte HTTPs unterstützen.

HTTPs mit Redirects erzwingen. Dies hängt von ihrem Server und ihrer Konfiguration ab, ist aber für Apache, Nginx und IIS gut dokumentiert.

Aktualisieren Sie alte Ridirects, die derzeit vorhanden sind. Ich habe bereits in Vergangenheit schon erwähnt, dass ich beim Wechsel zu HTTPs nie einen Rückgang der Rangliste oder des Datentraffics hatte und viele Leute haben mich dazu befragt. Due Dilligence bei Ridirects und Ridirect-Ketten ist wahrscheinlich der Unterschied, denn das ist es, was ich bei der Fehlersuche bei Migrationen am meisten vermasselt sehe.

Aktualisieren Sie die Sitemaps, um HTTPs-Versionen der URLs zu verwenden.

Aktualisieren Sie ihre robots.txt-Datei, um ihre neue Sitemap einzubinden.

HSTS aktivieren. Dadurch wird der Browser angewiesen, immer HTTPs zu verwenden, wodurch eine serverseitige Prüfung entfällt und ihre Website schneller geladen wird. Dies kann auch manchmal zur Verwirrung führen, da die Umleitung also 307 angezeigt wird. Es könnte jedoch eine 301 oder eine 302 dahinter haben und Sie müssen möglicherweise ihren Browser-Cache leeren, um zu sehen, welche.

Aktivieren Sie das OCSP-Stapling. Dadurch kann ein Server prüfen, ob ein Sicherheitszertifikat widerrufen wird, statt eines Browsers, der verhindert, dass der Browser heruntergeladen odfer mit der ausstellenden Zertifizierungsstelle verglichen werden muss.

Fügen Sie HTTP/2- Support hinzu.

Fügen Sie die HTTPs-Version ihrer Website zu allen Suchmaschinenversionen der von ihnen verwendeten Webmaster-Tools hinzu und laden Sie die neue Sitemap mit HTTPs. Dies ist wichtig, da ich gesehen habe, dass der Datentraffic in Wirklichkeit in das HTTPs-Profil verschoben wurde. Ein weiterer Hinweis ist, dass Sie beim Wechsel von HTTP zu HTTPs das Change of Address Tool nicht verwenden müssen.

Aktualisieren Sie ihre Disavow-Datei, falls Sie eine für die HTTPs-Version hatten.

Aktualisieren Sie ihre URL-Parameter-Einstellungen, wenn Sie diese konfiguriert haben.

Gehen Sie online.

Stellen Sie in ihrer Analyseplattform sicher, dass Sie die Standard-URL aktualisieren, falls eine solche erforderlich ist, um sicherzustellen, dass Sie HTTPs korrekt verfolgen und fügen Sie Notizen über die Änderung hinzu, damit Sie wissen, wann sie aufgetreten ist.

Aktualisieren Sie ihre Social Share Counts.

Aktualisieren Sie alle kostenpflichtigen Medien-, E-Mail- oder Marketing-Automatisierungskampagnen, um die HTTPs-Versionen der URLs zu verwenden.

Aktualisieren Sie alle anderen Tools wie A/B-Testsoftware, Heatmaps und Keyword-Tracking, um die HTTPs-Versionen der URLs zu verwenden.

Überwachen Sie alles während der Migration und stellen Sie sicher, dass alles reibungslos läuft. Es gibt so viele Orte, an denen Dinge schief gehen können und es scheint, als gäbe es normalerweise mehrere Probleme, die bei jedem Wechsel zu HTTPS auftreten.

Eine Frage, die mir oft gestellt wird, ist, ob eingehende Links bereinigt werden sollen. Das ist eine riesige Menge an Einsatz und Anstrengung. Wenn Sie Zeit haben, dann sicher; aber höchstwahrscheinlich sind Sie mit anderen Dingen beschäftigt und ich glaube nicht, dass es absolut notwendig ist. Sie sollten jedoch die Links auf allen von Ihnen kontrollierten Eigenschaften aktualisieren, z. B. auf sozialen Profilen.

Häufige Probleme bei HTTPs-Migrationen.

Zu den Dingen, die schiefgehen können, gehören:

  • Verhindern, dass Google die HTTP-Version der Website crawlt oder generell verhindert, dass die Website crawlt.
  • Probleme bei der Veröffentlichung von Inhalten, wobei sowohl HTTPs- als auch HTTP-Versionen der Seiten angezeigt werden und
  • verschiedene Versionen der Seite auf HTTP und HTTPS.

Die meisten der häufigsten Probleme mit HTTPS-Migrationen sind das Ergebnis falsch implementierter Redirects. (Ich hatte auch Spaß beim Aufräumen von Websites, die ihre gesamte Struktur/Design verändert haben, während ich auf HTTPS umgestiegen bin.)

Redirects vedienen einen eigenen Bereich.

Wie oben erwähnt, haben die Hauptprobleme, die ich bei der Migration auf HTTPS sehe, mit Redirects zu tun. Es hilft nicht, dass die Änderung auf Registrar-Ebene, in der Serverkonfiguration oder sogar in einer .htaccess-Datei durchgeführt werden kann; alle haben ihre eigenen kleinen Problemchen.

Fehlgeschlagene Redirects und Redirect-Ketten sind fast immer Probleme. Achten Sie darauf, sowohl die Unterseiten als auch die Startseite zu überprüfen; je nachdem, wie die Regeln geschrieben sind und wo sie platziert sind, können diese unterschiedlich betroffen sein. Sie müssen auch wirklich betrachten, was mit diesen bis zu den Statuscodes und den Hops los ist, nicht gerade ob sie Sie an die korrekte Seite gelangen.

Es hilft definitiv nicht, wenn die Dokumentation des Apache dafür keinen 301 enthält und der Apache auf 302 voreingestellt ist. Der folgende Code sollte auf R=301 aktualisiert werden.

RewriteEngine On
# This will enable the Rewrite capabilities

RewriteCond %{HTTPS} !=on
# This checks to make sure the connection is not already HTTPS

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] # This rule will redirect users from their original location, to the same location but using HTTPS.
# i.e. http://www.example.com/foo/ to https://www.example.com/foo/
# The leading slash is made optional so that this will work either in httpd.conf
# or .htaccess context

Ich habe gesehen, wie sich Seiten von diesem Fehler beim Wechsel erholen, aber es scheint nur einige Monate später zu passieren, wenn Google herausfindet, was passiert ist und den Fehler an ihrem Ende korrigiert.

Vertrauen, aber bestätigen. Ich benutze Tools wie Screaming Frog und Ayima Redirect Path, um einige der alten URLs schnell zu überprüfen – oder, mit einigen Excel-Manipulationen, um Massenchecks auf große Mengen von URLs und älteren Redirects durchzuführen. So wird sichergestellt, dass alles richtig und ohne Mehrfachsprünge umgelenkt wird.

Abschließende Gedanken.

Einfach ausgedrückt, HTTPS geht nicht weg. HTTP/2, Google AMP und Googles QUIC-Protokoll erfordern sichere Verbindungen für Browser, um sie nutzen zu können. Die Tatsache bleibt, dass HTTPS von den Kräften, die da sind, stark gefordert wird und es ist an der Zeit, den Wechsel vorzunehmen.

Die meisten der Probleme, die ich sehe, sind auf eine schlechte Planung, eine schlechte Umsetzung oder ein schlechtes Tracking zurückzuführen. Wenn Sie die von mir beschriebenen Schritte befolgen, sollten Sie bei der Migration von HTTP nach HTTPS wenig bis keine Probleme haben.

Vielen herzlichen Dank für ihren Besuch.

2018-04-13T15:36:10+00:00 By |