Monday, April 3, 2023

AMP-Statusbericht – Search Console-Hilfe [gg-webmasters-de]

AMP-Statusbericht

Dieser Bericht hilft Ihnen, Fehler zu beheben, die verhindern, dass Ihre AMP-Seiten in den Google-Suchergebnissen mit AMP-spezifischen Funktionen erscheinen.

Die Ansicht der obersten Ebene zeigt kritische Probleme, die AMP-Seiten auf Ihrer Website betreffen. Klicken Sie auf ein bestimmtes Problem, um Seiten anzuzeigen, die von diesem Problem betroffen sind, und Einzelheiten zum Problem.

AMP-BERICHT ÖFFNEN

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

Was steht im Bericht

Kritische Probleme : Von kritischen AMP-Problemen betroffene Seiten können nicht auf Google angezeigt werden. Eine Liste der auf Ihrer Website gefundenen kritischen Probleme wird direkt unter dem Diagramm auf der obersten Seite des AMP-Berichts mit dem Titel Warum AMP-Seiten ungültig sind angezeigt. Klicken Sie auf ein Problem in der Liste, um Seiten mit dem ausgewählten Problem anzuzeigen.

Unkritische Probleme (Warnungen): AMP-Seiten mit nicht kritischen Problemen können weiterhin bei Google angezeigt werden, wenn sie auch keine kritischen Probleme aufweisen. Eine Liste der nicht kritischen Probleme, die auf Ihrer Website gefunden wurden, wird unter der Liste der kritischen Probleme auf der obersten Seite des AMP-Berichts mit dem Titel Nicht kritische Probleme angezeigt. Klicken Sie auf ein Problem in der Liste, um Seiten mit dem ausgewählten Problem anzuzeigen. AMP-Seiten mit Warnungen werden möglicherweise nicht mit allen möglichen AMP-Funktionen angezeigt (z. B. in einem Top Stories-Karussell). Mit anderen Worten, diese Seiten werden möglicherweise nur als einfache blaue Link-Suchergebnisse angezeigt.

Seitenstatus ( gültige und ungültige Seiten): AMP-Seiten sind entweder gültig oder ungültig. Gültige AMP-Seiten können bei Google angezeigt werden; ungültige AMP-Seiten können nicht auf Google angezeigt werden. Wenn eine Seite kritische Probleme aufweist, wird sie als ungültig betrachtet; Wenn es nur Warnungen oder überhaupt keine Probleme gibt, gilt es als gültig. Sie können eine Liste gültiger AMP-Seiten anzeigen, indem Sie unter dem Diagramm auf der obersten Seite des AMP-Berichts auf Daten zu gültigen AMP-Seiten anzeigen klicken.

Wonach schauen

Sie sollten in Ihrem Bericht die folgenden Zahlen anstreben:

Die Liste der betroffenen URLs ist ein Beispiel, es wird jedoch nicht garantiert, dass jede URL angezeigt wird, die von einem bestimmten Problem betroffen ist. Der Bericht ist auf 1.000 URLs pro Ausgabe begrenzt. Außerdem ist es möglich, dass wir aus irgendeinem Grund weitere Seiten nicht erkannt oder gezählt haben.

Der Bericht kann insgesamt nur 200 kritische + nicht kritische Probleme anzeigen. Wenn Ihre Website eine sehr lange Liste von Problemen hat (unabhängig davon, ob es aktive Instanzen gibt oder nicht), werden nur die 200 wichtigsten Probleme, sortiert nach Wichtigkeit, angezeigt.

AMP-Probleme

Zusätzlich zu den standardmäßigen AMP-spezifischen Fehlern kann der Bericht die folgenden zusätzlichen Probleme aufdecken (Fehler und Warnungen).

