Statusbericht zu AMP-Seiten

Anhand dieses Berichts können Sie Fehler beheben, die verhindern, dass Ihre AMP-Seiten in Google-Suchergebnissen mit AMP-spezifischen Funktionen angezeigt werden.

Auf der obersten Ebene des Berichts werden kritische Probleme angezeigt, die AMP-Seiten auf Ihrer Website betreffen. Wenn Sie auf ein bestimmtes Problem klicken, können Sie sich die von diesem Problem betroffenen Seiten und Details zum Problem ansehen.

AMP-BERICHT ÖFFNEN

 

AMP-Statusbericht in der Search Console – Google Search Console-Schulung

 

Inhalt des Berichts

Kritische Probleme: Seiten, die von kritischen AMP-Problemen betroffen sind, können auf Google nicht angezeigt werden. Direkt unter dem Diagramm auf der Übersichtsseite des AMP-Berichts finden Sie eine Liste der kritischen Probleme auf Ihrer Website mit dem Titel Warum sind AMP-Seiten ungültig?. Per Klick auf ein Problem in der Liste können Sie Seiten mit dem ausgewählten Problem aufrufen.

Nicht kritische Probleme (Warnungen): AMP-Seiten mit nicht kritischen Problemen können weiterhin auf Google angezeigt werden, sofern nicht gleichzeitig kritische Probleme vorliegen. Unterhalb der Liste mit den kritischen Problemen auf der Übersichtsseite des AMP-Berichts finden Sie eine Liste der nicht kritischen Probleme auf Ihrer Website mit dem Titel Nicht kritische Probleme. Per Klick auf ein Problem in der Liste können Sie Seiten mit dem ausgewählten Problem aufrufen. AMP-Seiten mit Warnungen werden unter Umständen nicht mit allen verfügbaren AMP-Funktionen angezeigt, wie beispielsweise in einem Karussell „Schlagzeilen“. Diese Seiten werden also möglicherweise nur als einfache Suchergebnisse mit blauen Links angezeigt.

Seitenstatus (gültige und ungültige Seiten): AMP-Seiten sind entweder gültig oder ungültig. Gültige AMP-Seiten können auf Google angezeigt werden. Ungültige AMP-Seiten können nicht auf Google angezeigt werden. Eine Seite mit kritischen Problemen wird als ungültig eingestuft. Wenn es nur Warnungen oder überhaupt keine Probleme gibt, wird sie als gültig gekennzeichnet. Wenn Sie eine Liste der gültigen AMP-Seiten sehen möchten, klicken Sie unter dem Diagramm auf der Übersichtsseite des AMP-Berichts auf Daten zu gültigen AMP-Seiten ansehen.

Darauf sollten Sie achten

Ihr Bericht sollte folgende Zahlen enthalten:

  • Keine kritischen Probleme auf Ihrer Website. Empfehlungen zur Fehlerbehebung finden Sie unter Probleme priorisieren und beheben.
  • Die Gesamtzahl der AMP-Seiten im Bericht, d. h. Seiten mit dem Status „Gültig“ + „Ungültig“, sollte der Anzahl der AMP-Seiten auf Ihrer Website annähernd entsprechen. Ist dies nicht der Fall, lesen Sie den Abschnitt Fehlerbehebung bei fehlenden AMP-Seiten.

Die Liste der betroffenen URLs enthält Beispiele, jedoch nicht unbedingt alle URLs, die von einem bestimmten Problem betroffen sind. Der Bericht ist auf 1.000 URLs pro Problem beschränkt. Unter Umständen gibt es auch Seiten, die Google aus bestimmten Gründen nicht erkannt oder gezählt hat.

Der Bericht kann insgesamt nur 200 kritische und nicht kritische Probleme enthalten. Wenn auf Ihrer Website sehr viele Probleme auftreten – unabhängig davon, ob aktive Instanzen vorhanden sind oder nicht –, werden im Bericht nur die ersten 200 Probleme angezeigt, sortiert nach Wichtigkeit.

Probleme mit AMP-Seiten

Der Bericht enthält außer den spezifischen AMP-Fehlern zusätzlich die folgenden Probleme (Fehler und Warnungen).

