HTTPS Bericht in der Search Console: Warum laufen Seiten nicht über HTTPS?

Kurz gesagt zeigt Ihnen dieser Bericht, ob Ihre HTTPS Umstellung aus Sicht von Google wirklich abgeschlossen ist. Das Schloss im Browser reicht dafür nicht. Denn Google behandelt bei manchen Seiten vielleicht noch die alte HTTP Version als Hauptadresse. Wir, Talha Aslan und Team, öffnen diesen Bericht deshalb bei jedem technischen Audit sehr früh.

Die offizielle Hilfeseite zum HTTPS Bericht beschreibt auch den Idealzustand klar: Der Bericht sollte gar keine HTTP URLs mehr auflisten. Ihr Ziel ist also, die Zahl der HTTP URLs so nah wie möglich an null zu bringen.

Wo finden Sie den HTTPS Bericht und für welche Properties gilt er?

Sie öffnen den Bericht in der Search Console über den Bereich mit allen Berichten und Tools (All reports and tools). Allerdings erscheint er nicht bei jedem Property Typ. Laut Google funktioniert der HTTPS Bericht nur bei Domain Properties und bei Properties mit URL Präfix, das mit HTTPS beginnt.

Dieses Detail zählt in der Praxis. Haben Sie zum Beispiel vor Jahren nur eine Property mit dem Präfix http://example.com angelegt, finden Sie den Bericht dort nicht. In diesem Fall empfehlen wir eine Domain Property. Dann sehen Sie HTTP, HTTPS, www und die Variante ohne www auf einem Bildschirm.

• Domain Property: Der Bericht ist verfügbar und deckt alle Protokolle und Subdomains ab.
• Property mit HTTPS Präfix: Der Bericht ist verfügbar und deckt nur dieses Präfix ab.
• Property mit HTTP Präfix: Der Bericht fehlt.

Falls Sie neu in der Search Console sind, lesen Sie zunächst unsere Search Console Anleitung für Einsteiger. Solange die Bestätigung der Property fehlt, sollten Sie sich nicht auf die Daten dieses Berichts verlassen.

Was sagen Ihnen die Zahlen im HTTPS Bericht genau?

Der Bericht zeigt zwei Hauptwerte: indexierte HTTPS URLs und indexierte HTTP URLs. Danach gruppiert er die HTTP URLs nach Problemen. Auf den ersten Blick lesen Sie also das Verhältnis, auf den zweiten Blick die Verteilung der Fehler.

Beachten Sie allerdings einen Punkt. Google weist darauf hin, dass der Bericht nur eine Stichprobe zeigt und keine vollständige Liste. Daher bedeuten 40 gelistete URLs nicht, dass nur 40 Seiten betroffen sind. Lesen Sie den Bericht wie eine Karte der Symptome. Die eigentliche Ursache suchen Sie dann in der Serverkonfiguration, im CMS oder in den Templates.

In der Praxis hilft es, die gelisteten URLs nach Seitentyp zu sortieren. Stammen zum Beispiel Blogartikel, Produktseiten und Kategorieseiten aus getrennten Templates, sehen Sie sofort, wo sich das Problem häuft. So beheben Sie es an einer Stelle und beobachten die Wirkung in der ganzen Gruppe.

Achten Sie außerdem auf die Vergleichslogik. Für jede HTTP URL sucht der Bericht exakt denselben Pfad unter HTTPS und ignoriert dabei Parameter. Andererseits berücksichtigt er keine HTTPS Alternative mit anderer URL Struktur. Haben Sie also http://example.com/produkt?id=5 nach https://example.com/produkte/5 verschoben, verknüpft der Bericht beide Adressen nicht.

Warum liefert Ihre Website Seiten nicht über HTTPS aus?

Die Hilfeseite von Google ordnet die Ursachen benannten Problemgruppen zu. Da sich deutsche Bezeichnungen in der Oberfläche ändern können, nennen wir die englischen Namen, die Google verwendet:

1. HTTP marked with canonical tag.
2. HTTPS has invalid certificate.
3. Sitemap points to HTTP.
4. HTTPS has redirect.
5. Durch robots.txt gesperrt: HTTPS URL is roboted.
6. HTTPS not evaluated.
7. Other issues.

Die meisten dieser Gruppen entstehen durch ein einziges Template oder eine einzige Serverregel. So kann zum Beispiel eine falsche Canonical Einstellung Tausende Seiten gleichzeitig treffen. Deshalb empfehlen wir, zuerst die gemeinsame Ursache zu finden, statt die Liste Seite für Seite abzuarbeiten. Die folgenden Abschnitte behandeln jede Ursache einzeln.

Was bedeutet "HTTP marked with canonical tag"?

Dieses Problem heißt, dass Ihre HTTP Seite sich per rel="canonical" selbst als kanonisch ausweist. Selbst wenn die Seite über HTTPS lädt, sagt das Tag zu Google also: "Meine Hauptadresse ist HTTP." Google folgt diesem Signal womöglich und behält die HTTP Version im Index.

Das sehen Sie häufig bei älteren Themes und handgeschriebenen Templates. Baut das Template die Canonical URL zum Beispiel mit einem festen Präfix "http://" auf, gibt das Tag auch nach der Umstellung weiter das alte Protokoll aus. Ebenso erzeugen Plugins ein falsches Canonical, wenn im CMS die Websiteadresse noch auf HTTP steht.

Die Lösung besteht darin, die HTTPS Version als kanonisch anzugeben. Auch bei fehlenden HTTPS Seiten nennt Google genau diese Kennzeichnung als empfohlene Lösung. Die Grundlagen erklären wir in unserem Leitfaden zum Canonical Tag. Zudem zeigt unser Beitrag zu Canonical Fehlern in der Search Console, wie Sie Widersprüche in großer Zahl finden.

Wie beheben Sie das Problem mit dem ungültigen Zertifikat?

Dieses Problem bedeutet, dass die HTTPS URL ein ungültiges SSL Zertifikat hat. Laut Google betrifft ein Zertifikatsproblem meist die ganze Website und nicht nur eine Seite. Prüfen Sie daher zuerst das Zertifikat selbst.

Diese Ursachen begegnen uns am häufigsten:

• Das Zertifikat ist abgelaufen, und die automatische Verlängerung hat versagt.
• Das Zertifikat deckt die Variante mit www ab, aber nicht die ohne www, oder umgekehrt.
• Die Zwischenzertifikatskette ist unvollständig, also lehnen manche Clients die Verbindung ab.
• Sie haben die Domain auf einen neuen Server umgezogen, und dort fehlt das passende Zertifikat.

Zur Behebung erneuern Sie das Zertifikat und stellen sicher, dass es jeden genutzten Hostnamen abdeckt. Danach öffnen Sie die Website in mehreren Browsern und auf mehreren Geräten. Die Grundlagen finden Sie in unserem Beitrag Was ist ein SSL Zertifikat. Verwaltet Ihr Hoster das Zertifikat, prüfen Sie die Verlängerung gemeinsam mit ihm.

Was tun Sie, wenn Ihre Sitemap auf HTTP verweist?

Dieses Problem bedeutet, dass Ihre Sitemap eine HTTP URL enthält und Google diese HTTP URL als kanonisch indexiert hat. Laut Google erscheint das Problem nur, wenn Google die HTTP URL erfolgreich gecrawlt und indexiert hat. Ihre Sitemap empfiehlt Google also noch die alte Adresse.

Die Lösung ist einfach: Sie aktualisieren die Sitemaps, damit sie die HTTPS Versionen enthalten. Allerdings steckt das Problem oft in einer alten, von Hand hinzugefügten Sitemap Datei. Eine Website liefert zum Beispiel gleichzeitig eine dynamische Sitemap aus einem Plugin und eine statische Datei, die jemand vor Jahren hochgeladen hat.