Google-spezifische AMP-Probleme
Ausgabe Beschreibung
Inhaltskonflikt: Fehlendes eingebettetes Video Die kanonische Webseite hat ein eingebettetes Video, das in der AMP-Version fehlt. In der Regel ist es am besten, alle wichtigen Inhaltsressourcen in Ihre AMP-Version aufzunehmen wie in die kanonische Webseite. Beachten Sie, dass das Video anhand der URL erkannt wird; Wenn Sie zwei verschiedene URLs haben, die auf dasselbe Video verweisen, sehen Sie diese Warnung.
Bildgröße kleiner als die empfohlene Größe Die strukturierten Daten im AMP beziehen sich auf ein Bild, das kleiner als unsere empfohlene Größe ist. Dies kann verhindern, dass die Seite mit allen AMP-bezogenen Funktionen in der Google-Suche angezeigt wird, und kann auch verhindern, dass Ihre Discover-Karten mit großen Bildern angezeigt werden (was zu verringertem Website-Traffic und geringerer Nutzerinteraktion führt). Verwenden Sie zum Beheben des Problems ein größeres Bild gemäß unserenRichtlinien .
Nichtübereinstimmung der Domain der AMP-Seite Die AMP-Seite wird auf einer anderen Domain gehostet als ihre kanonische Version. Dies kann für mobile Suchende verwirrend sein, die eine URL-Domain in den Suchergebnissen sehen und eine andere, wenn sie die Seite im AMP-Reader öffnen. (Wirkt sich nicht auf die Seitenindizierung oder das Ranking aus.)
URL nicht gefunden (404) Die angeforderte AMP-URL konnte nicht gefunden werden. Erfahren Sie mehr über das Korrigieren von 404-Seiten.
Serverfehler (5XX) Unspezifizierter 5XX-Serverfehler beim Anfordern der AMP-Seite. Erfahren Sie mehr über Serverfehler .
Blockiert durch robots.txt Die angeforderte AMP-URL wurde durch eine robots.txt-Regel blockiert . Wenn Sie dies nicht möchten, testen Sie Ihre robots.txt-Datei auf die Sperrregel und ändern oder entfernen Sie dann die Regel (oder bitten Sie Ihren Webentwickler, dies für Sie zu tun).
Crawl- Problem Unbekannter Crawling-Fehler für die AMP-Seite. Verwenden Sie das URL-Prüftool für Ihre AMP-URL, um das Problem zu beheben.
Die referenzierte AMP-URL ist kein AMP Eine kanonische Seite verweist auf eine AMP-Seite, die eigentlich keine AMP-Seite ist. Erfahren Sie, wie eine Nicht-AMP-Seite auf eine AMP-Seite verweisen sollte.
Die referenzierte AMP-URL ist ein selbstkanonisches AMP Die kanonische Seite verweist auf ein eigenständiges AMP . Sie können ein eigenständiges AMP nicht als AMP-Version einer Seite referenzieren. Erfahren Sie, wie Sie auf eine AMP-Seite von einer Nicht-AMP-Seite aus verweisen.
Mit "noindex" gekennzeichnete URL AMP wird durch eine 'noindex'-Direktive blockiert. Google kann eine Seite, die von noindex blockiert wird, nicht indizieren; Entfernen Sie entweder die Direktive noindex oder den Verweis auf die blockierte Seite.
Das 'unavailable_after'-Datum für diese Seite ist abgelaufen Die AMP-Seite hat ein „unavailable_after"-Meta-Tag oder eine Anweisung , die bereits bestanden wurde, was darauf hinweist, dass sie nicht mehr bereitgestellt werden sollte. Sie sollten das Tag entweder auf ein zukünftiges Datum aktualisieren oder das Tag entfernen.
Canonical zeigt auf ungültige URL Eine kanonische Seite verweist mit einer ungültig formatierten URL auf eine AMP-Version. Erfahren Sie, wie Sie richtig auf eine AMP-Version verweisen .
Kanonischer Fehler in der Amp-Geschichte

Eine Seite verweist fälschlicherweise auf eine AMP-Story-Seite als ihre AMP-Version. Dies ist nicht zulässig, da eine AMP-Story-Seite per Definition selbstkanonisch ist: Sie muss mit einem <rel="canonical"> Tag auf sich selbst verweisen und darf nicht als AMP-Version einer anderen Seite dienen.

Modulskript ohne nomodule-Alternative deklariert (oder umgekehrt) Sie verwenden entweder ein <script type="module">-Tag ohne ein passendes <script nomodule async>-Tag oder umgekehrt. Diese Tags müssen in übereinstimmenden Paaren verwendet werden, um eine ordnungsgemäße Handhabung durch Browser zu ermöglichen, die Modulskripte unterstützen oder nicht unterstützen .
Fehlende URL im HTML-Tag Das angegebene HTML-Tag erfordert ein Attribut mit einer gültigen URL ungleich Null, aber die URL ist eine leere Zeichenfolge. Geben Sie eine gültige URL für das hervorgehobene Attribut an.
Das Attribut fehlt oder ist falsch, wird aber vom Attribut 'on' benötigt Das angegebene Attribut ist erforderlich, aber falsch oder fehlt. Dieses Attribut ist erforderlich, da Sie im selben Tag ein "on"-Attribut angegeben haben.
Untergeordnetes <svg>-Tag außerhalb eines <svg>-Blocks gefunden. Sie haben ein Tag außerhalb eines <svg>-Blocks angegeben, das in einem <svg>-Block verschachtelt sein muss.
Die Seite lädt mehrere Versionen desselben Erweiterungsskripts Die Seite lädt mehrere Versionen derselben AMP-Erweiterung. Um das Problem zu beheben, entfernen Sie eine Version des Skripts.
Signierte Austauschprobleme

Sowohl der AMP-Statusbericht als auch der URL-Prüfbericht können Probleme für AMPs anzeigen, die das signierte Austauschprotokoll verwenden .

Um signierte Austauschdetails zu einem Problem anzuzeigen

