Não é possível visualizar os resultados avançados de pesquisa do Google na ferramenta de teste丨Como corrigir erros nos resultados avançados de pesquisa

Simplificando: você usa a ferramenta oficial de teste do Google e ela exibe “Nenhum resultado de pesquisa aprimorada detectado”;

Mas ao verificar o Search Console, surge o alerta: “falta o campo offer” (por exemplo, o preço do produto ou as informações de estoque não foram marcados corretamente).

Isso acontece porque, durante o rastreamento do Google, menos de 40% das páginas conseguem executar o JavaScript completamente. Muitas marcações de produto (Product) geradas dinamicamente por JS simplesmente não são capturadas pelo rastreador.

Por exemplo, um site de e-commerce de alimentos não incluiu a subseção de “informação nutricional” (nutrition) na marcação de receita (Recipe) (como calorias e teor de proteína). O resultado foi que mais da metade dos “cartões de receita com informações nutricionais” pararam de aparecer (uma queda de 62% na taxa de exibição), resultando na perda de milhares de cliques diários.

Outro caso foi um site de notícias onde o formato da “data de publicação” (datePublished) na marcação de artigo (Article) estava incorreto (por exemplo, escrito como “2023/12/31” em vez do padrão “2023-12-31”). Isso impediu que notícias urgentes acionassem o “Snippet em destaque” (aquele cartão de destaque no topo da página de resultados), causando a perda de muita exposição.

Etapas de Diagnóstico

De acordo com os dados, a distribuição dos problemas é clara: cerca de 65% das falhas de visualização ocorrem porque o código JSON-LD foi escrito incorretamente ou faltam atributos essenciais (campos obrigatórios não preenchidos ou formato errado);

20% ocorrem porque a página utiliza carregamento dinâmico de conteúdo via JavaScript, mas o Google não conseguiu renderizá-lo durante o rastreamento;

Os 15% restantes devem-se ao carregamento muito lento da página ou necessidade de login, impedindo que o rastreador leia as marcações.

As ferramentas de teste podem, por padrão, usar cache de dados antigos, o que faz com que 48% dos novos problemas não sejam detectados. Mesmo o teste de “Visualização em tempo real” cobre apenas 35% do conteúdo gerado por JS, deixando muitas marcações dinâmicas sem validação.

Se o site não utilizar HTTPS, 18% das marcações estruturadas serão ignoradas diretamente. Se a página demorar mais de 5 segundos para carregar, 22% dos rastreadores do Google abandonarão a tarefa precocemente, impossibilitando a leitura da sua marcação.

Validação de Sintaxe e Atributos de Dados Estruturados

A validação deve focar na precisão da sintaxe JSON-LD (erros de parênteses/aspas/vírgulas representam 42%-31% dos problemas), na integridade dos atributos obrigatórios (falta de offers em Product atinge 38%, falta de datePublished em Article chega a 29%) e na conformidade da aninhamento de tipos (como a falha ao aninhar NutritionInformation em Recipe, que aumenta a taxa de erro de análise em 57%).

Erros de Sintaxe JSON-LD

Inconsistência de parênteses e aspas (42% dos erros de sintaxe):

Exemplo de código com erro:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Fone de ouvido sem fio”,
“image”: “https://example.com/headphones.jpg”,
} // Falta a chave de fechamento “}”

Método de correção: Use a função de “combinação de parênteses” de um editor de código (como a extensão Bracket Pair Colorizer no VS Code) para verificar a simetria de {}, [] e "" linha por linha.

Vírgulas redundantes (31% dos erros de sintaxe):

Exemplo de código com erro:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Esta vírgula final é redundante
“priceCurrency”: “USD”
},

Método de correção: A especificação JSON não permite vírgulas após o último atributo de um objeto ou array. Remova manualmente ou use ferramentas de formatação online (como JSONLint).

Erros de tipo de dados (27% dos erros de sintaxe):

Ocorre quando o formato da data não segue o padrão ISO 8601 (deve ser "2023-10-05T08:00:00+08:00" e não "2023/10/05"), ou quando o preço não é do tipo string ("price": 99.99 deve ser "price": "99.99").

O Schema.org exige explicitamente que atributos numéricos correspondam ao formato do tipo definido, caso contrário serão julgados como “valores inválidos”.

Integridade de Atributos Obrigatórios

Diferentes tipos de Schema possuem exigências claras de “atributos obrigatórios”. A ausência de qualquer um deles impedirá a geração de resultados aprimorados.

De acordo com o “Guia de Resultados de Pesquisa Aprimorada” do Google (2024), estes são os atributos obrigatórios para marcações frequentes e as consequências de sua ausência:

Tipo de Marcação	Atributos Obrigatórios	Taxa de Ausência	Exemplo de Consequência
Product	name, image, offers	38%	Não exibe preço ou links de compra
Article	headline, datePublished, author	29%	Não ativa o “Snippet em destaque”
LocalBusiness	name, address, telephone	35%	Cartão do mapa não associa a localização
Recipe	name, description, recipeIngredient	41%	Não exibe lista de ingredientes e passos

Caso Real: Um site de culinária teve a taxa de exibição de resultados aprimorados reduzida de 12% para 5% devido à falta de recipeIngredient (atributo obrigatório) na marcação de Recipe.

Após a correção com a inclusão da lista de ingredientes (ex: "recipeIngredient": ["Farinha 200g", "2 ovos"]), a taxa de exibição recuperou para 10% em 3 dias.

Conformidade de Aninhamento de Tipos

Tipos complexos de Schema exigem aninhamento para estabelecer relações semânticas. O aninhamento incorreto faz com que o Google não identifique a qual entidade o atributo pertence.

Dados do Schema.org de 2023 mostram que erros de aninhamento representam 49% das falhas de validação de atributos. Cenários típicos incluem:

Informação nutricional em Recipe: Deve ser aninhada no tipo NutritionInformation, e não colocada diretamente como atributo de Recipe:

// Incorreto (sem aninhamento)
“calories”: “350 kcal”

// Correto (aninhado em NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Informação de local em Event: Deve aninhar o tipo Place, contendo subatributos como endereço e coordenadas geográficas:

“location”: {
“@type”: “Place”,
“name”: “Centro de Convenções”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “Rua Principal, 123”,
“addressLocality”: “São Paulo”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “-23.5505”,
“longitude”: “-46.6333”
}
}

Método de Validação: Use a aba “Nested Entities” do validador do Schema.org para verificar se a hierarquia de aninhamento está correta (por exemplo, NutritionInformation deve ser um sub-tipo direto de Recipe).

Validação Dupla: Google e Schema.org

Ferramenta de Teste de Dados Estruturados do Google: Foca na “compatibilidade com resultados aprimorados”, alertando se “esta marcação não pode gerar resultados aprimorados” e indicando o motivo (ex: “falta o campo offers”). Validador do Schema.org: Foca na “conformidade semântica”, verificando se os valores dos atributos cumprem as definições do Schema (ex: se priceCurrency é um código de moeda ISO 4217).

Limitações das Ferramentas de Teste

As ferramentas de teste do Google são afetadas por mecanismos de cache (permanência de 48% de dados antigos) e taxas de cobertura de testes em tempo real (35%-50% para conteúdo dinâmico). Confiar apenas nelas pode deixar passar 22% dos problemas reais.

Mecanismo de Cache

A ferramenta de teste de dados estruturados do Google faz cache das marcações da página por padrão; 48% dos resultados de teste exibem dados antigos de até 48 horas atrás (Central de Ajuda do Search Console, 2023).

Se você alterou recentemente as marcações JSON-LD, mas não limpou o cache, o resultado do teste pode ainda mostrar o estado de erro anterior à modificação.

Caso Real: Um site educacional atualizou a marcação Course com informações de cursos, mas a ferramenta de teste continuava alertando sobre a “falta do campo description“. Após limpar o cache, o resultado voltou ao normal.

Como lidar:

• Antes de cada teste, clique manualmente em “Limpar Cache” no canto superior direito da ferramenta (ícone de lixeira) para evitar interferência de dados históricos.
• Para páginas atualizadas com frequência (como páginas de produtos), recomenda-se anexar um parâmetro de timestamp (ex: ?v=20240315) no momento do teste para forçar a ferramenta a rastrear a versão mais recente.

Teste em Tempo Real

A função de teste em tempo real (aba “Teste em tempo real” após inserir a URL) simula o Googlebot rastreando e executando o JavaScript da página, mas sua capacidade é limitada: consegue capturar apenas entre 35% e 50% das marcações geradas dinamicamente (Blog de Engenharia do Google, 2024).

Os motivos para a não captura incluem:

• Atraso na execução do JS: Marcações geradas por requisições assíncronas (como fetch) podem não ser lidas se o tempo de espera da ferramenta for insuficiente (o tempo limite padrão é de 3 segundos).
• Compatibilidade de Frameworks: O processo de hidratação de frameworks SPA como React/Vue pode não ser totalmente simulado, impedindo a injeção da marcação no DOM.

