O limite de 2 MB do Googlebot: a gente mediu o HTML de 86 sites grandes e 20 passam

O que a documentação do Google diz

A página Googlebot, na Central da Pesquisa, diz com todas as letras: "Ao rastrear para a Pesquisa Google, o Googlebot rastreia os primeiros 2 MB de um tipo de arquivo compatível e os primeiros 64 MB de um arquivo PDF." Logo depois vêm as duas frases que importam pra este estudo:

• "Quando o limite é atingido, o Googlebot interrompe a busca e envia apenas a parte já baixada do arquivo para fins de indexação."
• "O limite de tamanho do arquivo é aplicado considerando os dados descompactados."

A segunda frase é a que pega muita gente. O número que o DevTools mostra por padrão, e o que aparece em relatório de CDN, é o tamanho transferido, já comprimido. Um HTML que trafega 300 KB com brotli pode ter 3 MB depois de aberto, e é esse segundo número que o Google conta.

Até o começo de 2026, a página do Googlebot falava em 15 MB. Em 3 de fevereiro de 2026, segundo o registro de atualizações da documentação, o Google moveu o limite padrão de 15 MB pra documentação dos rastreadores, porque ele vale pra todos os rastreadores e coletores do Google, e deixou na página do Googlebot o limite próprio dele. Por isso tanta gente leu a mudança como "o Google reduziu o limite de 15 MB pra 2 MB".

Em março de 2026, o post Inside Googlebot do blog do Search Central detalhou o resto: a parte baixada vai pro sistema de indexação e pro Web Rendering Service (WRS) "como se fosse o arquivo completo", o que passa do corte não é buscado, renderizado nem indexado, e os recursos externos (CSS, JavaScript) têm contador próprio, que não soma no tamanho da página. Ou seja: CSS num arquivo .css não pesa no HTML; o mesmo CSS dentro de um <style> pesa.

Como a gente mediu

A gente escolheu 86 sites conhecidos, brasileiros e de fora, e abriu cada um com Chromium de verdade, pelo Playwright, em 04/10/2026. O método teve três partes.

1. Medir o tamanho certo

No Playwright, response.body() devolve o corpo já descomprimido, que é o número que o Google usa. Pra conferir que não era o tamanho transferido, a gente comparou com o encodedDataLength do evento Network.loadingFinished, pelo protocolo do DevTools (CDP), que é o que trafegou de fato.

A mesma URL muda entre acessos: anúncio, vitrine personalizada, teste A/B. Por isso cada site foi medido duas vezes. A diferença entre as duas medidas ficou abaixo de 1%.

2. Achar onde o corte cai

Saber que o HTML tem 5 MB não diz o que se perde. Pra isso, a gente:

1. cortou o HTML no byte 2.097.152 (2 MB);
2. pegou o último elemento completo antes do corte e procurou esse elemento na página renderizada inteira;
3. mediu a posição vertical dele (getBoundingClientRect somado à rolagem) numa tela de celular e dividiu pela altura total da página.

O resultado é uma porcentagem: quanto da página, de cima pra baixo, cabe nos 2 MB. A tela de celular faz sentido porque, segundo o Google, na maioria dos sites a Pesquisa indexa principalmente a versão para dispositivos móveis, e a maior parte do rastreamento é feita pelo Googlebot de smartphone.

3. Ver o que é texto e o que é código

Por fim, a gente olhou o que ocupa os bytes: conteúdo visível, <style> inline ou JSON de hidratação.

Resultados: 20 de 86 passam dos 2 MB

Dos 86 sites, 20 tinham HTML descompactado acima de 2 MB. Estes são os cinco casos que a gente destaca, cada um por um motivo diferente:

Pra ter noção da escala: segundo o Web Almanac 2025, a mediana do HTML é 33 KB no celular e 35 KB no desktop. Os 2 MB são umas 60 vezes isso. A cnn.com tem quase 200 vezes a mediana.

A conclusão que mais surpreendeu a gente: o tamanho sozinho não diz se há problema. A cea.com.br tem o dobro do HTML da globo.com e, em texto, perde menos, porque o conteúdo vem antes e o peso fica no fim, num JSON que o Google não precisa pra indexar. A havaianas.com.br passa do limite por pouco, 0,11 MB, e mesmo assim perde um quarto da página, porque o corte cai no meio do conteúdo.

