Como auditar SEO técnico de um site feito em Next.js

Um checklist avançado para engenheiros e profissionais de SEO diagnosticarem problemas de renderização, metadata, sitemaps e performance no ecossistema App Router e Pages Router do Next.js.

Equipe RemountlyEngenharia de Performance e SEO

22 de julho de 20266 min de leitura

SEO

Neste artigo

TL;DR

Next.js não resolve SEO automaticamente apenas por oferecer Server-Side Rendering (SSR). Erros arquiteturais como misturar Client Components sem necessidade na dobra da página, ignorar a Metadata API e usar a tag <img> em vez do <Image> destroem a indexação e o Core Web Vitals. Você precisa auditar como o servidor exporta as rotas estáticas vs dinâmicas e garantir que status HTTP como 404 e 301 sejam disparados no backend, não emulados no front-end.

Leitura executiva

Principais conclusões

No App Router, o uso excessivo de `'use client'` destrói o propósito do SSR em páginas de conteúdo, atrasando a leitura do Googlebot.
A Metadata API (`generateMetadata`) deve ser auditada para garantir que Tags Canonicals, Open Graph e Title sejam injetados estaticamente.
Rotas dinâmicas (`[id]`) sem `generateStaticParams` forçam o servidor a renderizar sob demanda, elevando o TTFB.
Erros como não usar o componente `<Link>` do Next quebram o pré-carregamento de rotas e afetam o Crawl Budget interno.

Quando a Vercel popularizou o Next.js como o framework React definitivo, a promessa era clara: o fim dos problemas de SEO enfrentados pelas Single Page Applications (SPAs). Com o Server-Side Rendering (SSR) e a Geração de Site Estático (SSG), o Googlebot finalmente veria o HTML completo.

No entanto, a realidade operacional em 2026 é mais obscura. Entre os erros mais comuns em React e Next.js, a falsa segurança de que "o framework cuida do SEO" gerou uma epidemia de sites extremamente rápidos na máquina do desenvolvedor, mas lentos, inindexáveis e financeiramente ineficientes na produção.

Para auditar um site orientado a evidências, não basta jogar a URL no Lighthouse. Se você está avaliando um e-commerce ou plataforma SaaS em Next.js, você precisa depurar a arquitetura. Este guia técnico detalha as engrenagens ocultas do Next.js (com foco no App Router) que ditam o seu sucesso orgânico.

1. O Prisma da Renderização: SSR, SSG e Client Components

A primeira regra para investigar se o JavaScript está afetando a renderização e o SEO em Next.js é analisar a fronteira entre Servidor e Cliente.

No novo modelo do App Router, tudo é um Server Component por padrão. Isso é perfeito para SEO. O HTML é gerado no servidor, sem enviar o JavaScript correspondente ao navegador.

O vazamento de SEO acontece quando desenvolvedores injetam a diretiva 'use client' no topo de componentes primários do layout apenas para usar um useState ou evento de clique.

Como Auditar:

Revise a árvore de componentes (Layout.tsx e page.tsx).
Se a página principal do produto (a vitrine) é forçada como 'use client', todo o conteúdo e links internos ali dentro dependerão de hidratação.
A Correção Cirúrgica: Isole a interatividade. O botão "Adicionar ao Carrinho" deve ser um Client Component importado dentro de uma Página de Produto que permanece como Server Component.

2. Metadados e a API `generateMetadata`

Até o Next.js 12 (Pages Router), injetávamos títulos e meta descrições com a tag <Head>. No App Router, a abordagem mudou para a Metadata API, que é muito mais robusta, mas fácil de quebrar.

O erro mais comum é a falta de dados dinâmicos em páginas de produtos (/produto/[slug]/page.tsx). Se as meta tags são geradas de forma assíncrona, elas devem bloquear a renderização até serem resolvidas.

Evidência de Auditoria (O que procurar no código):

// Padrão Incorreto ou Rígido (Fixo em páginas dinâmicas)
export const metadata = {
  title: 'Produto Padrão',
}

// Padrão Correto e SEO-Orientado
export async function generateMetadata({ params }): Promise<Metadata> {
  const produto = await fetchProduto(params.slug)
  
  // Tratamento vital de 404 na raiz
  if (!produto) return notFound()

  return {
    title: `${produto.nome} | Sua Loja`,
    description: produto.descricao_curta,
    alternates: {
      canonical: `https://sualoja.com/produto/${params.slug}`
    }
  }
}

Garanta que as canonicais e os parâmetros de URL estão sendo servidos via objeto alternates. Se o canonical for inserido via script manipulando o DOM, o Googlebot não o lerá corretamente.

3. Gestão de Status HTTP: O Perigo do "Soft 404"

Um dos piores cenários financeiros para operações de E-commerce ocorre quando um produto sai de estoque permanentemente e a URL passa a renderizar um componente visual dizendo "Produto Inexistente", mas o servidor continua respondendo com HTTP 200 OK.

Isso causa Soft 404s em massa, destruindo a confiança do bot. No Next.js, garantir o envio de status codes HTTP reais a partir do servidor é fundamental durante o processo de qualidade antes do deploy.

