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.

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.
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 e não é possível fazer referência a ela como a própria versão AMP. Saiba como fazer referência a uma AMP a partir 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.

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 de AMP, filtre os avisos e concentre-se primeiro nos erros. 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 quantidade de páginas AMP (válidas, com aviso e com erro) no relatório for menor do que o total do site, talvez isso tenha ocorrido por algum dos seguintes motivos:

  • Os URLs informados nesse relatório representam uma amostra de todos os URLs de AMP conhecidos do site. A lista de URLs não é para ser completa.
  • Confirme se a página não AMP canônica está vinculada corretamente à 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.

Sobre a validação

Depois de corrigir todas as instâncias de um determinado problema no site, você pode solicitar ao Google que valide as alterações. Se todas as instâncias conhecidas desaparecerem, o problema será marcado como corrigido e movido para a parte inferior da tabela de status. O Search Console rastreia o estado de validação do problema como um todo, além da situação de cada uma das instâncias dele. Quando todas as instâncias do problema desaparecerem, ele será considerado resolvido. Para ver os estados registrados, consulte Estado de validação do problema e Estado de validação da instância.

Mais informações sobre o 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 será removido do histórico do relatório.

A primeira data detectada do problema é a primeira vez que ele foi identificado durante o ciclo e ela não se altera. Assim:

  • se todas as instâncias de um problema forem corrigidas e, 15 dias depois, uma nova instância surgir, o problema será marcado como aberto, e a "primeira data detectada" continuará sendo a data original;
  • se o mesmo problema ocorrer 91 dias após a última instância ter sido corrigida, o problema anterior terá sido encerrado, e o problema será registrado como novo. Além disso, a primeira data detectada será definida como "hoje".

Fluxo básico 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 demorar vários dias, e você receberá notificações do andamento dele 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 permanecerá inalterado.
    • Se as páginas de amostra não tiverem o erro atual, a validação 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 continuará.
  2. O Search Console processa toda a lista de URLs conhecidos afetados pelo problema. Apenas os URLs com instâncias conhecidas do problema ficarão 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 mudará para Aprovado. Se esta for a primeira instância verificada após o início da validação, o estado do problema mudará para Tudo certo até agora.
    2. Se o URL não estiver mais acessível, o estado de validação da instância mudará para Outro (o que não é um estado de erro).
    3. Se a instância ainda continuar presente, o estado do problema mudará para Reprovado, e a validação terminará. Se a página for nova e tiver sido descoberta pelo processo normal de rastreamento, ela será considerada outra instância do problema existente.
  4. Quando todos os URLs de erro e aviso tiverem sido verificados, e a contagem de problemas for zero, o estado do problema mudará para Aprovado. Importante: mesmo quando o número de páginas afetadas cair para zero, e o estado do problema mudar para Aprovado, o rótulo original de gravidade ainda será Erro ou Aviso.

Mesmo que você nunca clique em "Iniciar validação", o Google poderá detectar as 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, o estado do problema mudará para "N/D" no relatório.

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 ela não for obrigatória). Durante uma tentativa de validação, isso será considerado "Aprovado".
  • Se a página não estiver disponível para o Google porque requer autenticação, foi removida, marcada como "noindex", entre outros, o problema desse URL será considerado como corrigido. Durante uma tentativa de validação, ele será registrado como o estado de validação "Outro".

Revalidação

Quando você clicar em Revalidar para uma validação reprovada, a validação será reiniciada para todas as instâncias reprovadas, além de todas as novas instâncias do problema descobertas no processo normal de rastreamento.

É 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.

As instâncias que foram aprovadas na validação (marcadas como Aprovado) ou que não podem mais ser acessadas (marcadas como Outro) não serão verificadas novamente e serão removidas do histórico quando você clicar em "Revalidar".

Histórico de validação

É possível ver o progresso de uma solicitação ao clicar no link da validação na página de detalhes do problema.

As entradas na página do histórico de validação são agrupadas por URL nos relatórios de AMP e de Status do índice. 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). O estado de validação 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 "Reprovado", "Pendente" ou "Outros".

Estado de validação do problema

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

  • Não iniciado: há uma ou mais páginas com uma instância do problema que você nunca tentou enviar para 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 informações sobre a regra violada.
    3. Clique na linha de um URL de exemplo na tabela para ver detalhes sobre esse erro específico.
    4. Corrija as páginas e clique em Validar correção para que o Google faça um novo rastreamento delas. O Google notificará você sobre o andamento da validação. A validação pode levar desde alguns dias até cerca de duas semanas. 
  • 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 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 verificadas até agora foram corrigidas.Próxima etapa: nenhuma ação é necessária. No entanto, o Google enviará notificações durante o processo de validação informando o que você deve 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 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.
  • Reprovado: um determinado número de páginas ainda contém o problema depois de você ter clicado em "Validar". Próximas etapas: corrija o problema e refaça a validação.

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

  • 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.
  • Reprovado: 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.
  • 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?