Relatório de status de AMP

Este relatório ajuda a corrigir os erros que impedem a exibição das suas páginas AMP nos resultados da Pesquisa Google com os recursos específicos a essa tecnologia.

A visualização geral mostra os problemas críticos que afetam as páginas AMP no seu site. Clique em um problema específico para abrir as páginas afetadas por ele e os detalhes.

ABRIR O RELATÓRIO DE AMP

 

Relatório de status de AMP no Search Console — Treinamento do Google Search Console

 

O que o relatório mostra

Problemas críticos: não é possível exibir no Google as páginas afetadas por problemas críticos de AMP. Uma lista dos problemas críticos no seu site é mostrada diretamente abaixo do gráfico na página de informações gerais do relatório de AMP, com o título Por que as páginas AMP são inválidas. Clique em um problema na lista para abrir as páginas correspondentes.

Problemas não críticos (avisos): as páginas AMP com problemas que não são críticos ainda podem aparecer no Google. Uma lista de problemas não críticos no seu site é mostrada abaixo da lista de problemas críticos na página de informações gerais do relatório de AMP, com o título Problemas não críticos. Clique em um problema na lista para abrir as páginas correspondentes. As páginas AMP com avisos talvez não apareçam com todos os recursos AMP possíveis, como a exibição em um carrossel de notícias principais. Em outras palavras, essas páginas talvez só apareçam como resultados da pesquisa com link comum em azul.

Status da página (páginas válidas e inválidas): as páginas AMP podem ser válidas ou inválidas. As válidas podem aparecer no Google, e as inválidas não. Se uma página tiver algum problema crítico, ela vai ser considerada inválida. Se ela só tiver avisos ou não tiver nenhum problema, vai ser considerada válida. Para acessar uma lista de páginas AMP válidas, clique em Ver dados sobre páginas AMP válidas abaixo do gráfico na página de informações gerais do relatório de AMP.

O que procurar

Os seguintes números devem aparecer no relatório:

• Nenhum problema crítico no seu site. Confira recomendações para corrigir erros em Priorizar e corrigir problemas.
• O total de páginas AMP no relatório (válidas + inválidas) deve estar próximo do número de páginas desse tipo no site. Caso contrário, acesse Como solucionar problemas de páginas AMP ausentes.

A lista de URLs afetados é um exemplo. Não é garantido que todos os URLs afetados por um determinado problema sejam exibidos. O relatório é limitado a mil URLs por problema. Além disso, pode haver outras páginas que, por algum motivo, não foram detectadas ou contadas.

O relatório só pode mostrar um total de 200 problemas críticos e não críticos. Se o site tiver uma lista muito longa de problemas (com ou sem instâncias ativas), vão ser exibidos apenas os 200 principais erros, classificados por importância.

Problemas com AMP

Além dos erros específicos à AMP padrão, o relatório também pode mostrar os seguintes problemas (erros ou avisos).

Problemas de AMP específicos ao Google

