Auditoria técnica de base

Fase P2 · Etapa A — Compreender
Timebox: 2–4 horas para uma passagem leve, 1–2 dias úteis para uma passagem padrão, ou 3–8 dias úteis para uma passagem profunda.
Responsável: o líder técnico de SEO. Os responsáveis de engenharia, análise, conteúdo e localização contribuem com evidências e aceitam correções em suas áreas.

Uma auditoria técnica de base estabelece se os mecanismos de busca conseguem alcançar, interpretar e selecionar as URLs que a empresa espera que eles mostrem. Seu escopo cobre controles de rastreio, respostas HTTP, indexação, canônicos, links, renderização, segmentação internacional e entrega segura. O resultado é um registro priorizado de achados com responsáveis nomeados e testes de aceitação, não uma pontuação.

Por que esta fase vem aqui

Publicar em um site com problemas de rastreio ou indexação agrava o dano. Os mecanismos de busca frequentemente descobrem um defeito repetido em novas URLs mais rápido do que avaliam e recompensam o conteúdo. Um modelo canônico quebrado pode apontar cada artigo para outro lugar; uma regra de robots pode esconder um diretório; uma navegação renderizada no cliente pode criar órfãos para um cliente que não executa JavaScript. Cada nova página amplia o conjunto afetado e torna o reparo mais arriscado.

Conserte a fundação primeiro. A ordem é rastreabilidade → indexabilidade → qualidade do conteúdo → desempenho porque cada camada é um portal. Rastreabilidade significa que um rastreador pode descobrir e solicitar uma URL; indexabilidade significa que a URL alcançável é elegível para inclusão. Só então a qualidade do conteúdo e o desempenho devem ser julgados. Uma página rápida bloqueada por robots.txt não pode competir, e tags de título não importam em páginas inalcançáveis.

Esta fase consome o escopo, jornadas prioritárias, mercados e riscos de Descoberta e objetivos . Executá-la mais cedo produz um rastreio sem contexto de negócio. Pulá-la permite que pesquisa e produção tenham como alvo modelos que não conseguem entrar no índice de forma confiável.

Entradas e saídas

As entradas definem o site pretendido, não meramente o que um rastreador encontra. As saídas informam ao próximo responsável quais URLs são seguras para testar e quais permanecem bloqueadas.

Escolha a profundidade da auditoria

Selecione a profundidade antes de rastrear. As estimativas pressupõem que o acesso está pronto e excluem a implementação.

A checklist

Trabalhe em ordem. Um portal falho pode invalidar amostras posteriores, portanto registre a falha e seu escopo antes de continuar.

1. Confirme que o alvo é produção

O que fazer: verifique esquema, host, arquivo robots, propriedade de análise, propriedade do Search Console e host do sitemap. Por que é importante: staging pode parecer limpo enquanto a produção permanece quebrada. Como fazer: resolva o host canônico acordado, compare páginas prioritárias e cabeçalhos de resposta, e registre a origem do rastreio. Ferramenta: navegador, configuração do rastreador, seletor do Search Console. Concluído quando: o registro nomeia a origem e propriedade de produção confirmadas, sem nenhum hostname de staging nas sementes ou exportações.

2. Teste robots.txt antes de rastrear

O que fazer: inspecione o /robots.txt de cada host de produção e os sitemaps referenciados. Por que é importante: uma regra de desautorização impede o rastreio antes que o conteúdo possa ser avaliado. Como fazer: compare padrões Disallow com o inventário pretendido, teste URLs correspondentes e não correspondentes, e distinga um bloqueio de rastreio de noindex. Ferramenta: resposta bruta e testador de robots. Concluído quando: robots retorna 200, os bloqueios pretendidos têm razões, as amostras indexáveis são permitidas e um bloqueio não intencional gera um achado crítico.

3. Reconciliar sitemaps com URLs reais

O que fazer: compare os sitemaps enviados com o inventário canônico e indexável. Por que é importante: um sitemap deve nomear URLs que o site deseja selecionar, não redirecionamentos, erros ou duplicatas. Como fazer: normalize entradas, compare contagens por modelo e depois amostre adições e omissões em Sitemaps e Indexação . Ferramenta: https://app.amicited.com/reports/google-search/sitemaps-indexing e exportações de rastreio. Concluído quando: a cobertura é de pelo menos 95%, 0 entradas redirecionam ou geram erro, e cada lacuna tem uma razão ou responsável.

4. Meça a distribuição de código de status

