Auditoria de SEO Técnico: POP B20 para Diagnóstico Completo

Uma estratégia de SEO construída sobre uma infraestrutura técnica frágil é como construir sobre areia. Conteúdo excelente, backlinks de qualidade e palavras-chave bem pesquisadas não compensam falhas técnicas que impedem o Googlebot de rastrear, renderizar e indexar as páginas corretamente.

O Que é uma Auditoria de SEO Técnico e Quais Problemas Ela Diagnostica

Pré-requisitos, Acessos e Ferramentas para Execução da Auditoria Técnica

• Google Search Console: Acesso de Proprietário Delegado para visualizar cobertura, erros de rastreamento e Core Web Vitals;

• Google Analytics 4: Para cruzar dados de comportamento com URLs problemáticas;

• CMS ou FTP: Para consultar e editar diretamente o robots.txt, sitemaps e configurações de servidor;

• Hospedagem ou CDN: Para análise de tempo de resposta do servidor (TTFB) e configurações de cache.

• Screaming Frog SEO Spider: Ferramenta principal de emulação de rastreamento — realiza crawl completo do site e extrai dados estruturais de todas as URLs;

• Google PageSpeed Insights / Lighthouse: Para métricas de Core Web Vitals por URL;

• Semrush Site Audit ou Ahrefs Site Audit: Para análise complementar e monitoramento contínuo automatizado;

• Google Search Console: Para dados primários de cobertura e erros reais detectados pelo Googlebot;

• Extensão SEO Minion ou Detailed SEO Extension: Para inspeção rápida de elementos on-page durante o crawl.

Arquitetura da Auditoria Técnica B20: As 7 Dimensões de Análise

Checklist B20 de Execução da Auditoria de SEO Técnico (Passo a Passo)

Dimensão 1: Rastreabilidade e Controle de Acesso do Googlebot

• Acesse seudominio.com.br/robots.txt e verifique as diretivas de Disallow;

• Confirme que nenhuma seção estratégica do site (páginas de categoria, produto, blog) está bloqueada acidentalmente;

• Verifique se o arquivo indica corretamente a localização do Sitemap:;

• Teste o robots.txt usando a ferramenta de Teste de robots.txt disponível no Google Search Console.

• No Screaming Frog, acesse Reports > Crawl Overview após o rastreamento completo;

• Identifique o volume total de URLs encontradas versus URLs rastreáveis;

• Mapeie as fontes de desperdício de Crawl Budget: páginas de parâmetros de URL, páginas de tag, paginação excessiva, URLs de sessão dinâmica;

• Em sites com mais de 10.000 páginas, exporte o log de servidor e analise quais URLs o Googlebot está visitando com maior frequência — isso revela se o orçamento está sendo usado nas páginas certas.

• Valide o sitemap em seudominio.com.br/sitemap.xml;

• Confirme que o sitemap contém apenas URLs com status 200 — nunca URLs redirecionadas, com noindex ou retornando erro;

• Verifique se o sitemap está atualizado com as publicações mais recentes;

• Verifique se a frequência de atualização e priorização das URLs está condizente com a realidade;

• Para sites grandes, confirme se o sitemap index está corretamente estruturado e se cada sitemap filho contém no máximo 50.000 URLs ou 50MB.

Dimensão 2: Indexabilidade e Cobertura de Índice

• Acesse Indexação > Páginas e exporte todos os grupos de status

• Para cada grupo de Páginas Excluídas, classifique os motivos em:

• ✅ Exclusão intencional (login, carrinho, páginas de obrigado, área restrita);

• 🔴 Exclusão problemática (páginas de conteúdo estratégico sendo excluídas sem intenção).

• Investigue prioritariamente os status:

• "Rastreada, mas não indexada atualmente" — indica que o Google considera o conteúdo de baixo valor;

• "Página duplicada sem canonical selecionado pelo usuário" — indica ausência ou conflito de canonical tags;

• "Excluída por tag 'noindex'" — confirme se é intencional.

• Filtre por Directives > Noindex e exporte todas as URLs com essa diretiva;

• Cruze com a lista de páginas estratégicas — qualquer página importante com noindex é um erro crítico.

• No Screaming Frog, acesse Canonicals e verifique:

• Páginas sem canonical tag (ausência total);

• Páginas com canonical apontando para URL diferente da própria (canonical não autorreferenciado);

• Páginas com canonical apontando para URL com noindex — erro duplo crítico;

• Inconsistência entre canonical declarado no HTML e no HTTP header.

