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.

In der obersten Ebene des Berichts sehen Sie alle AMP-Seiten mit Problemen, die Google auf Ihrer Website gefunden hat. Die Seiten sind nach dem jeweiligen Problem gruppiert. Klicken Sie auf ein bestimmtes Problem, um Details aufzurufen, einschließlich einer Beispielliste der von diesem Problem betroffenen Seiten, Informationen zur Fehlerbehebung und eines Verfahrens, um Google über Ihre Korrekturen zu informieren.

Auf der Statusseite sehen Sie Diagramme mit Angaben zu den Problemen und Fehlerbehebungen.

Warum wird nur eine Beispielliste angezeigt? Wir listen so viele betroffene Seiten wie möglich auf, aber in unserer Tabelle können nur maximal 1.000 URLs angezeigt werden. Unter Umständen gibt es auch Seiten, die wir aus bestimmten Gründen nicht erkannt oder gezählt haben.

AMP-BERICHT ÖFFNEN

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

Darauf sollten Sie achten

Im Idealfall sollte der Bericht folgende Informationen enthalten:

  • Es gibt keine AMP-Fehler auf Ihrer Website. Warnungen werden dabei als Empfehlungen und nicht als Fehler betrachtet. Weitere Informationen dazu finden Sie im Abschnitt Warnungen interpretieren weiter unten. Falls doch Fehler aufgelistet sind, lesen Sie den Abschnitt Probleme priorisieren und beheben.
  • Die Gesamtzahl der AMP-Seiten im Bericht, d. h. Seiten mit dem Status „Gültig“ + „Warnung“ + „Fehler“, 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.

Liste der AMP-Probleme

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. Dies 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.

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.

Dieser Fehler kann aus unterschiedlichen Gründen auftreten:

  • 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. Filtern Sie auf der Übersichtsseite des AMP-Berichts die Warnungen heraus und konzentrieren Sie sich zuerst auf die Fehler. Standardmäßig werden die Probleme nach einer Kombination aus Schweregrad, Überprüfungsstatus und Anzahl der betroffenen Seiten sortiert. Wir empfehlen, bei der Fehlerbehebung diese Standardreihenfolge beizubehalten. 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.
  2. 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.
  3. Informationen zur Fehlerbehebung beim Anstieg der Fehlerzahl und bei fehlenden AMP-Seiten finden Sie weiter unten.
  4. 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 nicht immer vollständig, da sie auf 1.000 Zeilen beschränkt ist und kürzlich erkannte Instanzen dieses Fehlers eventuell noch nicht erscheinen.
    2. Wenn es sich um einen Syntaxfehler handelt, klicken Sie auf Weitere Informationen, um zur offiziellen Dokumentation zur richtigen Syntax zu gelangen.
    3. Klicken Sie auf das Prüfsymbol, um einen Gültigkeitstest für eine betroffene Seite durchzufü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. Nachdem ein Fehler auf der Live-Seite behoben wurde, wird er unter Umständen trotzdem noch als Fehler aufgelistet, weil die Seite noch nicht neu gecrawlt wurde. Wenn dies der Fall ist, beheben Sie alle Instanzen dieses Problems und beantragen Sie dann eine Überprüfung.
  5. Beheben Sie alle Instanzen des Problems auf Ihrer Website, testen Sie die neue Version und prüfen Sie, ob die korrigierte Version online verfügbar ist.
  6. Kehren Sie zur Seite mit den Fehlerdetails zurück und klicken Sie auf die Schaltfläche Fehlerbehebung überprüfen, um die Überprüfung zu starten. Dieser Vorgang beginnt nicht unmittelbar. Mehr dazu erfahren Sie im Abschnitt Überprüfung.
  7. Fahren Sie mit der Fehlerbehebung fort.
  8. Wenn alle Fehler behoben wurden, entfernen Sie den Filter für die Warnungen. Wir empfehlen, diese ebenfalls zu überprüfen und die Gründe für die Warnungen ggf. zu beheben. Einige Warnungen beziehen sich auf fehlende optionale Markups für strukturierte Daten, die für neue Suchfunktionen für Seiten mit relevantem Inhalt benötigt 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.

