Um cliente uma vez me enviou um site que tinha sido "otimizado para SEO por uma agência profissional" por 18 meses. Rankings estavam estagnados. Tráfego caiu ano após ano. O relatório da agência tinha 47 páginas e incluía uma seção sobre "alinhamento de voz de marca". O que não incluía era o fato de que 3.400 páginas estavam retornando status codes 200 mas tinham tags noindex embutidas na meta. Três mil e quinhentas páginas. Desaparecidas. Invisíveis. A agência nunca tinha feito o crawl do site.
Ponto-chave: um crawl do Screaming Frog referenciado cruzadamente com dados do Search Console ainda encontra a maioria dos problemas técnicos de SEO em qualquer site; o método importa mais do que ferramentas exóticas.
Arrumei em uma semana. Com Screaming Frog e Google Search Console.
É isso que tem o SEO técnico: ele recompensa quem realmente olha os dados em vez de falar sobre eles. E honestamente, para 90% dos sites que audito através da Seahawk, não preciso de Ahrefs, Semrush ou nenhuma das grandes plataformas para encontrar os problemas que estão genuinamente prejudicando a performance. Duas ferramentas. Um processo. Aqui está.
---
Antes de Fazer Crawl de Qualquer Coisa, Configure Screaming Frog Corretamente
A maioria das pessoas abre o Screaming Frog, cola uma URL e clica em iniciar. Tudo bem para um blog com 50 páginas. Para qualquer coisa maior, você fica esperando 40 minutos por um rastreamento que te dá dados errados.
A configuração importa mais do que a velocidade de rastreamento.
Primeiro que faço: vou para Configuration > Spider e me certifico de que estou fazendo crawl do protocolo correto. Se o site está em HTTPS (como deveria estar), começo pelo homepage HTTPS canônico. Também desativo o crawl de certos tipos de arquivo, PDFs, imagens, vídeos, a menos que eu especificamente queira auditar aqueles. Isso reduz o tempo de crawl pela metade.
Então defino Configuration > Respect Canonical Tags como desativado. Contra-intuitivo, eu sei. Mas quero ver toda URL canonicalizada para que eu possa auditar se a canonicalização está realmente correta. Se o Screaming Frog pula páginas canonicalizadas, você nunca saberá que elas existem.
Mais uma coisa: em Configuration > Custom Extraction, configuro uma regra de extração para puxar as tags <title> e meta description brutas direto do código-fonte HTML. Por quê? Porque alguns sites WordPress, particularmente aqueles rodando Yoast junto com um page builder, geram duas title tags. A coluna padrão do Screaming Frog só mostra a primeira. A regra de extração mostra tudo.
---
O Primeiro Passo: O Que Procuro nos Dados do Rastreamento
Assim que o rastreamento termina, não começo com links quebrados. Todo mundo começa com links quebrados. Começo com a aba Response Codes e filtro por redirecionamentos 3xx.
Em 2021, a Seahawk pegou um cliente e-commerce, uma varejista de móveis de médio porte, cerca de 8.000 URLs. O time de desenvolvimento deles tinha lidado com redirecionamentos ad hoc por dois anos. Encontramos 19 cadeias de redirecionamento, algumas com até quatro hops. A Página A redirecionava para a Página B, que redirecionava para a Página C, que redirecionava para a Página D. Google diz que segue até 10 hops, mas na prática, qualquer coisa além de dois hops desperdiça crawl budget e dilui link equity. Colapsamos tudo em redirecionamentos de single-hop. Só isso, sem mudanças de conteúdo, sem link building, moveu três páginas de categoria da página 3 para a página 1 em seis semanas.
A ordem em que trabalho através das abas
- Response Codes → 3xx, cadeias e loops de redirecionamento
- Response Codes → 4xx, páginas quebradas (filtrar por inlinks para priorizar)
- Indexability → Non-Indexable, noindex, canonicals apontando para outro lugar, bloqueado por robots.txt
- Page Titles, faltando, duplicadas, acima de 60 caracteres
- Meta Description, faltando ou duplicadas (não é fator de ranking, mas click-through importa)
- H1, ausente, duplicado ou mais de um por página
- Imagens → Alt Text ausente, vitória rápida, especialmente para sites de produtos
- Diretivas → Canônico, verifique se correspondem à URL realmente indexável
Essa ordem é deliberada. Trabalho de problemas estruturais (redirecionamentos, páginas quebradas) até problemas on-page. Corrigir uma cadeia de redirecionamento quebrada ajuda toda página nessa cadeia. Corrigir uma meta description ausente ajuda uma página.
---
Camadas no Search Console: Onde as Coisas Ficam Interessantes
Screaming Frog te diz o que está no site. Search Console te diz o que Google acha que está no site. O vão entre esses dois conjuntos de dados é onde os problemas reais vivem.
Abra Cobertura (ou Indexação → Páginas na interface mais nova). Você está olhando para quatro coisas:
- Erro, páginas que o Google tentou indexar e não conseguiu
- Válido com avisos, frequentemente "URL enviada não selecionada como canônica," o que é uma bagunça que você precisa desembaraçar
- Excluída, páginas que o Google optou por não indexar (rastreadas mas não indexadas, noindexadas, etc.)
- Válido, páginas que o Google indexou
O bucket "Excluída" é criminosamente subutilizado. A maioria das pessoas ignora. Eu vou direto lá. Filtre por "Rastreada, atualmente não indexada." Isso é o Google dizendo: encontrei esta página, li, e decidi que não valia a pena indexar. Quase sempre é um problema de conteúdo fino. Ou é uma página genuinamente boa mas muito similar a outra página, um problema clássico com navegação facetada ou arquivos de tags.
Correspondência de exclusões do GSC com seu rastreamento do Screaming Frog
Exporte seu rastreamento do Screaming Frog para CSV. Exporte as URLs "Excluídas" do Search Console. Carregue ambas no Google Sheets e execute um VLOOKUP. Qualquer URL que apareça no rastreamento do Screaming Frog e na lista de excluídas do GSC é uma investigação prioritária.
Sei que as pessoas recorrem a scripts Python para isso. Você não precisa. VLOOKUP no Sheets leva quatro minutos e te dá a mesma resposta.
---
Crawl Budget: Só Importa Se Seu Site For Realmente Grande
Certo, vamos ser honestos. Se seu site tem menos de 1.000 páginas, crawl budget não é seu problema. Você pode parar de se preocupar com isso.
Mas uma vez que você ultrapassa cerca de 10.000 URLs, e muitas lojas WooCommerce ou Magento atingem isso só a partir de variantes de produtos e URLs filtradas, o crawl budget começa a fazer efeito. A documentação do Google Search Central sobre crawl budget é na verdade uma das coisas mais claras que eles escreveram. Vale a pena ler com atenção.
Os dois mecanismos que você tem no Search Console são o relatório Crawl Stats e a ferramenta URL Inspection. Crawl Stats mostra a atividade de crawl do Google em 90 dias: páginas rastreadas por dia, tempos de resposta, códigos de resposta. Se você vê um pico de 404s em uma data específica, é um deployment que deu errado. Se o tempo médio de crawl está acima de 2 segundos, o problema é seu servidor, não seu SEO.
---
Link Interno: A Coisa Que Agências Sempre Perdem
Já fiz auditoria em bem mais de cem sites na Seahawk onde o cliente estava gastando dinheiro de verdade em link building, guest posts, digital PR, tudo isso, e tinha páginas órfãs que nenhum link interno apontava para. O Google não consegue priorizar o que não consegue encontrar através da sua estrutura de site.
No Screaming Frog, filtre o crawl por Inlinks = 0. Qualquer página com zero links internos é uma órfã. Cruze os dados com as páginas indexadas do Search Console. Se a página está indexada mas não tem links internos, significa que Google a encontrou através de um XML sitemap ou de um backlink externo. Isso é frágil. Dê um link interno a ela a partir de uma página relevante e você está dando ao Google um sinal estrutural de que essa página importa.
Algumas coisas que observo em links internos
- Páginas de paginação que linkam para páginas de produto/artigo, mas essas páginas não linkam de volta para páginas de categoria
- Posts de blog publicados em 2019 que nunca foram linkados a partir de nenhum conteúdo mais recente
- Páginas com dezenas de links internos apontando para elas, mas tráfego muito baixo no GSC, frequentemente um sinal de que a página em si tem um problema, não o link.
---
Core Web Vitals: Leia os Dados, Não Entre em Pânico
O Search Console tem um relatório de Core Web Vitals. Ele puxa dados do Chrome UX Report de usuários reais, que são dados de campo, usuários reais em dispositivos reais, não uma simulação em laboratório. Isso é mais significativo do que o que você teria de uma execução única do Lighthouse.
O relatório agrupa URLs em "Bom," "Precisa melhorar" e "Ruim" por LCP, FID (agora substituído por INP) e CLS. Não tente corrigir tudo de uma vez. Ordene pelo grupo "Ruim" e veja qual padrão de URL tem mais páginas falhando. Geralmente é um único template, todas as páginas de produto falhando em CLS, ou todas as páginas de categoria com LCP lento. Corrija o template, corrija centenas de páginas de uma vez.
Uma coisa que aprendi da maneira difícil: problemas de CLS em sites com anúncios ou banners de cookies quase sempre vêm de elementos sendo injetados acima da dobra após o paint inicial. Screaming Frog não vai pegar isso. Você precisa olhar a página de verdade. Use Chrome DevTools com Layout Shift regions habilitado em Rendering.
---
A Verificação do Robots.txt e Sitemap (Leva 10 Minutos, Economiza Semanas)
Acesse yourdomain.com/robots.txt . Leia cada linha. Já vi, com meus próprios olhos, um site de produção ao vivo com Disallow: / no robots.txt. Não um site de staging. Produção. Uma empresa com sete anos de existência. Seu desenvolvedor tinha copiado o robots.txt de staging durante uma migração e nunca verificou. Eles tinham sido essencialmente invisíveis para o Google por quatro meses antes de notarem.
No Search Console, vá para Sitemaps. Verifique o que foi enviado. Verifique a última vez que o Google buscou. Se o sitemap não foi buscado em mais de uma semana, algo está quebrado. Também verifique a contagem de URLs enviados versus a contagem de URLs indexados, se você enviou 4.000 URLs e apenas 1.200 foram indexados, essa é uma conversa que você precisa ter sobre qualidade de conteúdo, não sobre correções técnicas.
---
FAQ
Preciso da versão paga do Screaming Frog?
A versão gratuita tem limite de 500 URLs. Para qualquer coisa acima disso, que é a maioria dos sites que vale a pena auditar, você precisa da licença paga. É £259 por ano no momento desta escrita. Está no preço de uma única hora de tempo de agência. Compre.
Com que frequência devo executar uma auditoria técnica?
Para sites ativos que publicam regularmente ou mudam produtos frequentemente, eu diria trimestralmente. Para sites menores e mais estáticos, duas vezes por ano é adequado. Executar uma auditoria uma vez e tratá-la como "pronta" é como trocar o óleo de um carro uma vez e esperar que ele funcione para sempre.
Screaming Frog mostra status 200 mas GSC mostra que a página não está indexada, por quê?
Quase sempre uma de três coisas: uma tag meta noindex, um header HTTP noindex, ou uma tag canonical apontando para outro lugar. Passe a URL pela ferramenta Inspeção de URL do Search Console e ela vai te dizer exatamente o que encontrou. Essa ferramenta é subestimada, ela mostra a versão da página que o Google rastreou pela última vez, incluindo o HTML renderizado, o que captura tags noindex injetadas por JavaScript que uma requisição HTTP básica não detectaria.
E quanto aos sites renderizados em JavaScript?
Screaming Frog tem um modo de renderização JavaScript em Configuration > Spider > Rendering. Ative para sites pesados em JavaScript. É mais lento, significativamente mais lento, mas é a única forma de capturar problemas com conteúdo ou links que são injetados por JavaScript após o carregamento do HTML inicial. Para um site React ou Next.js, sempre rasteje em modo de renderização JS.
Google Search Console é suficiente para pesquisa de palavras-chave?
Para descobrir quais queries suas páginas existentes ocupam posição, sim, é excelente. Para descobrir novas oportunidades de keywords, não, você vai precisar de outra coisa. Mas isso está fora do escopo de uma auditoria técnica.
---
Duas ferramentas. Uma planilha. Algumas horas. É genuinamente tudo o que isso leva. As plataformas caras têm seu lugar, não sou contra elas, mas vi muitos donos de site assumirem que pagar mais significa encontrar mais. Os problemas quase sempre estão no básico. Eles só precisam de alguém que realmente olhe.