Scroll infinito e SEO: como o Google acha o que vem depois

O Googlebot não usa mouse nem toca na tela: ele carrega uma URL, espera a página estabilizar e passa para a próxima. Isso significa que ele nunca dispara o evento de scroll que faz um feed infinito carregar o segundo, o terceiro ou o vigésimo lote de itens. Se o único jeito de chegar a esses itens for rolar a página, para o rastreador eles simplesmente não existem — não é uma questão de demora no carregamento, é que a ação que dispara o carregamento nunca acontece.

Isso não significa abandonar o scroll infinito, uma escolha de interface válida para feeds e catálogos. Significa tratar cada lote como se também precisasse existir de outra forma: como uma URL própria, aberta direto pelo navegador ou pelo rastreador. Este artigo cobre como montar essa camada com URLs reais e History API, e como testar se ela de fato funciona.

Por que o scroll infinito quebra o rastreamento, não a indexação

Quando o Googlebot processa uma URL, ele busca o HTML, executa o JavaScript num Chromium sem interface, espera a rede ficar relativamente quieta e tira uma espécie de retrato daquele estado da página. Esse processo não inclui simular um usuário rolando a tela até o fim, nem clicar repetidamente num botão de carregar mais. O rastreador olha o que está no DOM naquele momento e segue os links que encontra ali — nada além disso.

O problema aparece quando o segundo lote só é buscado e inserido no DOM depois de um evento de scroll, ou de um IntersectionObserver que depende do elemento entrar na área visível durante a rolagem. Como esse evento nunca é disparado pelo rastreador, o lote nunca chega a existir do ponto de vista dele — não é demora em processar JavaScript pesado, é que a condição que aciona o carregamento simplesmente não ocorre. O mesmo vale para um botão "carregar mais" que é só um elemento com manipulador de clique, sem link real por baixo.

O sintoma no Search Console costuma ser diferente de uma exclusão explícita por qualidade: é um silêncio total sobre aqueles itens, como se eles nunca tivessem existido para o Google.

• Só os primeiros itens do feed aparecem no HTML renderizado que o Google mostra na inspeção de URL.
• Produtos ou artigos que só apareceriam após várias rolagens não recebem impressões nem cliques nos relatórios de desempenho.
• Um rastreador de terceiros sem execução de JavaScript para de encontrar links depois da primeira tela.

A base técnica: cada lote também precisa ser uma URL

A saída não é abandonar o scroll infinito, é dar a cada lote uma existência independente do gesto de rolar. Na prática, isso significa usar a History API do navegador — os métodos pushState e replaceState — para atualizar o endereço na barra conforme o usuário avança pelo feed, trocando por exemplo /categoria/pagina/1 por /categoria/pagina/2 sem recarregar a página inteira.

O ponto que costuma ser esquecido é que essa URL precisa funcionar sozinha. Se alguém pedir /categoria/pagina/2 direto, sem passar pela página 1 e sem rolar nada, o servidor precisa devolver o HTML já com os itens daquela página prontos. Se a resposta for uma casca vazia que só se preenche depois de um scroll que nunca vai acontecer numa visita direta, o problema volta pela porta dos fundos.

Esse padrão é essencialmente o que ficou conhecido como página de componente: cada trecho do conteúdo paginado tem sua própria URL, encadeada às vizinhas. O Google descontinuou o uso de rel=next e rel=prev como sinal de indexação em 2019, mas isso não muda o que importa aqui — o valor nunca esteve nas tags, estava em cada página ser individualmente rastreável, com links reais para a anterior e a seguinte.

Um padrão que funciona: link real por baixo, rolagem por cima

Num catálogo de e-commerce com scroll infinito de produtos, o padrão mais robusto separa duas camadas: a experiência visual, contínua, e a estrutura de navegação, feita de URLs reais. A página inicial é renderizada no servidor já com o primeiro lote de produtos e, junto dele, um elemento de ancoragem com um href real apontando para /categoria/pagina/2 — pode estar disfarçado de botão "ver mais produtos", mas por baixo é um link de verdade, não um <div> com onclick.

Quando o usuário rola até esse ponto (ou clica no botão), o JavaScript intercepta a navegação, busca o lote seguinte por uma chamada assíncrona, insere os novos produtos no DOM e chama history.pushState para atualizar a URL visível, sem recarregar a página. Se o JavaScript falhar, estiver desativado, ou se for um rastreador seguindo o href, a mesma URL carrega pelo caminho tradicional, com o servidor já entregando os produtos no HTML inicial — a experiência da pessoa não muda, mas agora existe um caminho que não depende de rolagem para ser encontrado.

O mesmo vale para blogs com feed contínuo, diretórios ou galerias: a regra é sempre a mesma — algo que um navegador sem JavaScript consiga seguir. Numa aplicação construída só no cliente, é comum buscar o próximo lote via uma chamada que devolve JSON puro, sem existir uma rota que devolva HTML completo quando a página é acessada direto — e nesse caso a URL existe, mas continua vazia por fora.

• Renderize cada página do lote no servidor com os itens que pertencem a ela, não com um estado vazio esperando JavaScript.
• Coloque um link real, com href, apontando para a próxima página, mesmo que estilizado como botão.
• Use history.pushState para manter a URL sincronizada com o lote visível, sem forçar um recarregamento completo.
• Garanta que abrir a URL de qualquer página do meio do feed, direto e sem navegar pelas anteriores, produza o conteúdo certo por si só.

Feed ou catálogo: quando indexar cada lote realmente importa

