Recherche
Effacer la recherche
Fermer la recherche
Applications Google
Menu principal
true

Rapport d'état AMP

Expérience bêta de la nouvelle Search Console

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 affiche toutes les pages AMP de votre site pour lesquelles Google a détecté un problème, regroupées par type de problème. Cliquez sur un problème spécifique pour afficher plus de détails, notamment une liste avec quelques exemples de pages concernées, des informations sur la façon de le résoudre et un processus permettant d'informer Google de vos correctifs.

Pour obtenir des graphiques montrant l'impact des problèmes et des correctifs, consultez la page "État".

Pourquoi la liste n'est-elle pas exhaustive ? Nous montrons autant de pages concernées par des erreurs que nous le pouvons ; cependant, notre tableau ne peut contenir que 1 000 URL. Il se peut aussi que pour une raison quelconque, nous n'ayons pas détecté ou pris en compte certaines pages.

OUVRIR LE RAPPORT AMP

Ce que vous devez chercher

Dans l'idéal, voici ce que vous deviez voir dans le rapport :

  • Aucune erreur AMP sur votre site (les avertissements sont considérés comme des recommandations et non comme des erreurs : voir la section Comprendre les avertissements ci-dessous). Si ce n'est pas le cas, consultez la section Hiérarchiser et corriger les problèmes.
  • Le nombre total de pages AMP dans le rapport (valides + avertissements + erreurs) doit correspondre au nombre de pages AMP sur votre site. Si ce n'est pas le cas, reportez-vous à la section Pages AMP manquantes.

Hiérarchiser et corriger les problèmes

  1. Sur la page de résumé, filtrez les avertissements et concentrez-vous d'abord sur les erreurs. Par défaut, les problèmes sont triés en fonction de la gravité, de l'état de validation et du nombre de pages concernées. Nous vous recommandons de les traiter dans cet ordre. 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.
  2. Observez si l'augmentation du nombre total d'erreurs est causée principalement par une seule erreur : recherchez un pic correspondant à un seul problème dans le tableau.
  3. Consultez les informations ci-dessous au sujet des pics de débogage et des pages AMP manquantes.
  4. Cliquez sur une ligne du tableau pour afficher la page d'informations sur l'erreur :
    1. La page d'informations inclut un exemple d'URL affectées. La liste n'est pas toujours exhaustive, car elle est limitée à 1 000 lignes et peut ne pas inclure les instances de cette erreur découvertes très récemment.
    2. S'il s'agit d'une erreur de syntaxe, cliquez sur En savoir plus pour obtenir la documentation officielle sur la syntaxe correcte.
    3. Cliquez sur l'icône "Inspecter" pour exécuter un test de validité sur une page concernée. 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. Il est possible qu'une erreur ait été corrigée sur la page en ligne, mais qu'elle soit toujours répertoriée comme une erreur, car la page n'a pas encore été explorée à nouveau. Si c'est le cas, demandez une validation après avoir corrigé toutes les instances de ce problème.
  5. Corrigez toutes les instances du problème sur votre site, testez votre correctif et assurez-vous que vos correctifs sont en ligne sur le Web.
  6. Revenez à la page des détails du problème et cliquez sur le bouton "Valider et prévenir Google" pour commencer le processus de validation. Ce processus n'est pas immédiat. Consultez la section À propos de la validation pour comprendre ce processus.
  7. Continuez à corriger les erreurs.
  8. Lorsque toutes les erreurs ont été corrigées, supprimez le filtre pour les avertissements et envisagez de corriger ces derniers. Certains d'entre eux concernent l'absence de balisage de données structurées facultatif, qui permet d'activer de nouvelles fonctionnalités de recherche pour les pages au contenu pertinent.

Partage du rapport

Vous pouvez partager les détails d'un problème en cliquant sur le bouton Partager de la page. Ce lien n'autorise l'accès qu'à la page actuelle, ainsi qu'aux pages d'historique de validation pour ce problème, à toute personne disposant du lien. Il n'accorde pas l'accès à d'autres pages pour votre ressource, et ne permet pas à l'utilisateur partagé d'effectuer des actions sur votre propriété ou votre compte. Vous pouvez révoquer le lien à tout moment en désactivant le partage pour cette page.

Pics d'erreur

Déterminez si un pic est causé par un groupe de pages passant d'un niveau de gravité à un autre :

  1. Si vous constatez un pic, recherchez une diminution correspondante pour un autre état (erreur ou valide).
  2. Si vous trouvez une diminution correspondante, vérifiez qu'il s'agit des mêmes URL.
  3. Si les URL passent d'un état à un autre, déterminez ce que vous avez modifié pour causer cela.

La raison la plus fréquente d'un pic d'erreurs est l'ajout d'une erreur à un modèle utilisé par de nombreuses pages sur votre site.

Pages AMP manquantes