Auch der Leitfaden von Google zum Websiteumzug empfiehlt eine Sitemap mit den neuen HTTPS URLs, die Sie in der Search Console einreichen. Danach können Sie die alte Sitemap entfernen. Kann die Search Console Ihre Sitemap gar nicht lesen, hilft unser Beitrag zum Fehler Sitemap konnte nicht abgerufen werden.

Wo liegt das Problem, wenn HTTPS auf HTTP weiterleitet?

Dieses Problem bedeutet, dass die HTTPS URL existiert, Besucher aber auf eine HTTP URL weiterleitet. Die Empfehlung von Google ist eindeutig: Entfernen Sie die Weiterleitung oder leiten Sie stattdessen auf eine HTTPS Seite weiter. Sonst kann Google die sichere Version nicht als Hauptadresse wählen.

Woher kommt also diese umgekehrte Weiterleitung? Meist stammt sie aus einer alten Serverregel, einer CDN Einstellung oder dem Adressfeld im CMS. Leitet der Server zum Beispiel HTTP auf HTTPS um, während das CMS jede Anfrage zurück auf HTTP schickt, entsteht eine Schleife. Diese Schleife behandeln wir in unserem Beitrag zu zu vielen Weiterleitungen.

Deshalb prüfen Sie jede Ebene einzeln: Serverregeln, CDN Einstellungen, die Websiteadresse im CMS und die Weiterleitungslisten Ihrer Plugins. Danach verfolgen Sie jeden Schritt der Weiterleitung mit den Entwicklertools Ihres Browsers. Die Zieladresse muss HTTPS nutzen, und dazwischen darf kein HTTP Schritt liegen.

Kann robots.txt Ihre HTTPS URLs blockieren?

Ja, und der Bericht führt das als eigene Problemgruppe. Sperrt eine Regel in der robots.txt das Crawling der HTTPS URL, kann Google die sichere Version nicht lesen. Folglich behält Google die HTTP Seite im Index, weil sie die einzige lesbare Version ist.

Das passiert meist auf zwei Wegen. Erstens liefern HTTP und HTTPS unterschiedliche robots.txt Dateien aus; zum Beispiel blieb eine Regel "alles sperren" aus der Entwicklungsphase auf der HTTPS Seite stehen. Zweitens erfasst eine Regel für einen Ordner nach der Umstellung plötzlich auch die neue URL Struktur.

Zur Lösung öffnen Sie die robots.txt auf beiden Protokollen und vergleichen sie. Dann korrigieren Sie die sperrende Regel. Häufige Fehler listen wir in unserem Beitrag zu robots.txt Fehlern auf. Nach der Änderung prüfen Sie im robots.txt Bericht der Search Console, ob Google die aktuelle Datei liest.

Wie lösen Sie "HTTPS not evaluated"?

Diese Gruppe bedeutet, dass Google die HTTPS Version nicht bewerten konnte. Die Hilfeseite von Google nennt mehrere mögliche Ursachen. Zum Beispiel existiert keine passende HTTPS URL, oder sie liefert einen 4XX Fehler wie 404 oder eine Anmeldepflicht, oder einen 5XX Serverfehler. Oder beide Versionen existieren, aber Google hat die HTTP Version als kanonisch gewählt.

Daneben gibt es weitere Ursachen. Google ist womöglich auf so viele Fehler gestoßen, dass es die Verarbeitung der wartenden URLs gestoppt hat. Ein Fehler auf der ganzen Website, etwa ein schlechtes Zertifikat, kann die Bewertung blockieren. Oder Google hat die URL schlicht noch nicht gesehen oder gecrawlt.