Dimensão 3: Arquitetura de URLs e Gestão de Redirecionamentos HTTP

• Verifique se as URLs seguem o padrão B20: curtas, descritivas, em letras minúsculas, sem caracteres especiais, com hífens como separadores (nunca underscores);

• Identifique URLs com parâmetros desnecessários (ex: ?utm_source=, ?sessionid=) sendo indexadas — devem ser bloqueadas via robots.txt ou canonical;

• Confirme se há consistência de www vs. não-www e HTTP vs. HTTPS em todo o site.

• No Screaming Frog, filtre por Response Codes > 3xx Redirects.

• Identifique e elimine:

• Redirect Chains: Cadeias com 2 ou mais saltos antes do destino final (A→B→C deve virar A→C);

• Redirect Loops: URLs que redirecionam para si mesmas ou criam ciclos infinitos;

• 302 incorretos: Redirecionamentos temporários (302) sendo usados onde deveriam ser permanentes (301).

• Filtre por Response Codes > 4xx e exporte todas as URLs com erro;

• Priorize correção de 404s que possuem backlinks externos apontando para eles (verifique no relatório de Links do GSC ou no Ahrefs);

• Para URLs com tráfego histórico ou backlinks, implemente redirecionamento 301 para a URL mais relevante disponível.

Dimensão 4: Renderização de JavaScript e Compatibilidade com Googlebot

• Determine se o site usa SSR (Server-Side Rendering), SSG (Static Site Generation) ou CSR (Client-Side Rendering);

• Sites em CSR puro (React, Angular, Vue sem SSR) dependem da fila de renderização do Google, que pode levar dias ou semanas — conteúdo crítico pode não ser indexado rapidamente.

• Use a Inspeção de URL no Google Search Console e compare a aba HTML (código bruto recebido) com a aba Captura de tela (página renderizada pelo Googlebot);

• Se o conteúdo visível na captura de tela for diferente do que aparece para o usuário, há problema de renderização.

• Teste URLs críticas na ferramenta Google Rich Results Test para verificar se o conteúdo estruturado está sendo corretamente renderizado e detectado.

Dimensão 5: Performance, Core Web Vitals e Page Experience

• Acesse Experiência > Core Web Vitals e identifique grupos de páginas com status "Ruim".

• As três métricas críticas a monitorar e suas metas:

• Teste as principais tipologias de página (Home, Categoria, Produto/Post, Landing Page) separadamente;

• Documente as oportunidades de melhoria listadas pela ferramenta e classifique por impacto estimado;

• Priorize correções de imagens sem dimensões definidas (causa de CLS), recursos bloqueantes de renderização (causa de LCP alto) e JavaScript excessivo (causa de INP alto).

• Meça o tempo de resposta do servidor usando o PageSpeed Insights ou o WebPageTest;

• TTFB acima de 800ms indica problema de servidor, cache ou CDN que deve ser resolvido antes de qualquer otimização de front-end.

Dimensão 6: Dados Estruturados, Schema Markup e Rich Results

• No Rich Results Test do Google, verifique quais tipos de schema estão implementados no site;

• Confirme se o formato usado é JSON-LD (recomendado pelo Google) e não Microdata ou RDFa (formatos mais antigos e propensos a erros).

• Teste as principais URLs no Google Rich Results Test (search.google.com/test/rich-results).

• Corrija todos os erros listados e avalie os avisos — erros impedem a exibição de Rich Results; avisos reduzem a elegibilidade.

• Mapeie quais tipos de schema seriam elegíveis para o negócio do cliente mas ainda não estão implementados:

• Article / BlogPosting: Para posts de blog e conteúdo editorial;

• FAQPage: Para seções de perguntas frequentes;

• HowTo: Para tutoriais e checklists passo a passo;

• Product: Para páginas de produto em e-commerce;

• LocalBusiness / Organization: Para empresas físicas e agências;

• BreadcrumbList: Para navegação estruturada em trilha de migalhas.

Dimensão 7: Segurança, Protocolo HTTPS e Sinais de Confiança Digital

• Confirme que o certificado SSL está ativo, válido e não está próximo do vencimento;

• Verifique se todas as URLs do site usam HTTPS — conteúdo misto (Mixed Content), onde elementos da página são carregados via HTTP em uma página HTTPS, gera avisos no navegador e penalidades de segurança;

• Confirme que o redirecionamento de HTTP para HTTPS está implementado via 301 em todas as URLs.

