Rapport d'état AMP

Ce rapport vous aide à corriger les erreurs qui empêchent vos pages AMP de figurer dans les résultats de recherche Google avec des fonctionnalités spécifiques aux pages AMP.

La vue d'ensemble recense les problèmes critiques qui affectent les pages AMP de votre site. Cliquez sur un problème spécifique pour afficher les pages concernées et les détails du problème.

OUVRIR LE RAPPORT AMP

 

Formation Google Search Console : rapport d'état AMP dans la Search Console

 

Contenu du rapport

Problèmes critiques : les pages affectées par des problèmes AMP critiques ne peuvent pas être affichées sur Google. Une liste des problèmes critiques détectés sur votre site est affichée directement sous le graphique, sur la page de premier niveau du rapport AMP, avec le titre Pourquoi les pages AMP ne sont pas valides. Cliquez sur un problème dans la liste pour afficher les pages affectées.

Problèmes non critiques (avertissements) : les pages AMP qui présentent des problèmes non critiques, mais aucun problème critique, peuvent être affichées sur Google. La liste des problèmes non critiques détectés sur votre site s'affiche sous celle des problèmes critiques, sur la page de premier niveau du rapport AMP, avec le titre Problèmes non critiques. Cliquez sur un problème dans la liste pour afficher les pages affectées. Les pages AMP qui contiennent des avertissements ne seront peut-être pas présentées avec toutes les fonctionnalités AMP disponibles (comme l'affichage dans un carrousel "À la une"). En d'autres termes, il est possible que ces pages soient uniquement affichées sous la forme d'un lien simple bleu dans les résultats de recherche.

État de la page (pages valides et non valides) : les pages AMP peuvent être valides ou non valides. Les pages AMP valides peuvent être affichées sur Google, et les pages AMP non valides ne le peuvent pas. Si une page présente des problèmes critiques, elle est considérée comme non valide. Une page qui ne rapporte que des avertissements, ou ne présente aucun problème, est considérée comme valide. Pour afficher la liste des pages AMP valides, cliquez sur Afficher les données concernant les pages AMP valides sous le graphique, sur la page de premier niveau du rapport AMP.

Ce que vous devez chercher

Vos objectifs devraient être les suivants :

• Aucun problème critique sur votre site. Consultez les recommandations pour corriger les erreurs dans Hiérarchiser et corriger les problèmes.
• Le nombre total de pages AMP dans le rapport (valides + non valides) doit être proche du nombre de pages AMP de votre site. Si ce n'est pas le cas, reportez-vous à la section Résoudre les problèmes de pages AMP manquantes.

La liste des URL concernées n'est qu'un échantillon. Il n'est pas garanti que toutes les URL concernées par un problème donné soient répertoriées. Le rapport est limité à 1 000 URL par problème. Il se peut aussi que pour une raison quelconque, nous n'ayons pas détecté ou pris en compte certaines pages.

Le rapport ne peut recenser que 200 problèmes au total (critiques + non critiques). Si votre site présente un très grand nombre de problèmes (avec des instances actives ou non), le rapport affiche uniquement les 200 premiers problèmes, classés par importance.

Problèmes relatifs aux pages AMP

En plus des erreurs AMP standards, le rapport peut indiquer les types de problèmes supplémentaires suivants (erreurs et avertissements).

Problèmes AMP propres à Google