Nem todo scroll infinito tem o mesmo objetivo, e isso muda quanto esforço vale investir no encadeamento de URLs. Num catálogo de e-commerce, cada produto costuma ter valor próprio de busca — é a página do produto que precisa ranquear, não a página 3 da categoria. Ainda assim, se essa página 3 nunca for descoberta porque depende de rolagem, os produtos que só aparecem ali também não são descobertos. A página paginada funciona como ponte de descoberta, não necessariamente como a página que se espera ver no resultado.

Já num feed onde os itens não têm valor de busca individual — uma galeria sem título próprio, um mural de atividades, um bloco que replica conteúdo já publicado com sua própria URL canônica — o argumento para indexar cada página intermediária é mais fraco. O que continua importando é garantir que o rastreador alcance os itens mais profundos de alguma forma, ainda que essa página em si não precise competir por uma posição no resultado.

A pergunta certa, então, não é se scroll infinito é bom ou mau para SEO, mas se os itens que só aparecem depois de rolar têm valor de busca próprio. Se a resposta for sim, o encadeamento de URLs reais deixa de ser um detalhe técnico e passa a ser a diferença entre metade do catálogo indexado e o catálogo inteiro indexado.

Como testar se o seu scroll infinito é rastreável

Antes de assumir que o padrão de link real com History API foi implementado corretamente, vale testar do jeito mais parecido possível com o que um rastreador faz.

Comece desativando o JavaScript, ou vendo o código-fonte da página, e procure por um link de verdade — um elemento <a> com href — apontando para o próximo lote. Se tudo que existir for um elemento com manipulador de clique e nenhum atributo de destino, não há caminho para quem não executa aquele script.

Em seguida, use a ferramenta de inspeção de URL, peça um teste ao vivo e abra a visualização do HTML renderizado pelo Google. Procure especificamente pelos itens do segundo ou terceiro lote nesse HTML — se eles não aparecerem ali, não vão aparecer no índice, mesmo que apareçam perfeitamente na tela do seu navegador.

Depois, pegue a URL que deveria corresponder à página 2 ou 3 do feed e abra-a direto numa aba nova, sem ter navegado por nenhuma página anterior. Se ela carregar vazia, ou pedir algum estado que só existia na sessão anterior, é sinal de que não é autocontida.

Por fim, olhe os registros de acesso do servidor por requisições do Googlebot batendo direto nessas URLs intermediárias. Se ele só aparece na página 1, o problema não é de renderização, é de descoberta.

• Veja o código-fonte da página com JavaScript desativado e procure por um link real para o próximo lote.
• Use a inspeção de URL para comparar o HTML renderizado pelo Google com o que você vê no navegador.
• Abra a URL de uma página intermediária do feed direto, sem navegar pelas anteriores.
• Confira nos logs do servidor se o Googlebot chega às páginas seguintes, ou só à primeira.

Erros comuns que travam a indexação do feed

O erro mais frequente é carregar o próximo lote só a partir de um evento de scroll ou de um clique num elemento sem link real por baixo — sem nenhuma URL correspondente àquele estado, não há nada que um rastreador possa seguir, por mais rápido que o carregamento seja para uma pessoa.

Outro erro comum é trocar apenas o fragmento da URL, depois do caractere #, em vez de um caminho real com a History API. Fragmentos historicamente não são enviados ao servidor numa requisição normal e, na prática, não criam uma URL que o Google trate como um estado distinto — o endereço muda na barra, mas para efeitos de rastreamento continua sendo a mesma página.

Um terceiro erro é canonicalizar todas as páginas do scroll para a página 1, numa tentativa equivocada de evitar conteúdo duplicado. O resultado prático é apagar da indexação tudo que estava nas páginas seguintes, porque a tag canônica diz ao Google para tratar aquelas URLs como cópias da primeira.

Por fim, feeds cuja ordem dos itens muda a cada carregamento — por exemplo, ordenados por "mais recente" sem nenhum controle de paginação estável — fazem o rastreador ver conjuntos diferentes de itens em cada página a cada visita, o que dificulta consolidar um índice consistente daquele conteúdo.

• Carregar o próximo lote sem nenhuma URL real associada a ele.
• Usar apenas um fragmento depois de # em vez de um caminho real via History API.
• Canonicalizar todas as páginas do feed para a primeira.
• Deixar a ordenação instável entre visitas, sem paginação consistente.

Quando vale manter a paginação clássica em vez do scroll infinito

Nem sempre o esforço de replicar o scroll infinito com History API e páginas autocontidas compensa. Quando cada item precisa ser descoberto e ranqueado de forma discreta, uma paginação numerada tradicional — com links visíveis para a página 2, 3, 4 — tende a ser mais fácil de acertar, porque há menos lógica de sincronização entre o gesto do usuário e o estado da URL para dar errado.

Um caminho intermediário comum é manter a paginação numerada como estrutura de navegação principal, com links reais entre as páginas, e adicionar o scroll contínuo como camada de conveniência sobre ela, sempre espelhando o mesmo conjunto de URLs que a paginação clássica já expõe. Isso entrega a rolagem para quem tem JavaScript habilitado, sem criar uma estrutura de descoberta paralela que só existe para humanos.

Vale reservar o scroll infinito sem esse cuidado extra para os casos em que os itens individuais não competem por posições no resultado de busca — feeds internos, painéis autenticados, ou blocos que já têm sua própria página canônica em outro lugar do site. Fora desses casos, tratar o encadeamento de URLs como parte obrigatória da implementação é o que separa um catálogo inteiro indexado de um catálogo que para de existir para o Google depois da primeira tela.

• Prefira paginação numerada visível quando cada item precisa ranquear de forma independente.
• Combine paginação clássica como estrutura de navegação com scroll infinito como camada de conveniência sobre ela.
• Reserve o scroll infinito sem encadeamento de URLs para feeds sem valor de busca individual.