• Acesse Segurança e Ações Manuais > Problemas de Segurança no GSC e confirme que não há alertas de malware, conteúdo hackeado ou phishing detectados pelo Google;

• Verifique se o site está livre de penalizações manuais em Segurança e Ações Manuais > Ações Manuais — qualquer item listado aqui exige atenção imediata e processo formal de reconsideração junto ao Google.

Dimensão 8: Canonicalização e Gestão de Conteúdo Duplicado

Tipos de Duplicação e Como Identificar Cada Um

• Variações de protocolo e www: http://exemplo.com, https://exemplo.com, http://www.exemplo.com e https://www.exemplo.com são quatro URLs tecnicamente diferentes para o mesmo conteúdo.

• Barras finais (Trailing Slash): exemplo.com/pagina e exemplo.com/pagina/ são URLs distintas para o Google.

• Parâmetros de URL: exemplo.com/produto?cor=azul e exemplo.com/produto?cor=vermelho podem ter o mesmo conteúdo principal com variações irrelevantes.

• Paginação sem canonical: Páginas de listagem paginadas (/categoria/page/2, /categoria/page/3) sem canonical correto competem entre si.

• Versões de impressão: Páginas com ?print=1 ou /imprimir/ duplicando o conteúdo principal.

• Conteúdo sindicado publicado em outros portais sem canonical apontando para o original.

• Conteúdo de fornecedores replicado em múltiplos e-commerces sem adaptação.

Como Auditar a Canonicalização no Screaming Frog

• Acesse Canonicals > Non-Indexable Canonicals — páginas cujo canonical aponta para uma URL não indexável (erro crítico).

• Acesse Canonicals > Canonical Mismatch — páginas onde o canonical declarado no HTML é diferente do canonical no HTTP header.

• Acesse Canonicals > Missing — páginas sem nenhuma tag canonical implementada.

• Acesse Canonicals > Self Referencing — confirme que todas as páginas que devem ser indexadas possuem canonical autorreferenciado.

Regras de Canonicalização da B20

Dimensão 9: Arquitetura de Navegação, Breadcrumbs e Linkagem Interna

Auditoria da Arquitetura de Navegação e Profundidade de Cliques

• Acesse Reports > Crawl Depth para visualizar a distribuição de URLs por profundidade de clique;

• Identifique páginas estratégicas (produtos, posts de alto tráfego) com profundidade acima de 3 e crie um plano de resgate via links internos.

Implementação e Validação de Breadcrumbs (Trilha de Migalhas)

1. UX e navegação: Permitem ao usuário retornar a níveis superiores da hierarquia sem usar o botão "voltar";

2. Linkagem interna: Cada item do breadcrumb é um link interno que distribui autoridade para páginas de categoria;

3. Rich Results: Com Schema BreadcrumbList implementado, o Google pode exibir a trilha de navegação diretamente na SERP, melhorando o CTR.

• Confirme que os breadcrumbs estão presentes em todas as páginas internas (produtos, posts, categorias);

• Verifique se os links do breadcrumb são links HTML reais (tag <a href="">) e não apenas texto decorativo — o Googlebot precisa seguir esses links;

• Implemente o Schema BreadcrumbList em JSON-LD em todas as páginas com breadcrumb;

• Valide a implementação no Rich Results Test do Google;

• No Screaming Frog, confirme que as URLs referenciadas nos breadcrumbs retornam status 200.

Auditoria de Linkagem Interna e Distribuição de PageRank

• Acesse Reports > Crawl Analysis e visualize o relatório de Inlinks por URL;

• Identifique páginas estratégicas com poucos links internos apontando para elas (menos de 3) e crie um plano de enriquecimento de linkagem;

• Identifique páginas com excesso de links internos saindo delas (Link Equity Leakage) — especialmente páginas de categoria que linkam para centenas de produtos sem priorização.

• No Screaming Frog, acesse All Inlinks de páginas estratégicas e analise os textos âncora usados;

• Âncoras genéricas como "clique aqui", "saiba mais" ou "leia mais" desperdiçam a oportunidade de reforçar a relevância semântica da página de destino;

• A B20 recomenda que âncoras de links internos para páginas estratégicas incluam a palavra-chave principal ou uma variação semântica.

• Acesse Reports > Orphan Pages no Screaming Frog (requer integração com GA4 ou GSC)

• Páginas órfãs são URLs sem nenhum link interno apontando para elas — são invisíveis para o Googlebot exceto via sitemap;