Google-spezifische AMP-Probleme
Problem Beschreibung
Nicht übereinstimmender Inhalt: eingebettetes Video fehlt Auf der kanonischen Webseite ist ein eingebettetes Video vorhanden, das in der AMP-Version fehlt. Wir empfehlen, dieselben wichtigen Content-Ressourcen auf der AMP-Seite wie auf der kanonischen Version einzutragen. Beachten Sie, dass das Video anhand der URL erkannt wird. Wenn zwei unterschiedliche URLs auf das gleiche Video verweisen, sehen Sie diese Warnung auch.
Bildgröße kleiner als empfohlene Größe Die strukturierten Daten auf der AMP-Seite beziehen sich auf ein Bild, das kleiner als die von uns empfohlene Größe ist. Dies kann dazu führen, dass die Seite in der Google-Suche nicht mit allen AMP-kompatiblen Funktionen angezeigt wird und Ihre Karten in Discover ohne große Bilder dargestellt werden, was wiederum die Anzahl der Website-Zugriffe und die Nutzerinteraktionen senkt. Verwenden Sie stattdessen ein größeres Bild gemäß unseren Richtlinien.
Domain der AMP-Seite stimmt nicht überein Die AMP-Seite wird auf einer anderen Domain als ihre kanonische Version gehostet. Dies kann für mobile Nutzer verwirrend sein, da sie in den Suchergebnissen eine URL-Domain sehen, die nicht mit der Domain der Seite übereinstimmt, die ihnen im AMP-Reader angezeigt wird. Bitte beachten Sie, dass dies weder die Seitenindexierung noch das Ranking beeinflusst.
URL nicht gefunden (404) Die angeforderte AMP-URL wurde nicht gefunden. Informationen zum Beheben von 404-Fehlern
Serverfehler (5xx) Unbekannter 5xx-Serverfehler beim Anfordern der AMP-Seite. Weitere Informationen zu Serverfehlern
Durch robots.txt-Datei blockiert Die angeforderte AMP-URL wurde durch eine robots.txt-Regel blockiert. Falls Sie das nicht möchten, testen Sie Ihre robots.txt-Datei auf die blockierende Regel und ändern oder entfernen Sie sie. Sie können auch Ihren Webentwickler bitten, dies für Sie zu tun.
Crawling-Fehler Unbekannter Crawling-Fehler für die AMP-Seite. Testen Sie Ihre AMP-URL mit dem URL-Prüftool. 
Referenzierte AMP-URL ist keine AMP-Seite Eine kanonische Seite referenziert eine AMP-Seite, die in Wirklichkeit keine AMP-Seite ist. Weitere Informationen zum korrekten Referenzieren einer AMP-Seite durch eine Nicht-AMP-Seite
Referenzierte AMP-URL ist eine eigenständige AMP-Seite Die kanonische Seite verweist auf eine eigenständige AMP-Seite. Eine eigenständige AMP-Seite kann jedoch nicht als AMP-Version einer Seite referenziert werden. Weitere Informationen zum Referenzieren einer AMP-Seite von einer Nicht-AMP-Seite
URL als "noindex" markiert Die AMP-Seite wird durch die Anweisung "noindex" blockiert. Google kann Seiten, die durch ein "noindex"-Tag blockiert werden, nicht indexieren. Sie müssen entweder die Anweisung "noindex" entfernen oder den Verweis auf die blockierte Seite löschen.
"unavailable_after"-Datum für diese Seite ist abgelaufen Die AMP-Seite hat das Meta-Tag oder die Anweisung "unavailable_after", doch das Datum ist bereits abgelaufen und die Seite wird deshalb nicht mehr bereitgestellt. Sie sollten das Tag entweder auf ein zukünftiges Datum aktualisieren oder ganz entfernen.
Kanonische Seite verweist auf eine ungültige URL Eine kanonische Seite referenziert eine AMP-Version, doch das Format der URL ist ungültig. Weitere Informationen zum korrekten Referenzieren einer AMP-Version
"AMP Story"-Fehler auf kanonischer Seite

Eine Seite referenziert fälschlicherweise eine "AMP Story"-Seite als ihre AMP-Version. Das ist nicht zulässig, da eine „AMP Story“-Seite immer eigenständig ist, d. h., sie muss mit einem <rel="canonical">-Tag auf sich selbst verweisen und kann nicht die AMP-Version einer anderen Seite sein.
Modulskript wurde ohne Alternative ohne Modul deklariert (oder umgekehrt) Sie verwenden entweder ein <script type="module">-Tag ohne passendes <script nomodule async>-Tag oder umgekehrt. Diese Tag-Paare müssen zusammenpassen, um eine ordnungsgemäße Verarbeitung durch Browser zu ermöglichen, die Modulskripte unterstützen bzw. diese nicht unterstützen.
Fehlende URL im HTML-Tag Für das angegebene HTML-Tag ist ein Attribut mit einer gültigen URL ungleich null erforderlich. Die URL ist jedoch ein leerer String. Geben Sie eine gültige URL für das hervorgehobene Attribut an.
Das Attribut fehlt oder ist falsch, wird jedoch von Attribut „on“ benötigt. Das angegebene Attribut ist erforderlich, ist aber falsch oder fehlt. Dieses Attribut ist erforderlich, da Sie im selben Tag das Attribut „on“ angegeben haben.
Ein untergeordnetes <svg>-Tag befindet sich außerhalb eines <svg>-Blocks. Sie haben ein Tag außerhalb eines <svg>-Blocks angegeben, der in einem <svg>-Block verschachtelt sein muss.
Auf der Seite werden mehrere Versionen desselben Erweiterungsskripts geladen. Auf der Seite werden mehrere Versionen derselben AMP-Erweiterung geladen. Entfernen Sie eine Version des Skripts, um das Problem zu beheben.
Probleme mit Signed Exchange

Im AMP-Statusbericht und im Bericht zur URL-Prüfung können Probleme für AMP-Seiten enthalten sein, auf denen das Signed Exchange-Protokoll verwendet wird.

Signed Exchange-Details zu einem Problem ansehen

Sie können an mehreren Orten Informationen zu dem mit einer AMP-Seite verknüpften Signed Exchange-Paket finden:

  • Klicken Sie im URL-Prüftool unter Details zur AMP-Version auf das Problem.
  • Klicken Sie im AMP-Statusbericht in der Tabelle mit den Problemdetails auf eine URL.

Feststellen, ob Signed Exchange auf Ihrer AMP-Seite verwendet wird

So stellen Sie fest, ob Google Signed Exchange-Header oder -Nutzlasten für Ihre AMP-Seite erkannt hat:

  1. Prüfen Sie die AMP-URL. Verwenden Sie dazu entweder das URL-Prüftool oder klicken Sie im AMP-Statusbericht in der Tabelle mit den Problemdetails neben der URL auf das Symbol "Prüfen" .
  2. Klicken Sie auf der Ergebnisseite auf Gecrawlte Seite anzeigen, um eine Seitenleiste mit weiteren Informationen zu öffnen.
  3. Klicken Sie auf den Tab Weitere Informationen.
  4. Unter dem Label Signed Exchange wird ein Status angezeigt, der angibt, ob Google Signed Exchange-Komponenten für diese AMP-Seite gefunden hat.