Problème	Description
Le contenu ne correspond pas : vidéo intégrée manquante	La page Web canonique contient une vidéo intégrée qui ne figure pas dans la page AMP. Il est généralement préférable d'inclure toutes les ressources de contenu importantes à la fois dans votre version AMP et dans la page Web canonique. Sachez que la vidéo est détectée par l'URL : si vous avez deux URL différentes renvoyant vers la même vidéo, vous verrez cet avertissement.
Taille d'image inférieure à celle recommandée	Les données structurées de la version AMP font référence à une image plus petite que la taille recommandée. Cela peut empêcher la page de s'afficher avec toutes les fonctionnalités AMP dans la recherche Google, et peut aussi empêcher vos cartes Discover de s'afficher avec des images grand format (entraînant une diminution du trafic du site et de l'engagement utilisateur). Pour corriger ce problème, utilisez une image plus grande conformément à nos consignes.
Le domaine de la page AMP ne correspond pas	La page AMP est hébergée sur un domaine qui diffère de sa version canonique. Cela peut porter confusion : les utilisateurs mobiles verront une URL dans les résultats de recherche et une autre URL lorsqu'ils ouvrent la page dans le lecteur AMP. (Cela n'affecte pas l'indexation ou le classement de la page.)
URL introuvable (404)	L'URL AMP demandée est introuvable. Découvrez comment corriger les erreurs de type 404.
Erreur serveur (5xx)	Erreur de serveur 5xx non spécifiée lors de la demande de la page AMP. En savoir plus sur les erreurs de serveur
Bloquée par le fichier robots.txt	L'URL AMP demandée a été bloquée par une règle robots.txt. Si ce n'est pas votre objectif, recherchez la règle de blocage dans votre fichier robots.txt, puis modifiez ou supprimez-la (ou demandez à votre développeur Web de le faire pour vous).
Problème d'exploration	Erreur d'exploration non spécifiée pour la page AMP. Utilisez l'outil d'inspection d'URL au niveau de votre URL AMP pour résoudre le problème.
L'URL AMP référencée n'est pas une URL AMP	La page canonique fait référence à une page AMP qui n'est pas, en réalité, une page AMP. Découvrez comment une page standard doit référencer une page AMP.
L'URL AMP référencée s'auto-désigne comme page AMP canonique	La page canonique renvoie vers une page AMP seule. Vous ne pouvez pas référencer une page AMP seule comme la version AMP de la page. Découvrez comment référencer une page AMP à partir d'une page standard.
URL marquée "noindex"	La page AMP est bloquée par une directive "noindex". Google ne peut pas indexer les pages qui sont bloquées par une balise noindex. Veuillez supprimer la directive ou la référence à la page bloquée.
La date "unavailable_after" de cette page a expiré	La page AMP contient une directive ou balise Meta "unavailable_after" dont la date est dépassée, indiquant qu'elle ne devrait plus être diffusée. Vous devez soit mettre à jour la balise en précisant une date ultérieure, soit la supprimer.
L'URL canonique ne semble pas être valide	La page canonique fait référence à une version AMP en utilisant une URL dont le format est incorrect. Découvrez comment référencer correctement une version AMP.
Erreur canonique amp-story	La page référence incorrectement une page amp-story comme sa version AMP. Ceci n'est pas autorisé, car une page amp-story s'auto-désigne comme canonique : elle doit rediriger vers elle-même avec une balise <rel="canonical"> et ne peut pas être utilisée comme la version AMP d'une autre page.
Script de module déclaré sans alternative nomodule (ou inversement).	Vous utilisez soit une balise <script type="module"> sans balise <script nomodule async> correspondante, soit l'inverse. Ces balises doivent être utilisées par paires correspondantes pour être correctement traitées par les navigateurs selon qu'ils acceptent ou non les scripts de module.
URL manquante dans la balise HTML	La balise HTML spécifiée nécessite un attribut avec une URL valide et non nulle, mais l'URL est une chaîne vide. Indiquez une URL valide pour l'attribut en surbrillance.
L'attribut est manquant ou incorrect, mais est requis par l'attribut "on".	L'attribut spécifié est obligatoire, mais il est incorrect ou manquant. Cet attribut est obligatoire, car vous avez spécifié un attribut "on" dans la même balise.
Balise enfant <svg> détectée à l'extérieur d'un bloc <svg>.	Vous avez spécifié une balise en dehors d'un bloc <svg> qui doit être imbriquée dans un bloc <svg>.
La page charge plusieurs versions du même script d'extension.	La page charge plusieurs versions de la même extension AMP. Pour corriger cette erreur, supprimez une version du script.

Problèmes d'échanges signés

Le rapport d'état AMP et le rapport d'inspection d'URL peuvent tous deux indiquer des problèmes pour les pages AMP qui utilisent le protocole d'échange signé.

Afficher les informations relatives à un problème d'échange signé

Plusieurs options s'offrent à vous pour consulter plus d'informations sur l'échange signé associé à une page AMP :

• Dans l'outil d'inspection d'URL, cliquez sur le problème sous Détails de la version AMP.
• Dans le rapport d'état AMP, cliquez sur une URL à partir du tableau des détails du problème.

Déterminer si une page AMP utilise un échange signé

Pour déterminer si Google a détecté des en-têtes ou des charges utiles d'échange signé pour une page AMP, procédez comme suit :

1. Inspectez l'URL de la page AMP. Utilisez l'outil d'inspection d'URL pour inspecter une URL spécifique ou, dans le rapport d'état AMP, cliquez sur l'icône d'inspection située à côté de l'URL souhaitée dans le tableau des détails du problème.
2. Cliquez sur Afficher la page explorée sur la page de résultats pour ouvrir un panneau latéral contenant des informations supplémentaires.
3. Cliquez sur l'onglet Plus d'infos.
4. Sous le libellé Échange signé, l'état indique si Google a détecté des composants d'échanges signés pour cette page AMP.

Liste des problèmes d'échanges signés

Les problèmes suivants peuvent survenir lorsqu'une page AMP utilise le protocole d'échange signé.