Anstieg der Fehlerzahl

So stellen Sie fest, ob der Anstieg von einer Gruppe von Seiten verursacht wurde, deren Schweregrad sich verändert hat:

  1. Wenn Sie feststellen, dass die Fehlerzahl angestiegen ist, suchen Sie nach einem entsprechenden Abfall bei einem anderen Status ("Fehler" oder "Gültig").
  2. Sollten Sie einen entsprechenden Abfall finden, überprüfen Sie, ob es sich um dieselben URLs handelt.
  3. Wenn die URLs von einem Status in einen anderen gewechselt sind, finden Sie heraus, welche Ihrer Änderungen diesen Wechsel verursacht hat.

Der häufigste Grund für einen Anstieg der Fehlerzahl ist ein Fehler in einer Vorlage, die auf vielen Seiten Ihrer Website verwendet wird.

Fehlerbehebung bei fehlenden AMP-Seiten

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

  • Die in diesem Bericht gemeldeten URLs sind Beispiele für alle bekannten AMP-URLs Ihrer Website. Die Liste der URLs ist nicht vollständig.
  • Ü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 Authentifizierungs- oder Anmeldeanforderungen geschützt sind.
  • Prüfen Sie, ob Ihre AMP- und kanonischen Seiten im Index vorhanden sind, indem Sie die URL der kanonischen Seite bei Google suchen. Wenn sie nicht aufgelistet ist, wurde sie nicht indexiert.
    • 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.
  • Sind Ihre AMP- oder kanonischen Seiten mit anderen Seiten verknüpft? Werden sie in einer Sitemap aufgelistet? Wenn Sie die Indexierung für eine kleine Anzahl von AMP-Seiten anfordern möchten, verwenden Sie das URL-Prüftool für die kanonische Seite. Für eine große Anzahl von Seiten sind Sitemaps besser geeignet. Sie müssen darin nur die kanonische Seite angeben. Eine Sitemap reichen Sie am besten über den Sitemaps-Bericht 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 Indexabdeckung aufgeführt sind. Dies liegt daran, dass der Bericht zur Indexabdeckung umfangreicher sein muss, damit Sie Indexierungsprobleme in Ihrem Bericht beheben können. Der AMP-Statusbericht deckt zwar weniger, aber relevantere Seiten detaillierter ab, um spezifische Probleme mit AMP-Seiten auf Ihrer Website zu beheben. Wenn Sie überprüfen möchten, ob eine AMP-Seite indexiert ist, verwenden Sie das URL-Prüftool, das die endgültige Antwort liefert.

Warnungen interpretieren

AMP-Seiten mit Warnungen werden indexiert und können in den Google-Suchergebnissen angezeigt werden. Unter Umständen werden sie jedoch 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.

Überprüfung

Nachdem Sie alle Instanzen eines bestimmten Problems auf Ihrer Website behoben haben, können Sie Google um die Überprüfung Ihrer Änderungen bitten. Wenn alle bekannten Instanzen des Problems beseitigt sind, wird es in der Statustabelle als behoben markiert und nach unten verschoben. Die Search Console erfasst den Überprüfungsstatus des gesamten Problems sowie den Status der einzelnen Probleminstanzen. Das Problem gilt als behoben, wenn alle Probleminstanzen beseitigt sind. Informationen zu erfassten Status finden Sie unter Status der Problemüberprüfung und Status der Instanzüberprüfung.

Lebensdauer eines Problems

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 dem Berichtsverlauf 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 dieses Problems 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. „Erstmals erkannt am“ wird in diesem Fall auf das aktuelle Datum festgelegt.