Problema	Descrição
Incompatibilidade de conteúdo: vídeo incorporado ausente	A página da Web canônica tem um vídeo incorporado que não aparece na versão AMP. Geralmente, o ideal é incluir todos os recursos de conteúdo importantes da página da Web canônica na versão AMP. O vídeo é detectado pelo URL. Por isso, se houver dois URLs diferentes que levam ao mesmo vídeo, você verá esse aviso.
O tamanho da imagem é menor que o recomendado	Os dados estruturados da versão AMP são referentes a uma imagem menor que o tamanho recomendado. Isso pode impedir que a página seja exibida com todos os recursos relacionados a AMP na Pesquisa Google e fazer com que os cartões do Discover não mostrem imagens grandes, o que prejudica o tráfego do site e o engajamento dos usuários. Para corrigir esse problema, use uma imagem maior de acordo com nossas diretrizes.
Domínio da página AMP não correspondente	A página AMP está hospedada em um domínio diferente do domínio da versão canônica. Isso pode confundir os usuários de dispositivos móveis, que veem um domínio de URL nos resultados de pesquisa e outro quando abrem a página no leitor de AMP. Isso não afeta a indexação nem a classificação das páginas.
URL não encontrado (404)	O URL de AMP solicitado não foi encontrado. Saiba mais sobre como corrigir páginas 404.
Erro de servidor (5XX)	É um erro 5XX não especificado de servidor ao solicitar a página AMP. Saiba mais sobre erros do servidor.
Bloqueada pelo robots.txt	O URL de AMP solicitado foi bloqueado por uma regra de robots.txt. Se não era isso que você queria, teste a regra de bloqueio no arquivo robots.txt e a modifique ou remova (ou peça ao desenvolvedor da Web que faça isso).
Problema de rastreamento	É um erro de rastreamento não especificado para a página AMP. Use a Ferramenta de inspeção de URL no URL de AMP para resolver o problema.
O URL de AMP referenciado não é uma AMP	Uma página canônica faz referência a uma AMP que não é verdadeiramente uma página AMP. Saiba como uma página não AMP precisa referenciar uma página desse tipo.
O URL de AMP referenciado é uma AMP independente	A página canônica direciona o usuário para uma AMP independente. Não é possível referenciar uma página AMP independente com a própria versão AMP. Saiba como referenciar uma AMP de uma página não AMP.
URL marcado como "noindex"	A AMP é bloqueada por uma diretiva "noindex". O Google não pode indexar uma página bloqueada por uma diretiva "noindex". Remova-a ou exclua a referência para a página bloqueada.
A data "unavailable_after" desta página expirou	A página AMP tem uma metatag "unavailable_after" ou uma diretiva que já foi aprovada, indicando que ela não precisa mais ser veiculada. Atualize a tag para uma data futura ou remova-a.
Pontos canônicos para um URL inválido	Uma página canônica faz referência a uma versão de AMP usando um URL formatado de maneira inválida. Saiba como referenciar adequadamente uma versão de AMP.
Erro canônico "amp-story"	Uma página faz referência incorreta a uma "amp-story" como sendo a própria versão AMP. Isso não é permitido, já que as páginas "amp-story" são independentes por definição, ou seja, precisam ser direcionadas ao próprio endereço com uma tag <rel="canonical"> e não podem ser a versão AMP de outra página.
Script de módulo declarado sem a alternativa nomodule (ou vice-versa)	Você está usando uma tag <script type="module"> sem uma tag <script nomodule async> ou vice-versa. Essas tags precisam ser usadas em pares correspondentes para permitir o processamento adequado por navegadores que podem ou não ser compatíveis com scripts de módulo.
O URL na tag HTML não foi encontrado	A tag HTML especificada requer um atributo com um URL válido e tamanho diferente de zero, mas o URL é uma string vazia. Forneça um URL válido para o atributo destacado.
O atributo está ausente ou incorreto, mas é exigido pelo atributo "on"	O atributo especificado é obrigatório, mas está incorreto ou ausente. Esse atributo é exigido porque você especificou um atributo "on" na mesma tag.
Tag filha <svg> encontrada fora de um bloco <svg>	Você especificou uma tag que precisa ser aninhada em um bloco <svg>.
A página está carregando várias versões do mesmo script de extensão	A página está carregando várias versões da mesma extensão AMP. Para corrigir o problema, remova uma versão do script.

Problemas de troca assinada

O relatório de status de AMP e o relatório de inspeção de URL podem mostrar problemas para AMPs que usam o protocolo de troca assinada.

Para ver detalhes de trocas assinadas sobre um problema

Você pode encontrar informações sobre a troca assinada associada a uma AMP em vários lugares:

• Na Ferramenta de inspeção de URL, clique no problema em Detalhes da versão AMP.
• No Relatório de status de AMP , clique em um URL na tabela de detalhes do problema.

Para ver se a AMP usa a troca assinada

Para ver se o Google detectou ou não cabeçalhos ou payloads de troca assinada para sua AMP, siga estas etapas:

1. Inspecione o URL da AMP (use a Ferramenta de inspeção de URL para inspecionar um URL específico ou, no relatório de status de AMP, clique no ícone de inspeção ao lado do URL na tabela de detalhes do problema).
2. Clique em Visualizar página rastreada na página de resultados para abrir um painel lateral com mais informações.
3. Clique na guia Mais informações.
4. Abaixo do rótulo Troca assinada, você verá um status que indica se o Google detectou algum componente de troca assinada para essa AMP.

Lista de problemas de troca assinada

Os problemas a seguir podem ocorrer quando sua AMP usa o protocolo de troca assinada.