Si le nombre de pages AMP (valides + avertissements + erreurs) dans le rapport est inférieur au nombre de pages AMP sur votre site :

  • Vérifiez que votre page canonique standard renvoie correctement vers votre page AMP.
  • Confirmez que vos pages AMP ou canoniques ne sont pas robotisées ou désignées comme "noindex", ou uniquement accessibles par authentification ou connexion.
  • Vérifiez la présence de vos pages AMP et canoniques dans l'index en effectuant une recherche info: <canonical-page-URL> de la page canonique sur Google. Si elles ne sont pas répertoriées, c'est qu'elles ne sont pas indexées. Notez que la commande info: search ne fonctionne pas sur la version AMP, mais seulement sur la version canonique standard.
    • 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 à l'aide du nouveau rapport sur les sitemaps (ou de l'ancien outil Explorer comme Google).
  • D'autres pages renvoient-elles vers votre page AMP/canonique ? Ces pages sont-elles répertoriées dans un sitemap ? Utilisez l'outil Explorer comme Google sur la version canonique pour demander l'indexation d'un petit nombre de pages AMP, mais pour un grand nombre de pages, utilisez des sitemaps. Seule la version canonique doit être répertoriée dans le sitemap. Vous pouvez utiliser le rapport sur les sitemaps pour envoyer un sitemap.
  • Notez que nous pouvons mettre quelques jours à trouver et à explorer les pages manquantes, selon la façon dont vous nous informez de la présence de nouvelles pages.

Comprendre les avertissements

Les pages AMP qui contiennent des avertissements sont indexées et peuvent être affichées dans les résultats de recherche Google, mais elles 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.

About validation

After you fix all instances of a specific issue on your site, you can ask Google to validate your changes. If all known instances are gone, the issue is marked as fixed in the status table and dropped to the bottom of the table. Search Console tracks the validation state of the issue as a whole, as well as the state of each instance of the issue. When all instances of the issue are gone, the issue is considered fixed. (For actual states recorded, see Issue validation state and Instance validation state.)

More about issue lifetime...

An issue's lifetime extends from the first time any instance of that issue was detected on your site until 90 days after the last instance was marked as gone from your site. If ninety days pass without any recurrences, the issue is removed from the report history.

The issue's first detected date is the first time the issue was detected during the issue's lifetime, and does not change. Therefore:

  • If all instances of an issue are fixed, but a new instance of the issue occurs 15 days later, the issue is marked as open, and "first detected" date remains the original date.
  • If the same issue occurs 91 days after the last instance was fixed, the previous issue was closed, and so this is recorded as a new issue, with the first detected date set to "today".

Basic validation flow

Here is an overview of the validation process after you click Validate Fix for an issue. This process can take several days, and you will receive progress notifications by email.

  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 all error and warning URLs have been checked and the issue count is 0, the issue state changes to Passed. Important: Even when the number of affected pages drops to 0 and issue state changes to Passed, the original severity label will still be shown (Error or Warning).

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 state to "N/A" on the report.

When is an issue considered "fixed" for a URL or item?

An issue is marked as fixed for a URL when either of the following conditions are met:

  • When the URL is crawled and the issue is no longer found on the page. Note that for an AMP tag error, this can mean that you either fixed the tag or that the tag has been removed (if the tag is not required). During a validation attempt, it will be considered as "passed."
  • If the page is not available to Google for any reason (page removed, marked noindex, requires authentication, and so on), the issue will be considered as fixed for that URL. During a validation attempt, it is counted in the "other" validation state.

Revalidation

When you click Revalidate for a failed validation, validation restarts for all failed instances, plus any new instances of this issue discovered through normal crawling.

You should wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

Instances that have passed validation (marked Passed) or are no longer reachable (marked Other) are not checked again, and are removed from the history when you click Revalidate.

Validation history

You can see the progress of a validation request by clicking the validation details link in the issue details page.

Items in validation history are grouped by URL for the AMP report and Index Status report. In the Jobs report or other structured data reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).

Issue validation state

The following validation states apply to a given issue:

  • Not started: There are one or more pages with an instance of this issue that you have never begun a validation attempt for. 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 rule that was violated.
    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 have Google recrawl your pages. Google will notify you about the progress of the validation. Validation takes anywhere from a few days up to about two weeks, 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 revalidate.

Instance validation state

After validation has been requested, every known issue instance is assigned one of the following validation states for a specific issue (states Passed and Other not used in Index Status report):

  • Pending validation: Queued for validation. The last time Google looked, this issue instance existed.
  • Passed: 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: 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.

 

Problèmes connus

Les problèmes suivants sont connus dans cette version bêta de la nouvelle 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 système 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.
  • L'expérience pour mobile est toujours en cours d'élaboration.
  • Les ensembles de propriétés ne sont pas encore pris en charge.
Cet article vous a-t-il été utile ?
Comment pouvons-nous l'améliorer ?
false