O que fazer: classifique as respostas como 2xx, 3xx, 4xx ou 5xx. Por que é importante: erros interrompem a recuperação e redirecionamentos adicionam saltos. Como fazer: siga e reporte redirecionamentos, segmente por modelo e compare com Rastreio Bing . Ferramenta: https://app.amicited.com/reports/bing-webmasters/crawl, rastreador e monitoramento. Concluído quando: URLs indexáveis retornam 200; erros internos, loops e cadeias são zero; e redirecionamentos intencionais estão documentados.

5. Remova cadeias e loops de redirecionamento

O que fazer: rastreie redirecionamentos até sua resposta final. Por que é importante: saltos atrasam a descoberta; um loop nunca alcança o conteúdo. Como fazer: exporte caminhos, atualize links internos para canônicos finais e consolide regras. Ferramenta: relatório de redirecionamentos e verificações de cabeçalho. Concluído quando: links internos vão direto, redirecionamentos legados levam um salto e nenhum loop ou cadeia permanece.

6. Estabeleça a proporção de indexação elegível

O que fazer: compare o estado do índice do Google com URLs deliberadamente elegíveis. Por que é importante: incluir redirecionamentos, filtros, duplicatas ou páginas noindex torna a proporção sem sentido. Como fazer: construa o denominador elegível, inspecione amostras prioritárias em Inspeção de URL , e agrupe exclusões por modelo. Ferramenta: https://app.amicited.com/reports/google-search/url-inspection, Search Console e inventário. Concluído quando: pelo menos 90% estão indexados ou cada lacuna tem um responsável pela causa raiz; abaixo de 80% é um achado importante.

7. Verifique a corretude canônica

O que fazer: compare canônicos declarados, finais e selecionados pelo Google. Um canônico é a versão preferida entre URLs similares. Por que é importante: um canônico errado consolida sinais para longe da página pretendida. Como fazer: teste autorreferências de páginas únicas, canônicos cruzados deliberados e consistência entre HTML, sitemaps, redirecionamentos e links. Ferramenta: relatório canônico e https://app.amicited.com/reports/google-search/url-inspection. Concluído quando: 100% das páginas indexáveis únicas nomeiam um canônico absoluto, 200, indexável, com cada incompatibilidade selecionada explicada.

8. Encontre clusters duplicados e quase duplicados

O que fazer: agrupe URLs com conteúdo principal idêntico ou substancialmente sobreposto e o mesmo propósito de busca. Por que é importante: duplicatas dividem sinais internos e forçam os mecanismos de busca a escolher uma versão que a empresa pode não preferir. Como fazer: compare hashes exatos, similaridade de texto normalizada, títulos, canônicos, parâmetros e propósito do modelo; depois escolha consolidação, diferenciação, noindex ou remoção. Ferramenta: relatórios de duplicatas do rastreador, inventário de páginas e Páginas do Google Search . Concluído quando: nenhum cluster contém mais de uma URL canônica indexável não explicada servindo ao mesmo propósito, e cada variante aceita tem um propósito distinto registrado.

9. Encontre órfãos e meça a profundidade dos links

O que fazer: combine URLs do rastreador com sitemaps, análises, Search Console, exportações do CMS e backlinks para encontrar páginas sem link interno rastreável. Meça o caminho de clique mais curto a partir da página inicial. Por que é importante: um órfão pode aparecer em um sitemap mas receber pouco contexto ou autoridade interna; profundidade excessiva torna a descoberta frágil. Como fazer: compare fontes, inspecione padrões de diretório em Visualização por Diretório , e rastreie navegação, breadcrumbs, hubs e links contextuais. Ferramenta: https://app.amicited.com/reports/directory e um rastreio de múltiplas fontes. Concluído quando: a quantidade de órfãos pretendidos é zero, páginas prioritárias estão a até três cliques da página inicial, outras páginas indexáveis pretendidas estão a até cinco, e cada exceção tem uma rota de descoberta deliberada.

10. Compare HTML renderizado e sem JavaScript

O que fazer: compare a resposta inicial do servidor com a página após a execução do JavaScript. Por que é importante: um navegador pode exibir conteúdo e links que um cliente sem JavaScript nunca recebe. Como fazer: busque páginas representativas com scripts desabilitados, inspecione o HTML bruto, depois compare títulos, texto principal, links, canônico, diretivas de robots, dados estruturados e status após a renderização. Ferramenta: rastreador em modos HTML e renderizado, além de ferramentas de desenvolvedor do navegador. Concluído quando: a resposta inicial contém o conteúdo principal, canônico, diretivas de indexação e navegação rastreável necessários para descobrir páginas prioritárias; qualquer dependência exclusiva de JavaScript é explicitamente aceita e testada em todos os modelos.

11. Valide hreflang quando aplicável