• L'échange signé n'est pas valide
• La charge utile de l'échange signé comporte une erreur d'analyse
• L'en-tête header_name de la charge utile de l'échange signé comporte une valeur incorrecte
• L'en-tête obligatoire header_name pour la charge utile de l'échange signé n'est pas présent
• L'analyse de l'en-tête de signature de l'échange signé est impossible
• Le paramètre parameter_name de l'en-tête de signature de l'échange signé est incorrect
• Les dates de l'échange signé ne sont pas valides
• L'analyse de la chaîne de certificat référencée par le paramètre "cert-url" de l'échange signé est impossible
• La chaîne de certificat référencée par le paramètre "cert-url" n'est pas valide pour l'échange signé
• L'analyse de l'échange signé est impossible
• L'URL de la charge utile interne ne correspond pas à l'URL de la demande pour l'échange signé
• L'en-tête header_name de la réponse HTTP de l'échange signé contient une valeur incorrecte

L'échange signé n'est pas valide

La réponse HTTP correspond à un échange signé qui ne répond pas aux exigences Google AMP Cache. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Cette erreur peut se produire pour plusieurs raisons :

• La page contient un en-tête non autorisé par la spécification des échanges signés ou par Google AMP Cache.
• Conformément à la spécification des échanges signés, le paramètre validity-url n'a pas la même origine que l'URL de remplacement (fallbackUrl).
• Ses en-têtes de réponses signées ne sont pas codés de manière canonique.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

La charge utile de l'échange signé comporte une erreur d'analyse

La réponse HTTP correspond à un échange signé dont la "charge utile" (le corps) ne répond pas aux exigences Google AMP Cache. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Procédez comme suit pour identifier et corriger l'erreur :

• Vérifiez que le code HTML ne contient aucun codage UTF-8 non valide. Pour l'$URL d'erreur, exécutez curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null, puis recherchez les messages d'erreur potentiels ("illegal input sequence", par exemple). Si vous trouvez des erreurs, assurez-vous que le document est correctement codé en UTF-8. Le texte non francophone et lesespaces sont deux sources communes de caractères à plusieurs octets.
• Vérifiez que le code HTML ne contient aucune valeur U+0000 NULL ni aucun caractère Unicode qui entraîne une erreur d'analyse HTML.
• Vérifiez que le code HTML n'a pas changé après l'appel de la commande transform -config NONE. Deux raisons peuvent expliquer pourquoi le code est susceptible de changer :
  • La sérialisation a eu lieu avec une imprimante autre que celle fournie avec AMP Packager. Si vous utilisez un autre générateur d'échanges signés, assurez-vous qu'il utilise la bibliothèque de transformateurs d'AMP Packager.
  • Le code HTML provoque une erreur d'analyse qui entraîne la modification de l'arborescence d'analyse. Ce type d'erreur est souvent causé par des balises de fin omises ou mal placées. Par exemple, il peut s'agir d'un algorithme de type "adoption agency" et de la gestion des balises de fin pour les éléments "form". Ces erreurs sont difficiles à diagnostiquer. Un outil de validation de balisage HTML facilite parfois l'identification de la cause.
  • Si aucune des raisons ci-dessus ne correspond à la source de votre problème :
    • Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.
    • Si vous utilisez AMP Packager, procédez comme suit :
      • Vérifiez que vous utilisez la dernière version d'AMP Packager.
      • Si tel est le cas, signalez un bug dans AMP Packager.

L'en-tête header_name de la charge utile de l'échange signé comporte une valeur incorrecte

La réponse HTTP correspond à un échange signé contenant un en-tête de réponse signée qui ne respecte pas l'une desexigences Google AMP Cache. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

L'en-tête obligatoire header_name pour la charge utile de l'échange signé n'est pas présent

La réponse HTTP correspond à un échange signé ne contenant pas l'en-tête spécifié requis par la spécification des échanges signés ou les exigences Google AMP Cache. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

L'analyse de l'en-tête de signature de l'échange signé est impossible

La réponse HTTP correspond à un échange signé contenant un en-tête de signature non conforme à la spécification des échanges signés. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

Le paramètre parameter_name de l'en-tête de signature de l'échange signé est incorrect

La réponse HTTP correspond à un échange signé dont l'en-tête de signature contient une valeur incorrecte pour le paramètre donné, conformément à la spécification des échanges signés. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

Les dates de l'échange signé ne sont pas valides

La réponse HTTP correspond à un échange signé dont l'en-tête de signature contient une valeur incorrecte pour date ou expire, conformément à la spécification des échanges signés ou aux exigences Google AMP Cache. Notez que la signature doit être valide au moment où elle est récupérée et pendant au moins 4 jours après cela. La page est alors présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, cela peut se produire pour plusieurs raisons :

• Vérifiez que le proxy inverse frontal ne conserve pas trop longtemps dans le cache les réponses d'échanges signés. Effectuez plusieurs demandes pour la page avec curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' et recherchez date= dans chaque réponse. Vérifiez que le numéro suivant est différent à chaque fois.
• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si vous avez exclu toutes les raisons possibles ci-dessus, il se peut qu'un bug affecte l'outil AMP Packager. Dans ce cas, veuillez le signaler.