O que mais pesa no HTML

Na maioria dos sites acima do limite, o excesso era JSON de hidratação ou script inline. Os outros dois padrões que apareceram foram CSS inline no topo e a página duplicada pra desktop e celular.

JSON de hidratação

Frameworks que renderizam no servidor e depois "hidratam" no navegador mandam, junto com o HTML, os dados que usaram pra montar a página, num <script> inline. No Next.js com Pages Router é o __NEXT_DATA__; no App Router é o RSC Payload, que, segundo a documentação do Next.js, inclui todas as props passadas de um Server Component pra um Client Component. Quando a página passa o objeto inteiro do produto, com todas as variações, avaliações e campos internos, o JSON vira megabytes. Foi o caso da cea.com.br e da maioria dos e-commerces.

Se esse JSON fica no fim do <body>, o texto visível costuma caber e o risco é menor. Mas o que vem depois dele, como links de rodapé e às vezes o JSON-LD de dados estruturados, fica fora.

CSS inline no <head>

É o caso mais grave, porque o <head> vem antes de tudo. Na cnn.com, os primeiros 3 MB são CSS dentro de <style>. Pro Googlebot, a página termina antes do primeiro parágrafo. Ferramentas de "critical CSS" e configurações de inline automático em build podem levar a isso sem ninguém perceber.

Desktop e mobile no mesmo HTML

Alguns sites renderizam dois blocos inteiros da página, um pra tela grande e outro pra celular, e escondem um deles com CSS. O conteúdo dobra no HTML. Na mobly.com.br, o excesso dos 7,95 MB é a repetição das vitrines nas duas versões.

O próprio Google cita outros dois culpados no post de março: imagens em base64 inline e páginas que começam com megabytes de menus.

Quando o corte custa conteúdo de verdade

Passar dos 2 MB só vira problema de SEO quando algo que você quer no Google cai depois do corte. Pelo que a gente viu, isso acontece em três situações:

• <head> gigante. CSS ou script inline no topo empurra o conteúdo inteiro pra fora (cnn.com). Pior ainda se o <title>, a meta description ou o canonical ficarem no fim do <head>.
• Página longa de listagem. Home de portal, categoria de loja, página de busca: os itens do fim só existem ali, e o corte pega o meio (globo.com, havaianas.com.br).
• O que fica no fim do <body>. JSON-LD, links de rodapé pra categorias e páginas institucionais. É exatamente onde o corte cai quando o HTML passa do limite por pouco.

Se o seu caso é o da cea.com.br, com todo o texto nos primeiros centenas de KB e só JSON depois, o risco pra indexação é baixo. Ainda assim vale reduzir: o mesmo peso atrasa a página no celular, e o Google não garante que o WRS lida bem com um script de hidratação cortado no meio (mais sobre isso no fim).

Como medir o HTML do seu site

No Chrome, pelo DevTools

1. Abra a página, aperte F12 e vá na aba Network.
2. Clique no filtro Doc e recarregue a página.
3. Na engrenagem de configurações do painel, ligue Big request rows.
4. Na coluna Size, o número de cima é o transferido (comprimido). O número de baixo é o tamanho descompactado, o que o Google conta.

A referência do painel Network explica a diferença: o valor padrão inclui cabeçalhos e corpo como o servidor enviou; o valor de baixo, com as linhas grandes ligadas, é o tamanho sem compressão.

No terminal, com curl

O --compressed faz o curl pedir gzip ou brotli e descomprimir na chegada. O wc -c conta os bytes do que sobrou, que é o número certo:

curl -s --compressed https://seusite.com.br/ | wc -c

Pra ver o transferido e o descompactado lado a lado:

curl -s --compressed -o /dev/null -w "transferido: %{size_download} bytes\ncabeçalhos: %{size_header} bytes\n" https://seusite.com.br/

Se o descompactado passa de 2.097.152, descubra onde o corte cai. Este comando mostra os últimos 400 caracteres que o Googlebot chega a ler:

curl -s --compressed https://seusite.com.br/ | head -c 2097152 | tail -c 400

E este diz em que byte o <body> começa e em que byte fecha o </head>. Foi assim que a gente achou o 3.028.230 da cnn.com:

curl -s --compressed https://seusite.com.br/ | grep -bo -e '</head>' -e '<body' | head -2

Pra saber se o JSON-LD ou o canonical estão antes do corte, troque o padrão. Qualquer resultado com número acima de 2097152 está fora:

curl -s --compressed https://seusite.com.br/ | grep -bo -e 'application/ld+json' -e 'rel="canonical"' -e '__NEXT_DATA__'

Achar o maior bloco inline

No Console do DevTools, este trecho lista os dez maiores <script> e <style> sem arquivo externo. Ele lê a página já carregada e conta caracteres, não bytes, então serve pra achar o culpado, não pra medir o total:

console.table([...document.querySelectorAll("script:not([src]), style")]
  .map((e) => ({ tag: e.tagName, id: e.id || e.type || "", tamanho: e.textContent.length }))
  .sort((a, b) => b.tamanho - a.tamanho)
  .slice(0, 10));

Em várias páginas de uma vez

A home quase nunca é a única página pesada. Categorias e páginas de produto com muitas variações costumam ser piores. A ferramenta grátis verificar tamanho do HTML mede o HTML descompactado da home e de páginas do sitemap e avisa quando passa ou chega perto dos 2 MB.

Como reduzir, por causa

A recomendação do Google no post de março é curta: deixe o HTML enxuto, mova CSS e JavaScript pesados pra arquivos externos e ponha o que é crítico no topo. Na prática, por stack:

Next.js com Pages Router: __NEXT_DATA__

O Next.js avisa quando os dados de uma página passam de 128 kB, com a mensagem Large Page Data. Não aumente o limite do aviso: corte os dados. Pra ver o que está indo, rode no Console:

JSON.parse(document.getElementById("__NEXT_DATA__").textContent)

Depois, no getStaticProps ou getServerSideProps, devolva só os campos que os componentes usam:

// pages/produto/[slug].js
export async function getServerSideProps({ params }) {
  const p = await getProduto(params.slug);
  return {
    props: {
      produto: { nome: p.nome, preco: p.preco, descricao: p.descricao, fotos: p.fotos.slice(0, 8) },
    },
  };
}

A própria documentação sugere paginar listas grandes e buscar no cliente o que não aparece no primeiro carregamento. Só tome cuidado com o que você quer indexado: conteúdo que só chega depois de uma ação do usuário pode não ser visto.

Next.js com App Router: RSC Payload

Aqui o equivalente são as props que vão pros Client Components, porque elas viajam serializadas no RSC Payload. Duas regras resolvem quase tudo:

• Marque com "use client" só o pedaço interativo (o botão, o seletor de tamanho), não a página inteira.
• Passe pro Client Component só o que ele usa. <BotaoComprar id={p.id} preco={p.preco} />, e não <BotaoComprar produto={p} /> com o objeto inteiro.

CSS inline

Mantenha inline só o CSS da primeira dobra, se for usar critical CSS, e mande o resto num <link rel="stylesheet">. Arquivo externo tem o próprio limite de 2 MB e não soma no HTML. Confira a configuração do build: plugins que embutem todo o CSS no HTML resolvem um problema de velocidade criando outro de rastreamento.

SVG repetido e imagens em base64

Ícone SVG colado inline em cada card de produto se repete centenas de vezes numa listagem. Defina uma vez e reaproveite com o elemento <use>:

<svg style="display:none">
  <symbol id="i-carrinho" viewBox="0 0 24 24"><path d="M3 4h2l2 12h11l2-8H6"/></symbol>
</svg>

<!-- em cada card -->
<svg width="20" height="20"><use href="#i-carrinho"/></svg>

Imagem em data:image/...;base64 dentro do HTML é pior ainda: base64 ocupa mais bytes que o arquivo original. Troque por um <img src> normal.

Desktop e mobile duplicados

Em vez de renderizar dois blocos e esconder um, use um só bloco com CSS responsivo. Se o componente realmente precisa ser diferente, renderize no servidor a versão do celular, que é a que o Google indexa na maioria dos sites, e carregue a outra só quando a tela pedir.

Listagens longas: paginação

Uma home ou categoria com centenas de itens no mesmo HTML é o cenário da globo.com e da havaianas.com.br. Divida em páginas. O guia de paginação do Google pede uma URL única por página, links <a href> de uma página pra seguinte e nada de número de página depois do #. Ele também avisa que os rastreadores do Google não clicam em botões, então um "Ver mais" em JavaScript sem link de verdade esconde os itens do Google.