Informationen über den mit einem AMP verknüpften signierten Austausch finden Sie an mehreren Stellen:

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

Um zu sehen, ob Ihr AMP Signed Exchange verwendet

So sehen Sie, ob Google signierte Exchange-Header oder Payloads für Ihr AMP erkannt hat:

  1. Prüfen Sie die AMP-URL (verwenden Sie entweder das URL-Prüftool , um eine bestimmte URL zu prüfen, oder klicken Sie im AMP-Statusbericht auf das Prüfsymbol neben der URL in der Problemdetailtabelle).
  2. Klicken Sie auf der Ergebnisseite auf Durchforstete Seite anzeigen , um einen Seitenbereich mit weiteren Informationen zu öffnen.
  3. Klicken Sie auf die Registerkarte Weitere Informationen .
  4. Unter dem Signed-Exchange- Label sehen Sie einen Status, der angibt, ob Google signierte Exchange-Komponenten für dieses AMP gefunden hat.

Liste der signierten Austauschausgaben

Die folgenden Probleme können auftreten, wenn Ihr AMP das signierte Austauschprotokoll verwendet .

Der unterzeichnete Austausch ist ungültig

Die HTTP-Antwort war ein signierter Austausch , der die Google-AMP-Cache- Anforderungen nicht erfüllte . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Dieser Fehler kann aus mehreren Gründen auftreten, darunter:

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Die Nutzdaten des signierten Austauschs weisen einen Parsing-Fehler auf

Die HTTP-Antwort war ein signierter Austausch , dessen „Payload" (Body) die Anforderungen von Google AMP Cache nicht erfüllte . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Versuchen Sie die folgenden Schritte, um den Fehler zu finden und zu beheben:

  • Stellen Sie sicher, dass der HTML-Code keine ungültige UTF-8-Codierung enthält. Führen Sie für die fehlerhafte $URL curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null aus curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null und suchen Sie nach Fehlermeldungen wie „unzulässige Eingabesequenz". Wenn dies der Fall ist, stellen Sie bitte sicher, dass das Dokument ordnungsgemäß mit UTF-8 codiert ist. Zwei häufige Quellen für Multibyte-Zeichen sind nicht englischer Text und Leerzeichen .
  • Stellen Sie sicher, dass der HTML-Code kein U+0000 NULL oder ein Unicode-Zeichen enthält, das einen HTML-Parse-Fehler verursacht .
  • Stellen Sie sicher, dass der HTML-Code nach dem Aufruf transform -config NONE unverändert ist. Es gibt zwei häufige Gründe für eine Änderung:

Der Header ' header_name ' für die Nutzlast des signierten Austauschs hat einen ungültigen Wert

Die HTTP-Antwort war ein signierter Austausch , der einen signierten Antwort-Header enthielt, der eine der Google AMP-Cache- Anforderungen nicht erfüllte . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Der obligatorische Header ' header_name ' für die Nutzlast des signierten Austauschs fehlt

Die HTTP-Antwort war ein signierter Austausch , dem der angegebene Header fehlte, der entweder von der Spezifikation für den signierten Austausch oder den Google AMP-Cache- Anforderungen verlangt wird . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Der Signaturheader für den signierten Austausch kann nicht geparst werden

Die HTTP-Antwort war ein signierter Austausch , der einen Signatur-Header enthielt, der gemäß der Spezifikation für signierten Austausch nicht wohlgeformt war . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Der Parameter ' parameter_name ' im Signatur-Header des signierten Austauschs ist ungültig

Die HTTP-Antwort war ein signierter Austausch , dessen Signatur-Header einen falschen Wert für den angegebenen Parameter hatte, wie von der Spezifikation für signierte Austausche gefordert . Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Die Daten für den unterzeichneten Austausch sind ungültig

Die HTTP-Antwort war ein signierter Austausch , dessen Signatur-Header einen falschen Wert für den date oder expires Parameter aufwies, wie von der Spezifikation für signierte Austausche oder den Google-AMP-Cache -Anforderungen gefordert. (Insbesondere muss die Signatur zum Zeitpunkt des Abrufs und mindestens 4 Tage in der Zukunft gültig sein.) Als Ergebnis wird die Seite Benutzern ohne Informationen aus der Signatur präsentiert

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden, kann dies mehrere Gründe haben:

  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy signierte Austauschantworten nicht zu lange zwischenspeichert. Stellen Sie mehrere Anfragen für die Seite mit curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' und suchen Sie in jeder Antwort nach " date= "; vergewissern Sie sich, dass die nachfolgende Nummer jedes Mal anders ist.
  • Stellen Sie sicher, dass Sie die neueste Version von AMP Packager ausführen.
  • Wenn Sie alle oben genannten Punkte ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. Bitte melden Sie einen Fehler .

Die Zertifikatskette, auf die der signierte Austausch „cert-url" verweist, kann nicht geparst werden

