HTTPS Weiterleitung prüfen: So testen Sie HTTP auf HTTPS richtig

Wir bei Talha Aslan und Team setzen diesen Test bei jedem Website Umzug und jedem technischen SEO Audit an den Anfang. Der Grund: Das Problem bleibt oft unsichtbar. Die Seite lädt, das Schloss erscheint, aber im Hintergrund läuft eine Kette aus zwei oder drei Schritten, ein temporärer 302 oder eine Pauschalregel, die alles auf die Startseite schickt. Für einen ersten schnellen Blick können Sie unseren kostenlosen Redirect Checker in einem zweiten Tab öffnen.

Dieser Ratgeber zeigt zunächst, wie ein korrektes Ergebnis aussieht. Danach folgt ein Test Schritt für Schritt, und anschließend geht es um HSTS, Mixed Content und Weiterleitungsketten. Jede Aussage stützen wir außerdem auf Primärquellen wie Google Search Central, IETF Standards und web.dev. Als Beispieladresse dient ausschließlich example.com.

Warum ist die HTTPS Weiterleitung so wichtig?

Wenn eine Website auf HTTPS umzieht, verschwinden die alten http Adressen nicht aus dem Netz. Alte Backlinks, Lesezeichen, E-Mail Signaturen, gedruckte Flyer und Links auf fremden Seiten zeigen weiterhin auf die http Version. Daher läuft jeder dieser Besuche über Ihre Weiterleitungsregel.

Laut Googles Dokumentation zu Weiterleitungen ist eine dauerhafte Weiterleitung ein Signal dafür, dass das Ziel die kanonische, also bevorzugte Version ist. Fehlt die Regel oder ist sie falsch, bleiben somit beide Versionen erreichbar. Google entscheidet dann selbst, welche Adresse erscheint, und Ihre Signale können sich auf zwei Adressen verteilen.

Auch Nutzer spüren den Unterschied. Zum Beispiel kann ein Formular, das noch über http lädt, eingegebene Daten unverschlüsselt übertragen. Deshalb muss die Weiterleitung auf jeder URL der Website funktionieren, nicht nur auf der Startseite. Die Grundlagen zum Zertifikat selbst erklärt unser Beitrag Was ist ein SSL Zertifikat.

Wie sieht eine korrekte Weiterleitung aus?

In der Praxis liefert eine korrekte Einrichtung ein einfaches Bild. Sie rufen http://example.com/leistungen/ auf, und der Server antwortet mit Status 301 sowie einem Location Header mit dem Wert https://example.com/leistungen/. Danach fragt der Client diese neue Adresse an und erhält Status 200. Insgesamt sind es zwei Schritte und eine Weiterleitung.

Achten Sie deshalb auf drei Details. Erstens muss der Statuscode dauerhaft sein. Zweitens muss der Pfad erhalten bleiben: /leistungen/ sollte auf /leistungen/ führen, nicht auf die Startseite. Drittens muss das Ziel die eine Version sein, die Sie bevorzugen; entscheiden Sie also vorab, ob Ihre Website mit oder ohne www läuft.

Vergleichen Sie als Beispielszenario zwei Ketten. Im gesunden Fall führt http://example.com/blog/ direkt zu https://example.com/blog/. Im fehlerhaften Fall geht es zunächst zu https://example.com/blog und dann, nach einer Regel für den abschließenden Schrägstrich, zu https://example.com/blog/. Auch die zweite Kette kommt am Ende an. Allerdings kostet sie bei jedem Besuch eine zusätzliche Runde.

Welchen Statuscode sollten Sie sehen: 301, 308 oder 302?

Der Wechsel von HTTP auf HTTPS ist dauerhaft, deshalb sollten Sie 301 oder 308 sehen. Googles Seite zu HTTP Statuscodes behandelt 308 als gleichwertig zu 301 und nennt beide ein starkes Signal für die Verarbeitung des Ziels. Dagegen wertet Google 302, 303 und 307 als schwaches Signal.

Der HTTP Standard der IETF, RFC 9110, ergänzt zu 301 außerdem einen wichtigen Hinweis. Aus historischen Gründen darf ein Client eine POST Anfrage im nächsten Schritt in GET umwandeln. Soll die Methode erhalten bleiben, ist 308 die Alternative. Die Unterschiede im Detail erklärt unser Beitrag 302 Weiterleitung und der Unterschied zu 301, 307 und 308.