Google schlägt diese Reihenfolge vor. Zeigt der Bericht viele andere Fehler, beheben Sie zuerst diese, denn das kann die Verarbeitung freigeben. Bei einer frisch gecrawlten URL warten Sie einen Tag und schauen dann erneut. Gibt es nur wenige andere Fehler, prüfen Sie HTTPS Probleme auf der ganzen Website, die Verfügbarkeit im Crawling Statistikbericht und Fehler 404 im Bericht zur Seitenindexierung. Nicht indexierte Seiten finden Sie mit unserer Anleitung zu nicht indexierten Seiten.

Beeinflussen gemischte Inhalte den HTTPS Bericht?

Gemischte Inhalte (Mixed Content) entstehen, wenn eine über HTTPS geladene Seite Bilder, Skripte oder Stylesheets über HTTP nachlädt. Der HTTPS Bericht führt gemischte Inhalte nicht als eigene Problemgruppe. Trotzdem sind sie eines der deutlichsten Zeichen für eine halb fertige Umstellung.

Laut der Erklärung von web.dev zu gemischten Inhalten blockieren Browser manche HTTP Ressourcen und laden andere mit einer Warnung. Folglich wirkt die Seite eventuell kaputt oder verliert das Schloss. Für Besucher bedeutet das einen Vertrauensverlust.

Gemischte Inhalte stammen meist aus alten Adressen in der Datenbank. Bilder in alten Blogartikeln verweisen zum Beispiel noch auf Adressen mit "http://". Also reicht es nicht, nur das Template zu korrigieren; Sie müssen auch alte URLs im Inhalt aktualisieren. Legen Sie vor jeder Massenänderung unbedingt eine Sicherung der Datenbank an.

Ein guter Startpunkt ist die Konsole in den Entwicklertools Ihres Browsers. Beim Öffnen einer Seite listet sie über HTTP geladene Ressourcen als Warnung auf. Dann wiederholen Sie die Prüfung bei einigen Seiten aus verschiedenen Templates. So erkennen Sie, ob das Problem im Template oder im Inhalt steckt.

Wie sollten Canonical Tags und 301 Weiterleitungen zusammenspielen?

Am stabilsten ist ein Aufbau, bei dem jedes Signal auf dieselbe Adresse zeigt. Der Leitfaden von Google zum Zusammenführen doppelter URLs erklärt, dass mehrere Signale in die Wahl der kanonischen URL einfließen. Weiterleitungen, Canonical Tags, Sitemaps und interne Links sollten deshalb übereinstimmen.

Konkret empfehlen wir diesen Aufbau:

• Jede HTTP URL leitet serverseitig dauerhaft (301 oder 308) auf denselben Pfad unter HTTPS weiter.
• Jede HTTPS Seite nennt ihre eigene HTTPS URL als Canonical.
• Die Sitemap enthält nur HTTPS URLs.
• Interne Links zeigen direkt auf HTTPS URLs und laufen nicht über Weiterleitungen.

Den Unterschied der Weiterleitungsarten erklären wir in unserem Beitrag zu 301, 302, 307 und 308. Bilden mehrere Weiterleitungen eine Kette, reduzieren Sie diese außerdem auf einen einzigen Schritt.

Welches Problem im HTTPS Bericht verlangt welche Lösung?

Die Tabelle fasst die Problemgruppen der Google Hilfeseite und die vorgeschlagenen Lösungen zusammen. Unser Team nutzt sie bei technischen Audits als erste Orientierung.

Die Tabelle legt zudem eine Reihenfolge nahe. Zuerst lösen Sie Probleme auf der ganzen Website wie Zertifikat und Weiterleitungen. Danach folgen Templateprobleme wie Canonical Tags und Sitemaps. Schließlich prüfen Sie einzelne URLs.

Noch ein Tipp: Notieren Sie jede Korrektur mit Datum und kurzer Beschreibung in einem Änderungsprotokoll. Ändert sich dann der Bericht, ordnen Sie die Veränderung leicht dem passenden Schritt zu. Arbeiten mehrere Personen an der Website, sinkt außerdem das Risiko, dieselbe Einstellung zweimal zu ändern.

Wie sieht eine Checkliste zur Behebung Schritt für Schritt aus?