O que fazer: verifique as anotações que conectam equivalentes de idioma ou região. Por que é importante: clusters incompletos ou conflitantes podem fazer os mecanismos de busca ignorarem a segmentação e mostrarem a versão de mercado errada. Como fazer: teste códigos de idioma-região válidos, URLs canônicas absolutas, autorreferências, links de retorno recíprocos, x-default onde ele tem um papel de fallback real, e a indexabilidade de cada alvo. Ferramenta: relatório de hreflang do rastreador e amostras de URL. Concluído quando: códigos inválidos, autorreferências ausentes, retornos ausentes, alvos não canônicos, redirecionamentos e erros são todos zero. Se o site não tiver equivalentes localizados, registre “não aplicável” em vez de inventar anotações.

12. Teste paginação e caminhos de rastreio

O que fazer: verifique se sequências de várias páginas de categoria ou arquivo expõem links rastreáveis e URLs úteis únicas. Por que é importante: rolagem infinita ou carregamento apenas por botão pode esconder itens mais profundos, enquanto canonizar cada página para a página um pode remover inventário distinto da descoberta. Como fazer: desabilite JavaScript, siga links “próximo” e numerados, inspecione status, diretivas canônicas e de robots, e teste a última página e parâmetros fora do intervalo. Ferramenta: rastreio não renderizado e navegador. Concluído quando: cada item pretendido é alcançável através de links âncora, cada página útil se autocanoniza, números de página inválidos retornam um erro apropriado em vez de um 200 suave, e nenhuma sequência cria um espaço de URL ilimitado.

13. Verifique paridade móvel

O que fazer: compare a entrega móvel e desktop quanto a conteúdo, links, metadados, diretivas, dados estruturados e status de resposta. Por que é importante: o Google avalia principalmente a representação móvel; esconder conteúdo ou links significativos apenas no móvel altera o que ele pode entender. Como fazer: rastreie com user agents de desktop e smartphone e compare modelos representativos, não apenas capturas de tela visuais. Ferramenta: rastreios pareados, inspeção de URL móvel e modo responsivo do navegador. Concluído quando: todo o conteúdo indexável e links rastreáveis necessários para significado e descoberta são equivalentes, com zero bloqueios exclusivos para móvel, diferenças canônicas ou respostas de erro.

14. Reforce HTTPS e remova conteúdo misto

O que fazer: verifique a entrega segura, redirecionamentos de host, certificados, esquema canônico, URLs internas e recursos carregados via HTTP. Conteúdo misto significa que uma página HTTPS solicita um recurso inseguro. Por que é importante: solicitações inseguras podem ser bloqueadas, expor usuários e criar sinais de URL inconsistentes. Como fazer: rastreie todas as variantes HTTP, inspecione a cobertura de certificados e erros de segurança do navegador, e pesquise solicitações de recursos renderizados. Ferramenta: rastreador, painel de segurança do navegador e configuração do servidor. Concluído quando: toda página HTTP redireciona uma vez para sua URL HTTPS correspondente, todos os canônicos e links internos usam HTTPS, certificados são válidos para cada host ativo, e solicitações de conteúdo misto ativo ou passivo são zero.

Ferramentas no AmICited

Use os relatórios do produto como evidência para a checklist, não como substituto de um rastreio.

• Sitemaps e Indexação em https://app.amicited.com/reports/google-search/sitemaps-indexing mostra o estado dos sitemaps enviados, avisos, erros e ações de indexação.
• Inspeção de URL em https://app.amicited.com/reports/google-search/url-inspection fornece o veredito ao vivo do Google para URLs amostradas e o canônico selecionado.
• Rastreio Bing em https://app.amicited.com/reports/bing-webmasters/crawl expõe a atividade do rastreador do Bing e problemas no nível da URL.
• Páginas do Google Search em https://app.amicited.com/reports/pages ajuda a selecionar páginas de destino de alto valor e separa páginas com visibilidade de páginas ausentes dos dados de busca.
• Visualização por Diretório em https://app.amicited.com/reports/directory revela padrões no nível da seção e apoia investigações de profundidade e órfãos.
• Saúde dos Dados em https://app.amicited.com/features/data-health/ registra se as evidências conectadas são completas o suficiente para apoiar decisões confiantes.

Regras de decisão

Os limiares criam achados; eles não substituem o julgamento. Segmente por modelo e importância do negócio: dez falhas na categoria de checkout podem importar mais do que mil tags de arquivo quebradas.