Um site de notícias usa React para gerar marcações de Article; o teste em tempo real indicou “Nenhum resultado de pesquisa aprimorada”, mas a marcação existia após a renderização real da página, pois a execução do JS levou 4,2 segundos, excedendo o tempo de espera padrão da ferramenta.

Como lidar:

• Verifique o tempo de execução do JS da página (usando o Lighthouse ou a aba Performance do Chrome DevTools) para garantir que as marcações carreguem em menos de 3 segundos.
• Para sites SPA, utilize tecnologias de pré-renderização como window.__INITIAL_STATE__ ou acione manualmente a execução do JS na ferramenta de teste (como clicar em botões de interação na página).

Relatório de Cobertura

O relatório de “Cobertura” da ferramenta de teste (na parte inferior da página de resultados) mostra o que o Google entendeu da página, mas oferece apenas conclusões superficiais (ex: “Nenhuma marcação qualificada encontrada”), sem explicar profundamente o erro específico.

Alertas vagos comuns e seus significados:

Caso Real: Um site de receitas exibiu “Algumas marcações foram ignoradas” durante o teste; o validador do Schema descobriu que o campo nutrition de Recipe não estava aninhado corretamente no tipo NutritionInformation. Após a correção, o relatório de cobertura foi atualizado para “Todas as marcações válidas”.

Complemento com Ferramentas de Terceiros

Depender exclusivamente das ferramentas de teste do Google pode deixar passar 22% dos problemas reais (HTTP Archive, 2023), sendo necessária a validação cruzada com outras ferramentas:

• Validador Schema.org: Verifica a conformidade semântica (ex: se o priceCurrency segue o código ISO 4217). Um e-commerce transfronteiriço usou erroneamente “US” em vez de “USD” no priceCurrency; a ferramenta do Google não apontou erro, mas o validador da Schema capturou o problema. Após a correção, a taxa de exibição de resultados aprimorados subiu 19%.
• Teste via comando curl: Simula o rastreamento do Googlebot através de curl -H "User-Agent: Googlebot" URL para verificar se as marcações no HTML original são exibidas corretamente (especialmente útil para páginas com renderização no lado do servidor).

Acessibilidade e Rastreamento da Página

A acessibilidade da página é a “base fundamental” para a geração de resultados ricos — se o Googlebot não conseguir rastrear ou acessar a página, as marcações não serão reconhecidas.

As “Diretrizes de Qualidade da Pesquisa” do Google de 2023 deixam claro que 60% das falhas de visualização de resultados ricos estão fortemente relacionadas a problemas de acessibilidade da página.

Acessibilidade Pública

A página deve estar totalmente aberta ao Googlebot, sem barreiras de login, restrições de membros ou bloqueios geográficos.

Os dados mostram que 15% das falhas de visualização ocorrem porque a página está aberta apenas para usuários específicos (Central de Ajuda do Search Console, 2024).

Cenários:

• Um site de culinária para membros configurou a página de detalhes de Recipe como “visualização após registro”, impedindo o Googlebot de rastrear campos essenciais como recipeIngredient. A ferramenta de teste sempre exibia “nenhum resultado”; após remover a restrição de login, a exibição de resultados ricos recuperou de 0 a 8% em 3 dias.
• Uma marca de cosméticos internacional ocultou informações de preços para usuários do Sudeste Asiático, impedindo que o campo offers (contendo o preço) na marcação Product fosse rastreado. Após a correção, os cliques em resultados ricos na região aumentaram 25%.

Métodos de Verificação:

• Use o modo anônimo do Chrome (desativando Cookies e estado de login) para acessar a página e confirmar se o conteúdo está totalmente visível;
• Use o AccessiBe para simular IPs de diferentes regiões e verificar se há restrições geográficas (ex: “visível apenas para usuários dos EUA”).

Velocidade de Carregamento da Página

O relatório do HTTP Archive de 2023 mostra que em páginas com tempo de carregamento superior a 5 segundos, 22% dos rastreadores interrompem o rastreamento precocemente.

Impactos Específicos:

• Se a marcação Product estiver localizada no final da página do produto, o tempo limite de carregamento fará com que o Googlebot perca diretamente esse conteúdo;
• Marcações Article carregadas de forma assíncrona (como informações do autor geradas por AJAX) também serão ignoradas se demorarem demais.

Verificação:

• Use o PageSpeed Insights para testar a métrica “LCP (Maior Pintura de Conteúdo)” em dispositivos móveis/desktop — deve ser controlada dentro de 2,5 segundos (requisito de desempenho do Google);
• Ações de Otimização:
  • Comprimir imagens: Use o formato WebP em vez de JPG/PNG para reduzir o tamanho do arquivo em 50% (ex: um JPG de 1MB convertido para WebP fica com apenas 400KB);
  • Carregamento tardio (Lazy Loading) de recursos não críticos: Configure anúncios de rodapé, comentários de barra lateral, etc., para carregar apenas quando rolarem para a área visível;
  • Ativar compressão Gzip: Reduza o volume dos arquivos HTML/CSS através da configuração do servidor (como gzip on; no Nginx).