Zeigt der Bericht Probleme, empfehlen wir die folgende Reihenfolge. Sie schließt die wirkungsvollsten Probleme zuerst und spart doppelte Arbeit.

1. Bestätigen Sie, dass das Zertifikat gültig ist und jeden Hostnamen abdeckt.
2. Testen Sie, ob die dauerhafte Weiterleitung von HTTP auf HTTPS in einem Schritt funktioniert.
3. Prüfen Sie, dass HTTPS URLs nie zurück auf HTTP weiterleiten.
4. Kontrollieren Sie, dass das Template HTTPS Canonical URLs ausgibt.
5. Stellen Sie die Websiteadresse im CMS auf HTTPS um.
6. Erzeugen Sie die Sitemap mit HTTPS URLs neu und reichen Sie sie in der Search Console ein.
7. Vergleichen Sie die robots.txt auf beiden Protokollen.
8. Aktualisieren Sie alte HTTP Ressourcen und interne Links im Inhalt.
9. Führen Sie für einige Beispiel URLs einen Live Test im URL Prüftool aus.
10. Beobachten Sie den Bericht einige Wochen lang regelmäßig.

Folgen Sie dieser Liste bei jeder Umstellung in derselben Reihenfolge, erkennen Sie die meisten Probleme früh. Allerdings läuft jede Website auf einer anderen Technik; die Liste ist also ein Rahmen und keine Garantie.

Wie testen Sie eine Korrektur mit dem URL Prüftool?

Die Hilfeseite von Google empfiehlt das URL Prüftool (URL Inspection), um das Canonical Problem zu testen. Im Bericht klicken Sie auf das Prüfsymbol neben der URL. Dann wählen Sie die URL Prüfung und starten den Live Test.

Nach dem Live Test öffnen Sie die Ansicht der getesteten Seite (View tested page). Dort suchen Sie im HTML, das Google sieht, nach dem Canonical Tag. Zeigt das Tag die HTTPS URL, hat Google Ihre Korrektur im Template übernommen.

Im selben Tool vergleichen Sie zudem die von Google gewählte kanonische URL mit der von Ihnen angegebenen. Weichen beide ab, widerspricht noch eines Ihrer Signale. In diesem Fall prüfen Sie interne Links, Sitemap und Weiterleitungen erneut. Da die Hilfeseite für diesen Bericht keine eigene Validierungsfunktion beschreibt, ist der Live Test die praktischste Kontrolle.

Was sollten Sie vor einer HTTPS Umstellung vorbereiten?

Am einfachsten vermeiden Sie Probleme im Bericht durch eine geplante Umstellung. Der Leitfaden von Google zum Websiteumzug empfiehlt, sowohl die HTTP als auch die HTTPS Version in der Search Console zu bestätigen. Außerdem stellt er klar, dass Sie für den Wechsel von HTTP zu HTTPS kein Tool zur Adressänderung (Change of Address) brauchen.

In der Vorbereitung sollten Sie diese Fragen beantworten:

• Haben Sie eine vollständige Liste aller Subdomains?
• Deckt das Zertifikat alle davon ab?
• Welche Ebene steuert die Weiterleitungen: CMS, CDN oder Server?
• Geben die Templates Canonical Tags und interne Links mit der richtigen HTTPS Adresse aus?
• Haben Sie alte Sitemaps, Adressen in externen Diensten und Zielseiten von Anzeigen erfasst?

Klären Sie diese Liste vorab, sinkt das Risiko von Überraschungen am Umstellungstag. Zudem lesen Sie den HTTPS Bericht danach viel leichter, denn verbleibende Probleme zeigen echte Ausnahmen.

Was passiert, wenn HTTP und HTTPS gleichzeitig erreichbar bleiben?

Liefern beide Versionen den Status 200, sieht Google zwei Kopien desselben Inhalts. Laut Google bevorzugt Google bei einer Seite auf beiden Protokollen die HTTPS Version für den Index. Allerdings gilt diese Bevorzugung nur, solange andere Signale nicht widersprechen.