Wie testen Sie die HTTPS Weiterleitung Schritt für Schritt?

Am zuverlässigsten prüfen Sie mit einem Tool, das bei jedem Schritt eine neue Anfrage sendet und jeden Statuscode einzeln auflistet. Diese Reihenfolge können Sie direkt auf Ihrer Website anwenden.

1. Öffnen Sie den Redirect Checker und tragen Sie Ihre Adresse mit http am Anfang, zum Beispiel http://example.com/, in das Feld Adresse (URL) ein.
2. Wählen Sie den Modus Einzelne URL und klicken Sie auf Prüfen. Jede Zeile der Kette zeigt Statuscode, Adresse und Antwortzeit.
3. Prüfen Sie die Zahl der Weiterleitungen. Ideal ist 1; ab 2 liegt eine Kette vor.
4. Lesen Sie den Typ. Sehen Sie nur 301 oder 308, ist die Regel dauerhaft; ein 302 oder 307 bedeutet eine temporäre Regel.
5. Stellen Sie sicher, dass der Endstatus 200 lautet und die Zieladresse mit https beginnt.
6. Wiederholen Sie den Test für eine Unterseite, einen Blogbeitrag und eine URL mit Parametern.
7. Starten Sie zum Schluss den Modus 4 Varianten und bestätigen Sie, dass alle vier Varianten Ihrer Domain am selben Ziel enden.

Unser Tool folgt einer Kette höchstens 10 Schritte weit. Diese Grenze entspricht der Zahl an Schritten, der die Crawler von Google im Allgemeinen folgen. Allerdings zeigt es keine Meta Refresh oder JavaScript Weiterleitungen, denn es liest nur die Statuscodes, die der Server liefert.

Warum sollten Sie alle vier Varianten Ihrer Domain testen?

Eine Domain hat mindestens vier Eingangstüren: http://example.com, http://www.example.com, https://example.com und https://www.example.com. Allerdings erfassen Serverregeln oft nur einen Teil davon und vergessen den Rest. Somit gibt Ihnen ein Test mit nur einer Variante eine falsche Sicherheit.

Ein Beispielszenario: http://example.com führt korrekt zu https://example.com. Dagegen führt http://www.example.com zunächst zu https://www.example.com und erst dann zu https://example.com. Die Hauptvariante wirkt fehlerfrei, doch jeder alte Link mit www durchläuft eine Kette aus zwei Schritten.

Googles Dokumentation zu Weiterleitungen empfiehlt: Ist Ihre Startseite unter mehreren URLs erreichbar, wählen Sie eine davon als bevorzugte Adresse und leiten die anderen dorthin weiter. Ihr Ziel ist also klar. Alle vier Varianten sollten in einem Schritt dieselbe https Adresse erreichen. Die bevorzugte Variante selbst sollte direkt Status 200 liefern.

• http ohne www: eine 301 Weiterleitung auf die bevorzugte Adresse.
• http mit www: ein Schritt, keine Kette, dasselbe Ziel.
• https auf dem nicht bevorzugten Host: eine 301 Weiterleitung auf die bevorzugte Adresse.
• https auf dem bevorzugten Host: direkt Status 200.

Warum zeigt Ihr Browser oft ein falsches Bild?

Http in die Adresszeile tippen und zusehen, wie die Seite unter https öffnet, ist kein echter Test. Dafür gibt es zwei technische Gründe, und beide stehen in offiziellen Standards.

Der erste Grund ist zunächst der Cache. Laut RFC 9110 ist eine 301 Antwort heuristisch cachebar. Ihr Browser kann sich also an eine frühere dauerhafte Weiterleitung erinnern und ohne Rückfrage beim Server direkt zu https springen. Selbst wenn jemand die Regel auf dem Server gelöscht hat, sieht in Ihrem Browser alles gut aus.

Der zweite Grund ist dann HSTS. Laut RFC 6797 wandelt ein Browser http Links zu einer Domain, die er als HSTS Host kennt, schon vor dem Senden einer Anfrage in https um. Die http Anfrage erreicht Ihren Server dann gar nicht. Folglich haben Sie die serverseitige Weiterleitung in Wahrheit nie getestet.

Kurz gesagt: Wenn Sie wissen möchten, was ein Erstbesucher oder ein Suchmaschinen Crawler sieht, brauchen Sie einen Client ohne Cache und ohne HSTS Eintrag. Deshalb liefert ein Checker, der auf einem Server läuft, ein genaueres Ergebnis.