Die HTTP-Antwort war ein signierter Austausch , dessen Zertifikat-URL gemäß der Spezifikation für signierten Austausch nicht wohlgeformt war. Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden:

Die von „cert-url" referenzierte Zertifikatskette ist für den signierten Austausch ungültig

Die HTTP-Antwort war ein signierter Austausch , dessen Zertifikat-URL gemäß der Spezifikation für signierten Austausch ungültig war. Als Ergebnis wird die Seite den Benutzern ohne Informationen aus der Signatur präsentiert.

Auswirkungen auf Ihre Website:

Die Seite wird in einem AMP-Viewer mit einer Google-URL und nicht mit ihrer ursprünglichen URL angezeigt.

Nächste Schritte:

Die Behebung dieses Fehlers ist optional; Seiten mit diesem Fehler werden in einem AMP-Viewer weiterhin ordnungsgemäß angezeigt. Wenn Sie möchten, dass diese Seite mit ihrer signierten URL angezeigt wird, lesen Sie weiter.

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden, kann dieser Fehler aus mehreren Gründen auftreten. Einige Dinge zu überprüfen:

  • Stellen Sie sicher, dass Ihre CertFile keine vollständige Liste des Blattzertifikats plus Zwischenprodukte enthält.
  • Stellen Sie sicher, dass AMP Packager nicht mit dem Flag -development oder -invalidcert gestartet wurde. Im Produktionsmodus überprüft AMP Packager mehrere Aspekte des Zertifikats.
  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy /amppkg/cert/ URLs nicht länger zwischenspeichert, als durch ihr max-age festgelegt ist.
  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy keine Cache-Header ändert. Dies könnte dazu führen, dass ein Upstream-Proxy diese Zertifikatsketten zu lange zwischenspeichert. Ermitteln Sie zum Testen die entsprechende URL /amppkg/cert/ auf Ihrer internen Packager-Domain, rufen Sie sie einschließlich der Antwortheader ab (z. B. mit curl -i ) und vergleichen Sie die Antwortheader mit denen, die vom Frontend-Server zurückgegeben werden.
  • Stellen Sie sicher, dass Ihr Zertifikat ein SCT enthält, beispielsweise mit dem Tool openssl x509 . Wenn dies nicht der Fall ist, wenden Sie sich bitte an Ihre Zertifizierungsstelle.
  • Stellen Sie sicher, dass Sie die neueste Version von AMP Packager ausführen.
  • Wenn Sie alle oben genannten Punkte ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. Bitte melden Sie einen Fehler .

Der signierte Austausch kann nicht analysiert werden

Die HTTP-Antwort hatte den Inhaltstyp application/signed-exchange;v=b3 , aber der Antworttext konnte nicht extrahiert werden. Dies könnte daran liegen, dass es die hohen Anforderungen dieses Typs nicht erfüllt hat oder dass seine Nutzlast nicht ordnungsgemäß mit Merkle codiert war.

Auswirkungen auf Ihre Website:

Wenn die Seite über eine entsprechende Nicht-AMP-Seite verfügt, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise überhaupt nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden, kann dies mehrere Gründe haben:

  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy die Antworten des Paketierers nicht verändert. Ermitteln Sie für die fehlerhafte URL die entsprechende URL /priv/doc in Ihrer internen Packager-Domäne und testen Sie sie mit dump-signedexchange . Wenn die interne Packager-Antwort ein gültiger signierter Austausch ist, die externe Front-End-Antwort jedoch nicht, liegt wahrscheinlich ein Konfigurationsfehler im Front-End vor.
  • Stellen Sie sicher, dass Sie die neueste Version von AMP Packager ausführen.
  • Wenn Sie alle oben genannten Punkte ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. Bitte melden Sie einen Fehler .

Die URL für die innere Nutzlast stimmt nicht mit der Anforderungs-URL für den signierten Austausch überein

Die HTTP-Antwort war ein signierter Austausch , dessen fallbackUrl nicht mit der Anforderungs-URL übereinstimmte; sie müssen Byte für Byte gleich sein. Daher vertraut die Google-Suche nicht darauf, dass die Antwort repräsentativ für die Anfrage-URL ist.

Auswirkungen auf Ihre Website:

Wenn die Seite über eine entsprechende Nicht-AMP-Seite verfügt, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise überhaupt nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten. Mögliche Problemumgehungen umfassen das Ändern der URL der Seite, um Fehler in gängigen URL-Parsern zu vermeiden. Versuchen Sie beispielsweise, prozentcodierte oder reservierte Zeichen oder ungewöhnliche Codierungen von Abfragezeichenfolgen wie ein ? zu eliminieren. ohne Parameter.