Trägt die HTTP Version zum Beispiel ihr eigenes Canonical, zeigen interne Links auf HTTP und listet die Sitemap HTTP, wählt Google eventuell HTTP. Dann sehen Sie URLs in der Gruppe "HTTPS not evaluated". Die Hilfeseite nennt genau diese Ursache: Beide Versionen existieren, aber Google hat HTTP als kanonisch gewählt.

Lassen Sie deshalb nicht beide Versionen lange parallel laufen. Aktivieren Sie die dauerhafte Weiterleitung am Tag der Umstellung. Somit hat Google nur noch eine lesbare Version, und alle Signale bündeln sich auf einer Adresse. Ihre Besucher erreichen außerdem immer eine sichere Verbindung.

Wie wirken interne und externe Links auf den HTTPS Bericht?

Interne Links sind ein wichtiger Weg, über den Google Ihre Seiten entdeckt. Zeigen Links in Menü, Footer oder Text auf HTTP, ruft Google bei jedem Crawl zuerst die HTTP Adresse auf. Selbst bei funktionierender Weiterleitung kostet das einen zusätzlichen Schritt und sendet ein schwaches, aber widersprüchliches Signal.

Daher empfehlen wir, interne Links direkt auf HTTPS umzustellen. Achten Sie vor allem auf diese Bereiche:

• Hauptmenü und Footer.
• Links im Text älterer Blogartikel.
• Produktbeschreibungen und Kategorietexte.
• Adressen in strukturierten Daten.

Alte Links auf fremden Websites können Sie nicht einzeln ändern. Trotzdem lassen sich Links von wichtigen Partnern und Ihren eigenen Social Profilen leicht aktualisieren. Für den Rest sorgt die dauerhafte Weiterleitung; lassen Sie sie also lange bestehen. Mehr dazu lesen Sie in unserem Beitrag Wie lange 301 Weiterleitungen bestehen sollten.

Wie lesen Sie den HTTPS Bericht bei mehrsprachigen Websites?

Bei mehrsprachigen Websites liegen die Sprachversionen oft in eigenen Ordnern oder Subdomains. Klären Sie beim Lesen des HTTPS Berichts also zuerst, welche Version betroffen ist. Erscheinen zum Beispiel nur URLs unter de.example.com, liegt die Ursache vermutlich im Zertifikat oder in der Weiterleitungsregel dieser Subdomain.

Prüfen Sie außerdem die Adressen in Ihren hreflang Tags. Verweisen die Sprachversionen mit HTTP URLs aufeinander, erhält Google erneut ein widersprüchliches Signal. Kurz gesagt sollten Canonical Tags, hreflang, Sitemaps und interne Links dasselbe Protokoll nutzen.

Eine Domain Property hilft bei solchen Websites sehr. Sie sehen alle Subdomains auf einem Bildschirm und erkennen schnell, wo sich das Problem häuft. Danach können Sie für jede Subdomain eine eigene Property mit URL Präfix anlegen und genauer prüfen.

Wie oft sollten Sie den HTTPS Bericht prüfen?

In den Wochen direkt nach einer Umstellung empfehlen wir häufige Kontrollen. Denn in dieser Phase crawlt Google alte und neue Adressen erneut, und der Bericht verändert sich schnell. Danach genügt für die meisten Websites eine monatliche Kontrolle.

Allerdings verlangen manche Ereignisse einen neuen Blick. Dazu zählen zum Beispiel ein neues Theme, ein Serverumzug, ein neues CDN, ein anderer Zertifikatsanbieter oder eine neue Sprachversion. Nach solchen Änderungen öffnen Sie den Bericht innerhalb weniger Tage.