Können Sie die Weiterleitung auch per Kommandozeile prüfen?

Technische Teams prüfen Weiterleitungen oft zusätzlich über die Kommandozeile. Die Logik ist dabei dieselbe wie bei unserem Tool. Sie senden eine Anfrage, die nur die Antwortheader abruft, und lesen dann Statuscode und Location Header. So beeinflussen weder Browsercache noch HSTS Eintrag das Ergebnis.

Beachten Sie dabei zwei Punkte. Erstens folgen viele Kommandozeilenprogramme Weiterleitungen standardmäßig nicht und zeigen nur die erste Antwort. Für die ganze Kette aktivieren Sie also die passende Option oder fragen jeden Schritt einzeln ab. Zweitens kann der DNS Cache Ihres Rechners oder ein Proxy im Firmennetz ein anderes Ergebnis erzeugen als bei einem externen Besucher.

Deshalb vergleichen wir ein Ergebnis aus der Kommandozeile immer mit einem Checker, der von außen arbeitet. Stimmen beide überein, können Sie beruhigt sein. Weichen sie ab, liegt die Ursache meist in einer Cacheschicht, einem CDN oder einer lokalen Netzwerkeinstellung. Konkret: Eine veraltete Regel im CDN fällt bei einem externen Test auf, Ihr lokaler Test kann sie dagegen übersehen. Zwei Blickwinkel statt einem machen aus einer stundenlangen Suche oft wenige Minuten Arbeit.

Was ist eine Weiterleitungskette und wie viele Schritte sind vertretbar?

Eine Weiterleitungskette entsteht, wenn eine Adresse vor dem Ziel mehr als eine Weiterleitung durchläuft. Beim Umzug auf HTTPS stammen Ketten meist aus drei Regeln: der Protokollregel, der www Regel und der Regel für den abschließenden Schrägstrich. Jede Regel ist für sich allerdings korrekt. Erst wenn sie nacheinander greifen, entsteht eine Kette.

Googles Leitfaden zum Websiteumzug mit URL Änderungen empfiehlt, direkt auf das endgültige Ziel weiterzuleiten. Geht das nicht, sollten Sie die Kette kurz halten, idealerweise höchstens 3 Weiterleitungen und weniger als 5. Zudem folgen die Crawler von Google im Allgemeinen bis zu 10 Schritten; eine längere Kette erreicht ihr Ziel womöglich nie.

In der Praxis setzen wir beim Umzug auf HTTPS ein klares Ziel: Keine Variante darf mehr als eine Weiterleitung brauchen. So entfällt für Nutzer die zusätzliche Wartezeit, und Crawler verschwenden keine Anfragen auf unnötige Schritte. Wie Sie Ketten finden und zusammenführen, zeigt unser Beitrag Weiterleitungskette beheben.

Woran erkennen Sie eine Weiterleitungsschleife?

Bei einer Schleife springen die Weiterleitungen zwischen Adressen hin und her, ohne je Status 200 zu erreichen. Im Browser endet das meist mit einer Fehlerseite, die von zu vielen Weiterleitungen spricht. Im Checker sehen Sie dagegen dieselbe Adresse zweimal in der Kette, und das Ergebnis lautet nie 200.

Beim Umzug auf HTTPS liegt die klassische Ursache in zwei Ebenen mit gegensätzlichen Regeln. Ein Beispielszenario: Ein CDN spricht mit Besuchern über https, verbindet sich aber per http mit Ihrem Ursprungsserver. Der Server sieht eine http Anfrage und leitet auf https um, und das CDN fragt erneut per http an. Daraus entsteht folglich eine endlose Runde.

Eine ähnliche Schleife sehen Sie, wenn die Adresseinstellung im CMS mit der Serverregel kollidiert. Um die Schleife zu lösen, listen Sie zunächst auf, welche Ebene welche Regel anwendet. Eine vollständige Anleitung finden Sie in unserem Beitrag ERR_TOO_MANY_REDIRECTS beheben.

Was ist HSTS und ersetzt es die HTTPS Weiterleitung?

HSTS ist eine Sicherheitsrichtlinie, mit der eine Website dem Browser sagt: Besuche mich ab jetzt nur noch über HTTPS. Konkret definiert sie RFC 6797. Der Server sendet die Richtlinie im Header Strict-Transport-Security, und der Pflichtwert max-age legt fest, wie viele Sekunden sie gilt.