Liste der Probleme mit Signed Exchange

Die folgenden Probleme können auftreten, wenn auf Ihrer AMP-Seite das Signed Exchange-Protokoll verwendet wird:

Das Signed Exchange-Paket ist ungültig

Die HTTP-Antwort war ein Signed Exchange-Paket, das die Anforderungen des AMP-Cache von Google nicht erfüllt. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Dieser Fehler kann aus unterschiedlichen Gründen auftreten, zum Beispiel:

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Bei der Signed Exchange-Nutzlast ist ein Parsing-Fehler aufgetreten

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen "Nutzlast" (Text) nicht die Anforderungen des AMP-Cache von Google erfüllt. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Möglicherweise lässt sich das Problem auch durch einen der folgenden Schritte finden und beheben.

  • Vergewissern Sie sich, dass der HTML-Code keine ungültige UTF-8-Codierung enthält. Führen Sie für das fehlerhafte $URL-Element curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null aus und prüfen Sie, ob Fehlermeldungen vorhanden sind, die beispielsweise auf eine ungültige Eingabesequenz zurückzuführen sind. Falls ja, kontrollieren Sie, dass die UTF-8-Codierung des Dokuments korrekt ist. Zwei häufige Fehlerquellen sind nicht englischsprachiger Text und Leerzeichen.
  • Achten Sie darauf, dass der HTML-Code keinen NULL-Wert (U+0000) und kein Unicode-Zeichen enthält, das einen HTML-Parsing-Fehler verursacht.
  • Überprüfen Sie, ob der HTML-Code nach dem Aufruf von transform -config NONE unverändert ist. Es gibt zwei häufige Gründe für eine Änderung des HTML-Codes:

Ein Wert im Header „header_name“ für die Signed Exchange-Nutzlast ist ungültig

Die HTTP-Antwort war ein Signed Exchange-Paket, das einen Header einer signierten Antwort enthielt, der eine der Anforderungen des AMP-Cache von Google nicht erfüllt. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Der verpflichtende Header "header_name" für die Signed Exchange-Nutzlast fehlt

Die HTTP-Antwort war ein Signed Exchange-Paket, in dem der angegebene Header fehlte, der aufgrund der Anforderungen der Signed Exchange-Spezifikation oder des AMP-Cache von Google erforderlich ist. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Der Signaturheader des Signed Exchange-Pakets kann nicht geparst werden

Die HTTP-Antwort war ein Signed Exchange-Paket mit einem Signaturheader, der gemäß der Signed Exchange-Spezifikation nicht korrekt war. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Der Parameter "parameter_name" im Signaturheader des Signed Exchange-Pakets ist ungültig

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen Signaturheader einen gemäß der Signed Exchange-Spezifikation falschen Wert für den angegebenen Parameter enthielt. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Die Daten für das Signed Exchange-Paket sind ungültig

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen Signaturheader einen gemäß den Anforderungen der Signed Exchange-Spezifikation oder des AMP-Cache von Google falschen Wert für den Parameter date oder expires enthielt. Insbesondere muss die Signatur zum Zeitpunkt des Abrufs und darüber hinaus noch mindestens vier Tage gültig sein. Deshalb wird die Seite den Nutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus verschiedenen Gründen auftreten:

  • Achten Sie darauf, dass Ihr Front-End-Reverse-Proxy die Signed Exchange-Antworten nicht zu lange im Cache speichert. Führen Sie mit curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' mehrere Anfragen für die Seite aus und suchen Sie in allen Antworten nach "date=". Überprüfen Sie, ob jedes Mal eine andere Zahl angegeben ist.
  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Wenn Sie alle oben genannten Ursachen ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. In diesem Fall sollten Sie den Fehler melden.

Die Zertifikatskette, auf die im Signed Exchange-Paket "cert-url" verwiesen wird, kann nicht geparst werden

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen Parameter "cert-url" gemäß der Signed Exchange-Spezifikation nicht korrekt war. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden:

  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Falls ja, melden Sie den Fehler.

Die Zertifikatskette, auf die in "cert-url" verwiesen wird, ist ungültig und kann nicht geparst werden

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen "cert-url"-Parameter gemäß der Signed Exchange-Spezifikation ungültig war. Deshalb wird den Nutzern die Seite ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer nicht mit der ursprünglichen URL, sondern mit einer Google-URL angezeigt.

Nächste Schritte:

Da Seiten mit diesem Fehler in einem AMP-Viewer weiterhin korrekt angezeigt werden, ist die Behebung dieses Fehlers optional. Lesen Sie weiter, wenn diese Seite mit der signierten URL angezeigt werden soll.

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus verschiedenen Gründen auftreten. Prüfen Sie Folgendes:

  • Vergewissern Sie sich, dass CertFile keine vollständige Liste aus untergeordnetem Zertifikat und Zwischenzertifikaten enthält.
  • Vergewissern Sie sich, dass AMP Packager nicht mit dem -development- oder -invalidcert-Flag gestartet wurde. Im Produktionsmodus überprüft AMP Packager verschiedene Aspekte des Zertifikats.
  • Achten Sie darauf, dass Ihr Front-End-Reverse-Proxy /amppkg/cert/-URLs nicht länger im Cache speichert, als durch max-age festgelegt ist.
  • Vergewissern Sie sich, dass Ihr Front-End-Reverse-Proxy keine Cache-Header ändert. Dies könnte dazu führen, dass ein Upstream-Proxy diese Zertifikatsketten zu lange im Cache speichert. Ermitteln Sie zum Testen die entsprechende /amppkg/cert/-URL in Ihrer internen Packager-Domain, rufen Sie sie einschließlich Antwortheadern ab – z. B. mit curl -i – und vergleichen Sie die Antwortheader mit den vom Front-End-Server zurückgegebenen Headern.
  • Überprüfen Sie, ob Ihr Zertifikat einen Signed Certificate Timestamp (SCT) enthält. Dazu können Sie z. B. das Tool openssl x509 verwenden. Falls es keinen SCT enthält, wenden Sie sich an Ihre Zertifizierungsstelle.
  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Wenn Sie alle oben genannten Ursachen ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. In diesem Fall sollten Sie den Fehler melden.