• A troca assinada é inválida.
• Há um erro de análise no payload da troca assinada.
• O cabeçalho header_name referente ao payload da troca assinada tem um valor inválido.
• O cabeçalho obrigatório header_name referente ao payload da troca assinada está ausente.
• Não é possível analisar o cabeçalho da assinatura da troca assinada.
• O parâmetro parameter_name no cabeçalho da assinatura da troca assinada é inválido.
• As datas da troca assinada são inválidas.
• Não é possível analisar a cadeia de certificados referenciada pelo "cert-url" da troca assinada.
• A cadeia de certificados referenciada por "cert-url" é inválida para a troca assinada.
• Não é possível analisar a troca assinada.
• O URL do payload interno não corresponde ao da solicitação da troca assinada.
• O cabeçalho header_name da resposta HTTP da troca assinada tem um valor inválido.

A troca assinada é inválida

A resposta HTTP era uma troca assinada que não atendia aos requisitos do Cache de AMP do Google. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Esse erro pode ocorrer por vários motivos, incluindo os seguintes:

• Ela contém um cabeçalho que não é permitido pela especificação de trocas assinadas ou pelo Cache de AMP do Google.
• O validity-url não é da mesma origem que o fallbackUrl, de acordo com a especificação de trocas assinadas.
• Os cabeçalhos de resposta assinada dele não são canonicamente codificados.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

Há um erro de análise no payload da troca assinada

A resposta HTTP era uma troca assinada em que o "payload" (corpo) não atendia aos requisitos do Cache de AMP do Google. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Siga estas etapas para encontrar e corrigir o erro:

• Verifique se o HTML não contém uma codificação UTF-8 inválida. Para o erro $URL, execute curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null e verifique se há mensagens de erro como "sequência de entrada ilegal". Se isso acontecer, verifique se o documento está devidamente codificado em UTF-8. Duas origens comuns de caracteres multibyte são textos que não estejam em inglês e espaços.
• Verifique se o HTML não contém um U+0000 NULL ou um caractere Unicode que cause um erro de análise de HTML.
• Verifique se o HTML não foi alterado depois de chamar transform -config NONE. Há dois motivos comuns para a mudança:
  • Ele foi serializado usando uma impressora diferente da fornecida com o AMP Packager. Se você estiver usando outro gerador de troca assinada, verifique se ele está usando a biblioteca de transformadores do AMP Packager.
  • O HTML causa um erro de análise que é tratado pela modificação da árvore de análise. Muitas vezes, eles são causados por tags finais omitidas ou extraviadas. Exemplos disso incluem o algoritmo da agência de adoção e o tratamento da tag final "form". Diagnosticar esses erros é difícil. Um validador de marcação de HTML pode ajudar a encontrar a causa.
  • Se você descartou todos os itens acima, faça o seguinte:
    • Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.
    • Se você estiver usando o AMP Packager, faça o seguinte:
      • Verifique se você está usando a versão mais recente do AMP Packager.
      • Em caso afirmativo, pode haver um bug no AMP Packager. Registre o bug.

O cabeçalho header_name referente ao payload da troca assinada tem um valor inválido

A resposta HTTP era uma troca assinada que continha um cabeçalho de resposta assinada que não atendia a um dos requisitos do Cache de AMP do Google. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

O cabeçalho obrigatório header_name referente ao payload da troca assinada está ausente

A resposta HTTP foi uma troca assinada com o cabeçalho fornecido faltando, o que é exigido pela especificação de trocas assinadas ou pelo Cache de AMP do Google. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

Não é possível analisar o cabeçalho da assinatura da troca assinada

A resposta HTTP era uma troca assinada que continha um cabeçalho de assinatura que não foi bem formado de acordo com a especificação de trocas assinadas. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

O parâmetro parameter_name no cabeçalho da assinatura da troca assinada é inválido

A resposta HTTP era uma troca assinada em que o cabeçalho de assinatura tinha um valor incorreto para o parâmetro fornecido, conforme exigido pela especificação de trocas assinadas. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

As datas da troca assinada são inválidas

A resposta HTTP era uma troca assinada em que o cabeçalho de assinatura tinha um valor incorreto para o parâmetro date ou expires, conforme exigido pela especificação de trocas assinadas ou pelos requisitos do Cache de AMP do Google. Em particular, a assinatura deve ser válida no momento em que é obtida e pelo menos pelos próximos quatro dias. Como resultado, a página será apresentada aos usuários sem qualquer informação da assinatura

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, isso pode acontecer por vários motivos:

• Verifique se o proxy reverso de front-end não está armazenando em cache as respostas de troca assinada por muito tempo. Faça várias solicitações para a página com curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' e procure date= em cada resposta. Verifique se o número subsequente é diferente a cada vez.
• Verifique se você está usando a versão mais recente do AMP Packager.
• Se você descartou todas as opções acima, pode haver um bug no AMP Packager. Registre o bug .

Não é possível analisar a cadeia de certificados referenciada pelo "cert-url" da troca assinada

A resposta HTTP era uma troca assinada em que o "cert-url" não foi bem formado de acordo com a especificação de trocas assinadas. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, faça o seguinte:

• Verifique se você está usando a versão mais recente do AMP Packager.
• Em caso afirmativo, registre um bug.

A cadeia de certificados referenciada por "cert-url" é inválida para a troca assinada

A resposta HTTP era uma troca assinada em que o "cert-url" era inválido de acordo com a especificação de trocas assinadas. Como resultado, a página será exibida aos usuários sem qualquer informação da assinatura.

Impacto no seu site:

A página será exibida em um visualizador de AMP com um URL do Google, em vez do URL original.

Próximas etapas:

Resolver esse problema é opcional. As páginas com o erro ainda serão exibidas corretamente em um visualizador de AMP. Se você quiser que a página seja apresentada com o URL assinado, continue lendo.

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, esse erro poderá ocorrer por vários motivos. Alguns pontos a serem verificados:

• Verifique se o CertFile não contém uma lista completa do "leaf certificate" mais os intermediários.
• Verifique se o AMP Packager não foi iniciado com os sinalizadores -development ou -invalidcert. No modo de produção, o AMP Packager verificará vários aspectos do certificado.
• Verifique se o proxy reverso de front-end não está armazenando URLs /amppkg/cert/ em cache por mais tempo do que foi definido em max-age.
• Verifique se o proxy reverso de front-end está modificando os cabeçalhos de cache. Isso pode fazer com que um proxy upstream armazene em cache essas cadeias de certificados por muito tempo. Para testar, determine o URL /amppkg/cert/ correspondente no domínio do seu packager interno, busque-o incluindo cabeçalhos de resposta (por exemplo, com curl -i) e compare esses cabeçalhos aos retornados pelo servidor de front-end.
• Verifique se o certificado contém um SCT usando a ferramenta openssl x509, por exemplo. Se isso não acontecer, consulte sua autoridade de certificação.
• Verifique se você está usando a versão mais recente do AMP Packager.
• Se você descartou todas as opções acima, pode haver um bug no AMP Packager. Registre o bug .

Não é possível analisar a troca assinada

A resposta HTTP tinha um "content-type" application/signed-exchange;v=b3, mas o corpo da resposta não pôde ser extraído. Isso pode ter ocorrido porque os requisitos de alto nível desse tipo não foram correspondidos, ou porque o payload foi indevidamente codificado em Merkle.

Impacto no seu site:

Se a página tiver uma página não AMP correspondente, a Pesquisa Google vai indexar essa última. Caso contrário, a página pode não aparecer na Pesquisa Google.

Próximas etapas:

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, isso pode acontecer por vários motivos:

• Verifique se o proxy reverso de front-end está alterando as respostas do packager. Para o URL com erro, determine o URL /priv/doc correspondente no domínio do seu packager interno e teste-o usando dump-signedexchange. Se a resposta do packager interno for uma troca assinada válida, mas a resposta do front-end externo não for, provavelmente há um erro de configuração no front-end.
• Verifique se você está usando a versão mais recente do AMP Packager.
• Se você descartou todas as opções acima, pode haver um bug no AMP Packager. Registre o bug .

O URL do payload interno não corresponde ao da solicitação da troca assinada

A resposta HTTP era uma troca assinada em que o fallbackUrl não correspondia ao URL da solicitação. Eles precisam ser idênticos, byte por byte. Como resultado, a Pesquisa Google não confiará que a resposta representa o URL de solicitação.

Impacto no seu site:

Se a página tiver uma página não AMP correspondente, a Pesquisa Google vai indexar essa última. Caso contrário, a página pode não aparecer na Pesquisa Google.

Próximas etapas:

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência. As possíveis soluções incluem a alteração do URL da página para evitar bugs em analisadores de URL comuns. Por exemplo, tente eliminar a codificação por cento ou caracteresreservados, ou codificações incomuns de string de consulta, como ? sem parâmetros.

Se você estiver usando o AMP Packager, isso pode acontecer por vários motivos:

• Verifique se o proxy reverso de front-end está reconfigurando os URLs corretamente. Os problemas são especialmente prováveis em URLs com codificação por cento ou caracteresreservados. Por exemplo, o nginx tem problemas com a diretiva de regravação e a forma sem caminho da diretiva proxy_pass. Para testar, envie algumas solicitações de teste ao seu front-end e compare-as com os URLs que o AMP Packager registra no "stdout".
• Verifique se você está usando a versão mais recente do AMP Packager.
• Se você descartou todas as opções acima, pode haver um bug no AMP Packager. Registre o bug .

O cabeçalho header_name da resposta HTTP da troca assinada tem um valor inválido

A resposta HTTP tinha um "content-type" application/signed-exchange, mas os cabeçalhos de resposta eram inválidos de alguma outra forma. Por exemplo, talvez o "content-type" não tenha um parâmetro v=b3. Como resultado, o formato é desconhecido para o Google e, portanto, o corpo da resposta não pode ser extraído.

Impacto no seu site:

Se a página tiver uma página não AMP correspondente, a Pesquisa Google vai indexar essa última. Caso contrário, a página pode não aparecer na Pesquisa Google.

Próximas etapas:

Se você estiver usando um provedor de serviços de troca assinada, consulte-o para receber assistência.

Se você estiver usando o AMP Packager, isso pode acontecer por vários motivos:

• Verifique se o proxy reverso de front-end está alterando os cabeçalhos "content-type". Para o URL com erro, determine o URL /priv/doc correspondente no domínio do seu packager interno e busque-o incluindo cabeçalhos de resposta (por exemplo, com curl -i). Se os cabeçalhos das respostas do packager interno e do front-end externo forem diferentes, talvez essa seja a origem do erro. Se a diferença estiver em outro cabeçalho que não content-type, registre um bug neste documento de ajuda para atualizar a lista de requisitos.
• Verifique se você está usando a versão mais recente do AMP Packager.
• Se você descartou todas as opções acima, pode haver um bug no AMP Packager. Registre o bug .

Priorizar e corrigir problemas

1. Consulte a lista de problemas críticos do site na tabela Por que as páginas AMP são inválidas.
2. Analise os erros:
   • Confira se o aumento no total de erros foi causado principalmente por um único problema. Procure um pico que corresponda a esse problema específico na tabela.
   • Primeiro, corrija os erros causados por um motivo comum, como o uso de um modelo ruim. Em seguida, corrija os erros específicos de cada página.
3. Corrija os erros: clique em uma linha na tabela para abrir a página de detalhes do erro:
   1. A página de detalhes inclui exemplos de URLs afetados. A lista é limitada a mil linhas e talvez não inclua instâncias mais recentes do erro ou páginas que não foram rastreadas novamente desde a exibição do erro.
   2. Clique em Saiba mais ao lado de um problema para acessar a documentação oficial sobre o erro.
   3. Clique em um URL na tabela de URLs de exemplo para destacar o problema no código da página.
   4. Clique no ícone de inspeção para realizar um teste detalhado em uma página específica. Esse teste vai identificar todos os erros, não só o atual, e oferecer um explorador de códigos para destacar os problemas e mostrar mais informações. Se a página não tiver sido rastreada de novo recentemente, o problema da página indexada será mostrado, e não o da ativa. Se for o caso, solicite a indexação da página específica.
   5. Corrija todas as instâncias do problema no seu site, teste as soluções e confira se as correções foram publicadas na Web.
4. Depois de corrigir todas as instâncias, volte à página de detalhes do problema e clique no botão Validar a correção para iniciar o processo de validação. Esse processo não é imediato. Consulte Sobre a validação para saber mais.
5. Continue a correção de erros.
6. Se o total de páginas válidas e inválidas for significativamente menor do que o número de páginas AMP no seu site, consulte Como solucionar problemas de páginas AMP ausentes.
7. Quando todos os erros críticos forem corrigidos, corrija os problemas não críticos. Alguns deles, como o uso de recursos descontinuados, podem se tornar críticos no futuro.

Como compartilhar o relatório

Para compartilhar detalhes de problemas nos relatórios de cobertura ou melhoria, clique no botão Compartilhar na página. Qualquer usuário que receber o link só terá acesso à página de detalhes de problemas atual, além de qualquer página do histórico de validação. O link não dá acesso a outras páginas relacionadas ao seu recurso nem permite que o usuário compartilhado realize qualquer ação na sua propriedade ou conta. Você pode revogar o link a qualquer momento ao desativar o compartilhamento da página.

