Um cliente me ligou em 2022 -- um operador de e-commerce com sede no Reino Unido com aproximadamente 14.000 páginas de produtos -- furioso porque havia perdido 34% do tráfego orgânico em seis semanas. Sem penalidade manual. Sem anúncio de algoritmo. Apenas um colapso lento e silencioso. Fizemos um rastreamento completo com Screaming Frog e encontramos o problema em 90 minutos: a paginação estava gerando automaticamente milhares de URLs quase duplicadas, Google havia rastreado todas elas em vez das páginas de produtos reais, e o orçamento de rastreamento estava completamente esgotado. Desperdiçado. A cada 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.Auditing a 10,000-page site is not a bigger small-site audit: the failure modes are crawl budget, templates, and indexation at scale, and the checklist changes accordingly.
É assim que funciona o SEO de site grande. Os problemas não são mais difíceis de entender -- são apenas catastroficamente maiores em consequência. Uma tag canonical mal configurada em um site de 20 páginas é irritante. 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 cruza a marca de 10.000 páginas. Sem nenhuma ordem particular de importância -- porque cada site grande tem sua própria hierarquia de desastres.Seahawk Media when a site crosses the 10,000-page mark. In no particular order of importance -- because every large site has its own hierarchy of disasters.
---
Comece com Orçamento de Rastreamento -- 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.
Orçamento de rastreamento, para quem precisa da versão simples: é o número de URLs que o Googlebot rastreará no seu site em um determinado período. A documentação do próprio Google sobre orçamento de rastreamento realmente vale a pena ler aqui -- eles são bem específicos sobre o que o desperdiça.Google's own documentation on crawl budget is genuinely worth reading here -- they're quite specific about what wastes it.
O que está queimando seu budget?
Puxe seus server logs primeiro. Não dados de GSC -- actual server logs. Uso GoAccess para análise rápida em arquivos de log grandes porque ele lida com volume sem reclamar. O que você está procurando:GoAccess for quick analysis on large log files because it handles volume without crying. What you're looking for:
- URLs de navegação facetada (ex: /shoes?colour=red&size=10&sort=price)
/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
/page/1and/) both being crawled - Páginas de resultados de busca interna que não estão bloqueadas
Qualquer site com mais de 10.000 páginas com navegação facetada ativa está quase certamente desperdiçando orçamento de rastreamento. Quase certamente. A solução não é glamourosa -- é um disallow de robots.txt nos padrões de parâmetro, ou idealmente, tratamento adequado de parâmetros de URL via GSC combinado com tags canonical nas páginas facetadas.proper URL parameter handling via GSC combined with canonical tags on the faceted pages themselves.
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.noindex, follow and disallowed the heavy combinatorial patterns in robots.txt. Within six weeks, average crawl frequency on real product pages dropped to every 3-4 days.
---
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. in Google gives you a rough figure. Don't rely on it for precision, but it's a quick sanity check. Cross-reference with GSC's Index Coverage report.
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 -- tudo bem, deixa como está -- fine, leave it
- Excluído: noindex -- é intencional? Confirma que é -- intentional? Confirm it is
- Excluído: rastreado, atualmente não indexado -- é este que deveria te alarmar -- this is the one that should alarm you
- Excluído: descoberto, não rastreado -- problema de orçamento de rastreamento, volta à seção um -- crawl budget problem, come back up to section one
"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.I got here, I looked around, and I decided not to bother.That usually means thin content, near-duplicate content, or a quality signal so weak Google is making an active choice to skip it. On product pages, this often happens with auto-generated descriptions that are three sentences of boilerplate. Google has seen a thousand versions of "This product is available in multiple colours and ships within 3-5 working days." It doesn't want another one.
---
Canonical Tags em Escala
Canonicals são onde vejo os danos mais espetaculares que a gente faz em si mesmo em sites grandes. Não porque sejam complicados -- não são -- mas porque a partir de 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.Classic example: a paginated category page where page/2 has a canonical pointing to itself instead of page/1 or the root category. Multiply that by 400 category pages with 8 pages of pagination each and you've got 2,800+ pages with broken canonical signals.
Cadeias de canonicals. A página A faz canonical para página B, que faz canonical para página C. Google segue cadeias de canonicals, mas não é entusiasmado com elas. Três saltos já está no limite. Já 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 direto -- exporte, filtre por cadeias.Page A canonicalises to Page B, which canonicalises to Page C. Google follows canonical chains, but it's not enthusiastic about them. Three hops is already pushing it. I've seen sites with five-hop chains built up over years of migrations and redesigns. Screaming Frog's "Canonical" tab will show you this directly -- export it, filter for chains.
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
A partir de 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 bater nesse 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 segmentação importa? Porque quando algo quebra -- e vai quebrar -- você consegue isolar o problema. Se Google de repente não está pegando suas novas páginas de produtos, você checa a data de rastreamento do sitemap de produtos no GSC e debuga a partir daí. Um sitemap monolítico não te dá lugar nenhum para olhar.
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.only include URLs you actually want indexed in your sitemap.This sounds obvious. You'd be surprised. I've audited sites where the sitemap was auto-generated by a plugin and included tag pages, author archives, attachment pages, and half-a-dozen other URL types that had noindex on them. Pointless noise.
Valide seu sitemap com o Rich Results Test do Google se você também está lidando com dados estruturados -- e verifique a entrega de sitemap bruto em um navegador para confirmar que seu servidor está retornando um 200, não uma cadeia de 301 ou, pelo amor de Deus, um 404.Google's Rich Results Test if you're also dealing with structured data -- and check raw sitemap delivery in a browser to confirm your server is returning a 200, not a 301 chain or, god forbid, a 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.
A Seahawk tinha um cliente de publicações em 2023 -- aproximadamente 18.000 artigos distribuídos em um vertical de notícias e lifestyle. As páginas de categorias do topo do funil recebiam tráfego decente. Mas o conteúdo arquivado mais profundo -- material de 2015 a 2019 que ainda tinha demanda de busca genuína -- era praticamente invisível. Não porque o conteúdo fosse ruim. Porque nada mais apontava para ele. Eles haviam redesenhado a navegação de categorias três vezes, e a cada vez, conteúdo mais antigo ficava enterrado um nível mais fundo.
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.WordPress plugin that identified articles with relevant keyword overlap and inserted contextual links. Click depth on their archival content dropped from an average of 7.2 clicks from the homepage to 3.1. Organic impressions on those pages rose 28% over the following quarter.
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 em breadcrumb conta como link interno -- certifique-se de que está implementada corretamente e usa texto âncora real, não apenas "Categoria > Subcategoria" com rótulos genéricos
- Verifique páginas com apenas um link interno apontando para elas -- isso é mal pouco melhor 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.Product schema with Offer,Review, and AggregateRating properties, you're leaving SERP real estate on the table.
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 Product -- essas são omissões comuns)
priceandpriceCurrencyon Product pages -- these are common omissions) - Dados estruturados desalinhados (schema diz um nome de produto, a <title> diz outro)
<title>says another) - Tipos de schema deprecados -- DataFeedElement e alguns padrões de microdata itemscope mais antigos valem a pena ser auditados
DataFeedElementand some olderitemscopemicrodata patterns are worth auditing out - Revise schema que viola as diretrizes de trecho de avaliações do Google -- avaliações de primeira parte marcadas como terceiros, ou pontuações agregadas de amostras pequenasGoogle's review snippet guidelines -- first-party reviews marked up as third-party, or aggregated scores from tiny sample sizes
---
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. matter. But here's the thing that doesn't get said enough: auditing CWV across 10,000 pages and trying to fix every individual URL is a fool's errand. You audit by template, then fix by template.
Execute uma amostra -- 20-30 URLs por tipo de template -- através do PageSpeed Insights ou WebPageTest. Se suas páginas de produto têm uma LCP média de 4.8s, esse é um problema de nível de 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.WebPageTest. If your product pages have an average LCP of 4.8s, that's a template-level problem. The fix is in your image delivery pipeline, your critical CSS, or your server response time -- not in touching individual pages.
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
- Planos de hosting que não escalaram com o crescimento do site -- um plano que funcionava bem com 2.000 produtos geralmente está se afogando 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 páginas individuais. Um site com 12.000 páginas de produto tem talvez 4-6 templates de página significativos. Audite cada tipo de template minuciosamente com uma amostra representativa (mínimo 20-30 URLs), e seus achados se aplicarão ao template inteiro. 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?
Orçamento de rastreamento, 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. Vi essa correção única mexer mais na agulha do que qualquer outra mudança em sites de e-commerce com catálogos grandes. É trabalho pouco glamoroso -- edições de robots.txt, tags canônicas, 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 faria.
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.DeepCrawl (now Lumar)for cloud-based crawling that doesn't depend on your local machine's RAM.
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 escala onde as consequências da negligência se acumulam rapidamente. O checklist acima não vai ficar estático. Todo site tem seu próprio caos particular. Mas se você trabalhar através de orçamento de rastreamento, indexação, canônicas, sitemaps, linkagem interna, 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.