Das Signed Exchange-Paket kann nicht geparst werden

Der "content-type"-Header der HTTP-Antwort lautete application/signed-exchange;v=b3, aber der Antworttext konnte nicht extrahiert werden. Dies kann darauf zurückzuführen sein, dass die übergeordneten Anforderungen dieses Typs nicht erfüllt wurden oder dass die Nutzlast nicht ordnungsgemäß nach dem Merkle-Verfahren codiert war.

Auswirkungen auf Ihre Website:

Falls die Seite eine entsprechende Nicht-AMP-Seite umfasst, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise gar nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus verschiedenen Gründen auftreten:

  • Achten Sie darauf, dass Ihr Front-End-Reverse-Proxy die Packager-Antworten nicht ändert. Ermitteln Sie für die fehlerhafte URL die entsprechende "/priv/doc"-URL in Ihrer internen Packager-Domain und testen Sie sie mithilfe von "dump-signedexchange". Wenn die Antwort des internen Packagers ein gültiges Signed Exchange-Paket ist, die des externe Front-Ends jedoch nicht, liegt wahrscheinlich ein Konfigurationsfehler im Front-End vor.
  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Wenn Sie alle oben genannten Ursachen ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. In diesem Fall sollten Sie den Fehler melden.

Die URL für die innere Nutzlast stimmt nicht mit der Anfrage-URL für das Signed Exchange-Paket überein

Die HTTP-Antwort war ein Signed Exchange-Paket, dessen fallbackUrl nicht mit der Anfrage-URL übereinstimmte. Sie müssen Byte für Byte identisch sein. Aus diesem Grund wird in der Google-Suche nicht davon ausgegangen, dass die Antwort repräsentativ für die Anfrage-URL ist.

Auswirkungen auf Ihre Website:

Falls die Seite eine entsprechende Nicht-AMP-Seite umfasst, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise gar nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung. Zur Problemumgehung können Sie z. B. die URL der Seite ändern, um Fehler in gängigen URL-Parsern zu vermeiden. Versuchen Sie beispielsweise, als Prozentwert codierte oder reservierte Zeichen oder ungewöhnliche Abfragestringcodierungen wie ? ohne Parameter zu entfernen.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus verschiedenen Gründen auftreten:

  • Achten Sie darauf, dass Ihr Front-End-Reverse-Proxy URLs korrekt umschreibt. Probleme treten besonders bei URLs mit als Prozentwert codierten oder reservierten Zeichen auf. Bei nginx treten beispielsweise Probleme mit der "rewrite"-Anweisung und der pfadlosen Form der zugehörigen "proxy_pass"-Anweisung auf. Wenn Sie dies testen möchten, senden Sie einige Testanforderungen an Ihr Front-End und vergleichen Sie diese mit den URLs, die AMP Packager in stdout protokolliert.
  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Wenn Sie alle oben genannten Ursachen ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. In diesem Fall sollten Sie den Fehler melden.

Ein Wert im Header "header_name" für die HTTP-Antwort des Signed Exchange-Pakets ist ungültig

Der "content-type"-Header der HTTP-Antwort lautete application/signed-exchange, aber die Antwortheader waren aus einem anderen Grund ungültig. Beispielsweise fehlt im "content-type"-Header möglicherweise der Parameter "v=b3". Das Format ist Google daher unbekannt. Infolgedessen kann der Antworttext nicht extrahiert werden.

Auswirkungen auf Ihre Website:

Falls die Seite eine entsprechende Nicht-AMP-Seite umfasst, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise gar nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie mit einem Signed Exchange-Dienstanbieter arbeiten, bitten Sie diesen um Unterstützung.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus verschiedenen Gründen auftreten:

  • Achten Sie darauf, dass Ihr Front-End-Reverse-Proxy die "content-type"-Header nicht ändert. Ermitteln Sie für die fehlerhafte URL die entsprechende "/priv/doc"-URL in Ihrer internen Packager-Domain und rufen Sie sie einschließlich Antwortheadern ab, z. B. mit curl -i. Wenn sich die Header der Antwort des internen Packagers von denen der Antwort des externen Front-Ends unterscheiden, kann dies die Fehlerquelle sein. Wenn der Unterschied nicht auf content-type, sondern auf einen anderen Header zurückzuführen ist, melden Sie bitte anhand dieses Hilfeartikels einen Fehler, um die Liste der Anforderungen zu aktualisieren.
  • Vergewissern Sie sich, dass Sie die neueste Version von AMP Packager verwenden.
  • Wenn Sie alle oben genannten Ursachen ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. In diesem Fall sollten Sie den Fehler melden.