Wenn Sie AMP Packager verwenden, kann dies mehrere Gründe haben:

  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy URLs korrekt umschreibt. Probleme sind besonders wahrscheinlich bei URLs mit prozentkodierten oder reservierten Zeichen. Beispielsweise hat nginx Probleme mit seiner rewrite-Direktive und der pfadlosen Form seiner proxy_pass-Direktive . Um dies zu testen, senden Sie einige Testanfragen an Ihr Front-End und vergleichen Sie diese mit den URLs, die AMP Packager in seiner Standardausgabe protokolliert.
  • Stellen Sie sicher, dass Sie die neueste Version von AMP Packager ausführen.
  • Wenn Sie alle oben genannten Punkte ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. Bitte melden Sie einen Fehler .

Der Header ' header_name ' für die HTTP-Antwort des signierten Austauschs hat einen ungültigen Wert

Die HTTP-Antwort hatte einen Inhaltstyp von application/signed-exchange , aber die Antwortheader waren auf andere Weise ungültig. Dem Inhaltstyp kann beispielsweise der Parameter v=b3 fehlen. Infolgedessen ist das Format Google unbekannt und der Antworttext kann daher nicht extrahiert werden.

Auswirkungen auf Ihre Website:

Wenn die Seite über eine entsprechende Nicht-AMP-Seite verfügt, indexiert die Google-Suche stattdessen diese. Andernfalls wird die Seite möglicherweise überhaupt nicht in der Google-Suche angezeigt.

Nächste Schritte:

Wenn Sie einen signierten Austauschdienstanbieter verwenden, wenden Sie sich an diesen, um Unterstützung zu erhalten.

Wenn Sie AMP Packager verwenden, kann dies mehrere Gründe haben:

  • Stellen Sie sicher, dass Ihr Front-End-Reverse-Proxy die Content-Type-Header nicht ändert. Ermitteln Sie für die fehlerhafte URL die entsprechende URL /priv/doc auf Ihrer internen Packager-Domain und rufen Sie sie einschließlich der Antwortheader ab (z. B. mit curl -i ). Wenn sich die Header zwischen der internen Packager-Antwort und der externen Frontend-Antwort unterscheiden, kann dies die Fehlerquelle sein. Wenn der Unterschied in einem anderen Header als content-type liegt, melden Sie bitte einen Fehler in diesem Hilfedokument, um die Liste der Anforderungen zu aktualisieren.
  • Stellen Sie sicher, dass Sie die neueste Version von AMP Packager ausführen.
  • Wenn Sie alle oben genannten Punkte ausgeschlossen haben, liegt möglicherweise ein Fehler in AMP Packager vor. Bitte melden Sie einen Fehler .

Priorisieren und beheben Sie Probleme

  1. Sehen Sie sich die Liste der kritischen Probleme für Ihre Website in der Tabelle Warum AMP-Seiten ungültig sind an.
  2. Analysieren Sie Ihre Fehler:
    • Überprüfen Sie, ob ein Anstieg der Gesamtfehlerzahl hauptsächlich durch einen einzelnen Fehler verursacht wird: Suchen Sie in der Tabelle nach einer entsprechenden Spitze in einem einzelnen Problem.
    • Beheben Sie zuerst Fehler, die durch eine häufige Ursache verursacht werden (z. B. eine schlechte Vorlage), und beheben Sie dann Fehler, die für jede Seite einzigartig sind.
  3. Beheben Sie Ihre Fehler: Klicken Sie auf eine Zeile in der Tabelle, um die Seite mit den Fehlerdetails anzuzeigen:
    1. Die Detailseite enthält ein Beispiel für betroffene URLs. Die Liste ist auf 1.000 Zeilen begrenzt und enthält möglicherweise keine kürzlich entdeckten Instanzen dieses Fehlers oder Seiten, die seit Auftreten des Fehlers nicht erneut gecrawlt wurden.
    2. Klicken Sie neben einem Problem auf Weitere Informationen , um eine offizielle Dokumentation zu dem Fehler zu erhalten.
    3. Klicken Sie in der URL-Beispieltabelle auf eine URL, um das im Seitencode hervorgehobene Problem anzuzeigen.
    4. Klicken Sie auf das Symbol „Inspizieren". um einen detaillierten Test für eine bestimmte Seite durchzuführen. Dieser Test lokalisiert alle Fehler (nicht nur das aktuelle Problem) und stellt einen Code-Explorer bereit, der die Fehler hervorhebt und weitere Informationen bereitstellt. Wenn die Seite in letzter Zeit nicht erneut gecrawlt wurde, sehen Sie das Problem für die indexierte Seite, aber nicht für die Live-Seite. In diesem Fall können Sie die Indexierung dieser bestimmten Seite anfordern.
    5. Beheben Sie alle Instanzen des Problems auf Ihrer Website, testen Sie Ihre Behebung und stellen Sie sicher, dass Ihre Behebungen im Internet verfügbar sind.
  4. Wenn Sie alle Instanzen behoben haben, kehren Sie zur Seite mit den Problemdetails zurück und klicken Sie auf die Schaltfläche „Fix validieren" , um den Validierungsprozess zu starten. Dieser Prozess ist nicht unmittelbar. Siehe Informationen zur Validierung , um den Validierungsprozess zu verstehen.
  5. Fahren Sie mit der Fehlerbeseitigung fort.
  6. Wenn die Gesamtzahl gültiger und ungültiger Seiten deutlich unter der Anzahl der AMP-Seiten auf Ihrer Website liegt, finden Sie weitere Informationen unter Fehlerbehebung bei fehlenden AMP-Seiten .
  7. Wenn alle kritischen Fehler behoben wurden, sollten Sie die nicht kritischen Probleme beheben. Einige nicht kritische Probleme (z. B. die Verwendung veralteter Funktionen) können in Zukunft kritisch werden.