Como exportar dados dos relatórios

Muitos relatórios têm um botão que permite exportar os dados. As informações dos gráficos e das tabelas são incluídas na exportação. Os valores exibidos como ~ ou - (indisponíveis/não numéricos) no relatório serão representados por zeros nos dados transferidos.

Como solucionar problemas de páginas AMP ausentes

Se a quantidade de páginas AMP (válidas + inválidas) no relatório for menor do que o total do site, talvez isso tenha ocorrido por algum dos seguintes motivos:

• Confirme se a página não AMP canônica está vinculada corretamente à AMP.
• Confira se as páginas AMP ou canônicas não têm robôs ou noindex nem são protegidas por requisitos de login.
• Inspecione o URL da página AMP canônica para verificar se ela está indexada.
  • Caso a canônica seja encontrada, confirme se ela vincula corretamente sua página AMP.
  • Se a canônica não estiver lá, envie a página para indexação.
• O Google pode levar alguns dias para encontrar e rastrear páginas ausentes dependendo de como ele foi notificado sobre as novas páginas.
• Algumas páginas AMP válidas podem não estar incluídas nesse relatório, embora apareçam listadas no Relatório de indexação de páginas. Isso acontece porque o Relatório de indexação de páginas precisa ser mais abrangente para ajudar a depurar problemas de indexação. Já o Relatório de status de AMP inclui um número menor de páginas, mas um conteúdo mais relevante e detalhado para ajudar você a depurar problemas específicos de AMP no seu site. Para confirmar se uma página AMP foi indexada, use a Ferramenta de inspeção de URL, que vai ter a resposta definitiva.

Validar suas correções

Depois de corrigir todas as instâncias de um determinado problema no site, você pode pedir que o Google confirme as mudanças. Quando todas as instâncias conhecidas são corrigidas, a contagem de problemas muda para zero na tabela e vai para o final dela.

Por que validar?

Informar ao Google que você corrigiu todos os problemas em um status ou categoria específicos tem os seguintes benefícios:

• Você vai receber um e-mail quando o Google confirmar a correção em todos os URLs ou, caso contrário, se ele ainda encontrar instâncias desse problema.
• Você pode acompanhar o progresso do Google na confirmação das correções, além de acessar um registro de todas as páginas na fila para verificação e o status da correção de cada URL.

Nem sempre faz sentido corrigir e validar determinados problemas no site. Por exemplo, os URLs bloqueados pelo robots.txt provavelmente estão assim de propósito. Use o bom senso ao decidir se deve resolver um determinado problema.

Também é possível corrigir os problemas sem fazer a validação. O Google atualiza a contagem de instâncias sempre que rastreia uma página com problemas conhecidos, mesmo que você não solicite explicitamente a validação da correção.

Dica: valide suas correções com um sitemap

Para acelerar uma solicitação de correção, crie e envie um sitemap contendo somente as páginas mais importantes. Depois filtre o relatório pelo sitemap antes de solicitar uma validação. Uma solicitação de validação para um subconjunto dos URLs afetados pode ser concluída mais rapidamente do que uma que inclui todos os URLs com problemas no seu site.

Iniciar validação

Para informar ao Search Console que você corrigiu um problema, faça o seguinte:

1. Corrija todas as instâncias do problema no site. Se alguma delas não for resolvida, a validação vai ser interrompida quando o Google encontrar uma única instância restante do problema.
2. Abra a página de detalhes do problema que você corrigiu. Clique no problema na lista do relatório.
   • ⚠️ Se você filtrar o relatório por um sitemap específico, a validação vai ser aplicada somente aos itens desse sitemap no momento em que ela for solicitada. Talvez essa opção não seja útil para você, mas é importante ter isso em mente.
3. Clique em Validar a correção. Não clique nessa opção novamente até a validação terminar ou falhar. Confira mais detalhes sobre como o Google verifica suas correções.
4. Você pode monitorar o progresso da validação. Em geral, a validação leva até duas semanas, mas pode demorar muito mais em alguns casos. Por isso, tenha paciência. Você vai receber uma notificação quando a validação terminar ou falhar.
5. Se a validação falhar, clique em Ver detalhes na página de detalhes do problema para saber qual URL causou a falha. Corrija a página, confirme a correção em todos os URLs no estado Pendente e reinicie a validação.

Quando o problema de um URL ou item é considerado "corrigido"?