Probleme priorisieren und beheben

  1. Sehen Sie sich in der Tabelle Warum sind AMP-Seiten ungültig? die Liste mit kritischen Problemen für Ihre Website an.
  2. Analysieren Sie die Fehler:
    • Prüfen Sie, ob der Anstieg der Gesamtfehlerzahl hauptsächlich auf einen einzelnen Fehler zurückzuführen ist. Suchen Sie dazu in der Tabelle nach einem einzelnen Problem, das entsprechend häufiger auftritt.
    • Beheben Sie zuerst die Fehler, die auf mehrere Seiten zutreffen, z. B. eine fehlerhafte Vorlage. Korrigieren Sie dann die Fehler, die nur jeweils eine Seite betreffen.
  3. Beheben Sie die Fehler: Klicken Sie auf eine Zeile in der Tabelle, um die Seite mit den Fehlerdetails aufzurufen:
    1. Auf der Detailseite finden Sie eine Liste mit betroffenen URLs. Diese Liste ist auf 1.000 Zeilen beschränkt. Daher kann es sein, dass kürzlich erkannte Instanzen dieses Fehlers oder Seiten, die seit dem Auftreten des Fehlers nicht noch einmal gecrawlt wurden, noch nicht erscheinen.
    2. Klicken Sie neben einem Problem auf Weitere Informationen, um zur offiziellen Dokumentation zum jeweiligen Fehler zu gelangen.
    3. Klicken Sie in der Tabelle mit den Beispiel-URLs auf eine URL, um das Problem im Seitencode hervorzuheben.
    4. Klicken Sie auf das Überprüfungssymbol , um für eine bestimmte Seite einen detaillierten Test auszuführen. Bei diesem Test werden alle Fehler ermittelt, nicht nur das aktuelle Problem. Außerdem wird ein Code-Explorer geöffnet, in dem die Fehler hervorgehoben und weitere Informationen angegeben werden. Wenn die Seite für längere Zeit nicht gecrawlt wurde, wird das Problem für die indexierte Seite, aber nicht für die Live-Seite angezeigt. In diesem Fall können Sie die Indexierung dieser Seite beantragen.
    5. Beheben Sie alle Instanzen des Problems auf Ihrer Website, testen Sie die neue Version und überprüfen Sie, ob die korrigierte Version online verfügbar ist.
  4. Wenn Sie alle Instanzen korrigiert haben, kehren Sie zur Seite mit den Fehlerdetails zurück und klicken Sie auf Fehlerbehebung überprüfen, um die Überprüfung zu starten. Dieser Vorgang beginnt nicht unmittelbar. Mehr dazu erfahren Sie im Abschnitt Überprüfung.
  5. Fahren Sie mit der Fehlerbehebung fort.
  6. Wenn die Gesamtzahl der gültigen und ungültigen Seiten deutlich niedriger ist als die Anzahl der AMP-Seiten auf Ihrer Website, lesen Sie Fehlerbehebung bei fehlenden AMP-Seiten.
  7. Wenn alle kritischen Fehler behoben wurden, sollten Sie eventuell die nicht kritischen Probleme beheben. Einige nicht kritische Probleme, z. B. die Verwendung veralteter Funktionen, können in Zukunft zu kritischen Fehlern werden.

Bericht teilen

Sie können Problemdetails in den Berichten zur Indexabdeckung und zur Video-Optimierung teilen, indem Sie auf der Seite auf die Schaltfläche Teilen klicken. Der geteilte Link bietet nur Zugriff auf die Seite mit den Problemdetails sowie auf die Seiten mit dem Überprüfungsverlauf für das Problem. Jeder, der ihn hat, kann darauf zugreifen. Nutzer, mit denen der Link geteilt wurde, können also weder auf andere Seiten für Ihre Ressource zugreifen, noch etwas an Ihrer Property oder Ihrem Konto verändern. Sie können den Link jederzeit ungültig machen, indem Sie das Teilen für diese Seite deaktivieren.

Berichtsdaten exportieren

Viele Berichte enthalten die Schaltfläche "Exportieren" , mit der Sie die Berichtsdaten exportieren können. Dabei werden sowohl Diagramm- als auch Tabellendaten exportiert. Werte, die im Bericht als „~“ (nicht verfügbar) oder „-“ (keine Zahl) angezeigt werden, sind in den heruntergeladenen Daten als Nullen dargestellt.

Fehlerbehebung bei fehlenden AMP-Seiten

Wenn die Anzahl der AMP-Seiten im Bericht, d. h. Seiten mit den Status „Gültig“ + „Ungültig“, geringer ist als die Anzahl der AMP-Seiten auf Ihrer Website, gehen Sie so vor:

  • Überprüfen Sie, ob Ihre kanonische Nicht-AMP-Seite korrekt mit Ihrer AMP-Seite verknüpft ist.
  • Achten Sie darauf, dass Ihre AMP- oder kanonischen Seiten weder durch eine robots.txt-Datei oder ein „noindex“-Tag blockiert noch durch Anmeldeanforderungen geschützt sind.
  • Prüfen Sie die URL der kanonischen Seite Ihrer AMP, um herauszufinden, ob sie indexiert ist.
    • Wenn die kanonische Seite vorhanden ist, prüfen Sie, ob sie korrekt mit Ihrer AMP-Seite verknüpft ist.
    • Wenn die kanonische Seite nicht vorhanden ist, senden Sie diese zur Indexierung ein.
  • Je nachdem, wie Sie Google über die neuen Seiten informiert haben, kann es einige Tage dauern, bis Google die fehlenden Seiten gefunden und gecrawlt hat.
  • Einige gültige AMP-Seiten können in diesem Bericht nicht enthalten sein, obwohl sie möglicherweise im Bericht zur Seitenindexierung aufgeführt sind. Das liegt daran, dass der Bericht zur Seitenindexierung umfangreicher sein muss, damit Sie Indexierungsprobleme in Ihrem Bericht besser beheben können. Der Statusbericht zu AMP-Seiten deckt zwar möglicherweise weniger, aber dafür relevantere Seiten ab, und diese auch ausführlicher, damit Sie bestimmte AMP-Fehler auf Ihrer Website besser beheben können. Wenn Sie überprüfen möchten, ob eine AMP-Seite indexiert ist, verwenden Sie das URL-Prüftool, das die endgültige Antwort liefert.