Ordem do HTML

Mesmo antes de reduzir, dá pra proteger o essencial. O Google recomenda colocar no alto do documento as meta tags, o <title>, os <link>, o canonical e os dados estruturados essenciais. Um JSON-LD no topo do <head> não depende de onde o corte cai.

Como conferir que resolveu

1. Rode de novo o curl -s --compressed URL | wc -c nas páginas que estavam acima do limite. O alvo é ficar bem abaixo de 2.097.152, com folga pra variação entre acessos.
2. Rode o comando do head -c 2097152 | tail -c 400. Se o resultado termina em </html>, a página inteira cabe.
3. Confira com o grep -bo que o canonical, o JSON-LD e o <body> aparecem com números baixos.
4. No Search Console, use a Inspeção de URL, clique em Testar o URL publicado e depois em Ver a página testada pra ver o HTML e a captura de tela. Depois do próximo rastreamento, Ver a página rastreada mostra o que o Google buscou.
5. Meça categorias e páginas de produto, não só a home. Uma mudança no template costuma afetar todas de uma vez.

Se a página estava com conteúdo cortado e ficou de fora do índice, o artigo sobre rastreada, mas não indexada explica como acompanhar a volta no relatório de páginas.

Limitações do estudo

A gente prefere dizer o que os números não mostram:

• Amostra de 86 sites. São sites conhecidos, não uma amostra aleatória da web. Não dá pra dizer que 23% da web passa do limite; dá pra dizer que 20 dos 86 sites que a gente mediu passam.
• Uma data só. Tudo foi medido em 04/10/2026. Sites grandes mudam de template com frequência, e o número de hoje pode ser outro.
• Variação entre acessos. Anúncios, vitrines personalizadas e testes A/B mudam o HTML. Entre duas medidas a diferença ficou abaixo de 1%, o que não muda nenhuma conclusão, mas um site perto dos 2 MB pode estar acima num acesso e abaixo no outro.
• Páginas medidas. Outras páginas de cada site, como categorias e produtos, podem ser mais leves ou mais pesadas.
• Navegador da gente, não o Googlebot. O servidor pode responder diferente pro Googlebot. A gente mediu o que um Chromium recebe, numa tela de celular.
• 2 MB contados como 2.097.152 bytes. O Google escreve "2 MB" e não diz se são 2.000.000 ou 2.097.152 bytes. Se forem 2.000.000, o corte cai uns 97 KB antes do que a gente usou.

As dúvidas que ficaram

Duas perguntas apareceram enquanto a gente fazia o estudo. Uma o Google já respondeu em parte; a outra continua aberta.

Os cabeçalhos HTTP contam nos 2 MB?

A página da documentação em português não fala disso. O post de março de 2026 do blog do Search Central diz que sim: o Googlebot busca os primeiros 2 MB "incluindo o cabeçalho HTTP". Na prática, os cabeçalhos raramente pesam: o %{size_header} do curl acima mostra quantos bytes os seus ocupam. Só fica relevante se o site manda cookies ou cabeçalhos de política de segurança muito longos e o HTML já está no limite.

O Google renderiza a partir do HTML cortado?

Também segundo o post de março, sim: a parte baixada vai pro WRS como se fosse o arquivo completo, e o WRS só executa o código que o rastreador de fato buscou. O que o Google não diz é o que acontece quando o corte cai no meio de um <script> de hidratação. A hipótese da gente é que um script cortado não executa, e numa página que depende dele pra montar o conteúdo isso afetaria mais que o fim da página. A gente não conseguiu confirmar isso em documentação, então trate como hipótese. Também não encontramos nada oficial dizendo se a Inspeção de URL aplica o mesmo corte de 2 MB ao mostrar o HTML.

O caminho mais seguro é não depender dessas respostas: deixe o conteúdo, o canonical e os dados estruturados bem antes dos 2 MB. O HTML costuma crescer aos poucos, a cada componente novo. A varredura grátis da Varrida mede isso junto com noindex, canonical e sitemap, e o plano Pro confere todo dia e a cada deploy, avisando por e-mail e Slack quando uma página passa do limite.