O problema de um URL será marcado como corrigido quando uma das seguintes condições for cumprida:

• Quando o URL for rastreado e o problema não for mais encontrado na página. Para um erro de tag AMP, talvez isso signifique que você corrigiu a tag ou que ela foi removida (se não for obrigatória). Durante uma tentativa de validação, ela vai ser marcada como Aprovado.
• Se a página não estiver disponível para o Google porque exige autenticação, foi removida ou marcada como "noindex", entre outros, o problema desse URL vai ser considerado corrigido. Durante uma tentativa de validação, ele fica no estado de validação Outro.

Ciclo de vida do problema

O ciclo de vida de um problema começa na primeira vez que uma instância dele é detectada no site e termina 90 dias após a última instância ter sido marcada como eliminada. Após 90 dias sem recorrências, o problema é removido da tabela.

A data da primeira detecção do problema indica quando ele foi identificado pela primeira vez no ciclo de vida. Ela não muda. Assim:

• se todas as instâncias de um problema forem corrigidas e, 15 dias depois, surgir uma nova, o problema vai ser marcado como aberto, e a primeira detecção vai continuar na mesma data;
• se o mesmo problema ocorrer 91 dias após a última instância ter sido corrigida, o caso anterior já vai estar encerrado, e o de agora será registrado como um novo problema. Além disso, a primeira detecção vai ser definida como a data em que esse novo problema foi encontrado.

Fluxo de validação

Esta é uma visão geral do processo de validação depois que você clica em Validar correção para um problema. Esse processo pode levar vários dias ou até mais, e você vai receber notificações de progresso por e-mail.

1. Quando você clica em Validar a correção, o Search Console imediatamente verifica algumas páginas.
   • Se a instância atual existir em qualquer uma dessas páginas, a validação terminará, e o estado de validação vai continuar igual.
   • Se as páginas da amostra não tiverem o erro atual, a validação vai continuar com o estado Iniciado. Se a validação encontrar outros problemas não relacionados, eles serão registrados como esse outro tipo, e a validação vai continuar.
2. O Search Console processa toda a lista de URLs conhecidos afetados pelo problema. Apenas os URLs com instâncias conhecidas do problema ficam na fila para novo rastreamento, não o site inteiro. O Search Console mantém um registro de todos os URLs verificados no histórico de validação, que pode ser acessado na página de detalhes do problema.
3. Quando um URL é verificado:
   1. Se o problema não for encontrado, o estado de validação da instância vai mudar para Aprovado. Se esta for a primeira instância verificada após o início da validação, o estado do problema vai mudar para Tudo certo até agora.
   2. Se o URL não estiver mais acessível, o estado de validação da instância vai mudar para Outro (o que não é um estado de erro).
   3. Se a instância ainda continuar presente, o estado do problema vai mudar para Falha, e a validação terminará. Se a página for nova e tiver sido descoberta pelo processo normal de rastreamento, ela vai ser considerada outra instância do problema.
4. Quando os URLs na fila são verificados com relação ao problema e corrigidos, o estado do problema muda para Aprovado. No entanto, mesmo quando todas as instâncias forem corrigidas, apenas o número de itens afetados (0) vai mudar. O rótulo de gravidade do problema (Erro ou Aviso) continua igual.

Mesmo que você nunca clique em "Iniciar validação", o Google pode detectar instâncias corrigidas de um problema. Se o Google detectar que todas as instâncias de um problema foram corrigidas durante o processo normal de rastreamento, a contagem de problemas vai mudar para 0 no relatório.

Revalidação

⚠️ É necessário aguardar o fim de um ciclo de validação antes de pedir outro, mesmo que você tenha corrigido alguns problemas durante o ciclo atual.

Para reiniciar uma validação que falhou, faça o seguinte:

1. Acesse o registro da validação com falha: abra a página de detalhes do problema que teve a validação reprovada e clique em Ver detalhes.
2. Clique em Iniciar nova validação.
3. A validação vai ser reiniciada para todos os URLs marcados como Pendente ou Falha, além de todas as novas instâncias desse problema identificadas pelo rastreamento normal desde a última tentativa de validação. Os URLs marcados como Aprovados ou Outros não vão ser verificados novamente.
4. Em geral, a validação leva até duas semanas, mas pode demorar muito mais em alguns casos. Por isso, tenha paciência.

Conferir o progresso da validação

