Indexação Next.js no Google: o guia completo para App Router e Pages Router
Navega por SSG, SSR, ISR e client components para tornar cada rota descobrível pelo Google
Neste guia
O Next.js é a framework React mais popular para apps em produção, e o seu modelo de renderização — abrangendo SSG, SSR, ISR e renderização do lado do cliente — cria oportunidades poderosas e armadilhas subtis de indexação. Algumas rotas servem HTML perfeito logo no primeiro pedido; outras enviam um shell vazio que requer execução de JavaScript.
Este guia cobre tanto o App Router como o Pages Router, percorrendo a Metadata API, generateStaticParams, sitemaps programáticos com sitemap.ts, configuração de robots.ts, dados estruturados e as armadilhas específicas que fazem com que páginas Next.js apareçam em branco para o Googlebot.
Estratégias de renderização e o seu impacto na indexação
O Next.js oferece quatro estratégias de renderização, e cada uma tem implicações diferentes em como (e se) o Googlebot vê o teu conteúdo.
A Static Site Generation (SSG) é o padrão de ouro para indexação. As páginas são renderizadas para HTML completo no momento do build e servidas como ficheiros estáticos. O Googlebot recebe HTML totalmente formado de imediato — sem necessidade de execução de JavaScript. No App Router, qualquer Server Component que não chame funções dinâmicas (como cookies(), headers() ou searchParams) é renderizado estaticamente por defeito. No Pages Router, consegues SSG ao exportar getStaticProps.
O Server-Side Rendering (SSR) gera HTML em cada pedido. O Googlebot recebe HTML completo tal como com SSG, mas a página não fica em cache (a não ser que adiciones cabeçalhos de cache). O SSR é desencadeado no App Router ao usar funções dinâmicas ou ao definir export const dynamic = "force-dynamic" num segmento de rota. No Pages Router, usas getServerSideProps. O SSR é fiável para indexação mas mais lento que SSG porque cada pedido de crawl despoleta uma renderização completa.
A Incremental Static Regeneration (ISR) é um híbrido: a página é gerada estaticamente no momento do build, servida a partir da cache e regenerada em segundo plano após um intervalo de tempo configurável. No App Router, a ISR é alcançada ao definir export const revalidate = 3600 (em segundos) numa página ou layout. No Pages Router, adicionas revalidate ao valor de retorno de getStaticProps. A ISR é excelente para indexação — o Googlebot recebe HTML estático rápido e o conteúdo mantém-se razoavelmente fresco.
A renderização do lado do cliente (CSR) é onde os problemas de indexação surgem. Se um componente está marcado com "use client" e faz fetch de dados num hook useEffect, o HTML inicial enviado para o browser (e para o Googlebot) contém apenas um estado de loading. Embora o Googlebot consiga executar JavaScript até certo ponto, processa-o numa passagem de indexação secundária que pode acontecer horas ou dias depois — e o fetching complexo de dados do lado do cliente falha frequentemente em silêncio no ambiente de renderização do Google.
A regra: qualquer conteúdo que queres indexado tem de estar presente no HTML renderizado pelo servidor inicial, não carregado via JavaScript do lado do cliente após hidratação.
A Metadata API: generateMetadata e metadata estática
O App Router introduziu uma poderosa Metadata API que substitui o antigo componente <Head> do Pages Router. Existem duas formas de definir metadata: exports estáticos e a função dinâmica generateMetadata.
Para metadata estática, exporta um objeto metadata de qualquer ficheiro page.tsx ou layout.tsx. Isto funciona bem para páginas com metadata conhecida e fixa.
Para rotas dinâmicas onde a metadata depende de dados (como um slug de blog post), usa generateMetadata. Esta função async recebe os parâmetros da rota e pode fazer fetch de dados para construir metadata dinamicamente.
Um ponto crítico: o generateMetadata corre no servidor, por isso executa sempre para pedidos do Googlebot. Se em vez disso defines metadata num componente "use client" usando document.title ou um gestor de head de terceiros, o Googlebot pode não a captar durante o seu parse inicial de HTML. Define sempre metadata através da Metadata API do lado do servidor.
A Metadata API suporta toda a gama de meta tags:
titleedescriptionopenGraphetwitterpara partilha socialrobotspara controlo de indexaçãoalternatespara hreflang e URLs canonicalverificationpara o Google Search Consoleiconspara favicons
Para URLs canonical, usa o campo alternates.canonical. Para páginas com variantes de idioma, preenche alternates.languages com um mapa de códigos de locale para URLs.
No Pages Router, a metadata é tratada importando Head de "next/head" e colocando meta tags dentro dele no teu componente. Embora isto ainda funcione, tem limitações: o conteúdo do Head só é processado após a renderização React, e componentes Head aninhados complexos podem levar a duplicação de tags. Se estás a começar um novo projeto, usa a Metadata API do App Router.
Gerar sitemaps com sitemap.ts e sitemap.xml
O App Router do Next.js suporta geração programática de sitemaps através de um ficheiro especial sitemap.ts (ou sitemap.xml/route.ts) colocado no diretório app. A abordagem mais simples é criar app/sitemap.ts que exporta uma função por defeito que devolve um array de entradas de sitemap.
Isto gera /sitemap.xml automaticamente. A função corre em tempo de pedido em desenvolvimento e em tempo de build em produção (para exports estáticos) ou em cada pedido (para renderização dinâmica).
Para sites grandes com mais de 50.000 URLs, usa o padrão de sitemap index. Cria app/sitemap.ts que devolve um sitemap index a apontar para vários sub-sitemaps, e depois cria route handlers individuais para cada sub-sitemap (ex.: app/sitemaps/[id]/route.ts). A especificação do sitemap do Google permite até 50.000 URLs por ficheiro de sitemap e até 500 ficheiros de sitemap num índice.
O erro crucial que os developers cometem é esquecerem-se de incluir rotas dinâmicas no sitemap. Se a tua app tem uma rota como /blog/[slug], a função de sitemap tem de consultar a tua base de dados ou CMS para obter cada slug válido e gerar URLs para cada um. Listar apenas /blog/[slug] no sitemap é inútil — o Google precisa dos URLs reais e resolvidos.
No Pages Router não há geração de sitemap incorporada. Tens duas opções:
- Usar o pacote npm
next-sitemap(gera sitemaps em tempo de build lendo o teu diretório de pages e o output degetStaticPaths) - Criar uma API route personalizada em
pages/api/sitemap.tsque gera XML dinamicamente
O pacote next-sitemap é a escolha mais comum e suporta sitemaps do lado do servidor, geração de robotsTxt e divisão de múltiplos sitemaps.
Rotas dinâmicas: generateStaticParams e comportamento de fallback
Rotas dinâmicas (app/blog/[slug]/page.tsx) são a causa mais comum de falhas de indexação em aplicações Next.js. Sem configuração adequada, rotas dinâmicas podem não ser pré-renderizadas em tempo de build, o que significa que o Googlebot encontra ou um 404 ou um estado de loading na primeira visita.
No App Router, exporta uma função generateStaticParams da tua página dinâmica para pré-renderizar caminhos específicos em tempo de build. Cada slug devolvido por esta função torna-se uma página gerada estaticamente.
Mas e os slugs que não existem em generateStaticParams? Isto é controlado pelo export dynamicParams:
- `dynamicParams = true` (predefinição) — o Next.js tenta renderizar slugs não correspondidos no servidor sob pedido e fazer cache do resultado
- `dynamicParams = false` — slugs não correspondidos devolvem 404
Para SEO, a predefinição (true) é normalmente a correta porque permite que conteúdo recém-publicado seja renderizado sem um rebuild completo.
No Pages Router, o equivalente é getStaticPaths com um parâmetro fallback:
- `fallback: false` — devolve 404 para caminhos desconhecidos
- `fallback: true` — renderiza uma página de loading no primeiro pedido (o Googlebot vê o estado de loading, o que é terrível para indexação)
- `fallback: "blocking"` — bloqueia a resposta até a página estar totalmente renderizada e depois faz cache
Para SEO, usa sempre `fallback: "blocking"` no Pages Router.
A interação entre generateStaticParams e ISR é importante. Se definires revalidate numa página dinâmica, as páginas pré-renderizadas regeneram em segundo plano após o período de revalidação. Novos slugs que não estejam em generateStaticParams são renderizados no primeiro pedido (se dynamicParams for true) e depois ficam em cache com ISR. Esta combinação dá-te o melhor dos dois mundos: servição estática rápida para páginas conhecidas e renderização sob pedido para conteúdo novo.
robots.ts, regras noindex e controlo de crawl
O App Router suporta um ficheiro robots.ts em app/robots.ts que gera programaticamente /robots.txt.
Considerações específicas do Next.js para robots.txt:
- Bloqueia sempre rotas
/api/(devolvem JSON, não HTML) - Bloqueia
/_next/data/(dados JSON para navegação do lado do cliente que não devem ser indexados como páginas autónomas) - Bloqueia quaisquer rotas de dashboard autenticadas
- NÃO bloqueies
/_next/static/— este contém ficheiros CSS e JS que o Googlebot precisa para renderizar as tuas páginas corretamente
Para controlo de noindex a nível de página, usa o campo robots na Metadata API. Define robots: { index: false } no export de metadata de qualquer página que queres excluir dos resultados de pesquisa. Isto é apropriado para:
- Páginas de autenticação (
/login,/register) - Dashboards de utilizador
- Documentação de API atrás de autenticação
- Qualquer página com conteúdo personalizado
O middleware (middleware.ts na raiz do projeto) também pode afetar a indexação. Se o teu middleware faz redirecionamentos para autenticação ou deteção de locale, garante que o Googlebot não fica preso em loops de redirecionamento.
Um padrão seguro comum é middleware que redireciona utilizadores não autenticados de /dashboard para /login — isto está bem porque queres /dashboard noindexado de qualquer forma. Mas middleware que redireciona com base em geolocalização pode prender o Googlebot (que faz crawl a partir de IPs nos EUA) a ver sempre a versão dos EUA, impedindo que outras versões de locale sejam indexadas.
Testa o comportamento do teu middleware com a ferramenta URL Inspection do Google Search Console para veres exatamente o que o Googlebot encontra.
Dados estruturados e Open Graph para rich results
Os dados estruturados (JSON-LD) são críticos para ganhar rich results no Google: classificações por estrelas, accordions de FAQ, breadcrumbs, datas de publicação de artigos e muito mais. No App Router, a abordagem mais limpa é criar um Server Component JsonLd que renderiza uma tag <script type="application/ld+json">.
Este componente deve aceitar props tipadas correspondendo a tipos de Schema.org (Article, FAQPage, Product, BreadcrumbList, Organization) e serializá-las na tag de script. Como é um Server Component, o JSON-LD está presente no HTML inicial que o Googlebot recebe — sem necessidade de execução do lado do cliente.
Para tags Open Graph, usa o campo openGraph no teu export da Metadata API. Inclui:
og:titleeog:descriptionog:image(com dimensões)og:url,og:typeeog:locale
Para Twitter Cards, usa o campo twitter. Estas tags têm de estar presentes no <head> do HTML, o que a Metadata API trata automaticamente.
Um erro comum em aplicações Next.js é gerar dados estruturados do lado do cliente. Se usares um componente "use client" para fazer fetch de reviews de produtos e depois gerar um bloco JSON-LD com a classificação agregada, o parse inicial de HTML do Googlebot pode não incluir os dados estruturados. Gera sempre dados estruturados em Server Components ou em `generateMetadata`. A ferramenta Rich Results Test do Google deixa-te testar URLs específicos para verificar se os teus dados estruturados são visíveis aos crawlers.
Os dados estruturados de breadcrumb são especialmente valiosos para apps Next.js com rotas aninhadas. Se a estrutura da tua app é /blog/categoria/post-slug, gera um schema BreadcrumbList com itens para Home, Blog, a página de categoria e o post atual. Isto dá ao Google informação explícita sobre a hierarquia de navegação e pode resultar na exibição de breadcrumb nos resultados de pesquisa em vez do URL em bruto.
Guia passo a passo
Audita a tua estratégia de renderização por rota
Verifica next.config.ts para definições globais de output. Revê cada page.tsx e classifica-o: funções dinâmicas = SSR, export revalidate = ISR, generateStaticParams = pré-renderizada, "use client" com fetching de dados em useEffect = CSR (risco de indexação). Constrói uma folha de cálculo de cada rota, da sua estratégia e se o conteúdo crítico aparece no HTML inicial.
Implementa a Metadata API em todas as rotas
Para cada page.tsx e layout.tsx no teu App Router, adiciona ou um export de metadata estática ou uma função generateMetadata. No mínimo, cada página precisa de um title e uma description únicos.
- Para o teu layout raiz (
app/layout.tsx), define metadata por defeito usando o campotitle.template(ex.:title: { template: "%s | OTeuApp", default: "OTeuApp" }) - Para rotas dinâmicas como
/blog/[slug], implementagenerateMetadataque faz fetch do conteúdo e devolve metadata específica da página - Adiciona
alternates.canonicala cada página para definir o URL canonical explicitamente - Se a tua app suporta múltiplas línguas, preenche
alternates.languages
Não definas metadata em componentes "use client" — usa sempre exports de metadata do lado do servidor.
Cria sitemap.ts e robots.ts
Cria app/sitemap.ts que exporta uma função async por defeito que devolve um array de entradas de sitemap. Consulta a tua base de dados ou CMS para todo o conteúdo dinâmico (blog posts, páginas de produto, páginas de categoria) e gera um URL completo para cada um.
Define valores de prioridade:
- 1.0 para a homepage
- 0.8-0.9 para landing pages principais
- 0.5-0.7 para conteúdo regular
Inclui datas lastModified para cada entrada.
Cria app/robots.ts que devolve regras a bloquear /api/, /_next/data/, /admin/ e quaisquer rotas autenticadas, permitindo tudo o resto e especificando o URL do teu sitemap.
Faz deploy e verifica que /sitemap.xml devolve XML válido e que /robots.txt devolve diretivas válidas visitando-os no teu browser.
Pré-renderiza rotas dinâmicas com generateStaticParams
Exporta generateStaticParams de cada rota dinâmica para pré-renderizar caminhos válidos em tempo de build. Combina com dynamicParams: true e revalidate para que conteúdo novo seja renderizado no servidor no primeiro pedido e ficado em cache via ISR. No Pages Router, usa fallback: "blocking" em vez de fallback: true para evitar servir estados de loading ao Googlebot.
Move conteúdo crítico para fora dos Client Components
Revê cada componente "use client" que exibe conteúdo que queres indexado. Se o componente faz fetch de dados usando useEffect, useSWR ou React Query e os renderiza do lado do cliente, o Googlebot pode não ver esse conteúdo.
Padrão de refactoring: Move o fetching de dados para um Server Component pai e passa os dados como props para o componente cliente. O componente cliente ainda pode tratar de interatividade (handlers de cliques, estado), mas o conteúdo inicial deve estar presente no HTML renderizado pelo servidor.
Testa: Desativa o JavaScript no teu browser e carrega cada página. O que vês sem JavaScript é aproximadamente o que o Googlebot vê no seu parse inicial de HTML.
Adiciona dados estruturados para rich results
Cria um Server Component reutilizável para dados estruturados JSON-LD. Adiciona os tipos de schema apropriados:
- Blog posts — schema
Articlecomheadline,author,datePublished,dateModifiedeimage - Páginas de produto — schema
Productcomname,description,priceeaggregateRating - Todas as páginas aninhadas — schema
BreadcrumbListpara hierarquia de navegação - Homepage — schema
Organization
Valida cada implementação de dados estruturados usando o Rich Results Test do Google ao introduzir os teus URLs em produção. Corrige quaisquer erros ou avisos antes de avançar.
Lembra-te: todos os dados estruturados têm de estar em Server Components para aparecerem no HTML inicial.
Submete URLs críticos via IndexBolt e monitoriza
Submete a tua homepage, landing pages principais e conteúdo de alta prioridade através da IndexBolt. Para uma nova app, 20-50 URLs aceleram a compreensão do Google em dias. Monitoriza no URL Inspection do Search Console — verifica que o fetch da página mostra HTML completo, não estados de loading. Investiga quaisquer rotas "Discovered - currently not indexed" para problemas de renderização.
Problemas comuns e como resolvê-los
Páginas mostram conteúdo em branco ou spinners de loading ao Googlebot
Causa: O conteúdo é obtido dentro de um componente "use client" usando useEffect ou uma biblioteca de fetching de dados do lado do cliente. O HTML inicial renderizado pelo servidor contém apenas o estado de loading (um spinner, esqueleto ou div vazio). O parse inicial de HTML do Googlebot não vê conteúdo nenhum, e a sua passagem de renderização JavaScript secundária pode falhar devido a autenticação de API, problemas de CORS ou timeout de renderização.
Solução: Move o fetching de dados para Server Components ou usa generateStaticParams com geração estática. Passa dados como props para componentes cliente que precisam de interatividade. Para o Pages Router, usa getStaticProps ou getServerSideProps em vez de fetching do lado do cliente. Testa visualizando a fonte da página (não o DOM renderizado nas DevTools) — a fonte deve conter o texto real do teu conteúdo.
Rotas dinâmicas devolvem 404 para páginas que não estão em generateStaticParams
Causa: A rota dinâmica tem export const dynamicParams = false definido, o que significa que qualquer slug não devolvido por generateStaticParams produz 404. No Pages Router, getStaticPaths com fallback: false comporta-se da mesma forma. Conteúdo recém-publicado que não estava presente em tempo de build é inacessível.
Solução: Define dynamicParams como true (a predefinição) e adiciona um período revalidate para que páginas recém-geradas fiquem em cache via ISR. No Pages Router, muda de fallback: false para fallback: "blocking". Depois garante que o teu sitemap.ts consulta dinamicamente todo o conteúdo atual para que novas páginas apareçam no sitemap mesmo que não tenham sido pré-renderizadas em tempo de build.
O sitemap não inclui páginas geradas dinamicamente
Causa: O ficheiro sitemap.ts foi escrito com uma lista estática de URLs e não consulta a base de dados ou CMS para conteúdo dinâmico. Ou o sitemap foi gerado em tempo de build usando next-sitemap mas o build não foi reexecutado depois de novo conteúdo ser publicado. Novos blog posts, páginas de produto ou páginas de categoria estão em falta no sitemap.
Solução: Reescreve sitemap.ts para consultar dinamicamente a tua fonte de conteúdo (base de dados, API de CMS headless ou sistema de ficheiros) sempre que é pedido. Para sites baseados em ISR, define revalidate na rota do sitemap para que regenere periodicamente. Se usares next-sitemap no Pages Router, configura geração de sitemap do lado do servidor ou cria uma cron job para despoletar rebuilds quando o conteúdo muda.
Redirecionamentos de middleware impedem o Googlebot de aceder a páginas específicas de locale
Causa: O middleware de deteção de locale lê o cabeçalho Accept-Language ou usa geolocalização por IP para redirecionar visitantes para um caminho específico de locale (ex.: /en-us/, /fr/). O Googlebot faz crawl maioritariamente a partir de IPs nos EUA com cabeçalhos em inglês, por isso é sempre redirecionado para a versão em inglês dos EUA. Páginas para outros locales nunca são rastreadas ou indexadas.
Solução: Não redirecciones o Googlebot com base em geolocalização ou Accept-Language. Em vez disso, serve o conteúdo do locale predefinido e confia em tags hreflang (definidas via alternates.languages na Metadata API) para informar o Google sobre as variantes de locale. No teu middleware, podes verificar o User-Agent para o Googlebot e saltar os redirecionamentos de locale para ele, ou melhor ainda, usar hreflang como sinal primário de locale e usar redirecionamentos de middleware apenas como conveniência para utilizadores reais.
Ficheiros loading.tsx mostram conteúdo placeholder que é indexado
Causa: O App Router do Next.js usa loading.tsx para exibir UI de loading instantânea via React Suspense enquanto uma página está a ser renderizada. Se a página usa SSR (renderização dinâmica), o pedido inicial do Googlebot pode receber o conteúdo de loading.tsx em vez da página real. Isto é especialmente provável em páginas com fetching de dados lento.
Solução: Para páginas com conteúdo crítico para SEO, prefere geração estática ou ISR a renderização dinâmica. Se a renderização dinâmica for necessária, garante que o fetching de dados conclui rapidamente (menos de 5 segundos) para que a resposta streaming entregue conteúdo real antes do timeout do Googlebot. Considera mover fetching de dados pesado para componentes cliente que enriqueçam a página depois do conteúdo crítico renderizado pelo servidor já estar presente.
O componente Image do Next.js gera URLs que entopem o crawl budget
Causa: O componente Image do Next.js otimiza imagens através de caminhos /_next/image?url=...&w=...&q=... Cada combinação de largura e qualidade gera um URL único. Se estes URLs não forem bloqueados no robots.txt, o Googlebot pode gastar crawl budget a fazer fetch de endpoints de otimização de imagem em vez de conteúdo real da página.
Solução: Adiciona Disallow: /_next/image ao teu ficheiro robots.ts para impedir o Googlebot de fazer crawl direto a URLs de otimização de imagem. As imagens reais referenciadas nas tags <img> das tuas páginas continuarão descobríveis e indexáveis através do HTML das páginas. Isto poupa crawl budget significativo em sites com muitas imagens.
Dicas de profissional
Fizeste deploy de uma nova app Next.js ou adicionaste rotas dinâmicas? O Google pode demorar semanas a descobrir páginas renderizadas sob pedido. Usa a IndexBolt para empurrar as tuas páginas acabadas de construir diretamente para a fila de indexação do Google — especialmente crítico para rotas SSR e ISR que não têm pegada de URL em tempo de build.
100 créditos gratuitos. Sem cartão de crédito. Resultados em menos de 24 horas.
Perguntas frequentes
O Googlebot executa JavaScript em aplicações Next.js?+
Sim, o Googlebot tem um motor de renderização JavaScript baseado numa versão recente do Chromium. No entanto, a renderização JavaScript acontece numa passagem de indexação secundária que pode ocorrer horas ou mesmo dias após o crawl inicial de HTML. Isto significa que conteúdo que só aparece após execução de JavaScript é indexado com atraso — e fetching complexo de dados do lado do cliente (especialmente para APIs autenticadas) pode falhar completamente no ambiente de renderização do Google. Para indexação fiável, garante que todo o conteúdo crítico está presente no HTML inicial renderizado pelo servidor usando Server Components, getStaticProps ou getServerSideProps.
Devo usar o App Router ou o Pages Router para melhor SEO?+
O App Router tem ferramentas de SEO superiores, incluindo a Metadata API integrada, sitemap.ts, robots.ts e Server Components que renderizam conteúdo do lado do servidor por defeito. O Pages Router funciona bem para SEO mas requer mais trabalho manual: precisas do componente next/head para metadata, pacotes de terceiros como next-sitemap para sitemaps, e getStaticProps/getServerSideProps para renderização no servidor. Para novos projetos, o App Router é a escolha clara. Para projetos existentes em Pages Router, não há urgência em migrar — concentra-te em garantir que tens getStaticProps/getServerSideProps adequados implementados e um sitemap funcional.
Como é que a ISR afeta a indexação no Google?+
A Incremental Static Regeneration é excelente para indexação. O Googlebot recebe HTML em cache estática instantaneamente (o tempo de resposta rápido melhora a eficiência de crawl), e o conteúdo regenera em segundo plano para se manter fresco. A única consideração é o período de revalidação: se definires revalidate como 3600 (uma hora), mudanças de conteúdo podem demorar até uma hora a aparecer na página em cache. Para conteúdo sensível ao tempo, usa um período de revalidação mais curto ou despoleta revalidação sob pedido via webhooks. Da perspetiva do Google, páginas ISR comportam-se identicamente a páginas estáticas — são rápidas, totalmente renderizadas e fiáveis.
As minhas páginas Next.js mostram 'Discovered - currently not indexed' no Search Console. Porquê?+
Este estado significa que o Google encontrou o URL (através do teu sitemap ou de links internos) mas ainda não o renderizou e indexou. Para apps Next.js, isto acontece comumente quando: (1) a página usa renderização do lado do cliente e o crawl inicial de HTML do Googlebot não encontrou conteúdo, por isso despriorizou a página; (2) a página tem thin content que o Google considera de baixo valor; (3) o teu site é novo e o Google ainda não alocou crawl budget suficiente; ou (4) a página tem uma tag canonical a apontar para outro local. Usa a ferramenta URL Inspection para fazer fetch da página como Googlebot e examinar o HTML renderizado. Se estiver vazio ou mostrar um estado de loading, tens um problema de renderização para corrigir.
Como trato URLs canonical no Next.js para páginas com query parameters?+
Na Metadata API do App Router, define alternates: { canonical: "https://oteudominio.com/page" } sem query parameters. Isto diz ao Google que o URL base é a versão canonical, independentemente de quaisquer parâmetros de tracking, paginação ou parâmetros de filtro anexados. Para páginas onde query parameters criam conteúdo significativamente diferente (como resultados de pesquisa paginados), ou geras URLs canonical únicos para cada página (alternates: { canonical: "https://oteudominio.com/search?page=2" }) ou usas um único canonical a apontar para a página 1 e confias em links internos para o Google descobrir páginas subsequentes.
Posso usar a IndexBolt com Next.js para acelerar a indexação de páginas novas?+
Absolutamente. A IndexBolt é especialmente valiosa para aplicações Next.js porque muitos sites Next.js usam ISR ou renderização sob pedido, o que significa que páginas novas não têm URLs estáticos que o Google descobre através de crawl tradicional. Depois de publicar conteúdo novo, usa a API ou o dashboard da IndexBolt para submeter os URLs diretamente para o pipeline de indexação do Google. Isto é particularmente eficaz para páginas de produto e-commerce geradas sob pedido, novos blog posts num setup de CMS headless ou landing pages implementadas como parte do lançamento de uma feature. O modo Normal funciona para conteúdo de rotina; usa o modo Instant para lançamentos de produto ou páginas sensíveis ao tempo.