Relatório de status de AMP

Esse 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 de nível superior mostra todas as páginas AMP com problemas que foram encontradas pelo Google no seu site, agrupadas por erro. Clique em um erro específico para ver os detalhes, que incluem uma lista de amostra das páginas afetadas por ele, informações sobre como corrigi-lo e o processo de notificação do Google a respeito das suas correções.

Para ver gráficos que mostram o impacto dos problemas e as correções, acesse a página "Status".

Por que usamos uma lista de amostra? Mostramos o maior número possível de páginas afetadas por erros. No entanto, só podemos exibir até mil URLs na tabela. Além disso, pode haver outras páginas que, por algum motivo, não foram detectadas ou contadas.

ABRIR O RELATÓRIO DE AMP

 

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

O que procurar

O ideal é que você veja estas informações no relatório:

  • Ele não deve exibir erros de AMP no site. Os avisos são considerados recomendações, e não erros. Consulte Como interpretar os avisos abaixo. Se houver erros, leia Priorizar e corrigir problemas.
  • O total de páginas AMP no relatório (válidas, com aviso e com erro) deve estar próximo do número de páginas desse tipo no site. Caso contrário, veja a seção sobre páginas AMP ausentes.

 

O relatório está diferente?
Os usuários talvez percebam uma mudança em alguns relatórios. Em determinados casos, isso significa o reagrupamento de todos os itens de três categorias (válido, aviso e inválido) em duas categorias (válido e inválido). Também pode ser que a tabela na página de destino do relatório agora mostre somente itens inválidos. Caso seu relatório pareça muito diferente do último acessado por você, saiba mais sobre as alterações aplicadas aqui.

Lista de problemas de AMP

Além dos erros específicos a AMP padrão, o relatório também pode exibir 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

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:

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.

Esse erro pode ocorrer por vários motivos:

  • 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:

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 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 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 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. Na página de resumo, filtre os avisos e trabalhe nos erros primeiro. Por padrão, todos os problemas são classificados por uma combinação de gravidade, estado de validação e número de páginas afetadas. Recomendamos que você os resolva nessa ordem. 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.
  2. Veja 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.
  3. Consulte as informações abaixo sobre a depuração de picos e páginas AMP ausentes.
  4. Clique em uma linha na tabela para ver a página de detalhes do erro:
    1. A página de detalhes inclui exemplos de URLs afetados. A lista nem sempre está completa, já que tem um limite de mil linhas e pode não incluir as instâncias mais recentes do erro.
    2. Se for um erro de sintaxe, clique em Saiba mais para acessar a documentação oficial sobre a sintaxe adequada.
    3. Clique no ícone de inspeção para realizar um teste de validação na página afetada. Esse teste identificará todos os erros (não só o atual) e fornecerá um explorador de códigos para destacar os problemas e mostrar mais informações. Talvez um erro já corrigido na página publicada ainda apareça na lista de problemas porque não foi rastreado novamente. Se isso ocorrer, solicite uma validação após corrigir todas as instâncias dele.
  5. Corrija todas as instâncias do problema no seu site, teste se ele foi solucionado e verifique se as correções foram publicadas na Web.
  6. Volte à página de detalhes do erro 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.
  7. Continue a correção de erros.
  8. Quando todos os erros forem corrigidos, remova o filtro de avisos e faça a correção deles. Alguns avisos referem-se à ausência da marcação de dados estruturados opcionais, que podem permitir novos recursos de pesquisa para páginas com conteúdo relevante.

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.

Picos de erros

Para determinar se um crescimento no número de erros foi causado por um grupo de páginas, mude de uma gravidade para outra:

  1. Se você identificar um grande aumento no volume de erros, procure por uma queda correspondente em outro estado (com erro ou válidas).
  2. Caso você encontre essa queda, confirme se são os mesmos URLs.
  3. Se houver alteração no estado dos URLs, determine a causa dessa mudança.

O motivo mais comum de um aumento no número de problemas é a adição de um erro a um modelo usado por muitas páginas do seu site.

Como solucionar problemas de ausência de páginas AMP

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

  • Confirme se a página não AMP canônica vincula corretamente sua página AMP.
  • Verifique se as páginas AMP ou canônicas não têm robôs ou noindex nem são protegidas por requisitos de autenticação ou login.
  • Confira se as versões AMP e canônica estão no índice pesquisando o URL da página canônica no Google. Se a página não aparece na lista, não está indexada.
  • Sua página AMP/canônica é vinculada por outras páginas? Elas estão listadas em um sitemap? Use a Ferramenta de inspeção de URL na página canônica para solicitar a indexação de um pequeno número de páginas AMP. Para um volume maior, utilize os sitemaps. Você só precisa listar a página canônica no sitemap. Use o Relatório de sitemaps para enviá-lo.
  • 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 cobertura do índice. Isso acontece porque o Relatório de cobertura do índice 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 terá a resposta definitiva.

Como interpretar os avisos

As páginas AMP com avisos são indexadas e podem aparecer nos resultados da Pesquisa Google. No entanto, talvez elas não sejam publicadas com todos os recursos AMP possíveis, como a exibição em um carrossel de notícias principais. Em outras palavras, essas páginas só poderão ser exibidas como resultados da pesquisa com link comum em azul.

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ífica 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 ver 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.

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 na linha da tabela onde ele aparece na lista do relatório.
  3. Clique em Validar a correção. Não clique nessa opção novamente até a validação terminar ou falhar. Veja 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 vai 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 vai 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 vão ser 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 a partir da 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 vai 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 existente.
  4. Quando os URLs na fila foram verificados com relação ao problema e foram corrigidos, o estado do problema muda para Aprovado. No entanto, mesmo quando todas as instâncias forem corrigidas, o rótulo de gravidade do problema não vai mudar (Erro ou Aviso), apenas o número de itens afetados (0).

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 para solicitar 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.

Ver o progresso da validação

Para ver 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.
  2. Clique em Ver detalhes para abrir a página de detalhes da validação da solicitaçã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 cobertura do índice, 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 ver os detalhes do erro. Inspecione cada página para ver exemplos do erro na página ativa usando o teste de AMP. Se o teste de AMP não mostrar o erro, é porque o erro foi corrigido na página ativa depois que o Google o detectou e gerou o relatório do problema.
    2. Clique em Saiba mais na página de detalhes para ver mais detalhes do problema.
    3. Clique na linha de um URL de exemplo na tabela para ver detalhes sobre esse erro específico.
    4. Corrija suas páginas e clique em Validar a correção para iniciar a validaçãoEm 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ó vai 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ó vai 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.
  • Caso seu site tenha um número muito grande de problemas (com ou sem instâncias ativas), o relatório exibirá somente os primeiros 200 erros, classificados por importância.
Isso foi útil?
Como podemos melhorá-lo?
true
Chegou agora ao Search Console?

Nunca usou o Search Console antes? Comece aqui. Temos informações para todos, dos novatos aos especialistas em SEO ou desenvolvedores de sites.

Pesquisa
Limpar pesquisa
Fechar pesquisa
Google Apps
Menu principal
Pesquisar na Central de Ajuda
true
83844
false