Para consultar o andamento de uma solicitação de validação atual ou o histórico da última solicitação se uma validação não estiver em andamento:

1. Abra a página de detalhes do problema. Clique na linha do problema na página principal do relatório para abrir a página de detalhes.
   • O status da solicitação de validação é exibido na página de detalhes do problema e também na linha Validação da tabela "Detalhes".
2. Clique em Ver detalhes para abrir a página de detalhes da validação da solicitação.
   • O status da instância de cada URL incluído na solicitação é mostrado na tabela.
   • O status da instância se aplica ao problema específico que você está examinando. Você pode ter um problema marcado como Aprovado em uma página, mas outros problemas denominados Falha, Pendente ou Outro na mesma página.
   • Nos relatórios de AMP e de indexação de páginas, as entradas na página do histórico de validação são agrupadas por URL.
   • Nos relatórios de usabilidade em dispositivos móveis e de pesquisa aprimorada, os itens são agrupados pela combinação de URL + item de dados estruturados, conforme determinado pelo valor "Nome" do item.

Status da solicitação de validação

Os seguintes estados de validação podem ser aplicados à validação de um determinado problema:

• Não foi iniciado: uma ou mais instâncias do problema nunca estiveram em uma solicitação de validação.
  Próximas etapas:
  1. Clique no problema para descobrir os detalhes do erro. Inspecione as páginas individuais para ver exemplos do erro na página ativa.
  2. Clique em Saiba mais na página de detalhes para conferir mais detalhes do problema.
  3. Clique na linha de um URL de exemplo na tabela para saber detalhes sobre esse erro específico.
  4. Corrija suas páginas e clique em Validar a correção para iniciar a validação. Em geral, a validação leva até duas semanas. Em alguns casos, ela pode demorar muito mais. Por isso, tenha paciência.
• Iniciado: você iniciou uma tentativa de validação e ainda não foram encontradas as instâncias remanescentes do problema.
  Próxima etapa: o Google vai enviar notificações durante o andamento da validação informando o que você deve fazer, conforme necessário.
• Tudo certo até agora: você iniciou uma tentativa de validação, e todas as instâncias do problema detectadas até agora foram corrigidas.
  Próxima etapa: nenhuma ação é necessária. No entanto, o Google vai enviar notificações durante o processo de validação informando o que você precisa fazer.
• Aprovado: todas as instâncias conhecidas do problema foram eliminadas (ou o URL afetado não está mais disponível). Provavelmente, você clicou em Validar a correção para chegar a esse estado. Se as instâncias tivessem desaparecido sem que você tivesse solicitado a validação, o estado teria mudado para "N/D".
  Próxima etapa: nenhuma ação é necessária.
• N/D: o Google descobriu que o problema foi corrigido em todos os URLs, mesmo que você nunca tenha iniciado uma tentativa de validação.
  Próxima etapa: nenhuma ação é necessária.
• Falha: um determinado limite de páginas ainda vai ter esse problema depois que você clicar em Validar.
  Próximas etapas: corrija o problema e reinicie a validação.

Status de validação da instância

Após a validação ser solicitada, cada instância do problema recebe um dos seguintes estados de validação:

• Pendente: na fila para validação. Na última verificação feita pelo Google, o problema ainda existia.
• Aprovado: a verificação feita pelo Google não detectou mais a instância do problema [não está disponível em todos os relatórios]. Esse estado só poderá ser alcançado se você clicar em Validar para a instância do problema.
• Falha: a verificação feita pelo Google detectou a presença do problema. Esse estado só poderá ser alcançado se você clicar em Validar para a instância do problema.
• Outro: o Google não conseguiu acessar o URL que hospeda a instância ou, no caso de dados estruturados, não foi possível encontrar o item na página [não está disponível em todos os relatórios]. Esse estado é equivalente a Aprovado.

O mesmo URL pode ter estados diferentes para problemas distintos. Por exemplo, se uma única página tiver os problemas X e Y, talvez o problema X tenha o estado de validação Aprovado e o Y exiba o estado Pendente.

 

Problemas conhecidos

Estes são problemas conhecidos no Search Console. Não é necessário informá-los, mas gostaríamos de receber seu feedback a respeito de qualquer outro recurso ou erro que você identificar. Use o mecanismo de feedback da barra de navegação.

• Alguns problemas têm nomes longos que são difíceis de compreender.
• Pode haver um intervalo entre o momento em que um problema é adicionado ao gráfico e à tabela.