• Toda página estratégica deve ter pelo menos um link interno de uma página de alta autoridade.

Compatibilidade Mobile e Mobile-First Indexing

• Acesse Experiência > Usabilidade em dispositivos móveis e corrija todos os erros listados.

• Os erros mais comuns a identificar e corrigir são:

• Acesse a URL via Inspeção de URL no GSC e compare o HTML renderizado na versão mobile com o conteúdo visível no desktop.

• Todo conteúdo estratégico (texto, links internos, headings, Schema) deve estar presente na versão mobile — conteúdo oculto no mobile mas visível no desktop recebe peso de ranqueamento reduzido.

Auditoria de UX Técnico e Sinais de Comportamento do Usuário

• O Google penaliza sites que exibem pop-ups que cobrem o conteúdo principal imediatamente após o carregamento, especialmente em mobile.

• A B20 recomenda que pop-ups de captação (newsletter, cookies) sejam exibidos apenas após 30 segundos de permanência ou ao detectar intenção de saída (exit intent).

• O CLS (Cumulative Layout Shift) não é apenas uma métrica técnica de Core Web Vitals — é um indicador direto de UX ruim.

• Elementos que "pulam" durante o carregamento (imagens sem dimensões, anúncios carregando dinamicamente, fontes causando FOUT) frustram o usuário e aumentam a taxa de rejeição.

• Audite o CLS usando o PageSpeed Insights e o Web Vitals Chrome Extension em todas as tipologias de página.

• Analise se a navegação principal (menu) é clara, hierárquica e acessível em mobile.

• Verifique se o site possui Search interno funcional — em sites com muitas páginas, a busca interna é tanto um fator de UX quanto uma fonte valiosa de dados sobre intenção do usuário.

• Confirme que páginas de erro 404 possuem design personalizado com links de recuperação para a Home e categorias principais — uma página 404 bem projetada retém o usuário; uma genérica o expulsa.

Priorização de Correções por Impacto e Complexidade Técnica

Dimensão 11: Textualização de Páginas de Categoria e Fichas Técnicas de SKUs

Por Que Páginas de Categoria Precisam de Textualização

• Qual é o tema central da categoria e para qual intenção de busca ela é relevante;

• Quais entidades e atributos caracterizam os produtos daquela categoria;

• Por que aquele domínio tem autoridade para ranquear aquela categoria específica.

• A introdução menciona a palavra-chave principal no primeiro parágrafo;

• O texto usa variações semânticas e termos LSI relacionados à categoria (não repete a mesma palavra-chave mecanicamente);

• O conteúdo orienta genuinamente o usuário na decisão de compra — não é texto genérico que poderia ser colado em qualquer categoria;

• Não há conteúdo duplicado entre categorias irmãs (Ex: o texto de "Tênis Masculino" não pode ser uma variação mínima do texto de "Tênis Feminino");

• O texto inclui dados concretos quando disponíveis: número de produtos na categoria, marcas disponíveis, faixa de preço, atributos mais buscados.

Textualização de Subcategorias e Navegação Facetada

• O H1 da subcategoria deve ser mais específico que o da categoria pai (Ex: Categoria: "Tênis de Corrida" → Subcategoria: "Tênis de Corrida para Asfalto Masculino").

• O texto da subcategoria deve cobrir atributos mais específicos que o da categoria pai, sem repetir os mesmos parágrafos.

• Páginas de navegação facetada (filtros de cor, tamanho, marca) devem ter canonical apontando para a URL raiz da categoria — nunca devem ser indexadas com conteúdo duplicado da categoria principal.

Ficha Técnica de SKUs: Estrutura de Conteúdo para Páginas de Produto

• O Title Tag deve seguir o padrão: [Nome do Produto] + [Atributo Diferenciador] + [Marca] | [Nome da Loja].

• Exemplo: "Tênis de Corrida Nike Air Zoom Pegasus 41 Masculino Azul | Loja XYZ".

• O H1 pode ser ligeiramente diferente do Title Tag, mas deve conter a palavra-chave principal do produto.

• Nunca use apenas o código do SKU (Ex: "Produto REF-4521") como H1 — é invisível para buscas orgânicas.

• 2 a 3 frases posicionadas próximas ao botão de compra.

• Deve responder imediatamente: O que é, para quem serve e qual é o principal benefício.

• Exemplo: "O Nike Air Zoom Pegasus 41 é o tênis de corrida mais versátil da Nike, ideal para treinos diários em asfalto com pisada neutra ou supinada. Amortecimento reativo e cabedal em mesh respirável para corridas de 5 a 21km.".

