Gary Illyes revela arquitetura de crawling do Googlebot com limites de 2 MB para páginas e 64 MB para PDFs, enquanto dados mostram que homepage mobile mediana triplicou de tamanho em uma década
Google publicou detalhamento técnico sobre os limites de bytes do Googlebot e a arquitetura de crawling da plataforma. Gary Illyes, analista do Google Search, explicou os limiares em post no blog oficial e no episódio 105 do podcast Search Off the Record.
O Googlebot opera com limite de 2 MB para páginas padrão, incluindo cabeçalhos HTTP. Conteúdo que excede esse limiar é truncado e enviado aos sistemas de indexação como se fosse completo, sem que o restante seja buscado ou processado.
Em paralelo, dados do Web Almanac 2025 revelam que a mediana de peso de homepages mobile cresceu de 845 KB em 2015 para 2.362 KB em julho de 2025. O aumento de aproximadamente três vezes em uma década torna os limites de crawling relevantes para um número crescente de sites.
Googlebot aplica limite de 2 MB para páginas e 64 MB para PDFs
A arquitetura de crawling do Google opera como plataforma centralizada utilizada por múltiplos produtos. O Googlebot, Google Shopping e AdSense compartilham a mesma infraestrutura, mas cada cliente configura seus próprios limites, tokens de robots.txt e identificadores de agente.
Para páginas padrão, o limite é de 2 MB. Arquivos PDF recebem limiar mais alto, de 64 MB. O limite padrão para crawlers não especificados é de 15 MB. Os cabeçalhos HTTP são contabilizados dentro do limite de 2 MB da página.
Gary Illyes ressaltou que “o limite de 2 MB não é fixo e pode mudar com o tempo”, indicando que o Google ajusta esses parâmetros conforme a evolução da web. No entanto, a recomendação é que desenvolvedores tratem o limiar atual como referência para otimização.
Conteúdo após o limite é truncado sem aviso ao webmaster
Quando uma página excede 2 MB, o Googlebot não rejeita o arquivo. Em vez disso, interrompe a leitura no ponto de corte e envia o conteúdo truncado ao sistema de indexação e ao Web Rendering Service como se fosse a versão completa.
Essa abordagem implica que elementos posicionados no final do HTML podem não ser indexados. Tags de metadados, links canônicos e dados estruturados inseridos após a marca de 2 MB ficam invisíveis para o Google, sem que o webmaster receba notificação.
Recursos externos como CSS e JavaScript possuem contadores de bytes separados e não contam para o limite da página principal. Arquivos de mídia e fontes não são buscados pelo Web Rendering Service, reduzindo a carga total de crawling.
Homepages mobile triplicaram de peso em uma década
Dados do Web Almanac 2025, publicado pelo HTTP Archive, documentam o crescimento no tamanho das páginas web. A mediana de peso de homepages mobile era de 845 KB em 2015 e atingiu 2.362 KB em julho de 2025.
Martin Splitt, também da equipe de Search Relations do Google, reconheceu no podcast que o tamanho das páginas continua relevante. Conexões rápidas mascaram o problema, mas redes mais lentas e internet via satélite com franquia limitada expõem o impacto de páginas pesadas na experiência do usuário.
O crescimento constante do peso das páginas aproxima cada vez mais a mediana do limite de 2 MB do Googlebot. Sites com conteúdo extenso, menus pesados ou dados estruturados volumosos podem ultrapassar o limiar sem perceber.
Recomendações incluem mover recursos pesados para arquivos externos
Google recomenda que desenvolvedores posicionem tags de metadados, títulos, links canônicos e dados estruturados no início do HTML. Essa prática garante que elementos críticos para otimização para mecanismos de busca sejam processados antes de qualquer truncamento.
A empresa orienta ainda a mover blocos grandes de CSS e JavaScript para arquivos externos, já que recursos separados recebem contadores independentes. Imagens codificadas em base64, blocos de estilo extensos e menus com volume excessivo de código são os principais vilões do peso interno.
Illyes levantou discussão adicional sobre dados estruturados como fator de peso desnecessário para usuários. Os markups de schema.org existem exclusivamente para máquinas e adicionam volume que visitantes nunca visualizam, o que cria tensão entre conformidade técnica e otimização de performance.