HSTS ersetzt die HTTPS Weiterleitung nicht, sondern ergänzt sie. Der Standard nennt den Grund ausdrücklich. Ein Browser beachtet diesen Header nur über eine sichere Verbindung und muss ihn über reines http ignorieren. Ein Besucher muss also einmal eine https Seite erreichen, und genau dorthin bringt ihn die 301 Weiterleitung.

Der Standard räumt zudem ein, dass der erste Besuch deshalb ungeschützt bleibt. Kennt der Browser die Richtlinie noch nicht, geht die erste Anfrage über einen unsicheren Kanal. Als mögliche Abhilfe nennt der Standard Listen, die Browser bereits vorinstalliert mitbringen. Allerdings lässt sich die Aufnahme in eine solche Liste nur mühsam rückgängig machen. Daher sollten Weiterleitung und Zertifikat vorher fehlerfrei laufen.

Worauf sollten Sie achten, bevor Sie HSTS aktivieren?

HSTS ist ein starkes Werkzeug, und eine fehlerhafte Konfiguration wirkt ebenso stark. Der HTTPS Leitfaden von web.dev rät, HSTS erst dann zu aktivieren, wenn Ihre Website zuverlässig läuft. Denn Browser, die die Richtlinie gespeichert haben, können Nutzer bei einem Zertifikatsproblem komplett aussperren.

Deshalb gehen wir in dieser Reihenfolge vor:

1. Prüfen Sie zunächst ohne Weiterleitung, ob die HTTPS Version auf allen Seiten funktioniert.
2. Aktivieren Sie dann die 301 Weiterleitung und testen Sie alle vier Varianten.
3. Kontrollieren Sie Zertifikat und Zertifikatskette mit unserem SSL Check.
4. Starten Sie HSTS mit einem niedrigen max-age und erhöhen Sie den Wert schrittweise, solange nichts bricht.
5. Ergänzen Sie includeSubDomains nur, wenn alle Subdomains sicher HTTPS unterstützen.

Laut Standard dehnt includeSubDomains die Richtlinie auf alle Subdomains aus. Läuft zum Beispiel ein alter Adminbereich oder eine Testumgebung auf einer Subdomain noch rein über http, kann diese Option den Zugriff darauf abschneiden. Außerdem hält der Standard fest, dass ein max-age von null die Richtlinie aufhebt. Browser erfahren davon allerdings erst bei ihrem nächsten sicheren Besuch.

Warum sollten Sie Mixed Content separat prüfen?

Selbst bei perfekter Weiterleitung können Bilder, Skripte und Stylesheets einer Seite noch http Adressen nutzen. Web.dev nennt das Mixed Content, also gemischte Inhalte. Die Seitenadresse lautet zwar auf HTTPS, einige Ressourcen kommen aber über eine unverschlüsselte Verbindung.

Web.dev unterscheidet zudem zwei Arten. Passiver Mixed Content umfasst Bilder, Video und Audio; der Browser kann die Seite als nicht sicher kennzeichnen, und Chrome versucht manchmal, diese Dateien selbst auf https anzuheben. Aktiver Mixed Content umfasst Skripte, Stylesheets und iframes, und die meisten Browser blockieren ihn standardmäßig. Somit funktionieren Menüs nicht mehr, Formulare versagen oder das Layout bricht.

Ein Redirect Checker zeigt nur den Weg der Seitenadresse, nicht die Ressourcen innerhalb der Seite. Deshalb prüfen Sie Mixed Content in den Entwicklertools Ihres Browsers, etwa im Bereich für Probleme und in der Konsole. Die dauerhafte Lösung: Ressourcen mit https oder als protokollunabhängige relative Pfade einbinden. Mehr dazu lesen Sie in unserem Beitrag Mixed Content Fehler beheben.

Leiten Unterseiten und URLs mit Parametern korrekt weiter?

Der häufigste Fehler, den wir sehen: Jemand testet nur die Startseite und hält die Sache für erledigt. Ob eine Regel Pfad und Parameter erhält, erkennen Sie aber erst an Unterseiten. Manche Regeln schicken jede http Anfrage auf die https Startseite, und dann besteht der Test der Startseite trotzdem.

Ein Beispielszenario: Testen Sie http://example.com/produkte/stuhl?farbe=blau, sollte das Ziel https://example.com/produkte/stuhl?farbe=blau lauten. Lautet das Ziel https://example.com/, verwirft die Regel den Pfad. Fehlt der Teil ?farbe=blau, geht der Query String verloren, und mit ihm verschwinden auch Kampagnenparameter.