Teilen des Berichts

Sie können Problemdetails in den Abdeckungs- oder Verbesserungsberichten teilen, indem Sie auf „ Teilen" klicken Schaltfläche auf der Seite. Dieser Link gewährt jedem, der über den Link verfügt, nur Zugriff auf die Detailseite des aktuellen Problems sowie alle Validierungsverlaufsseiten für dieses Problem. Es gewährt keinen Zugriff auf andere Seiten für Ihre Ressource oder ermöglicht es dem freigegebenen Benutzer, Aktionen für Ihre Property oder Ihr Konto durchzuführen. Sie können die Verlinkung jederzeit aufheben, indem Sie das Teilen für diese Seite deaktivieren.

Berichtsdaten exportieren

Viele Berichte bieten eine Exportschaltfläche um die Berichtsdaten zu exportieren. Sowohl Diagramm- als auch Tabellendaten werden exportiert. Werte, die im Bericht entweder als ~ oder - angezeigt werden (nicht verfügbar/keine Zahl), sind in den heruntergeladenen Daten Nullen.

Fehlerbehebung bei fehlenden AMP-Seiten

Wenn die Anzahl der AMP-Seiten (gültig + ungültig) im Bericht geringer ist als die Anzahl der AMP-Seiten auf Ihrer Website, sind dies einige mögliche Gründe:

  • Bestätigen Sie, dass Ihre kanonische Nicht-AMP-Seite korrekt mit Ihrer AMP-Seite verknüpft ist.
  • Bestätigen Sie, dass Ihre AMP- oder kanonischen Seiten nicht automatisiert oder nicht indexiert oder durch Anmeldeanforderungen geschützt sind.
  • Überprüfen Sie die kanonische Seiten-URL für Ihr AMP, um festzustellen, ob es indexiert ist.
    • Wenn das Canonical vorhanden ist, vergewissern Sie sich, dass es korrekt auf Ihre AMP-Seite verlinkt.
    • Wenn das Canonical nicht vorhanden ist, reichen Sie es zur Indexierung ein .
  • Es kann einige Tage dauern, bis Google die fehlenden Seiten gefunden und gecrawlt hat, je nachdem, wie Sie Google über die neuen Seiten informieren.
  • Einige gültige AMP-Seiten sind möglicherweise nicht in diesem Bericht enthalten, obwohl sie möglicherweise im Seitenindizierungsbericht aufgeführt sind. Dies liegt daran, dass der Bericht zur Seitenindizierung umfassender sein muss, um Ihnen beim Debuggen von Indizierungsproblemen in Ihrem Bericht zu helfen, während der AMP-Statusbericht möglicherweise weniger, aber relevantere Seiten abdeckt, aber detaillierter, um Ihnen beim Debuggen bestimmter AMP zu helfen Probleme auf Ihrer Website. Um zu bestätigen, ob eine AMP-Seite indexiert ist, verwenden Sie das URL-Inspektionstool , das die endgültige Antwort liefert.
Validieren Sie Ihre Korrekturen

Nachdem Sie alle Instanzen eines bestimmten Problems auf Ihrer Website behoben haben, können Sie Google bitten, Ihre Korrekturen zu bestätigen. Wenn alle bekannten Instanzen behoben sind, geht die Problemanzahl in der Problemtabelle auf Null und wird an das Ende der Tabelle verschoben.

Warum validieren

Wenn Sie Google mitteilen, dass Sie alle Probleme in einem bestimmten Problemstatus oder einer bestimmten Kategorie behoben haben, hat das folgende Vorteile:

  • Sie erhalten eine E-Mail, wenn Google Ihre Korrektur für alle URLs bestätigt hat oder umgekehrt, wenn Google verbleibende Instanzen dieses Problems gefunden hat.
  • Sie können den Fortschritt von Google bei der Bestätigung Ihrer Korrekturen verfolgen und ein Protokoll aller Seiten anzeigen, die zur Überprüfung in die Warteschlange gestellt wurden, sowie den Korrekturstatus jeder URL.