• 150 a 300 palavras de conteúdo original — nunca copie a descrição do fornecedor ou fabricante.

• Cobre: história ou contexto do produto, tecnologias exclusivas, casos de uso recomendados, público ideal.

• Inclui naturalmente as palavras-chave LSI mapeadas para aquele produto (Ex: para um tênis: "amortecimento", "pisada", "drop", "cabedal", "entressola").

• Diferencia genuinamente o produto de variantes próximas no catálogo.

• Todas as imagens devem ter alt text descritivo e único por imagem (Ex: alt="Tênis Nike Air Zoom Pegasus 41 masculino azul lateral direita").

• Nunca use alt text genérico como alt="produto" ou alt="imagem1".

• Implemente imagens em formato WebP para reduzir peso sem perda de qualidade (impacto direto em LCP).

• Vídeos de produto devem ter transcrição ou descrição textual para que o conteúdo seja indexável.

• Reviews de clientes são conteúdo fresco e único gerado continuamente — impactam positivamente a relevância semântica da página ao longo do tempo.

• Implemente Schema Review e AggregateRating para elegibilidade às estrelas de avaliação na SERP (aumentam CTR em até 35%).

• Exiba o número total de avaliações próximo ao H1 para reforçar os sinais de EEAT (prova social como indicador de autoridade)

• A seção de produtos relacionados deve linkar para SKUs genuinamente complementares ou alternativos — não apenas os mais populares do catálogo.

• Use âncoras descritivas nos links (Ex: "Ver também: Tênis de Trail Running Nike Wildhorse 8") em vez de texto genérico.

• Linke o SKU de volta para sua categoria pai e subcategoria via breadcrumb e links editoriais na descrição.

Checklist Final de Qualidade para Ficha Técnica de SKU

• Title Tag único, com palavra-chave + atributo + marca + loja;

• H1 diferente do Title Tag mas com a palavra-chave principal;

• Descrição curta original acima do botão de compra;

• Descrição longa com mínimo de 150 palavras originais (não copiadas do fornecedor);

• Ficha técnica completa em formato HTML com todos os atributos preenchidos;

• Alt text único e descritivo em todas as imagens;

• Schema Product implementado em JSON-LD com brand, color, size e AggregateRating;

• Breadcrumb presente e funcional com Schema BreadcrumbList;

• URL amigável com nome do produto (sem códigos de referência ou parâmetros);

• Canonical autorreferenciado na versão principal do SKU;

• Variações de cor/tamanho com canonical apontando para o SKU principal (quando aplicável);

• Seção de reviews ativa com Schema de avaliação implementado;

• Links internos para categoria pai e produtos relacionados com âncoras descritivas.

Boas Práticas da B20 para Auditorias Técnicas em Projetos Complexos

• Nunca audite apenas a Home: A maioria dos problemas técnicos críticos está nas páginas internas — categorias, produtos e posts. A Home costuma ser a página mais cuidada e menos representativa da saúde real do site.

• Documente o estado antes de qualquer correção: Sempre registre screenshots, exportações do Screaming Frog e dados do GSC antes de iniciar as correções. Isso cria um baseline comparativo para medir o impacto das mudanças.

• Valide cada correção individualmente: Após corrigir um problema técnico, use a Inspeção de URL no GSC para solicitar reindexação e confirmar que a correção foi implementada corretamente antes de avançar para o próximo item.

• Envolva o time de desenvolvimento desde o início: Apresente os resultados da auditoria para o time de dev antes de qualquer reunião com o cliente. Problemas técnicos que o analista de SEO não sabe se são corrigíveis em dias ou meses não devem ser comprometidos com o cliente sem validação técnica prévia.

• Repita a auditoria a cada 90 dias: A infraestrutura técnica de um site muda constantemente — atualizações de CMS, novos plugins, mudanças de design e migrações de servidor podem introduzir novos problemas a qualquer momento.

Perguntas Frequentes (FAQ) sobre Auditoria de SEO Técnico

• Sites institucionais e blogs: Auditoria completa a cada 6 meses, com monitoramento contínuo via GSC.

• E-commerces e SaaS: Auditoria completa a cada 3 meses, pois a natureza dinâmica dessas plataformas (novos SKUs, filtros, promoções) introduz problemas técnicos com muito mais frequência.

• Pós-migração ou redesign: Auditoria imediata nas primeiras 48 horas após o Go-Live, independentemente do ciclo regular.