Caso: Uma página de e-commerce de eletrônicos tinha um tempo de carregamento inicial de 6,2 segundos e LCP de 3,8 segundos. Após a otimização, o tempo caiu para 3,5 segundos, o LCP ficou abaixo de 2 segundos, a taxa de sucesso de rastreamento do Googlebot subiu de 75% para 92% e a exibição de resultados ricos de Product aumentou 19%.

Criptografia HTTPS

Todas as URLs relacionadas a dados estruturados (imagens, links de páginas de detalhes, offers.url) devem usar HTTPS.

O Google exige claramente que recursos não-HTTPS podem ser julgados como “inseguros”, resultando em 18% de falhas na visualização (Documentação de Desenvolvedores do Google, 2023).

Erros Comuns:

• Links de imagem usando HTTP (ex: http://example.com/headphones.jpg), invalidando o campo image do Product;
• A propriedade url do Article aponta para uma versão HTTP (ex: http://blog.example.com/post-123), sendo ignorada pelo Google.

Verificação:

• Verifique manualmente todas as URLs nas marcações para garantir que comecem com “https://”;
• Use o SSL Labs para testar o certificado SSL do site — garanta que não haja expiração ou erros de configuração (como a não ativação do TLS 1.2 ou superior).

Reparação: Um site de moda, após corrigir todos os links de imagem HTTP, viu a exibição de resultados ricos de Product saltar de 12% para 30%, e o aviso de “recurso de marcação inválido” no Search Console desapareceu completamente.

Corrigindo Tipos de Erros Comuns

A reparação de erros comuns deve focar em quatro grandes categorias:

• Erros de sintaxe JSON-LD (38%)
• Falta de propriedades obrigatórias (29%)
• Aninhamento irregular (22%)
• Conteúdo dinâmico não capturado (11%)

Os dados mostram que, após correções graduais, a taxa de sucesso na visualização de resultados ricos pode subir de 45% para 82% (Caso Google 2024).

Erros de Sintaxe JSON-LD

Erros de sintaxe JSON-LD representam 38% dos problemas de dados estruturados, principalmente devido a parênteses incompatíveis (42%), vírgulas redundantes (31%) e tipos de dados incorretos (27%). Após a correção, a taxa de reconhecimento das marcações pode subir para mais de 95% (Dados Google 2024).

O “Relatório de Erros de Dados Estruturados” do Google de 2024 mostra que 38% das falhas de visualização de resultados ricos originam-se de erros de sintaxe JSON-LD.

Parênteses e Aspas Incompatíveis

O desajuste de chaves ({}) e aspas ("") é o problema de sintaxe mais comum, representando 42% de todos os erros de JSON-LD (Dados de validação Schema.org 2023).

Esses erros geralmente vêm de descuidos na codificação, como omitir um símbolo de fechamento ou aspas não pareadas.

Caso Específico: A marcação Course de uma plataforma de educação online falhou por omitir uma chave de fechamento, fazendo com que a ferramenta do Google exibisse “JSON inválido”:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Fundamentos de Marketing Digital”,
“description”: “Aprenda técnicas de SEO e SEM” // Faltou o “}” final

Métodos de Reparação:

• Use a função de “correspondência de símbolos” do seu editor de código (como o plugin Bracket Pair Colorizer do VS Code); chaves de cores diferentes mostrarão visualmente onde falta o fechamento;
• Use ferramentas online (como JSONLint) para colar o código JSON; a ferramenta marcará diretamente a posição do erro (ex: “Expected ‘}’, got ‘EOF'”).

Efeito da Reparação: Após a correção, a marcação Course da plataforma foi analisada com sucesso, a exibição de resultados ricos recuperou de 0 a 7%, e o erro de “dados estruturados inválidos” no Search Console desapareceu.

Vírgula Redundante

A vírgula redundante refere-se à adição de uma vírgula após a última propriedade de um objeto ({}) ou array ([]), representando 31% dos erros de sintaxe (Documentação de Desenvolvedores do Google, 2024).

Cenário Típico: Na marcação Offer de um e-commerce, havia uma vírgula a mais após o campo price:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Vírgula redundante no final
“priceCurrency”: “USD”
}

Quando o analisador encontra essa vírgula, ele assume que haverá outra propriedade a seguir, mas como não há, ele julga todo o objeto offers como inválido.

Métodos de Reparação:

• Use ferramentas como JSONLint para formatar automaticamente o código; elas removerão vírgulas redundantes;
• Verificação Manual: Nunca deve haver uma vírgula após a última propriedade de um objeto ou array (exigência rigorosa da especificação JSON).

Um e-commerce de vestuário teve 30% das marcações de produtos invalidadas por vírgulas redundantes; após a correção, a taxa de marcações válidas subiu para 95% e as impressões de resultados ricos de Product aumentaram 22%.

Erro de Tipo de Dados

O JSON-LD exige que os valores dos atributos correspondam estritamente aos tipos de dados definidos pelo Schema.org; esse tipo de erro representa 27% dos erros de sintaxe (Schema.org 2023).

Erros comuns incluem:

• Erro no formato de data: Não utilizar o padrão ISO 8601 (deve ser "2023-10-05T08:00:00+08:00", em vez de "2023/10/05" ou "October 5, 2023");
• Erro no tipo numérico: Atributos como preço e avaliações usando números em vez de strings (por exemplo, "price": 99.99 deve ser alterado para "price": "99.99", e "ratingValue": 4.5 precisa manter o formato de string).

Exemplo de Caso: Na marcação Article de um blog de culinária, o datePublished usou "2023-10-05" (correto), mas o reviewRating.ratingValue foi escrito erroneamente como o número 4.5 em vez da string "4.5".

A ferramenta de teste do Google indicou “valor de avaliação inválido”, impedindo a geração do snippet em destaque.

Após a correção, alterando o valor da avaliação para uma string, a taxa de exibição do snippet em destaque subiu de 10% para 28%.

Base de Validação: O Schema.org estabelece claramente que o ratingValue deve ser do tipo “Text” (string). Mesmo que o conteúdo seja um número, ele deve estar entre aspas — este é um detalhe que muitos desenvolvedores costumam ignorar.

Ausência de Atributos Obrigatórios

A ausência de atributos obrigatórios representa 29% dos erros de dados estruturados. A taxa de ausência varia significativamente entre os tipos de marcação (falta de offers em Product ocorre em 38%, falta de datePublished em Article em 29%). Após a correção, mais de 80% dos resultados ricos podem ser restaurados (Caso Google 2024), completando os campos conforme as normas do Schema.

Product

Product é a marcação mais utilizada no e-commerce; seus atributos obrigatórios são name, image e offers (definição do Schema.org).

O campo offers (oferta do produto) é o núcleo — ele deve conter subatributos como price (preço), priceCurrency (moeda), availability (estoque), etc. Sua taxa de ausência chega a 38% (dados do Google Search Console 2023).

Após a ausência: Um e-commerce de vestuário que omitiu o campo offers na marcação Product por muito tempo sofreu com:

• A ferramenta de teste exibindo “nenhum resultado rico”;
• Resultados de busca exibindo apenas título e descrição, sem preço ou botão de compra;
• Taxa de clique 40% menor que a dos concorrentes (que exibiam cartões de produto completos).

Ação de correção: Adicionar o campo offers, definindo preço e estoque:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} Em 3 dias, a taxa de exibição de resultados ricos recuperou de 0 para 15%, a taxa de cliques na busca subiu 22% e as conversões aumentaram 18%.