Nachdem Sie alle Instanzen eines bestimmten Problems auf Ihrer Website behoben haben, können Sie Google um die Überprüfung dieser Fehlerbehebung bitten. Wenn alle bekannten Instanzen des Problems beseitigt sind, wird die Zahl der Instanzen dieses Problems in der Problemtabelle auf null gesetzt und das Problem nach unten verschoben.

Gründe für die Überprüfung

Wenn Sie Google mitteilen, dass Sie alle Instanzen mit einem bestimmten Problemstatus oder einer bestimmten Problemkategorie beseitigt haben, hat das folgende Vorteile:

  • Sie erhalten eine E-Mail, wenn Google Ihre Fehlerbehebung für alle URLs bestätigt hat oder wenn Google verbleibende Instanzen dieses Problems gefunden hat.
  • Sie können den Fortschritt bei der Überprüfung Ihrer Fehlerbehebung durch Google verfolgen, eine Liste aller Seiten aufrufen, die zur Überprüfung in die Warteschlange gestellt wurden, und den Fehlerbehebungsstatus der einzelnen URLs sehen.

Es ist nicht immer sinnvoll, ein bestimmtes Problem auf Ihrer Website zu beheben und überprüfen zu lassen. So werden beispielsweise von robots.txt blockierte URLs in der Regel absichtlich blockiert. Es liegt in Ihrem eigenem Ermessen, ob Sie sich um ein bestimmtes Problem kümmern oder nicht.

Sie können Probleme auch ohne Überprüfung beheben. Wenn eine Seite mit bekannten Problemen gecrawlt wird, aktualisiert Google die Anzahl der Instanzen – unabhängig davon, ob Sie die Überprüfung der Fehlerbehebung ausdrücklich angefordert haben.

Profitipp: Korrekturen per Sitemap bestätigen
Sie können die Fehlerbehebung beschleunigen, indem Sie eine Sitemap mit Ihren wichtigsten Seiten erstellen und einreichen. Filtern Sie den Bericht dann nach dieser Sitemap, bevor Sie eine Überprüfung anfordern. Eine Überprüfung für einen Teil der betroffenen URLs kann schneller abgeschlossen werden als eine Anfrage mit allen betroffenen URLs auf Ihrer Website.

Überprüfung starten

So melden Sie in der Search Console, dass Sie ein Problem behoben haben:

  1. Beheben Sie alle Instanzen des Problems auf Ihrer Website. Falls Sie eine Instanz übersehen haben und Google sie findet, wird die Überprüfung beendet.
  2. Öffnen Sie die Seite mit den Details des behobenen Problems. Klicken Sie in der Liste der Probleme auf das Problem.
    • ⚠️ Bitte beachten Sie, dass wenn Sie Ihren Bericht nach einer bestimmten Sitemap filtern, nur die Elemente überprüft werden, die sich zum Zeitpunkt, zu dem Sie die Überprüfung anfordern, in der Sitemap befinden.
  3. Klicken Sie auf Fehlerbehebung überprüfen. Klicken Sie erst wieder auf „Fehlerbehebung überprüfen“, wenn die Überprüfung erfolgreich war oder fehlgeschlagen ist. Weitere Informationen dazu, wie Google Fehlerbehebungen überprüft
  4. Sie können den Fortschritt der Überprüfung verfolgen. Die Überprüfung dauert in der Regel etwa zwei Wochen, manchmal aber auch um einiges länger. Bitte haben Sie etwas Geduld. Wenn die Überprüfung erfolgreich ist oder fehlschlägt, erhalten Sie eine Benachrichtigung.
  5. Wenn die Überprüfung fehlschlägt, können Sie sich ansehen, auf welche URL das zurückzuführen ist. Klicken Sie dazu auf der Seite mit den Problemdetails auf Details anzeigen. Korrigieren Sie die Seite, bestätigen Sie die Fehlerbehebung aller URLs mit dem Status Ausstehend und starten Sie die Überprüfung neu.

Wann wird ein Problem für eine URL oder ein Element als behoben angesehen?

Ein Problem wird für ein Element oder eine URL als behoben markiert, wenn eine der folgenden Bedingungen erfüllt ist:

  • Die URL wird gecrawlt und das Problem wird auf der Seite nicht mehr gefunden. Bei einem AMP-Tag-Fehler kann dies bedeuten, dass Sie entweder den Tag-Fehler behoben haben oder dass das Tag entfernt wurde, sofern es nicht erforderlich ist. Während der Überprüfung erhält die Seite den Status Bestanden.
  • Wenn die Seite aus irgendeinem Grund nicht für Google verfügbar ist, z. B. weil sie entfernt oder als „noindex“ markiert wurde oder eine Authentifizierung erforderlich ist, wird das Problem für diese URL als behoben angesehen. Während der Überprüfung erhält die Seite den Überprüfungsstatus Sonstiges.

Lebensdauer von Problemen

Die Lebensdauer eines Problems beginnt mit der ersten Erkennung einer Instanz dieses Problems auf Ihrer Website. Sie endet 90 Tage nachdem die letzte Instanz als von der Website entfernt markiert wurde. Wenn das Problem innerhalb von 90 Tagen nicht wieder auftritt, wird es aus der Problemtabelle entfernt.