Auditoria de Status: No App Router, sempre que uma busca a um banco de dados dinâmico falhar, o código deve obrigatoriamente chamar a função notFound() do pacote next/navigation. Isso interrompe a execução, envia o cabeçalho HTTP 404 correto para o robô e renderiza o arquivo not-found.tsx.

Se o objetivo for um redirecionamento 301, a função redirect('/nova-rota', 'replace') deve ser usada no lado do servidor.

4. Estratégia de Sitemaps e Crawl Budget

O Next.js 13+ facilitou a criação de sitemaps dinâmicos através da geração do arquivo sitemap.ts. No entanto, gerar dinamicamente sitemaps pesados contendo milhões de linhas consultando o banco de dados on-the-fly a cada requisição de bot causa lentidão extrema.

Sitemaps em XML frequentemente geram erros silenciosos. A auditoria do sitemap Next.js deve verificar se há cache sendo aplicado na rota do sitemap.ts (ou sitemap.xml).

Verificação de Arquitetura:

Para sites acima de 50.000 páginas, o sitemap.ts nativo pode esgotar a memória do servidor Node.js (Vercel serverless function limits).
Avalie se a engenharia está dividindo os sitemaps (Sitemap Indexes) ou gerando-os de forma estática (Static Generation) no momento de build, via Cron Job ou Webhooks de CMS.

5. O Componente `<Image>` e o Diagnóstico de LCP

Você não audita performance de imagem no Next.js do mesmo modo que audita no WordPress. O componente nativo <Image /> (next/image) aplica otimização automática (.webp ou .avif) e previne Layout Shifts exigindo width e height.

Mas ele pode atuar contra o SEO se implementado cegamente. O erro principal ocorre na Hero Image (a principal imagem visível na dobra da página que dita o seu LCP). Por padrão, <Image> aplica loading="lazy". O Lazy Loading em uma imagem LCP atrasa drasticamente o tempo de pintura porque o navegador espera o script rodar antes de iniciar o download da imagem.

No seu diagnóstico de LCP, inspecione o código e procure pela imagem principal. Ela deve obrigatoriamente conter a flag priority.

Padrão Otimizado (Correção de LCP):

<Image
  src="/banner-principal.jpg"
  alt="Oferta de Black Friday"
  width={1200}
  height={600}
  priority={true} // Diz ao navegador: Faça o fetch disso imediatamente!
/>

Leia nosso guia sobre otimização de imagens e performance de LCP para entender as implicações do fetchpriority nos navegadores modernos.

6. Links e Pré-Carregamento (Prefetching)

Finalmente, audite a malha de links internos. Se os desenvolvedores usarem a tag <a> padrão do HTML5, eles perdem o recurso de prefetch (pré-carregamento) em segundo plano que o Next.js oferece.

Por outro lado, o uso excessivo de <Link> em páginas densas com centenas de links (como uma galeria de categorias) pode causar um engarrafamento na rede (network waterfall), pois o Next.js tenta baixar os metadados (payload JS) de todos os links visíveis na tela simultaneamente.

A Solução de Auditoria: Em listas imensas de links internos que não precisam de carregamento instantâneo, você deve auditar o código para garantir a configuração prefetch={false}.

<Link href="/categoria-pesada" prefetch={false}>
  Acessar Categoria
</Link>

Isso desativa o prefetch agressivo e economiza recursos do dispositivo do usuário e do servidor.

Conclusão: Next.js e o Futuro da Busca (AEO e SGE)

A promessa do Next.js só se cumpre com supervisão rigorosa. A arquitetura de Server Components e de APIs de dados não beneficia apenas o Google, ela está estruturando seu negócio para a Era Generativa.

A renderização dinâmica guiada por IA e as IAs que geram respostas na rede preferem consumir HTML rápido, limpo e estruturado. Se o seu projeto Next.js serve HTML denso e foca o JavaScript na interatividade real, você não precisará adaptar sua arquitetura para os novos modelos.

Use este artigo e adicione-o ao seu checklist de SEO Técnico pré-lançamento. Audite os componentes de servidor, valide a Metadata API, corrija seus Soft 404s e garanta que o Next.js funcione como um acelerador orgânico, não como um peso morto.

Respostas diretas

Perguntas frequentes

Next.js é automaticamente bom para SEO?

Não. Ele fornece as ferramentas para ser excepcional, mas permite configurações catastróficas. Fazer fetch de dados cruciais de SEO via `useEffect` no lado do cliente transforma seu site Next.js em um SPA problemático padrão.

Devo usar App Router ou Pages Router para o meu blog?

O App Router (React Server Components) é superior para performance e SEO porque envia zero JavaScript para o cliente em componentes estáticos. No entanto, exige uma curva de aprendizado para isolar componentes de cliente apenas onde há interatividade.

Como lidar com Status 404 dinâmicos no Next.js?

Use a função `notFound()` do Next.js após verificar que o dado não existe no banco. Isso força o servidor a retornar um HTTP 404 real. Apenas renderizar uma tela de 'Produto não encontrado' retornando HTTP 200 gera Soft 404s no Google.