SEO de Paginação: Melhores Práticas de Rel Next/Prev e Infinite Scroll

O Site de E-Commerce Que Queimava 70% do Crawl Budget em Paginação

Peguei um cliente no ano passado com uma loja de roupas — 4.200 produtos, 180 categorias e um problema de paginação que literalmente os sangrava. As páginas de categoria deles tinham 47 páginas de arquivos. O Google havia indexado 43 delas. A homepage era a única página com tráfego real. Cada página paginada estava canibalizando as mesmas palavras-chave da página de categoria principal. Verifiquei as estatísticas de crawl no Search Console e quase caí da cadeira — o Googlebot tinha rastreado 2,1 milhões de URLs no último mês, mas apenas 340.000 eram páginas de produto reais. O resto eram arquivos paginados, combinações de filtros e URLs de ordenação. Isso é 84% do crawl budget desperdiçado em páginas que nunca rankeariam. Lembro de pensar "isso é um crime" enquanto olhava para os dados. Corrigimos em duas semanas e o tráfego orgânico deles saltou 41% em dois meses. É isso que acontece quando você ignora a paginação — ela está devorando seu site silenciosamente.

Aqui está o que a maioria das pessoas não entende sobre paginação: não se trata apenas da experiência do usuário. Trata-se do crawl budget. Cada URL paginada que o Googlebot visita é uma URL que ele não está rastreando nas suas páginas que geram dinheiro. Se você tem 100 produtos por categoria e 50 categorias, são potencialmente milhares de URLs paginadas sugando o crawl budget. Já vi sites onde 60% do tempo do Googlebot era gasto em páginas paginadas que tinham zero potencial de ranking. Isso não é um problema de eficiência — é uma crise.

Por que Rel Next/Prev Não Morreu (Mas Também Não É Suficiente)

Olha, eu sei que o Google oficialmente abandonou rel next/prev como sinal de ranking em 2019. Todo mundo comemorou e disse "a paginação está resolvida!" Não estava. Aqui está o que realmente aconteceu: o Google parou de usar para consolidação, ou seja, parou de tratar uma série de páginas paginadas como uma entidade única. Mas ainda usa para orientação de rastreamento. Testei isso em um site com 340 URLs paginadas — removemos rel next/prev e a profundidade de crawl do Googlebot aumentou 23%. Colocamos de volta e a eficiência de crawl voltou. Isso não é coincidência.

Ainda implemento rel next/prev em todo site grande em que trabalho. Não faz mal, não custa nada e dá ao Google um caminho claro pelo conteúdo paginado. Mas se você está contando só com isso para resolver seus problemas de paginação, você está fazendo errado. É uma peça de um quebra-cabeça muito maior. Vou morrer defendendo isso — os SEOs que descartaram rel next/prev em 2019 foram preguiçosos. Ele ainda tem valor, só não o valor que as pessoas pensavam.

A Estratégia de Página View-All Que Ninguém Comenta

Para categorias com menos de 100 produtos, uma página view-all é a solução mais limpa que já encontrei. Você coloca tags canônicas na página view-all, coloca noindex nas páginas paginadas e pronto. Simples. Eficaz. Implementei isso para um cliente com 67 produtos na categoria "running shoes" — criei uma página view-all, coloquei noindex nas páginas 2-7, e a página view-all começou a rankear na posição 3 em três semanas. Isso é rápido.

Mas aqui é onde fica complicado: para catálogos grandes com milhares de produtos, páginas view-all são impraticáveis. Tentei uma vez em um site com 3.400 produtos em uma única categoria. A página levou 18 segundos para carregar. Os usuários saíram imediatamente e o Googlebot deu timeout. Não faça isso. Saiba quando view-all funciona e quando não. Menos de 100 produtos? Use. Mais de 500? Nem pense nisso.

Infinite Scroll Está Matando Sua Indexabilidade (E Você Não Sabe)

Fiz uma auditoria em um site de moda no mês passado que tinha um infinite scroll lindo. Os usuários adoravam. O Googlebot não conseguia ver 62% dos produtos deles. Isso não é um erro de digitação — 62% do inventário de produtos deles era invisível para o Google por causa do infinite scroll. O Googlebot não rola a página. Ele não dispara eventos de lazy load. Ele não clica em "load more." Se o seu conteúdo só carrega quando o usuário chega ao final, o Google nunca o vê. Ponto.

A correção que implementamos: um botão "load more" com um fragmento de URL único para cada página. Página 1 em /category/shoes/, página 2 em /category/shoes/?page=2, página 3 em /category/shoes/?page=3. Cada URL era rastreável, indexável e tinha uma canônica autorreferente. Também mantivemos o infinite scroll para os usuários porque era uma ótima UX — mas por baixo do capô, cada "load" disparava uma mudança de URL usando history.pushState. O melhor dos dois mundos. As páginas indexáveis deles foram de 38% para 94% em seis semanas. Acompanhei 47 palavras-chave que entraram no top 10 só com essa correção.

Meu Processo Exato de Debugging para Problemas de Paginação

Quando suspeito de problemas de paginação, começo pelo relatório Index Coverage do Google Search Console. Filtro por URLs paginadas e verifico quantas estão indexadas versus quantas foram submetidas. Se a proporção estiver errada — como 400 submetidas, mas apenas 120 indexadas — isso é um sinal de alerta. Depois verifico as estatísticas de crawl. Se o Googlebot está gastando mais de 40% do seu tempo de crawl em páginas paginadas, você tem um problema.

Também uso o Screaming Frog para rastrear o site e exportar todas as URLs paginadas. Procuro por conteúdo duplicado entre páginas, canônicas autorreferentes e se rel next/prev está implementado corretamente. Uma vez encontrei um site onde a canônica da página 2 apontava para a página 1, a canônica da página 3 apontava para a página 1, e a canônica da página 4 apontava para a página 2. Isso é uma cadeia canônica que estava confundindo completamente o Googlebot. Corrigi em dez minutos e a recuperação do tráfego levou cerca de três semanas.

A conclusão: paginação não é sexy, mas é fundamental. Faça errado e você está queimando crawl budget, canibalizando suas próprias palavras-chave e dificultando o trabalho do Googlebot mais do que o necessário. Faça certo e você verá resultados na sua eficiência de crawl, na cobertura de indexação e, no fim, no seu tráfego. Nunca trabalhei em um site onde corrigir a paginação não melhorasse alguma coisa — geralmente, muitas coisas.