L'analyse de la chaîne de certificat référencée par le paramètre "cert-url" de l'échange signé est impossible

La réponse HTTP correspond à un échange signé dont le paramètre cert-url n'est pas conforme à la spécification des échanges signés. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, procédez comme suit :

• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si tel est le cas, signalez un bug.

La chaîne de certificat référencée par le paramètre "cert-url" n'est pas valide pour l'échange signé

La réponse HTTP correspond à un échange signé dont le paramètre cert-url n'est pas valide conformément à la spécification des échanges signés. Dès lors, la page est présentée aux utilisateurs sans aucune information de signature.

Conséquence pour votre site :

La page est présentée dans un lecteur AMP avec une URL Google, et non son URL d'origine.

Étapes suivantes :

Le traitement de cette erreur est facultatif. Les pages affectées continueront à s'afficher correctement dans un lecteur AMP. Si vous souhaitez que l'URL signée soit indiquée, veuillez lire la suite.

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, cette erreur peut se produire pour plusieurs raisons. Voici quelques éléments à vérifier :

• Assurez-vous que le fichier CertFile ne contient pas la liste complète du certificat feuille et des certificats intermédiaires.
• Vérifiez que l'outil AMP Packager n'a pas été lancé avec l'indicateur -development ou -invalidcert. En mode production, AMP Packager examine plusieurs aspects du certificat.
• Vérifiez que le proxy inverse frontal ne conserve pas les URL /amppkg/cert/ dans le cache plus longtemps que spécifié dans l'attribut max-age.
• Vérifiez que le proxy inverse frontal ne modifie pas les en-têtes du cache. Un cache en amont risquerait de mettre en cache ces chaînes de certificats trop longtemps. Pour effectuer un test, déterminez l'URL /amppkg/cert/ correspondante sur votre domaine de package interne, récupérez-la, y compris les en-têtes de réponse (avec curl -i, par exemple), puis comparez les en-têtes de réponse à ceux renvoyés par le serveur frontal.
• Vérifiez que le certificat contient un horodatage de certificat signé avec l'outil openssl x509, par exemple. En l'absence d'horodatage, contactez votre autorité de certification.
• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si vous avez exclu toutes les raisons possibles ci-dessus, il se peut qu'un bug affecte l'outil AMP Packager. Dans ce cas, veuillez le signaler.

L'analyse de l'échange signé est impossible

Le type de contenu de la réponse HTTP correspond à application/signed-exchange;v=b3, mais le corps de la réponse n'a pas pu être extrait. Cette erreur peut s'expliquer par le non-respect des exigences générales liées à ce type de contenu ou par le codage Merkle incorrect de la charge utile.

Conséquence pour votre site :

Si une version standard (non AMP) correspond à cette page, la recherche Google indexe la version standard à la place. Dans le cas contraire, il est possible que la page n'apparaisse pas dans la recherche Google.

Étapes suivantes :

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, cela peut se produire pour plusieurs raisons :

• Vérifiez que le proxy inverse frontal ne modifie pas les réponses du packager. Pour l'URL d'erreur, déterminez l'URL /priv/doc correspondante sur votre domaine de packager interne, puis testez-la avec dump-signedexchange. Si la réponse du packager interne est un échange signé valide, mais que la réponse de l'interface utilisateur externe ne l'est pas, il est probable qu'une erreur de configuration affecte le serveur frontal.
• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si vous avez exclu toutes les raisons possibles ci-dessus, il se peut qu'un bug affecte l'outil AMP Packager. Dans ce cas, veuillez le signaler.

L'URL de la charge utile interne ne correspond pas à l'URL de la demande pour l'échange signé

La réponse HTTP correspond à un échange signé dont le paramètre fallbackUrl ne concorde pas avec l'URL de la demande. Le nombre d'octets doit être identique pour les deux. Dès lors, la recherche Google n'est pas convaincue que la réponse est représentative de l'URL de la demande.

Conséquence pour votre site :

Si une version standard (non AMP) correspond à cette page, la recherche Google indexe la version standard à la place. Dans le cas contraire, il est possible que la page n'apparaisse pas dans la recherche Google.

Étapes suivantes :

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder. Les solutions possibles consistent à modifier l'URL de la page pour éviter les bugs dans les analyseurs d'URL courants. Par exemple, essayez d'éliminer les caractères encodés en pour cent ou réservés, ainsi que les encodages de chaîne de requête inhabituels comme ? sans paramètres.

Si vous utilisez AMP Packager, cela peut se produire pour plusieurs raisons :