Es ist möglicherweise nicht immer sinnvoll, ein bestimmtes Problem auf Ihrer Website zu beheben und zu validieren: Zum Beispiel werden URLs, die von robots.txt blockiert werden, wahrscheinlich absichtlich blockiert. Verwenden Sie Ihr Urteilsvermögen, wenn Sie entscheiden, ob Sie ein bestimmtes Problem ansprechen.

Sie können Probleme auch ohne Validierung beheben; Google aktualisiert Ihre Instanzenzahl immer dann, wenn eine Seite mit bekannten Problemen gecrawlt wird, unabhängig davon, ob Sie die Fixvalidierung explizit angefordert haben oder nicht.

Profi-Tipp: Validieren Sie Ihre Korrekturen anhand der Sitemap
Um eine Fehlerbehebungsanfrage zu beschleunigen, erstellen und übermitteln Sie eine Sitemap, die nur Ihre wichtigsten Seiten enthält, und filtern Sie dann den Bericht nach dieser Sitemap, bevor Sie eine Fehlerbehebungsvalidierung anfordern. Eine Validierungsanfrage für eine Teilmenge Ihrer betroffenen URLs kann schneller abgeschlossen werden als eine Anfrage, die alle betroffenen URLs auf Ihrer Website umfasst.

Validierung starten

So teilen Sie der Search Console mit, dass Sie ein Problem behoben haben:

  1. Beheben Sie alle Instanzen des Problems auf Ihrer Website. Wenn Sie eine Lösung verpasst haben, wird die Validierung beendet, wenn Google eine einzige verbleibende Instanz dieses Problems findet.
  2. Öffnen Sie die Problemdetailseite des Problems, das Sie behoben haben. Klicken Sie auf das Problem in der Problemliste in Ihrem Bericht.
    • ⚠️ Wenn Sie in Ihrem Bericht auf eine bestimmte Sitemap gefiltert werden, gilt die Validierung nur für Elemente in der Sitemap zu dem Zeitpunkt, an dem Sie die Validierung angefordert haben. Dies kann das sein, was Sie wollen, oder auch nicht. Seien Sie sich dessen bewusst.
  3. Klicken Sie auf Fix validieren . Klicken Sie nicht erneut auf Fix validieren, bis die Validierung erfolgreich war oder fehlgeschlagen ist. Weitere Einzelheiten darüber, wie Google Ihre Korrekturen prüft .
  4. Sie können den Validierungsfortschritt überwachen . Die Validierung dauert in der Regel bis zu zwei Wochen, kann aber in einigen Fällen viel länger dauern , also haben Sie bitte etwas Geduld. Sie erhalten eine Benachrichtigung, wenn die Validierung erfolgreich ist oder fehlschlägt.
  5. Wenn die Validierung fehlschlägt , können Sie sehen, welche URL das Fehlschlagen der Validierung verursacht hat, indem Sie auf der Seite mit den Problemdetails auf Details anzeigen klicken. Korrigieren Sie diese Seite, bestätigen Sie Ihre Korrektur für alle URLs im Status „Ausstehend" und starten Sie die Validierung neu .

Wann gilt ein Problem für eine URL oder einen Artikel als „behoben"?

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

  • Wenn die URL gecrawlt wird und das Problem nicht mehr auf der Seite gefunden wird. Bei einem AMP-Tag-Fehler kann dies bedeuten, dass Sie das Tag entweder repariert haben oder dass das Tag entfernt wurde (wenn das Tag nicht erforderlich ist). Während eines Validierungsversuchs wird es mit Passed gekennzeichnet.
  • Wenn die Seite aus irgendeinem Grund für Google nicht verfügbar ist (Seite entfernt, als noindex gekennzeichnet, Authentifizierung erforderlich usw.), gilt das Problem für diese URL als behoben. Während eines Validierungsversuchs wird es in den anderen Validierungszustand kategorisiert.

Lebensdauer ausgeben

Die Lebensdauer eines Problems erstreckt sich vom ersten Auftreten dieses Problems auf Ihrer Website bis zu 90 Tagen, nachdem das letzte Vorkommen von Ihrer Website als verschwunden markiert wurde. Wenn neunzig Tage ohne Wiederholungen vergehen, wird das Problem aus der Problemtabelle entfernt.

Das Datum der ersten Erkennung eines Problems ist das erste Mal, dass das Problem während der Lebensdauer des Problems erkannt wurde, und ändert sich nicht. Deshalb:

  • Wenn alle Instanzen eines Problems behoben wurden, aber 15 Tage später eine neue Instanz des Problems auftritt, wird das Problem als offen markiert und das Datum der ersten Erkennung bleibt das ursprüngliche Datum.
  • Wenn das gleiche Problem 91 Tage nach der Behebung der letzten Instanz auftritt, wurde das vorherige Problem geschlossen, und dieses Problem wird als neues Problem aufgezeichnet, wobei das erste Erkennungsdatum auf das neue Erkennungsdatum gesetzt wird.