Unter Erstmals erkannt am ist das Datum angegeben, an dem das Problem zum ersten Mal erkannt wurde und seine Lebensdauer beginnt. Dieses Datum ist unveränderlich. Beispiele:

  • Wenn alle Instanzen eines Problems behoben sind, 15 Tage später jedoch eine neue Instanz auftritt, wird das Problem als „Offen“ markiert. Unter „Erstmals erkannt am“ wird dann weiterhin das ursprüngliche Datum angezeigt.
  • Wenn 91 Tage nach Behebung der letzten Instanz das gleiche Problem auftritt, wird es als neues Problem verzeichnet, da die vorherige Problembehebung abgeschlossen wurde. Für „Erstmals erkannt am“ wird in diesem Fall das neue Erkennungsdatum festgelegt.
Ablauf der Überprüfung

Hier finden Sie einen Überblick über die Überprüfung, die stattfindet, nachdem Sie für ein Problem auf Fehlerbehebung überprüfen geklickt haben. Dieser Vorgang kann mehrere Tage oder sogar noch länger dauern. Sie werden per E-Mail über den Fortschritt informiert.

  1. Wenn Sie in der Search Console auf Fehlerbehebung überprüfen klicken, werden sofort einige Seiten überprüft.
    • Falls die aktuelle Instanz auf einer dieser Seiten vorhanden ist, wird die Überprüfung beendet und der Überprüfungsstatus bleibt unverändert.
    • Falls die überprüften Seiten den aktuellen Fehler nicht enthalten, wird die Überprüfung mit dem Status Gestartet fortgesetzt. Werden dabei Probleme festgestellt, die nicht mit dem aktuellen Fehler zusammenhängen, so werden diese einem anderen Problemtyp zugeordnet und die Überprüfung wird fortgesetzt.
  2. Die Liste der bekannten URLs, die von diesem Problem betroffen sind, wird in der Search Console abgearbeitet. Dabei werden nur URLs mit bekannten Instanzen dieses Problems zum nochmaligen Crawlen in die Warteschlange gestellt, nicht die gesamte Website. Alle geprüften URLs werden im Überprüfungsverlauf gespeichert, auf den Sie über die Seite mit den Problemdetails zugreifen können.
  3. Wenn bei der Prüfung einer URL:
    1. das Problem nicht gefunden wird, ändert sich der Status der Instanzüberprüfung zu Bestanden. Falls dies die erste geprüfte Instanz nach dem Start der Überprüfung ist, ändert sich der Status der Problemüberprüfung zu Bisher alles in Ordnung.
    2. nicht auf die URL zugegriffen werden kann, ändert sich der Status der Instanzüberprüfung zu Sonstiges. Dies ist kein Fehlerstatus.
    3. die Instanz noch vorhanden ist, ändert sich der Status zu Fehlgeschlagen und die Überprüfung wird beendet. Falls dies eine neue Seite ist, die beim regulären Crawlen gefunden wurde, wird sie als weitere Instanz des bestehenden Problems angesehen.
  4. Wenn die URLs in der Warteschlange auf dieses Problem überprüft wurden und festgestellt wurde, dass es dort behoben ist, ändert sich der Status des Problems zu Bestanden. Selbst wenn alle Instanzen behoben wurden, ändert sich das Label der Warn- oder Fehlermeldung nicht (Fehler oder Warnung), sondern nur die Anzahl der betroffenen URLs, die dann auf „0“ gesetzt wird.

Selbst wenn Sie niemals auf „Überprüfung starten“ klicken, kann Google behobene Instanzen eines Problems erkennen. Falls Google während des regulären Crawlings feststellt, dass alle Instanzen eines Problems behoben wurden, wird die Anzahl der betroffenen URLs im Bericht zu „0“ geändert.

Neuüberprüfung

⚠️ Warten Sie auf den Abschluss eines Überprüfungszyklus, bevor Sie einen weiteren Zyklus anfordern. Dies gilt auch dann, wenn Sie während des aktuellen Zyklus bereits einige Probleme behoben haben.

So starten Sie eine fehlgeschlagene Überprüfung neu:

  1. Protokoll für die fehlgeschlagene Überprüfung aufrufen: Öffnen Sie die Detailseite des Problems, bei dem die Überprüfung fehlgeschlagen ist, und klicken Sie auf Details anzeigen.
  2. Klicken Sie auf Neue Überprüfung starten.
  3. Die Überprüfung wird für alle URLs, die mit Ausstehend oder Fehlgeschlagen gekennzeichnet sind, sowie bei allen neuen Instanzen dieses Problems, die seit der letzten Überprüfung durch das reguläre Crawling gefunden wurden, neu gestartet. URLs, die als Bestanden oder Sonstiges gekennzeichnet sind, werden nicht noch einmal geprüft.
  4. Die Überprüfung dauert in der Regel etwa zwei Wochen, manchmal aber auch um einiges länger. Bitte haben Sie etwas Geduld.

Fortschritt der Überprüfung ansehen

So sehen Sie sich den Fortschritt einer aktuellen Überprüfungsanfrage oder den Verlauf der letzten Anfrage an, wenn keine Überprüfung läuft:

  1. Die Detailseite des Problems öffnen: Klicken Sie auf der Hauptseite des Berichts auf die entsprechende Zeile, um die Seite mit den Problemdetails zu öffnen.
  2. Klicken Sie auf Details anzeigen, um die Seite mit den Überprüfungsdetails für die Anfrage zu öffnen.
    • In der Tabelle sehen Sie den Instanzstatus für jede in der Anfrage enthaltene URL.
    • Der Instanzstatus gilt für das konkrete Problem, das Sie untersuchen. Auf ein und derselben Seite kann das eine Problem als Bestanden gekennzeichnet sein und andere Probleme als Fehlgeschlagen, Ausstehend oder Sonstiges.
    • Im AMP-Bericht und im Bericht zur Seitenindexierung werden Einträge auf der Seite mit dem Überprüfungsverlauf nach URL gruppiert.
    • In den Berichten zu Rich-Suchergebnissen sind die Elemente anhand der Kombination aus URL und dem Wert „Name“ des strukturierten Datenelements gruppiert.
