Um cliente me ligou em 2022, um operador de e-commerce sediado no Reino Unido com aproximadamente 14.000 páginas de produtos, furioso porque tinha perdido 34% do tráfego orgânico em seis semanas. Sem penalidade manual. Sem anúncio de algoritmo. Apenas um colapso lento e silencioso. Rodamos um crawl completo com Screaming Frog e encontramos o problema em 90 minutos: a paginação deles estava auto-gerando milhares de URLs quase duplicadas, Google tinha crawleado todas elas em vez das páginas de produtos reais, e o crawl budget deles tinha acabado completamente. Desperdiçado. Todo mês.
Aprendizado principal: Auditar um site de 10.000 páginas não é apenas uma auditoria maior de site pequeno: os modos de falha são orçamento de rastreamento, templates e indexação em escala, e o checklist muda accordingly.
Isso é o problema do SEO em sites grandes. Os problemas não são mais difíceis de entender, eles são apenas catastroficamente maiores em consequência. Uma tag canonical mal configurada em um site de 20 páginas é chato. Em um site de 14.000 páginas, pode silenciosamente estrangular seu índice inteiro.
Este é o checklist de auditoria que uso na Seahawk Media quando um site ultrapassa a marca de 10.000 páginas. Sem ordem particular de importância, porque todo site grande tem sua própria hierarquia de desastres.
---
Comece Com Crawl Budget, Não Keywords
A maioria das pessoas começa uma auditoria de site grande olhando para rankings. Ordem errada. Completamente errada. Rankings são consequência da indexação, e indexação é consequência do crawl budget. Corrija a ordem das operações.
Crawl budget, para quem precisa da versão simples: é o número de URLs que o Googlebot vai crawlear no seu site dentro de um período determinado. A documentação própria do Google sobre crawl budget realmente vale a pena ler aqui, eles são bem específicos sobre o que o desperdiça.
O que está queimando seu budget?
Puxe seus server logs primeiro. Não dados de GSC, server logs reais. Uso GoAccess para análise rápida em arquivos de log grandes porque consegue lidar com volume sem reclamar. O que você está procurando:
- URLs de navegação facetada (ex: /shoes?colour=red&size=10&sort=price)
- Session IDs adicionados às URLs
- Implementações de infinite scroll ou "load more" gerando strings de parâmetros únicos
- URLs de paginação duplicadas (/page/1 e /) sendo rastreadas ambas
- Páginas de resultados de busca interna que não estão bloqueadas
Qualquer site acima de 10.000 páginas com uma navegação facetada ativa está quase com certeza desperdiçando crawl budget. Quase com certeza. O fix não é glamouroso, é um disallow em robots.txt nos padrões de parâmetros, ou idealmente, manipulação adequada de parâmetros de URL via GSC combinada com tags canonical nas próprias páginas facetadas.
No início de 2021, Seahawk tinha um cliente varejista de móveis com 23.000 URLs de produtos. Parecia bom na superfície. Mas a análise de log mostrou o Googlebot gastando 61% de suas visitas de rastreamento em combinações de filtros facetados que tinham zero demanda de busca e zero conteúdo único. As páginas de produtos reais estavam sendo rastreadas aproximadamente uma vez a cada 14 dias. Mudamos os parâmetros de faceta para noindex, follow e desabilitamos os padrões combinatórios pesados em robots.txt. Em seis semanas, a frequência média de rastreamento em páginas de produtos reais caiu para a cada 3-4 dias.
---
Auditoria de Indexação: O Que Realmente Está no Índice do Google?
site:yourdomain.com no Google te dá uma cifra aproximada. Não dependa dela para precisão, mas é uma verificação rápida de sanidade. Faça referência cruzada com o relatório Index Coverage do GSC.
O gap entre "páginas que você quer indexadas" e "páginas que o Google indexou" é onde está o dinheiro. Em sites grandes, esse gap tende a ser enorme e totalmente prevenível.
Os quatro estados que você se importa
- Indexado, sem problemas, ok, deixe assim
- Excluído: noindex, intencional? Confirme que é
- Excluído: rastreado, não indexado no momento, este é o que deveria soar o alarme
- Excluído: descoberto, não rastreado, problema de orçamento de rastreamento, volte à seção um
"Rastreado, atualmente não indexado" é o jeito que Google tem de dizer: cheguei aqui, olhei em volta, e decidi que não vale a pena. Isso normalmente significa conteúdo fino, conteúdo quase duplicado, ou um sinal de qualidade tão fraco que Google está fazendo uma escolha ativa de pular. Em páginas de produtos, isso acontece frequentemente com descrições geradas automaticamente que são três frases de texto padrão. Google já viu mil versões de "Este produto está disponível em várias cores e é entregue em 3-5 dias úteis." Ele não quer mais uma.
---
Canonical Tags em Escala
Canonicals é onde vejo os danos mais espetaculares auto-infligidos em sites grandes. Não porque sejam complicados, não são, mas porque em 10.000+ páginas, um único erro de template se propaga instantaneamente por milhares de URLs.
Os dois problemas que vejo constantemente:
Canonicals autoreferenciadores que na verdade não apontam para o lugar certo. Exemplo clássico: uma página de categoria paginada onde page/2 tem uma canonical apontando para si mesma em vez de page/1 ou a categoria raiz. Multiplique isso por 400 páginas de categoria com 8 páginas de paginação cada uma e você tem 2 mil+ páginas com sinais canonical quebrados.
Cadeias de canonicals. A Página A canonicaliza para a Página B, que canonicaliza para a Página C. Google segue cadeias de canonicals, mas não é entusiasmado com elas. Três saltos já é exagero. Vi sites com cadeias de cinco saltos construídas ao longo de anos de migrações e redesigns. A aba "Canonical" do Screaming Frog vai mostrar isso diretamente; exporte, filtre por cadeias.
Execute um audit de canonical completo em cada tipo de template separadamente. Páginas de produto. Páginas de categoria. Posts de blog. Arquivos de tag. Páginas de autor. Cada template tem seu próprio modo de falha, e você não vai pegá-los todos em uma amostra aleatória.
---
XML Sitemaps: Mais Importante do Que as Pessoas Pensam
Em 10.000+ páginas, um único arquivo de sitemap começa a ser um problema. O limite do Google é 50.000 URLs ou 50MB por arquivo de sitemap, mas atingir esse limite não é o ponto. O ponto é que um sitemap monolítico com 40.000 URLs é difícil de monitorar e difícil de debugar quando as coisas dão errado.
Divida em partes. Use um arquivo de índice de sitemap apontando para sitemaps segmentados:
- Sitemap de produtos
- Sitemap de categorias
- Sitemap de blog/editorial
- Sitemap de páginas de marca ou fabricante (se aplicável)
Por que a segmentação importa? Porque quando algo quebra, e isso vai acontecer, você consegue isolar o problema. Se Google de repente não está pegando suas novas páginas de produtos, você verifica a data de rastreamento do sitemap de produtos no GSC e debuga a partir daí. Um sitemap monolítico não deixa lugar nenhum para procurar.
Também: só inclua URLs que você realmente quer indexadas no seu sitemap. Isso parece óbvio. Você ficaria surpreso. Já auditei sites onde o sitemap foi auto-gerado por um plugin e incluía páginas de tag, arquivos de autor, páginas de anexo e meia dúzia de outros tipos de URL que tinham noindex neles. Ruído inútil.
Valide seu sitemap com o Rich Results Test do Google se você também está lidando com dados estruturados, e verifique a entrega do sitemap bruto em um navegador para confirmar que seu servidor está retornando um 200, não uma cadeia de 301 ou, que Deus nos guarde, um 404.
---
Linkagem Interna em Escala: O Subestimado
PageRank ainda é real. Ele flui através de links internos. Em um site grande, a arquitetura da sua linkagem interna efetivamente decide quais páginas têm autoridade e quais são órfãs morrendo silenciosamente num canto.
Seahawk tinha um cliente de publicação em 2023, aproximadamente 18.000 artigos entre um vertical de notícias e lifestyle. Suas páginas de categoria de topo de funil estavam recebendo tráfego decente. Mas seu conteúdo arquival mais profundo, material de 2015 a 2019 que ainda tinha demanda de busca genuína, era quase invisível. Não porque o conteúdo fosse ruim. Porque nada mais linkava para ele. Eles havia redesenhado sua navegação de categoria três vezes, e cada vez, o conteúdo mais antigo ficava enterrado mais um nível de profundidade.
O fix foi sem glamour: construímos uma estratégia de linkagem interna programática usando um plugin WordPress customizado que identificava artigos com sobreposição de palavras-chave relevantes e inseria links contextuais. A profundidade de cliques em seu conteúdo de arquivo caiu de uma média de 7.2 cliques da homepage para 3.1. As impressões orgânicas nessas páginas subiram 28% no trimestre seguinte.
Aqui está um checklist rápido de linkagem interna para sites grandes:
- Nenhuma página que você quer indexada deve estar a mais de 3 cliques da homepage
- Páginas órfãs (zero links internos apontando para elas) devem ser tratadas como uma emergência, não um item do backlog
- Navegação de breadcrumb conta como linking interno, certifique-se de que está implementada corretamente e usa texto de âncora real, não apenas "Categoria > Subcategoria" com labels genéricos
- Procure por páginas com apenas um link interno apontando para elas, isso é mal pouco melhor do que órfão
---
Dados Estruturados e Schema em Escala
Se você tem 10.000+ páginas de produto e nenhuma delas tem schema de Product com as propriedades Offer, Review e AggregateRating, você está deixando espaço no SERP na mesa.
Mas dados estruturados em escala também introduzem seus próprios requisitos de auditoria. Um erro de schema em um template significa milhares de instâncias de markup inválido. Verifico dados estruturados com duas ferramentas em combinação: Google's Rich Results Test para amostragem de URLs individuais, e uma extração de schema em nível de crawl no Screaming Frog (Configuration → Custom Extraction → XPath para blocos JSON-LD) para obter uma visão em massa em todos os tipos de página.
O que procurar:
- Propriedades obrigatórias ausentes (especialmente price e priceCurrency em páginas de Produto, essas são omissões comuns)
- Dados estruturados desalinhados (schema diz um nome de produto, a <title> diz outro)
- Tipos de schema desatualizados, DataFeedElement e alguns padrões microdata itemscope mais antigos merecem uma auditoria
- Revise schema que viola as diretrizes de snippet de avaliação do Google, avaliações próprias marcadas como de terceiros, ou pontuações agregadas de amostras pequenas
---
Page Speed em Escala: Não Audite o Que Você Não Pode Corrigir
Core Web Vitals importam. Mas aqui está a coisa que não é dita o suficiente: auditar CWV em 10.000 páginas e tentar corrigir cada URL individual é perda de tempo. Você audita por template, depois corrige por template.
Execute uma amostra de 20-30 URLs por tipo de template através do PageSpeed Insights ou WebPageTest. Se suas páginas de produto têm um LCP médio de 4.8s, esse é um problema no nível do template. A solução está no seu pipeline de entrega de imagens, seu CSS crítico, ou seu tempo de resposta do servidor, não em tocar páginas individuais.
Em grandes sites WordPress especificamente (que é a maior parte do que trabalhamos na Seahawk), os culpados usuais em escala são:
- Imagens de produto WooCommerce não otimizadas servidas sem conversão WebP
- Muitas requisições HTTP de enqueues de plugins mal escopo em páginas que não precisam daqueles scripts
- Tiers de hospedagem que não escalaram com o crescimento do site, um plano que funcionava bem com 2.000 produtos frequentemente desaba com 12.000
Acerte sua hospedagem primeiro. Tudo o mais é decoração.
---
Auditoria de Redirecionamento: O Problema da Dívida Técnica de Migração
Grandes sites acumulam cadeias de redirecionamento do jeito que casas antigas acumulam fiação duvidosa. Cada redesign, cada migração de domínio, cada reestruturação de URL adiciona outra camada. Depois de quatro ou cinco anos, não é incomum encontrar cadeias de redirecionamento com quatro ou cinco saltos de profundidade.
Cada salto custa tempo. Cada salto dilui o sinal de PageRank sendo passado. E alguns 302s muito antigos que eram para ser temporários ainda estão lá causando dano muito permanente.
Meu processo:
- Rastrear com Screaming Frog, exportar todas as respostas 3xx
- Filtrar por cadeias (A → B → C, ou mais longas)
- Atualizar todos os links de origem para apontar diretamente para o destino final
- Confirmar que o destino final é um 200, não outro redirecionamento
- Sinalizar qualquer 302 que deveria ser 301 e fazer com que sejam alterados no nível do servidor
Também verificar: alguma das URLs do seu XML sitemap está retornando redirecionamentos? Porque esse é um comum. Um sitemap deve conter apenas URLs que retornam 200s. Se seu sitemap está cheio de 301s, você está fazendo o trabalho do Google para ele e fazendo mal feito.
---
FAQ
Quanto tempo leva uma auditoria técnica de SEO para um site com 10.000+ páginas?
Honestamente, depende de quão bem instrumentado o site está. Se eles têm GSC configurado adequadamente, logs de servidor acessíveis, e Screaming Frog consegue rastrear sem se auto-limitar, uma auditoria completa leva cerca de 3-5 dias úteis apenas para a fase de coleta e análise de dados. Relatórios são mais 1-2 dias. Qualquer um dizendo que consegue fazer uma auditoria significativa de site grande em uma tarde está amostrando, não auditando.
Preciso auditar cada página ou posso trabalhar com amostras?
Trabalhe a partir de templates, não de páginas individuais. Um site com 12.000 páginas de produto tem talvez 4-6 templates de página significativas. Audite cada tipo de template minuciosamente com uma amostra representativa (mínimo 20-30 URLs), e suas descobertas se aplicarão em todo o template. A exceção é identificação de páginas órfãs e descoberta de cadeias de redirecionamento, essas precisam de cobertura de rastreamento completo, não amostragem.
Qual é o conserto de maior impacto na maioria dos sites grandes?
Crawl budget, nove em cada dez vezes. Especificamente, bloquear ou canonicalizar URLs de navegação facetada que não têm demanda de busca e nenhum conteúdo único. Eu vi esse único fix mexer a agulha mais que qualquer outra mudança em sites de e-commerce com catálogos grandes. É trabalho desagradável, edições de robots.txt, tags canonical, configurações de parâmetros, mas frequentemente produz resultados mais rápidos do que qualquer esforço de conteúdo ou construção de links conseguiria.
Devo usar Screaming Frog ou Sitebulb para sites grandes?
Ambas são boas. Eu uso Screaming Frog para a maioria do meu trabalho de crawl porque conheço seus formatos de exportação de ponta a ponta após anos de uso, e suas opções de extração customizada são excelentes. Sitebulb tem uma camada de visualização genuinamente melhor e seu relatório de auditoria é mais legível para clientes. Para sites com mais de 50.000 páginas, você também pode considerar DeepCrawl (agora Lumar) para crawling baseado em nuvem que não depende da RAM da sua máquina local.
Qual é o problema mais comumente ignorado em auditorias de sites grandes?
Profundidade de linking interno. Todo mundo verifica links quebrados e canonicals. Muito poucas pessoas identificam sistematicamente páginas que estão seis ou sete cliques da homepage e se perguntam por que se espera que elas rankiem por algo competitivo. Profundidade de cliques é um proxy para prioridade de crawl e distribuição de autoridade. Audite isso todas as vezes.
---
SEO em sites grandes não é uma disciplina diferente, são os mesmos princípios em uma escala onde as consequências da negligência se multiplicam rapidamente. A checklist acima não permanecerá estática. Todo site tem seu próprio caos particular. Mas se você trabalhar através de crawl budget, indexação, canonicals, sitemaps, link interno, dados estruturados, velocidade de página e redirecionamentos nessa ordem aproximada, você encontrará 80% do que está quebrado antes de ter olhado para uma única palavra-chave.
Comece com a infraestrutura. Os rankings vêm depois.