Priorize com impacto × esforço × confiança. Pontue o impacto de 1 a 5 com base nas URLs elegíveis afetadas e jornadas de negócio. Pontue o esforço de 1 a 5 como um fator de facilidade, onde 5 significa uma mudança pequena e reversível e 1 significa um programa grande e arriscado; registre também a estimativa honesta em horas ou dias. Pontue a confiança como 0,5 para uma hipótese plausível, 0,75 para evidência repetida, ou 1,0 para uma causa raiz reproduzida. O produto fornece um auxílio de ordenação, não uma precisão falsa.

Aplique a sobreposição de dependência: uma correção que desbloqueia outro trabalho supera uma pontuação maior que não o faz. Remover um bloqueio de robots antes do lançamento vem antes de polir tags de título indexadas. No mesmo nível de dependência, trate causas que afetam o modelo inteiro antes dos sintomas.

Entregável: o registro priorizado de achados

Entregue um registro compartilhado, não uma exportação de rastreador. Use uma linha por causa raiz e anexe amostras de URL separadamente.

O registro está completo quando achados críticos e importantes têm responsáveis e estimativas, bloqueadores têm uma sequência, hipóteses estão etiquetadas e a decisão de publicação é explícita.

O que dá errado

Um relatório de 200 itens que ninguém consegue executar

Exportações de rastreador confundem observações com decisões. Agrupe URLs repetidas sob o modelo ou regra que as causa, forneça uma amostra representativa e atribua um responsável. Duzentas URLs quebradas produzidas por um componente de navegação são um achado de causa raiz com escopo mensurável, não duzentas tarefas.

Relatar sintomas em vez de causas

“Página não indexada” é um sintoma. A causa pode ser um canônico não intencional, um modelo órfão, variantes finas de parâmetros, um erro móvel ou um link exclusivo de JavaScript. Um achado não está pronto para priorização até que identifique a causa controlável ou etiquete claramente o próximo teste de diagnóstico.

Auditar staging por acidente

O staging pode ter regras de robots diferentes, autenticação, dados, modelos, flags de funcionalidade e comportamento do host. Registre a origem de produção e a propriedade do Search Console no topo de cada exportação. Se um rastreio precisar ser executado contra staging para garantia de lançamento, rotule-o como uma comparação separada e nunca mescle suas métricas na base de produção.

Também evite contar exclusões deliberadas como perdas, tratar a inclusão em sitemap como prova de indexação, testar apenas a página inicial, ou priorizar apenas pela contagem de URLs. Defina o conjunto elegível, segmente por modelo e retenha evidências de aceitação.

Próxima fase

A próxima fase, Acessibilidade de IA e prontidão para agentes , precisa de uma amostra tecnicamente estável. Entregue o inventário indexável pretendido, URLs representativas limpas para cada modelo prioritário, comparações de HTML bruto e renderizado, evidências de robots e resposta, decisões canônicas, exclusões conhecidas e o registro de achados em aberto.

Não afirme que o site está “tecnicamente saudável”. Indique quais modelos passaram nos portais de rastreio e indexação, quais permanecem bloqueados e se a publicação pode prosseguir. O próximo responsável aceita quando puder testar user agents de IA específicos e extração sem redescobrir defeitos de rastreio de busca não resolvidos.

FAQ

Com que frequência devemos repetir uma auditoria técnica de base?

Execute-a antes de uma migração, reformulação, mudança de domínio ou grande programa de publicação; depois, repita as verificações afetadas após o lançamento. Monitore continuamente e repita uma passagem padrão quando modelos, navegação, renderização ou regras canônicas mudarem.

Qual proporção de indexação um site saudável deve ter?

Para URLs deliberadamente elegíveis, 90% ou mais é a expectativa inicial, 80–90% precisa de explicação e abaixo de 80% é um achado. Exclua redirecionamentos, duplicatas, filtros e páginas intencionais com noindex do denominador.

Podemos publicar conteúdo enquanto correções técnicas estão em andamento?

Apenas quando novas URLs forem rastreáveis, indexáveis, canonizadas, linkadas internamente e não afetadas pelo defeito. Se a descoberta ou seleção estiver bloqueada, pause; novas URLs apenas expandem a correção.

Precisamos de um rastreador se o Search Console estiver conectado?

Sim. O Search Console relata o que o Google observou; um rastreador testa o site atual e revela links, respostas, profundidade, canônicos e duplicatas. Nenhum substitui o outro.

Quem é responsável pelas correções encontradas na auditoria?

O líder de SEO é responsável pelo registro e critérios de aceitação. A engenharia geralmente é responsável por correções de servidor, renderização, redirecionamento, canônico e HTTPS; as equipes de conteúdo podem ser responsáveis por duplicação e links. Cada item precisa de uma pessoa nomeada.