Status der Überprüfungsanfrage

Folgende Statusmeldungen sind für die Überprüfung eines bestimmten Problems möglich:

  • Nicht gestartet: Für eine oder mehrere Instanzen dieses Problems wurde noch nie eine Überprüfung angefordert.
    Nächste Schritte:
    1. Klicken Sie auf das Problem, um sich die Fehlerdetails anzusehen. Überprüfen Sie die einzelnen Seiten, um Beispiele für den Fehler auf der Liveseite aufzurufen.
    2. Klicken Sie auf der Detailseite auf Weitere Informationen, um die Details des Problems aufzurufen.
    3. Klicken Sie in der Tabelle auf eine Zeile mit einer Beispiel-URL, um Details zum konkreten Fehler zu erhalten.
    4. Korrigieren Sie die Seiten und klicken Sie dann auf Fehlerbehebung überprüfen, um die Überprüfung zu starten. Die Überprüfung dauert in der Regel etwa zwei Wochen, manchmal aber auch um einiges länger. Bitte haben Sie etwas Geduld.
  • Gestartet: Sie haben eine Überprüfung gestartet und es wurden keine verbleibenden Instanzen des Problems gefunden.
    Nächster Schritt: Google sendet Benachrichtigungen zum Fortschritt der Überprüfung und teilt Ihnen gegebenenfalls mit, was zu tun ist.
  • Bisher alles in Ordnung: Sie haben einen Überprüfungsversuch gestartet und alle bisher geprüften Probleminstanzen wurden behoben.
    Nächster Schritt: Es sind keine Aktionen erforderlich. Google sendet Benachrichtigungen zum Fortschritt der Überprüfung und teilt Ihnen mit, was zu tun ist.
  • Bestanden: Alle bekannten Instanzen des Problems sind beseitigt oder die betroffene URL ist nicht mehr verfügbar. Sie müssen auf Fehlerbehebung überprüfen geklickt haben, um zu diesem Status zu gelangen. Wären Instanzen verschwunden, ohne dass Sie eine Überprüfung angefordert haben, würde sich der Status zu „Nicht zutreffend“ ändern.
    Nächster Schritt: Es sind keine weiteren Aktionen erforderlich.
  • Nicht zutreffend: Google hat festgestellt, dass das Problem bei allen URLs behoben wurde, obwohl Sie noch keinen Überprüfungsversuch gestartet haben.
    Nächster Schritt: Es sind keine weiteren Aktionen erforderlich.
  • Fehlgeschlagen: Ein bestimmter Schwellenwert von Seiten enthält weiterhin dieses Problem, nachdem Sie auf Fehlerbehebung überprüfen geklickt haben.
    Nächste Schritte: Beheben Sie das Problem und starten Sie die Überprüfung neu.
Status der Instanzüberprüfung

Nachdem die Überprüfung angefordert wurde, wird jeder Instanz des Problems eine der folgenden Statusmeldungen zugewiesen:

  • Ausstehend: Zur Überprüfung in die Warteschlange gestellt. Bei der letzten Überprüfung durch Google war diese Probleminstanz vorhanden.
  • Bestanden: [Nicht in allen Berichten verfügbar] Google hat nach der Probleminstanz gesucht und sie ist nicht mehr vorhanden. Dieser Status wird nur zugewiesen, wenn Sie für diese Probleminstanz explizit auf Fehlerbehebung überprüfen geklickt haben.
  • Fehlgeschlagen: Google hat nach der Probleminstanz gesucht und sie ist immer noch vorhanden. Dieser Status wird nur zugewiesen, wenn Sie für diese Probleminstanz explizit auf Fehlerbehebung überprüfen geklickt haben.
  • Sonstiges: [Nicht in allen Berichten verfügbar] Google konnte auf die URL, die die Instanz hostet, nicht zugreifen oder – bei strukturierten Daten – das Element nicht mehr auf der Seite finden. Dieser Status und Bestanden gelten als gleichwertig.

Beachten Sie, dass bei einer URL für unterschiedliche Probleme unterschiedliche Statusmeldungen gelten können. Wenn beispielsweise auf einer einzelnen Seite sowohl das Problem X als auch das Problem Y auftreten, kann das Problem X den Überprüfungsstatus Bestanden und das Problem Y auf derselben Seite den Überprüfungsstatus Ausstehend haben.

 

Bekannte Probleme

Die folgenden Probleme sind in der Search Console bekannt. Sie brauchen uns diese nicht zu melden, aber wir freuen uns über Feedback zu anderen Funktionen oder Problemen, die Sie entdecken. Verwenden Sie dazu die Feedbackfunktion in der Navigationsleiste.

  • Manche Probleme haben lange Namen, die nur schwer zu verstehen sind.
  • Manchmal werden Probleme, die bereits in der Grafik erscheinen, erst verzögert in der Tabelle angezeigt.

War das hilfreich?

Wie können wir die Seite verbessern?

Benötigen Sie weitere Hilfe?

Mögliche weitere Schritte:

Im Hilfeforum posten Antworten von Forenmitgliedern erhalten
true
Neu bei der Search Console?

Sie haben die Search Console noch nie verwendet? Egal, ob Sie Anfänger, SEO-Experte oder Website-Entwickler sind: Beginnen Sie hier.

Suche
Suche löschen
Suche schließen
Hauptmenü
3975856049421970276
true
Suchen in der Hilfe
true
true
true
true
true
83844
false
false