Ablauf einer Ü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 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 normalen Crawlen gefunden wurde, wird sie als weitere Instanz des bestehenden Problems angesehen.
  4. Wenn alle URLs mit Fehlern und Warnungen geprüft und dabei keine Probleme gefunden wurden, ändert sich der Problemstatus zu Bestanden. Wichtig: Auch wenn die Anzahl der betroffenen Seiten auf null fällt und sich der Problemstatus zu Bestanden ändert, wird weiterhin das ursprüngliche Label der Warn- oder Fehlermeldung angezeigt, also Fehler oder Warnung.

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 der Problemstatus im Bericht zu „Nicht zutreffend“ geändert.

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.Bei einem Überprüfungsversuch erhält die Seite den Status „Bestanden“.
  • Wenn die Seite 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. Bei einem Überprüfungsversuch erhält die Seite den Überprüfungsstatus „Sonstiges“.

Neuüberprüfung

Wenn Sie bei einer fehlgeschlagenen Überprüfung auf Erneut überprüfen klicken, wird die Überprüfung bei allen fehlgeschlagenen Instanzen sowie bei allen neuen Instanzen dieses Problems, die beim normalen Crawlen gefunden wurden, neu gestartet.

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

Instanzen, die die Überprüfung erfolgreich durchlaufen haben und als Bestanden markiert wurden oder die nicht mehr erreichbar sind und als Sonstiges markiert wurden, werden nicht noch einmal geprüft. Sie werden aus dem Verlauf entfernt, wenn Sie auf „Neu überprüfen“ klicken.

Überprüfungsverlauf

Sie können sich den Fortschritt einer Überprüfungsanforderung anzeigen lassen, indem Sie auf der Seite mit den Problemdetails auf den Link zu den Überprüfungsdetails klicken.

Für den AMP-Bericht und den Bericht zum Indexierungsstatus werden die Einträge im Überprüfungsverlauf nach URL gruppiert. Im Bericht zur Nutzererfahrung auf Mobilgeräten und im Bericht zu Rich-Suchergebnissen sind die Elemente anhand der Kombination aus URL und dem Wert „Name“ des strukturierten Datenelements gruppiert. Der Überprüfungsstatus 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 wiederum als „Fehlgeschlagen“, „Ausstehend“ oder „Sonstiges“.

Status der Problemüberprüfung

Folgende Statusmeldungen sind für ein bestimmtes Problem möglich:

  • Nicht gestartet: Es gibt eine oder mehrere Seiten mit einer Instanz dieses Problems, für die Sie noch nie einen Überprüfungsversuch begonnen haben. Nächste Schritte:
    1. Klicken Sie auf das Problem, um sich die Fehlerdetails anzusehen. Überprüfen Sie die einzelnen Seiten, um mithilfe des AMP-Tests Beispiele für den Fehler auf der Liveseite aufzurufen. Falls der Fehler beim AMP-Test nicht auf der Seite angezeigt wird, liegt dies daran, dass Sie den Fehler auf der Liveseite behoben haben, nachdem Google ihn gefunden und diesen Problembericht erstellt hat.
    2. Klicken Sie auf der Detailseite auf „Weitere Informationen“, um die Details der Regel aufzurufen, gegen die verstoßen wurde.
    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, damit Google die Seiten neu crawlt. Google informiert Sie über den Fortschritt der Überprüfung. Die Überprüfung dauert in der Regel etwa zwei Wochen, manchmal aber auch etwas 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 der Status zu „Nicht zutreffend“ geändert. 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 „Überprüfen“ geklickt haben. Nächste Schritte: Beheben Sie das Problem und führen Sie eine neue Überprüfung durch.

Status der Instanzüberprüfung

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

  • Ausstehende Überprüfung: 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.
  • 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.
War das hilfreich?
Wie können wir die Seite verbessern?
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
Google-Apps
Hauptmenü
Suchen in der Hilfe
true
83844
false