Validierungsfluss

Hier ist eine Übersicht über den Validierungsprozess, nachdem Sie auf „Fix überprüfen" für ein Problem geklickt haben. Dieser Vorgang kann mehrere Tage oder sogar länger dauern und Sie erhalten Fortschrittsbenachrichtigungen per E-Mail.

  1. When you click Validate Fix , Search Console immediately checks a few pages.
    • If the current instance exists in any of these pages, validation ends, and the validation state remains unchanged.
    • If the sample pages do not have the current error, validation continues with state Started . If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.
  2. Search Console works through the list of known URLs affected by this issue. Only URLs with known instances of this issue are queued for recrawling, not the whole site. Search Console keeps a record of all URLs checked in the validation history, which can be reached from the issue details page.
  3. When a URL is checked:
    1. If the issue is not found, the instance validation state changes to Passing . If this is the first instance checked after validation has started, the issue validation state changes to Looking good .
    2. If the URL is no longer reachable, the instance validation state changes to Other (which is not an error state).
    3. If the instance is still present, issue state changes to Failed and validation ends. If this is a new page discovered by normal crawling, it is considered another instance of this existing issue.
  4. When queued URLs have been checked for this issue and found to be fixed of this issue, the issue state changes to Passed . However, even when all instances have been fixed, the severity label of the issue doesn't change ( Error or Warning ), only the number of affected items (0).

Even if you never click Start validation Google can detect fixed instances of an issue. If Google detects that all instances of an issue have been fixed during its regular crawl, it will change the issue count to 0 on the report.

Revalidation

⚠️ Wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

To restart a failed validation:

  1. Navigate into the validation log for the failed validation: Open to the issue details page of the issue that failed validation and click See details .
  2. Click Start new validation .
  3. Validation will restart for all URLs marked Pending or Failed , plus any new instances of this issue discovered through normal crawling since the last validation attempt. URLs marked Passed or Other are not rechecked.
  4. Validation typically takes up to about two weeks , but in some cases can take much longer, so please be patient.

See validation progress

To see the progress of a current validation request, or the history of the last request if a validation is not in progress:

  1. Open the issue details page for the issue. Click the issue row in the main report page to open the issue details page.
  2. Click See details to open the validation details page for that request.
    • The instance status for each URL included in the request is shown in the table.
    • The instance status applies to the specific issue that you are examining. You can have one issue labeled Passed on a page, but other issues labeled Failed , Pending , or Other on the same page.
    • In the AMP report and Page Indexing report, entries in the validation history page are grouped by URL.
    • In the Mobile Usability and Rich Result reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).
Validation request status

The following validation states apply to validation for a given issue:

  • Not started: One or more instances of this issue have never been in a validation request for this issue.
    Next steps:
    1. Click into the issue to learn the details of the error. Inspect the individual pages to see examples of the error on the live page using the AMP Test. (If the AMP Test does not show the error on the page, it is because you fixed the error on the live page after Google found the error and generated this issue report.)
    2. Click Learn more on the details page to see the details of the problem.
    3. Click an example URL row in the table to get details on that specific error.
    4. Fix your pages and then click Validate fix to start validation . Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.
  • Started: You have begun a validation attempt and no remaining instances of the issue have been found yet.
    Next step: Google will send notifications as validation proceeds, telling you what to do, if necessary.
  • Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed.
    Next step: Nothing to do, but Google will send notifications as validation proceeds, telling you what to do.
  • Passed: All known instances of the issue are gone (or the affected URL is no longer available). You must have clicked Validate fix to get to this state (if instances disappeared without you requesting validation, state would change to N/A).
    Next step: Nothing more to do.
  • N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt.
    Next step: Nothing more to do.
  • Failed: A certain threshold of pages still contain this issue, after you clicked Validate .
    Next steps: Fix the issue and restart validation .
Instance validation status

After validation has been requested, every instance of the issue is assigned one of the following validation states:

  • Pending: Queued for validation. The last time Google looked, this issue instance existed.
  • Passed: [ Not available in all reports ] Google checked for the issue instance and it no longer exists. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Failed: Google checked for the issue instance and it's still there. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Other : [ Not available in all reports ] Google couldn't reach the URL hosting the instance, or (for structured data) couldn't find the item on the page any more. Considered equivalent to Passed .

Note that the same URL can have different states for different issues; For example, if a single page has both issue X and issue Y, issue X can be in validation state Passed and issue Y on the same page can be in validation state Pending .

Known issues

The following are known issues in Search Console. No need to report them to us, but we'd love your feedback on any other features or issues you spot. Use the Feedback mechanism built into the navigation bar.

  • Some issues have long names that are not easy to understand.
  • There can be a lag between when an issue is added to the graph and when it is added to the table.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)