• Vérifiez que le proxy inverse frontal réécrit correctement les URL. Les problèmes sont particulièrement fréquents au niveau des URL avec des caractères encodés en pour cent ou réservés. Par exemple, nginx rencontre des problèmes avec l'instruction de réécriture et la forme sans chemin de son instruction proxy_pass. Pour effectuer un test, envoyez quelques demandes de test au serveur frontal et comparez-les aux URL qu'AMP Packager enregistre dans sa sortie standard.
• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si vous avez exclu toutes les raisons possibles ci-dessus, il se peut qu'un bug affecte l'outil AMP Packager. Dans ce cas, veuillez le signaler.

L'en-tête header_name de la réponse HTTP de l'échange signé contient une valeur incorrecte

Le type de contenu de la réponse HTTP correspond à application/signed-exchange, mais les en-têtes de réponse ne sont pas valides pour une autre raison. Par exemple, il est possible que le paramètre v=b3 ne soit pas présent. Par conséquent, le format n'est pas reconnu par Google, ce qui empêche l'extraction du corps de la réponse.

Conséquence pour votre site :

Si une version standard (non AMP) correspond à cette page, la recherche Google indexe la version standard à la place. Dans le cas contraire, il est possible que la page n'apparaisse pas dans la recherche Google.

Étapes suivantes :

Si vous utilisez un fournisseur de services pour les échanges signés, contactez-le pour déterminer comment procéder.

Si vous utilisez AMP Packager, cela peut se produire pour plusieurs raisons :

• Vérifiez que le proxy inverse frontal ne modifie pas les en-têtes de ce type de contenu. Pour l'URL d'erreur, déterminez l'URL /priv/doc correspondante sur votre domaine de packager interne, puis récupérez-la, y compris les en-têtes de réponse (avec curl -i, par exemple). Toute différence d'en-tête entre la réponse du packager interne et la réponse du serveur frontal externe peut être à l'origine de l'erreur. Si la différence se trouve dans un en-tête autre que content-type, veuillez signaler un bug concernant ce document d'aide afin de mettre à jour la liste des exigences.
• Vérifiez que vous utilisez la dernière version d'AMP Packager.
• Si vous avez exclu toutes les raisons possibles ci-dessus, il se peut qu'un bug affecte l'outil AMP Packager. Dans ce cas, veuillez le signaler.

Hiérarchiser et corriger les problèmes

1. Consultez la liste des problèmes critiques de votre site dans le tableau Pourquoi les pages AMP ne sont pas valides.
2. Analysez les erreurs :
   • Observez si l'augmentation du nombre total d'erreurs est causée principalement par une seule erreur : recherchez un pic correspondant à un même problème dans le tableau.
   • Corrigez d'abord les erreurs causées par un élément commun (comme un mauvais modèle), puis corrigez les erreurs qui sont propres à chaque page.
3. Corriger les erreurs : cliquez sur une ligne du tableau pour afficher la page d'informations sur l'erreur :
   1. La page d'informations inclut un échantillon des URL concernées. La liste est limitée à 1 000 lignes. Les occurrences d'erreur détectées très récemment et les pages qui n'ont pas été réexplorées depuis l'apparition de l'erreur peuvent ne pas y figurer.
   2. Cliquez sur En savoir plus à côté d'un problème pour accéder à la documentation officielle concernant l'erreur.
   3. Cliquez sur une URL du tableau des exemples pour mettre le problème en surbrillance dans le code de la page.
   4. Cliquez sur l'icône "Inspecter"  pour exécuter un test détaillé sur une page spécifique. Ce test identifiera toutes les erreurs (pas seulement le problème actuel), et fournira un explorateur de code pour mettre en évidence les erreurs et obtenir plus d'informations. Si la page n'a pas été réexplorée récemment, l'erreur rapportée concerne la page indexée plutôt que la page en ligne. Si tel est le cas, vous pouvez demander l'indexation de cette page spécifique.
   5. Corrigez toutes les occurrences du problème sur votre site, testez vos corrections et assurez-vous qu'elles sont en ligne sur le Web.