Lesen Sie den HTTPS Bericht außerdem nie isoliert. Der Bericht zur Seitenindexierung, der Crawling Statistikbericht und der Sitemap Bericht ergeben zusammen ein klareres Bild. Auch Google verweist bei "HTTPS not evaluated" auf diese Berichte. Zusammengefasst gehört der HTTPS Bericht fest in Ihre technische SEO Routine.

Warum verschwinden manche Probleme von selbst?

Google weist darauf hin, dass sich manche Probleme mit der Zeit selbst beheben. Der Grund ist einfach: Google hat die HTTP Seite womöglich gecrawlt, bevor die HTTPS Seite online ging oder bevor Google sie crawlen konnte. Daher spiegelt der Bericht eine Zeit lang den alten Stand.

Reagieren Sie direkt nach einer neuen Umstellung also nicht hektisch auf jede Zeile. Hastige Änderungen beschädigen sonst womöglich eine funktionierende Einstellung und verwirren das Bild. Stattdessen schließen Sie zuerst die strukturellen Prüfungen ab. Dann geben Sie Google Zeit für einen neuen Crawl. Erst wenn dasselbe Problem nach einigen Wochen bei denselben URLs bleibt, suchen Sie nach einer dauerhaften Ursache.

Google ergänzt eine weitere Warnung. Erhält Google bei den ersten HTTPS URLs viele Antworten mit Status 404, stellt es das Crawlen von HTTPS Seiten eventuell ein. Dann zeigt der Bericht womöglich Probleme wie "HTTPS crawling issue" und "Other issues". Kurz gesagt schadet eine halb fertige Umstellung weit mehr als Geduld.

Beispielszenario: Warum bleibt die HTTP Version im Index?

Dieser Abschnitt ist ein Beispielszenario zur Erklärung und kein echter Kundenfall. Ein Unternehmen stellt example.com auf HTTPS um und richtet auf dem Server eine Weiterleitung ein. Einige Wochen später zeigt der HTTPS Bericht jedoch Hunderte HTTP URLs.

Die Analyse ergibt drei gemeinsame Ursachen. Erstens baut das Theme Canonical URLs mit festem Präfix "http://". Zweitens liegt eine alte statische Sitemap im Stammverzeichnis, und genau diese ist in der Search Console noch hinterlegt. Drittens speichert die Datenbank interne Links in Produktkategorien noch mit HTTP.

Die Reihenfolge der Lösung ist ebenso klar. Zuerst korrigieren Sie das Canonical Template, danach entfernen Sie die alte Sitemap und reichen eine neue ein. Schließlich aktualisieren Sie die internen Links. Somit zeigen Weiterleitung, Canonical, Sitemap und interne Links auf dieselbe HTTPS Adresse. Wie schnell die HTTP Zahl sinkt, hängt vom Crawling Zeitplan von Google ab; eine Frist zu versprechen wäre daher falsch.

Wann sollten Sie Probleme im HTTPS Bericht an Fachleute abgeben?

Stammt das Problem aus einem einzigen Template, beheben Sie es oft selbst. Verflechten sich jedoch Server, CDN und CMS oder treten Schleifen und widersprüchliche Canonical Signale auf, spart die Arbeit mit Fachleuten Zeit. Vor allem bei E-Commerce und mehrsprachigen Websites trifft eine falsche Regel schnell Tausende Seiten.

Im Rahmen unserer SEO Beratung prüfen wir, Talha Aslan und Team, den HTTPS Bericht, die Weiterleitungen, die Canonical Signale und die Sitemaps gemeinsam. Wir beheben dieses Problem auf Ihrer Website und verfolgen es danach in der Search Console. Rankings garantieren wir nicht; allerdings beseitigen wir technische Hürden an der Quelle und berichten offen über den Fortschritt.

Zeigt Ihr HTTPS Bericht Probleme, die Sie nicht lösen können, fordern Sie auf unserer Seite zur SEO Beratung ein Angebot an. Ein kurzes Formular genügt; unser Team legt den Umfang für Ihre Website fest und meldet sich bei Ihnen.

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