Nehmen Sie daher Folgendes in Ihre Testliste auf:

• Die Startseite und Ihre drei meistbesuchten Seiten.
• Eine Kategorieseite oder Leistungsseite und einen Blogbeitrag.
• Zudem eine URL mit Parametern, etwa einen Kampagnenlink mit UTM Parametern.
• Eine direkte Dateiadresse, etwa ein Bild oder ein PDF.
• Eine Adresse, die nicht existiert; sie sollte nach dem Umzug auf https Status 404 liefern, nicht die Startseite.

Zeigen interne Links, Canonicals und Sitemap schon auf HTTPS?

Eine Weiterleitung ist also ein Sicherheitsnetz für alte Adressen. Ihre eigene Website sollte sich im Alltag nicht darauf verlassen. Googles Leitfaden zum Websiteumzug empfiehlt ausdrücklich, interne Links von den alten auf die neuen URLs umzustellen. Sonst läuft jeder interne Klick über eine unnötige Weiterleitung.

Derselbe Leitfaden verlangt auf jeder neuen URL ein Canonical Tag, das auf die Seite selbst verweist. Zudem sollen Sie nach dem Start der Weiterleitungen prüfen, ob die Canonical Angaben auf die neuen URLs zeigen. Außerdem empfiehlt er eine Sitemap mit den neuen URLs, die Sie in der Search Console einreichen. Typische Fehler haben wir unter Canonical Fehler erkennen und beheben gesammelt.

Ein praktischer Test: Durchsuchen Sie den Quelltext der Seite nach http:// und prüfen Sie jeden Treffer, der auf Ihre eigene Domain zeigt. Jeder davon ist entweder ein interner Link oder eine Ressource, und beide brauchen eine Korrektur. Auch web.dev empfiehlt, interne URLs unabhängig vom Protokoll zu halten. Links auf fremde Websites stellen Sie dagegen nur um, wenn diese Seite HTTPS unterstützt.

Wie beobachten Sie den Umzug in der Search Console?

Googles Leitfaden zum Websiteumzug empfiehlt, in der Search Console sowohl die HTTP als auch die HTTPS Variante Ihrer Website zu bestätigen. So beobachten Sie nebeneinander, wie die alte Version den Index verlässt und die neue ihren Platz einnimmt. Laut demselben Leitfaden brauchen Sie für den Wechsel von HTTP auf HTTPS das Tool zur Adressänderung nicht.

Achten Sie allerdings auf ein Detail. Googles Seite zu HTTP Statuscodes sagt, dass die Prüftools von Google Weiterleitungen nicht folgen. Prüfen Sie also die http Adresse, sehen Sie nur die Weiterleitung selbst. Den Status der Zielseite erfahren Sie erst, wenn Sie die https Adresse separat prüfen.

In den Wochen nach dem Umzug sollten unter den indexierten Seiten weniger http und mehr https URLs auftauchen. Google kann die weitergeleitete URL eine Zeit lang als alternativen Namen behalten, und das ist normal. Wie Sie den Bericht lesen, erklärt unser Beitrag Search Console HTTPS Bericht.

Wie lange sollte die HTTPS Weiterleitung bestehen bleiben?

Die kurze Antwort: so lange wie möglich. Googles Leitfaden zum Websiteumzug rät, Weiterleitungen so lange wie möglich beizubehalten, im Allgemeinen mindestens ein Jahr. Beim Umzug auf HTTPS empfehlen wir, noch weiter zu gehen, denn es gibt keinen guten Grund, diese Regel je zu entfernen.

Bedenken Sie zunächst Folgendes. Alte http Links auf anderen Websites bleiben nämlich jahrelang bestehen, weil niemand sie ändert. Fällt die Regel weg, öffnen diese Links entweder eine unverschlüsselte Seite oder funktionieren gar nicht mehr. Zudem ist die HTTPS Weiterleitung meist eine einzige Serverregel mit kaum Pflegeaufwand. Das Entfernen bringt also Risiko, das Behalten kostet fast nichts.

Prüfen Sie bei jedem Server oder Hostingwechsel, ob diese Regel in die neue Umgebung mitgekommen ist. Denn genau das vergessen viele bei einem Umzug. Zur allgemeinen Frage der Dauer lesen Sie unseren Beitrag Wie lange 301 Weiterleitungen behalten.