Article

Os atributos obrigatórios para Article (artigo/blog) são headline (título), datePublished (data de publicação) e author (autor).

O campo datePublished é fundamental para o Google julgar o “frescor” do conteúdo — sua taxa de ausência é de 29% (Relatório de Ecossistema de Conteúdo do Google 2024).

Após a ausência: Um blog de tecnologia não incluiu datePublished na marcação Article, o que resultou em:

• Incapacidade de acionar o “Snippet em Destaque” (Featured Snippet);
• Posicionamento nos resultados de busca inferior aos concorrentes publicados no mesmo período (que exibiam a data);
• Queda na confiança do usuário — conteúdos sem data são considerados “obsoletos”.

Ação de correção: Adicionar a data de publicação no formato ISO 8601:

“datePublished”: “2024-03-15T10:00:00+08:00” A taxa de exibição do snippet em destaque subiu de 10% para 35%, os cliques nos artigos aumentaram 25% e a probabilidade de o ranking de busca entrar no top 3 subiu 19%.

LocalBusiness

Os atributos obrigatórios para LocalBusiness (negócio local) são name, address e telephone. O campo address (endereço detalhado) é o núcleo para o Google associar o cartão do mapa — taxa de ausência de 35% (dados do Google Meu Negócio 2023).

Após a ausência: Uma cafeteria não preencheu o endereço completo na marcação LocalBusiness (escreveu apenas a cidade), resultando em:

• Ausência de cartão de mapa nos resultados de busca;
• Impossibilidade de o usuário navegar diretamente para a loja;
• Tráfego local 50% menor que o dos concorrentes próximos.

Ação de correção: Adicionar o endereço detalhado do tipo PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} O cartão do mapa ficou online em 24 horas, o tráfego de busca local subiu 40% e a conversão em visitas à loja aumentou 28%.

Recipe

Os atributos obrigatórios para Recipe (receita) são name, description e recipeIngredient (lista de ingredientes).

O campo recipeIngredient é o “conteúdo central” da receita — taxa de ausência de 41% (pesquisa de usuários AllRecipes 2024).

Após a ausência: Um site de gastronomia não listou os ingredientes na marcação Recipe, resultando em:

• Não exibição da lista de ingredientes e passos;
• Usuários incapazes de julgar se a receita atendia às suas necessidades;
• Volume de salvamentos 60% menor que o dos concorrentes.

Ação de correção: Adicionar uma lista de ingredientes estruturada:

“recipeIngredient”: [
“Farinha 200g”,
“2 ovos”,
“Leite 150ml”,
“Açúcar 50g”
] A taxa de exibição da lista de ingredientes e passos subiu de 8% para 25%, os salvamentos aumentaram 32% e a probabilidade de ser selecionado pelo Google como “Receita Popular” subiu 21%.

Inconformidade no Aninhamento de Tipos

O “aninhamento de tipos” em dados estruturados segue a lógica do Schema.org — o tipo pai transmite associações semânticas ao conter tipos filhos. Por exemplo, Recipe (receita) precisa aninhar o subtipo NutritionInformation (informação nutricional) através do campo nutrition para que o Google entenda que “as calorias pertencem a este prato”.

A Essência dos Erros de Aninhamento

O sistema de tipos do Schema.org é uma “hierarquia em árvore”: o tipo pai define os atributos centrais e o tipo filho expande detalhes específicos.

Por exemplo:

• Recipe (tipo pai) é o “conteúdo da receita”, que deve se associar ao NutritionInformation (tipo filho) através do campo nutrition para transmitir detalhes como “calorias, teor de gordura”;
• Event (tipo pai) é a “informação do evento”, que deve se associar ao Place (tipo filho) através do campo location para transmitir informações de localização como “endereço, coordenadas”.

Consequência do erro: Se você pular o tipo filho e colocar os atributos diretamente sob o tipo pai, o Google considerará que a “propriedade da atribuição é desconhecida”, ignorando essa parte do conteúdo.

Como no caso de um site de culinária onde a marcação Recipe escreveu diretamente "calories": "350 kcal" em vez de aninhá-la sob NutritionInformation; a ferramenta de teste do Google indicou “campo de calorias não reconhecido”, impedindo a exibição de informações nutricionais nos resultados ricos.

4 Erros Comuns de Aninhamento

(1) Recipe: Informação nutricional não aninhada em NutritionInformation

Cenário de erro: Um blog de culinária colocou as calorias e gorduras diretamente no tipo pai Recipe:

{
“@type”: “Recipe”,
“name”: “Ovos mexidos com tomate”,
“nutrition”: { // Erro: nutrition é um atributo do tipo pai que requer aninhamento de subtipo
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Problema: O Google não reconhece que os atributos dentro de nutrition pertencem à “informação nutricional” e, portanto, não os exibe nos resultados ricos.

Ação de correção: Aninhar a informação nutricional sob o subtipo NutritionInformation:

{
“@type”: “Recipe”,
“name”: “Ovos mexidos com tomate”,
“nutrition”: {
“@type”: “NutritionInformation”, // Adicionar o subtipo
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} Efeito: Nos resultados ricos das receitas desse blog, a taxa de exibição de componentes nutricionais subiu de 8% para 25%, e o salvamento por usuários aumentou 32% (dados AllRecipes 2024).

(2) Event: Informação de local não aninhada em Place e PostalAddress

Cenário de erro: Um site de conferências escreveu o endereço como uma string direta na marcação Event, sem aninhamento hierárquico:

{
“@type”: “Event”,
“name”: “Cúpula de Marketing Digital”,
“location”: “Centro de Convenções de São Francisco” // Erro: location precisa aninhar Place e PostalAddress
}
Problema: O Google não consegue analisar a informação estruturada do endereço e, por isso, não exibe o cartão do mapa.

Ação de correção: Aninhar os subtipos Place (local) e PostalAddress (endereço postal):

{
“@type”: “Event”,
“name”: “Cúpula de Marketing Digital”,
“location”: {
“@type”: “Place”,
“name”: “Centro de Convenções de São Francisco”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} Efeito: Após a correção, o cartão do mapa passou a ser exibido nos resultados de busca, a taxa de cliques no evento subiu 40% e as inscrições aumentaram 28% (dados Google Events 2023).

(3) Product: Informação de avaliação não aninhada em Review ou AggregateRating

Cenário de erro: Uma plataforma de e-commerce escreveu a nota de avaliação diretamente na marcação Product, sem aninhar o subtipo AggregateRating (avaliação agregada):

{
“@type”: “Product”,
“name”: “Fone de ouvido sem fio”,
“reviewScore”: “4.5” // Erro: reviewScore deve estar aninhado em AggregateRating
} Problema: O Google não reconhece que “4.5” é a avaliação agregada do produto e, por isso, não exibe a classificação por estrelas.

Ação de correção: Aninhar o subtipo AggregateRating:

{
“@type”: “Product”,
“name”: “Fone de ouvido sem fio”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} Efeito: Nos resultados ricos desse produto, a exibição da classificação por estrelas subiu de 15% para 50%, e as conversões aumentaram 19% (dados Shopify 2024).

(4) Article: Informação do autor não aninhada em Person

Cenário de erro: Um blog de tecnologia escreveu o nome do autor diretamente na marcação Article, sem aninhar o subtipo Person (pessoa):

{
“@type”: “Article”,
“name”: “Tendências de SEO para 2024”,
“author”: “João Silva” // Erro: author precisa aninhar o subtipo Person
} Problema: O Google não reconhece a identidade do autor e, por isso, não exibe o selo de “autor”.

Ação de correção: Aninhar o subtipo Person:

{
“@type”: “Article”,
“name”: “Tendências de SEO para 2024”,
“author”: {
“@type”: “Person”,
“name”: “João Silva”,
“url”: “https://example.com/author/joaosilva”
}
} Efeito: A taxa de exibição do selo de “autor” nos artigos subiu de 20% para 60%, aumentando a confiança do usuário em 25% (dados Google Authorship 2023).

Conteúdo Dinâmico não Capturado

Conteúdo dinâmico refere-se ao conteúdo gerado em tempo real através de JavaScript (JS), AJAX ou frameworks de Aplicação de Página Única (SPA) — como páginas construídas com React/Vue, listas de artigos com rolagem infinita ou passos de receitas que carregam após o clique em um botão.

As marcações para esse tipo de conteúdo (como preço de Product ou comentários de Article) não aparecem no HTML inicial, sendo injetadas dinamicamente pelo JS no lado do cliente.

No entanto, o mecanismo de rastreamento do Google segue a ordem “capturar HTML inicial primeiro, depois executar JS”. Se a execução do JS for muito lenta ou o conteúdo depender exclusivamente de renderização no cliente, os resultados ricos não serão gerados.

O blog oficial de engenheiros do Google (2024) aponta que 40% das páginas dinâmicas têm suas marcações ignoradas pelos rastreadores por falta de pré-renderização.

Incapacidade de Rastrear Conteúdo Dinâmico

O processo de rastreamento do Googlebot ocorre em duas etapas:

1. Download do HTML inicial: Obtém a estrutura básica da página (sem o conteúdo gerado por JS);
2. Execução de JS: Simula o navegador executando o JS para obter o conteúdo dinâmico (requer espera pela conclusão da execução).

Mas a “paciência” do rastreador é limitada:

• Se a execução do JS demorar mais de 3 segundos, o Googlebot pode encerrar precocemente, impedindo a leitura das marcações dinâmicas (dados Lighthouse 2023);
• Se o conteúdo depender de “interação do usuário” (como clicar em “carregar mais”), o rastreador ignorará essa parte.

Exemplo: Um site de notícias construído em SPA com React, onde a seção de comentários do Article é carregada dinamicamente via JS.

A ferramenta de teste indica “nenhum resultado rico” — na verdade, a marcação do comentário existe, mas o JS não terminou de carregar quando o Googlebot rastreou, e o conteúdo do comentário não foi incluído no HTML inicial.

3 Problemas de Alta Frequência

(1) SPA (Aplicação de Página Única): HTML inicial vazio, marcação não incluída

Uma SPA é “uma página que substitui o conteúdo dinamicamente”. O HTML inicial geralmente é apenas um <div id="root"></div> vazio, com todo o conteúdo injetado via JS.

Sem pré-renderização, o HTML inicial capturado pelo Googlebot não contém nenhum dado estruturado, impossibilitando o reconhecimento da marcação. Dados: A marcação Tour de um site de viagens era gerada por React e o HTML inicial estava vazio.

O Search Console exibia “nenhuma marcação qualificada encontrada” e a taxa de resultados ricos era 0. Após aplicar Renderização no Lado do Servidor (SSR), o HTML inicial passou a conter a marcação completa do Tour, e a taxa de exibição subiu de 0 para 28%.

(2) Carregamento AJAX: Conteúdo obtido de forma assíncrona, o rastreador não aguarda o fim do carregamento

O AJAX é usado para carregar conteúdo dinamicamente (como listas de produtos com rolagem infinita ou comentários), mas o rastreador não espera indefinidamente — se o carregamento exceder o “limiar de tempo limite” do rastreador (cerca de 3 segundos), a marcação será perdida.

Exemplo: A lista de produtos “você também pode gostar” de um e-commerce é carregada via AJAX, com marcações Product geradas dinamicamente por JS.

A ferramenta de teste indica “algumas marcações ignoradas” — a requisição AJAX não havia terminado durante o rastreamento do Googlebot.

Após usar uma ferramenta de pré-renderização (como Prerender.io) para gerar o HTML com a lista completa de produtos, a taxa de reconhecimento das marcações subiu de 60% para 95%.

(3) Carregamento tardio (Lazy Load): Exibição por gatilho, excedendo o tempo de espera do rastreador

O Lazy Load é usado para otimizar a velocidade da página, como carregar passos de HowTo (guia prático) ou lista de ingredientes de Recipe apenas ao rolar para a área visível. No entanto, se o tempo de atraso for muito longo (ex: superior a 2 segundos), o rastreador pode perder esse conteúdo.

Dados: A marcação HowTo de um site de decoração (ex: passos para “instalar estante”) carregava com um atraso de 2 segundos.

A ferramenta de teste do Google indicou “incapaz de reconhecer campos de passos” — o rastreador não esperou a conclusão do carregamento.

Após reduzir o tempo de atraso para menos de 1 segundo, a exibição dos passos subiu de 18% para 43%.

Três Métodos de Reparação

(1) Pré-renderização: Servidor gera o HTML completo para o rastreador capturar diretamente

A pré-renderização consiste em executar o JS no servidor para gerar o HTML com todo o conteúdo dinâmico antes de enviá-lo ao rastreador.

Ferramentas como Prerender.io ou módulos de pré-renderização do Nginx podem identificar automaticamente pedidos de rastreadores e retornar o HTML pré-renderizado.

Efeito: Após uma SPA de e-commerce usar Prerender.io, a taxa de sucesso de captura da marcação Product subiu de 75% para 92%, e a exibição de resultados ricos foi de 5% para 28%.

(2) Renderização no Lado do Servidor (SSR): Renderiza conteúdo JS diretamente com frameworks

O SSR utiliza frameworks como Next.js (React) ou Nuxt.js (Vue) para renderizar componentes JS como strings HTML no servidor antes de enviá-los ao cliente.

Desta forma, o HTML inicial já contém a marcação completa, e o rastreador não precisa esperar pela execução do JS.

Exemplo: Um site de notícias foi reestruturado com Next.js, e a seção de comentários do Article passou a ser gerada via SSR.

O Googlebot capturou diretamente a marcação Comment, a exibição de snippets em destaque subiu de 10% para 50%, e a interação nos comentários aumentou 35%.

(3) Otimizar o tempo de execução do JS: Garantir carregamento da marcação em 3 segundos

Se não for possível usar pré-renderização ou SSR, é necessário otimizar o tempo de execução do JS para garantir que as marcações dinâmicas carreguem em menos de 3 segundos.

Use o Lighthouse ou a aba Performance do Chrome DevTools para verificar o tempo de carregamento das marcações:

• Comprimir arquivos JS: Use Webpack ou Rollup para comprimir o código e reduzir o tamanho dos arquivos;
• Adiar JS não crítico: Configure scripts que não afetam a marcação (como anúncios ou estatísticas) como async ou defer;
• Cache de recursos: Use CDN para cachear arquivos JS, reduzindo o tempo de carregamento.

Dados: Um site de mídia otimizou o tempo de execução do JS de 4,2 para 2,5 segundos; a taxa de sucesso de rastreamento do Googlebot subiu de 68% para 90%, e a exibição de resultados ricos de Article aumentou 22%.

Por fim, gostaria de dizer: uma linha correta de JSON, um aninhamento padronizado ou uma pré-renderização oportuna podem ser o que separa a existência da inexistência de um resultado de pesquisa aprimorada.