4. Lorsque vous avez traité toutes les occurrences, revenez à la page d'informations du problème et cliquez sur le bouton Valider la correction pour commencer le processus de validation. Ce processus n'est pas immédiat. Consultez la section À propos de la validation pour en comprendre le fonctionnement.
5. Continuez à corriger les erreurs.
6. Si le nombre total de pages valides et non valides est nettement inférieur au nombre de pages AMP de votre site, consultez la section Résoudre les problèmes de pages AMP manquantes.
7. Une fois toutes les erreurs critiques résolues, envisagez de résoudre les erreurs non critiques. Certains de ces problèmes (comme l'utilisation de fonctionnalités obsolètes) pourraient devenir critiques à l'avenir.

Partage du rapport

Pour partager les détails d'un problème dans les rapports de couverture ou d'amélioration, cliquez sur le bouton Partager sur la page. Toute personne disposant de ce lien a accès à la page actuelle de détails du problème, ainsi qu'aux pages d'historique de validation relatives à ce problème. Ce lien n'accorde aucun accès aux autres pages de votre ressource, et ne permet pas à l'utilisateur avec lequel vous l'avez partagé de modifier votre propriété ou votre compte. Vous pouvez révoquer le lien à tout moment en désactivant le partage pour cette page.

Exporter les données du rapport

De nombreux rapports contiennent un bouton permettant d'en exporter les données : . À la fois les données du graphique et celles du tableau sont exportées. Dans le rapport, les valeurs indiquées comme ~ ou - (non disponibles ou non numériques) sont représentées par des zéros dans les données téléchargées.

Résoudre les problèmes de pages AMP manquantes

Si le nombre de pages AMP (valides + non valides) dans le rapport est inférieur au nombre de pages AMP sur votre site, procédez comme suit :

• Vérifiez que votre page canonique standard renvoie correctement vers votre page AMP.
• Vérifiez que vos pages AMP ou canoniques ne sont pas bloquées par un fichier robot.txt ou une instruction "noindex", ou uniquement accessibles par authentification ou connexion.
• Inspectez l'URL canonique de votre page AMP pour vérifier qu'elle est indexée.
  • Si la page canonique est répertoriée, confirmez qu'elle renvoie bien vers votre page AMP.
  • Si la version canonique n’est pas répertoriée, demandez son indexation.
• Selon la façon dont vous informez Google de la présence de nouvelles pages, nous pouvons mettre quelques jours à trouver et à explorer les pages manquantes.
• Certaines pages AMP valides peuvent ne pas figurer dans ce rapport, bien qu'elles soient répertoriées dans celui sur l'indexation des pages. En effet, le rapport sur l'indexation des pages, qui a pour but de vous aider à résoudre les problèmes d'indexation éventuels, est plus complet par nature. De son côté, le rapport d'état AMP couvre potentiellement moins de pages, car il se concentre davantage sur les pages pertinentes. Il fournit également plus de détails pour vous aider à résoudre les problèmes AMP sur votre site. Pour déterminer si une page AMP est indexée, utilisez l'outil d'inspection d'URL, qui vous donnera la réponse définitive.

Valider vos corrections

Après avoir résolu toutes les instances d'un problème spécifique sur votre site, vous pouvez demander à Google de confirmer vos corrections. Si toutes les instances connues sont corrigées, le nombre de problèmes tombe à zéro et cette ligne est reléguée au bas du tableau.

Pourquoi cette validation

Indiquer à Google que vous avez résolu tous les problèmes relevant d'un état ou d'une catégorie spécifique présente les avantages suivants :

• Vous recevrez un e-mail une fois que Google aura confirmé la correction sur toutes les URL, ou inversement, si Google a détecté des instances restantes de ce problème.
• Vous pouvez suivre la progression de Google dans la validation de vos corrections, et consulter un journal de toutes les pages en attente de vérification ainsi que l'état de correction de chaque URL.

Il n'est pas toujours pertinent de corriger et de valider certains problèmes sur votre site Web. Par exemple, les URL bloquées par le fichier robots.txt le sont probablement intentionnellement. Il vous incombe de déterminer si un problème donné doit être traité.

Vous pouvez également résoudre les problèmes sans validation. Google met à jour le décompte d'instances à chaque fois qu'une page connue pour présenter des problèmes est explorée, et cela que vous ayez ou non explicitement demandé la validation des corrections.

Conseil d'expert : validez vos corrections par sitemap

Pour accélérer le traitement de votre demande de correction, créez et envoyez un sitemap contenant uniquement vos pages les plus importantes, puis filtrez le rapport en fonction de ce sitemap avant d'envoyer votre demande de validation. Une demande de validation portant sur un sous-ensemble des URL concernées peut être traitée plus rapidement qu'une demande incluant toutes les URL concernées sur votre site.

Lancer la validation

Pour indiquer à la Search Console que vous avez résolu un problème :

1. Corrigez toutes les instances du problème sur votre site. Si vous avez manqué une correction, la validation s'arrête dès que Google détecte une instance du problème.
2. Ouvrez la page d'informations du problème que vous avez résolu. Cliquez sur le problème dans la liste de votre rapport.
   • ⚠️ Si vous filtrez un sitemap spécifique dans votre rapport, la validation ne s'applique qu'aux éléments du sitemap au moment de la demande. C'est peut-être ce que vous souhaitez, mais peut-être pas. Soyez-en simplement conscient.
3. Cliquez sur Valider la correction. Ne cliquez pas de nouveau sur "Valider la correction" tant que la validation n'a pas abouti ou échoué. En savoir plus sur comment Google vérifie vos corrections
4. Vous pouvez surveiller la progression de la validation. La validation prend généralement deux semaines environ, mais parfois beaucoup plus. Merci de votre patience. Vous recevrez une notification lorsque la validation aura abouti ou échoué.
5. En cas d'échec de la validation, vous pouvez identifier l'URL en cause en cliquant sur Afficher les détails sur la page d'informations du problème. Corrigez cette page, confirmez la correction sur toutes les URL en attente et recommencez la validation.

Dans quels cas un problème est-il considéré comme "résolu" pour une URL ou un élément ?

Un problème est marqué comme résolu pour une URL ou un élément lorsque l'une des conditions suivantes est remplie :

• Lorsque l'URL est explorée et que le problème n'est plus détecté sur la page. Pour une erreur de balise AMP, cela peut signifier que vous avez soit corrigé, soit supprimé la balise (si celle-ci n'est pas obligatoire). Lors d'une tentative de validation, l'état de la balise sera Réussi.
• Si la page n'est pas disponible pour Google pour une raison quelconque (page supprimée, marquée "noindex", nécessitant une authentification, etc.), le problème sera considéré comme résolu pour cette URL. Lors d'une tentative de validation, il est classé dans l'état de validation Autre.

Durée de vie du problème

La durée de vie d'un problème est la suivante : elle commence la première fois qu'une instance du problème est détectée sur votre site et prend fin 90 jours après que la dernière instance est marquée comme ayant disparu. Si aucune nouvelle instance n'est détectée pendant 90 jours, le problème est supprimé du tableau.

La date de première détection du problème correspond à la première fois que le problème a été détecté pendant sa durée de vie, et elle ne change pas. Par conséquent :

• Si toutes les instances d'un problème sont résolues, mais qu'une nouvelle instance est détectée 15 jours plus tard, le problème est marqué comme étant ouvert et la date de première détection reste la date d'origine.
• Si le même problème survient 91 jours après la résolution de la dernière instance, le précédent problème a été fermé. Il est donc enregistré comme nouveau problème, avec une nouvelle date de première détection.

Parcours de validation

Voici un aperçu du processus de validation qui démarre après que vous cliquez sur Valider la correction pour un problème. Ce processus peut prendre quelques jours, voire davantage. Vous recevrez des notifications de progression par e-mail.

1. Lorsque vous cliquez sur Valider la correction, la Search Console vérifie immédiatement quelques pages.
   • Si l'instance actuelle est présente sur l'une de ces pages, la validation se termine et l'état de validation reste inchangé.
   • Si l'échantillon de pages ne comporte pas l'erreur actuelle, la validation continue et son état devient Démarré. Si d'autres problèmes non liés sont détectés au cours de l'étape de validation, ils sont décomptés du type de problème qui fait l'objet de l'analyse et la validation se poursuit.
2. La Search Console analyse la liste d'URL connues concernées par ce problème. Seules les URL qui contiennent des instances connues du problème sont mises en attente pour être explorées à nouveau, et non le site entier. La Search Console conserve un enregistrement de toutes les URL vérifiées dans l'historique de validation, accessible depuis la page d'informations du problème.
3. Lorsqu'une URL est vérifiée :
   1. Si le problème n'est pas trouvé, l'état de validation de l'instance devient Conforme. S'il s'agit de la première instance vérifiée après le démarrage de la validation, l'état de validation du problème devient Excellent.
   2. Si l'URL n'est plus accessible, l'état de validation de l'instance devient Autre (ce qui n'est pas un état d'erreur).
   3. Si l'instance est toujours présente, l'état du problème devient Échec et la validation prend fin. S'il s'agit d'une nouvelle page découverte grâce à l'exploration normale, elle est considérée comme une autre instance du problème existant.
4. Lorsque les URL en file d'attente ont été vérifiées et qu'il a été confirmé que le problème est résolu, l'état correspondant devient Réussi. Toutefois, même lorsque toutes les instances ont été corrigées, l'étiquette de gravité du problème ne change pas (Erreur ou Avertissement). Seul le nombre d'éléments affectés évolue, passant à zéro.

Même si vous ne cliquez jamais sur "Démarrer la validation", Google peut détecter les instances corrigées d'un problème. Si Google détecte que toutes les instances d'un problème ont été corrigées au cours de l'exploration normale, le décompte d'éléments affectés par ce problème sera de zéro dans le rapport.

Nouvelle validation

⚠️ Vous devez attendre la fin d'un cycle de validation avant d'en demander un autre, même si vous avez résolu certains problèmes pendant le cycle en cours.

Pour relancer une validation ayant échoué :

1. Accédez au journal de validation de la validation ayant échoué : ouvrez la page d'informations du problème concerné, puis cliquez sur Afficher les détails.
2. Cliquez sur Lancer une nouvelle validation.
3. La validation reprendra pour toutes les URL associées à l'état En attente ou Échec, ainsi qu'à de nouvelles instances de ce problème détectées par l'exploration normale depuis la dernière tentative de validation. Les URL associées à l'état Réussi ou Autre ne sont pas revérifiées.
4. La validation prend généralement deux semaines environ, mais parfois beaucoup plus. Merci de votre patience.

Consulter la progression de la validation

Pour afficher la progression d'une validation en cours, ou l'historique de la dernière demande si aucune validation n'est en cours :

1. Ouvrez la page d'informations du problème. Sur la page principale du rapport, cliquez sur la ligne correspondant au problème pour ouvrir la page d'informations.
   • L'état de la demande de validation s'affiche à la fois sur la page d'informations du problème et sur la ligne Validation du tableau des détails.
2. Cliquez sur Afficher les détails afin d'ouvrir la page d'informations de la validation correspondant à cette demande.
   • L'état d'instance de chaque URL incluse dans la demande s'affiche dans le tableau.
   • Cet état d'instance s'applique au problème spécifique que vous examinez. Il se peut que l'état Réussi soit attribué à un des problèmes sur une page, alors que d'autres problèmes sont encore considérés en Échec, En attente ou Autre.
   • Dans le rapport AMP et dans le rapport sur l'indexation des pages, les entrées de la page de l'historique de validation sont regroupées par URL.
   • Dans le rapport sur l'ergonomie mobile et celui concernant les résultats enrichis, les éléments sont regroupés par une combinaison d'URL et d'élément de données structurées (déterminée par la valeur Nom de l'élément).

État de la demande de validation

Les états de validation suivants s'appliquent à un problème donné :

• Non commencé : une ou plusieurs instances de ce problème n'ont jamais fait l'objet d'une demande de validation.
  Étapes suivantes :
  1. Cliquez sur le problème pour consulter les détails de l'erreur. Inspectez les pages individuellement pour voir des exemples de l'erreur sur la page en ligne.
  2. Pour afficher les détails du problème, cliquez sur En savoir plus sur la page correspondante.
  3. Cliquez sur une ligne d'exemple d'URL dans le tableau pour obtenir des détails sur cette erreur spécifique.
  4. Corrigez vos pages, puis cliquez sur Valider la correction pour lancer la validation. La validation prend généralement deux semaines environ, mais parfois beaucoup plus. Merci de votre patience.
• Commencé : vous avez commencé une tentative de validation et aucune instance restante du problème n'a encore été trouvée.
  Étape suivante : Google enverra des notifications au fur et à mesure de la validation, vous indiquant ce qu'il faut faire, si nécessaire.
• Excellent : vous avez lancé une tentative de validation et toutes les instances de problème qui ont été vérifiées jusqu'à présent ont été corrigées.
  Étape suivante : vous n'avez aucune action à effectuer à ce stade, mais Google enverra des notifications au fur et à mesure de la validation vous indiquant ce qu'il faut faire.
• Réussi : toutes les instances connues du problème ont disparu (ou l'URL concernée n'est plus disponible). Vous avez dû cliquer sur Valider la correction pour accéder à cet état (lorsque des instances disparaissent sans que vous n'en demandiez la validation, l'état indique "Sans objet").
  Étape suivante : vous n'avez rien de plus à faire.
• Sans objet : Google a constaté que le problème a été résolu sur toutes les URL, même si vous n'avez jamais lancé de tentative de validation.
  Étape suivante : vous n'avez rien de plus à faire.
• Échec : un certain nombre de pages contiennent toujours ce problème après que vous avez cliqué sur Valider.
  Étapes suivantes : corrigez le problème et relancez la validation.

État de validation de l'instance

Une fois la validation demandée, toutes les instances du problème sont affectées à l'un des états de validation suivants :

• En attente : mise en attente pour validation. La dernière fois que Google a vérifié, cette instance de problème existait.
• Réussi : [Non disponible dans tous les rapports] Google a vérifié l'instance de problème et elle n'est plus présente. Cet état ne peut être atteint que si vous avez explicitement cliqué sur Valider pour cette instance de problème.
• Échec : Google a vérifié l'instance de problème et elle est toujours présente. Cet état ne peut être atteint que si vous avez explicitement cliqué sur Valider pour cette instance de problème.
• Autre : [Non disponible dans tous les rapports] Google n'est pas parvenu à accéder à l'URL hébergeant l'instance, ou (pour les données structurées) n'a pas pu trouver l'élément sur la page. Cet état est considéré comme équivalent à Réussi.

Sachez que la même URL peut avoir des états différents pour des problèmes différents. Par exemple, si une même page contient à la fois le problème X et le problème Y, l'état de validation du problème X peut être Réussi et celui du problème Y sur la même page peut être En attente.

 

Problèmes connus

Les problèmes suivants sont connus dans la Search Console. Il n'est pas nécessaire de nous les signaler, mais nous aimerions connaître votre avis sur les autres fonctionnalités ou d'éventuels problèmes que vous avez repérés. Utilisez le mécanisme de commentaires intégré dans la barre de navigation.

• Certains problèmes ont des noms longs qui ne sont pas faciles à comprendre.
• Il peut y avoir un décalage entre le moment où un problème est ajouté au graphique et le moment où il est ajouté au tableau.