Welche Methode der Weiterleitung sollten Sie wählen?

Googles Dokumentation zu Weiterleitungen nennt serverseitige Weiterleitungen als die Methode, die Google am wahrscheinlichsten richtig deutet. Dabei richten Konfigurationsdateien oder serverseitiger Code die Weiterleitung ein, und der Statuscode kommt direkt mit der Antwort.

Ist eine serverseitige Weiterleitung nicht möglich, bleibt Meta Refresh als Option. Google wertet einen sofortigen Meta Refresh mit null Sekunden als dauerhaft und einen verzögerten als temporär. JavaScript Weiterleitungen empfiehlt Google nur als letzten Ausweg, weil Google die Weiterleitung womöglich nie sieht, wenn das Rendering scheitert.

Speziell beim Umzug auf HTTPS sind Meta Refresh und JavaScript unpraktisch. Beide setzen voraus, dass zuerst die http Seite lädt, also landet der Besucher zumindest kurz auf einer unverschlüsselten Seite. Deshalb empfehlen wir für die HTTPS Weiterleitung eine Regel auf Server oder CDN Ebene. Auch unser Checker liest nur Serverantworten und prüft damit genau diese Methode.

Welche Fehler treten am häufigsten auf?

Bei den Websites, die wir prüfen, kehren dieselben Fehler immer wieder. Die folgende Liste fasst die Punkte zusammen, auf die Sie besonders achten sollten.

• Temporäre Codes: Ein verbliebener 302 bei einem dauerhaften Umzug sendet Google ein schwaches Signal.
• Ketten: Protokollregel, www Regel und Schrägstrichregel greifen nacheinander.
• Verlorene Pfade: Jede http URL landet auf der https Startseite.
• Verlorene Parameter: Kampagnenparameter fehlen am Ziel.
• Rückstufung von HTTPS auf HTTP: Eine alte Regel arbeitet genau in die falsche Richtung.
• Vergessene Subdomains: Blog, Shop oder Adminbereich auf einer Subdomain haben keine Regel.
• Veraltete interne Links: Das eigene Menü zeigt noch auf http URLs.
• Übereiltes HSTS: Ein hoher max-age sperrt Nutzer bei einem Zertifikatsfehler aus.

Eine einzige Testrunde deckt also die meisten dieser Fehler auf. Manche, etwa fehlende Subdomains, zeigen sich allerdings erst, wenn Sie alle Varianten der Domain auflisten.

Was sollten Sie nach dem Umzug wann prüfen?

Ein Umzug auf HTTPS wirkt wie eine einmalige Einstellung, doch jede Änderung an der Website kann die Regel brechen. Theme Updates, Pluginwechsel, Serverumzüge und neue CDN Einstellungen stehen dabei ganz oben. Deshalb hilft ein fester Prüfplan.

Zieht die Website auf eine neue Domain oder in eine neue Struktur um, ist der HTTPS Test nur ein Teil einer größeren Liste. Dann empfehlen wir, zusätzlich die Schritte unserer Checkliste für die Website Migration abzuarbeiten.

Fazit: Welches Ergebnis sollte Sie beruhigen?

Zusammengefasst sieht eine gesunde HTTPS Weiterleitung so aus. Jede der vier Varianten erreicht mit einer einzigen 301 oder 308 Weiterleitung dieselbe https Adresse. Die bevorzugte Variante liefert direkt Status 200, und Unterseiten behalten Pfad und Parameter. Außerdem zeigen interne Links, Canonical Tags und Sitemap bereits auf https URLs.

Ergänzen Sie dann HSTS in einer vorsichtigen Reihenfolge, schützen Sie Ihre Nutzer und senden Suchmaschinen ein einheitliches Signal. Räumen Sie zusätzlich den Mixed Content auf, verschwinden auch die Warnungen im Browser.

Ein einmaliger Test reicht nicht, also wiederholen Sie dieselbe Liste nach jeder größeren Änderung. Wir bei Talha Aslan und Team beginnen diese Liste bei jedem technischen Audit von vorn, denn selbst die einfachste Regel kann nach einem unerwarteten Update still und leise brechen.

Quellen: Google Search Central: Weiterleitungen und die Google Suche, Google Search Central: Websiteumzug mit URL Änderungen, Google Search Central: HTTP Statuscodes, IETF RFC 6797: HSTS, web.dev: Was ist Mixed Content?

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.