SEO para Nuxt

TL;DR — Nuxt é o framework construído sobre Vue, e é bom para SEO por um motivo principal: em uma rota que mantém o padrão, ele constrói páginas no servidor, então os mecanismos de busca recebem uma página HTML completa em vez de uma página em branco que eles teriam que preencher sozinhos. Isso é uma configuração por rota, não uma garantia para todo o site — routeRules ou um ssr: false global podem transformar qualquer rota de volta em um shell vazio no estilo Vue puro. Verifique a rota real, não apenas o nome do projeto. A escolha mais importante que você fará é como cada rota é renderizada; todo o resto (meta tags, sitemaps) vem depois disso.

Por que Nuxt é bom para SEO — nas rotas que mantêm o padrão

Vue, por si só, constrói um aplicativo de página única: o servidor envia um shell HTML quase vazio, e o JavaScript preenche o conteúdo assim que é executado no navegador. Isso é complicado para a busca, porque a página parece vazia até que o JavaScript seja executado.

Nuxt é o “meta-framework” do Vue — um kit de ferramentas mais completo construído em torno do Vue — e seu padrão resolve esse problema. O Nuxt renderiza suas páginas no servidor primeiro (renderização no servidor, ou SSR), então quando o Google ou um visitante solicita uma página em uma rota que não teve o SSR desativado, eles recebem o HTML completo imediatamente. Evidência desta afirmação Nuxt universal rendering returns server-rendered HTML to the browser by default. Escopo: Nuxt default universal rendering. Confiança: alta · Verificado: 2026-07-14 Nuxt: Rendering modes Sem esperar pelo JavaScript. Essa é a única maior razão pela qual um site Nuxt pode ser mais fácil de indexar do que um aplicativo Vue puro — mas é um resultado rota por rota, não algo que o nome do framework garante. Uma rota com ssr: false, ou uma que depende de <ClientOnly> para seu conteúdo principal, abre mão dessa vantagem e entrega o mesmo problema de shell vazio que o Vue puro tem.

A decisão mais importante: renderização, por rota

Quando alguém solicita uma página específica, onde o HTML dela é construído? Essa é uma pergunta no nível de routeRules, não uma pergunta para todo o projeto — um aplicativo Nuxt pode misturar modos entre rotas. O Nuxt oferece algumas opções:

• Renderização no servidor (SSR) — o padrão. O servidor constrói a página completa em cada solicitação. Ótimo para SEO.
• Geração estática (SSG) — execute nuxt generate e o Nuxt constrói todas as suas páginas em arquivos HTML simples com antecedência. Também ótimo para SEO, e perfeito para blogs e documentação que não mudam a cada minuto.
• Modo SPA — a página é construída no navegador, como Vue puro. Evite isso para qualquer coisa que você queira encontrar na busca.

A boa notícia é que os padrões já estão apontados na direção certa. Você principalmente precisa evitar desativá-los **.

Adicionando títulos e meta tags

No Nuxt, você define o título da página e a meta descrição com uma função integrada chamada useSeoMeta(). Evidência desta afirmação Nuxt provides useSeoMeta for defining SEO and social metadata. Escopo: Current Nuxt composable. Confiança: alta · Verificado: 2026-07-14 Nuxt: useSeoMeta Você a coloca em uma página e passa seu título, descrição e imagem de compartilhamento social:

useSeoMeta({
  title: 'My Page Title',
  description: 'A concise, page-specific summary with the key information first',
})

Essa é a forma moderna e recomendada. (Existe uma função mais antiga chamada useHead() que ainda funciona e é usada para outras coisas no <head> da página, mas para meta tags de SEO use useSeoMeta().) O Google não tem um limite fixo de caracteres para meta descrição; os snippets dependem da consulta e são truncados para caber no dispositivo, então pré-visualize páginas importantes no idioma e script pretendidos em vez de codificar para uma cota.

O complemento opcional: os módulos de SEO do Nuxt

O núcleo do Nuxt não gera um robots.txt, um sitemap XML, imagens de compartilhamento social, dados estruturados ou URLs canônicas — essas são tarefas para pacotes separados e opcionais, não algo que nuxt.config.ts fornece por padrão. Um desenvolvedor chamado Harlan Wilton mantém um pacote gratuito da comunidade desses pacotes — instalado como @nuxtjs/seo — que cobre todos eles de uma vez. É um kit de ferramentas de terceiros, não parte do próprio Nuxt, então instalá-lo não torna automaticamente qualquer uma dessas saídas correta; você ainda confirma se o sitemap, as regras de robots e o schema que ele gera correspondem ao que você realmente deseja.

O que as pessoas entendem errado

As pessoas assumem que “Vue/Nuxt não pode estar no Google.” Isso era mais ou menos verdade para aplicativos Vue puro anos atrás — não é verdade para Nuxt com sua renderização no servidor. Os erros reais são coisas como desligar o SSR acidentalmente, ou bloquear seus arquivos JavaScript para que o Google não consiga montar a página.

Quer a versão mais aprofundada — o menu completo de modos de renderização, o ecossistema de módulos em detalhes, Core Web Vitals e os erros comuns com correções? Mude para a aba Avançado.

TL;DR — O padrão do Nuxt é a renderização no servidor, então uma rota que mantém esse padrão recebe um DOM completo em vez do shell vazio que um SPA Vue puro entrega — mas isso é um resultado por rota: ssr: false ou uma substituição de routeRules pode transformar qualquer rota em CSR ou híbrido, então teste a rota real, não o nome do projeto. A estratégia de renderização é a decisão fundamental — SSR (padrão), SSG (nuxt generate) ou routeRules híbrido — porque meta, schema e sitemaps vêm depois dela. Use useSeoMeta() para meta tags (useHead() para o resto do head, variantes somente no servidor quando você não precisa de reatividade), e trate o pacote @nuxtjs/seo do Harlan Wilton como um kit de ferramentas de terceiros opcional para robots/sitemap/OG/schema/canonical — não faz parte do núcleo do Nuxt, e não é prova de que sua saída está correta até você verificar. Nunca use renderização dinâmica (o Google a descontinuou). A renderização para rastreadores de IA varia por provedor — SSR/SSG maximiza a cobertura de HTML bruto. Além do HTML inicial, verifique hidratação/payload, presets de implantação e cache do Nitro, e o status HTTP direto de forma independente — o HTML do servidor sozinho não prova nenhum desses. As regras usuais de SEO para JavaScript ainda se aplicam: links reais <a href>, não bloqueie JS/CSS, observe o HTML renderizado vs. bruto.

Nuxt é a resposta do Vue para o problema de SPA

Vue, por si só, entrega um aplicativo de página única: um shell HTML mais JavaScript que monta o DOM no navegador. Nuxt é o meta-framework sobre Vue (rodando no motor de servidor Nitro no Nuxt 3, com Nuxt 4 seguindo em 2025), e toda a sua razão de existir — do ponto de vista de SEO — é que ele renderiza no servidor por padrão. Cada página chega como um documento HTML totalmente formado, que é exatamente o que o Googlebot quer ler sem ter que executar JavaScript primeiro. SEO de Vue puro é um tópico próprio com seus próprios modos de falha; aqui estou assumindo que você escolheu Nuxt justamente para não ter que lutar contra o problema de SPA.

Este é o mesmo ponto que faço sobre JavaScript em geral: “qualquer configuração de SSR, renderização estática ou pré-renderização vai funcionar bem para mecanismos de busca. Gatsby, Next, Nuxt, etc., são todos ótimos.” Os padrões do Nuxt estão apontados na direção certa. A maioria dos problemas de SEO com Nuxt são pessoas desligando esses padrões, ou empilhando erros por cima deles.

A estratégia de renderização é a base — decidida por rota, não por projeto

Antes de meta tags, antes de schema, antes de sitemaps, a pergunta que decide tudo é como o HTML é produzido para esta rota específica? O Nuxt documenta a renderização universal (no servidor) como o padrão de todo o aplicativo, mas esse padrão não é uma garantia no nível da rota: um ssr: false global muda todo o aplicativo para renderização no cliente, e routeRules pode atribuir um modo diferente a qualquer padrão de URL. “Este é um aplicativo Nuxt” não te diz nada sobre como uma página específica renderiza — você tem que verificar a rota. O Nuxt oferece cinco estratégias:

A documentação oficial do Nuxt é direta sobre por que a renderização no lado do cliente é a escolha errada para conteúdo: “Indexar e atualizar o conteúdo entregue via renderização no lado do cliente leva mais tempo”, enquanto com a renderização no servidor (universal) “os rastreadores da web podem indexar diretamente o conteúdo da página.” Evidência desta afirmação Nuxt documents that universal rendering delivers HTML content immediately and allows crawlers to index it directly. Escopo: Nuxt rendering; no indexing guarantee. Confiança: alta · Verificado: 2026-07-14 Nuxt: Rendering modes (Documentação de renderização do Nuxt.) CSR (ssr: false) é posicionado para back-office, dashboards e jogos — não para qualquer coisa que você queira indexada.

A renderização híbrida é a jogada de mestre para sites grandes. Regras de rota em nuxt.config.ts permitem definir o modo de renderização e cache por padrão de URL:

routeRules: {
  '/blog/**':     { prerender: true },        // SSG for the blog
  '/product/**':  { swr: 3600 },              // ISR-style: regenerate hourly
  '/admin/**':    { ssr: false },             // SPA for the admin area
  '/checkout/**': { ssr: true },              // always-fresh SSR
}

swr (stale-while-revalidate) e isr (regeneração estática incremental) geram uma página estaticamente e depois a atualizam em segundo plano — ideal para e-commerce com alto número de páginas ou notícias onde uma reconstrução completa a cada alteração não é prática. Nuxt Islands (<NuxtIsland>) renderizam componentes sem enviar JavaScript do lado do cliente, reduzindo o custo de hidratação e ajudando o INP — a Core Web Vital que mais frequentemente é o problema em aplicativos Nuxt.

Como verificar o que você realmente enviou: View Source mostra o HTML bruto que o servidor enviou; se o seu conteúdo estiver lá, você está renderizando no servidor. O painel Elements do DevTools mostra o DOM renderizado. E a ferramenta URL Inspection do GSC mostra o que o Google realmente buscou e renderizou — a fonte da verdade. Não confie em “parece bom no meu navegador.”

Como o Googlebot lida com um aplicativo Nuxt

O Google processa qualquer aplicativo JavaScript em três fases — rastreamento, renderização, indexação — e o problema é o tempo: a renderização acontece em uma fila, não instantaneamente. Como eu disse no meu guia de SEO para JavaScript, o renderizador é paciente — “não há um tempo limite fixo para o renderizador… Ele é realmente paciente, e você não deve se preocupar.” Mas paciente não é o mesmo que rápido para conteúdo novo. Se você enviar uma página renderizada no cliente, seu conteúdo não existe para o Google até que essa onda de renderização seja executada; SSR e SSG fecham essa lacuna porque o HTML está completo na primeira busca.

Mais duas coisas importam em escala. Renderizar JavaScript é caro — da minha palestra de 2019 JavaScript SEO (Ungagged), os custos de rastreamento aumentam em cerca de 20× quando o Google precisa renderizar (direcional, mas a ordem de grandeza ainda se mantém). E o Google adota a diretiva mais restritiva entre o HTML bruto e o renderizado — então um noindex injetado por JavaScript vencerá um index no HTML bruto, e vice-versa. Um canonical injetado via JavaScript é respeitado apenas se não houver um canonical no HTML bruto já. Mantenha seus sinais de robots e canonical no HTML renderizado no servidor, o que o Nuxt faz por você quando o SSR está ativado.

A realidade dos rastreadores de IA

Esta é a novidade de 2026. Rastreadores de IA — GPTBot, ClaudeBot, PerplexityBot e os demais — geralmente não executam JavaScript de forma alguma. Eles indexam o HTML bruto e nada mais. Portanto, uma página Nuxt renderizada no cliente é efetivamente invisível para os mecanismos de resposta de IA. SSR ou SSG não é apenas melhor para o Google aqui; é o preço de entrada para a otimização para mecanismos de resposta também. Se você quer que seu conteúdo seja citado pelo ChatGPT, Perplexity ou Claude, ele precisa estar no HTML na primeira busca.

Além do HTML inicial: payload, hidratação e códigos de status

Obter HTML do servidor com seu conteúdo é necessário, mas não suficiente — várias coisas ainda podem dar errado depois dessa primeira resposta, e “eu verifiquei o View Source” não cobre isso:

• Payload e hidratação. A renderização universal envia o HTML e um payload de dados serializado que o cliente usa para hidratar — anexar ouvintes de eventos e continuar de onde o servidor parou — sem buscar novamente. O HTML do servidor parecer correto não prova que a hidratação foi bem-sucedida, que a navegação do cliente reproduz o mesmo conteúdo ou que o payload não está desatualizado. Se uma página parece boa no primeiro carregamento, mas quebra após uma mudança de rota no lado do cliente, isso é um problema de hidratação/payload, não um problema de modo de renderização.
• <ClientOnly> e conteúdo somente no navegador. Envolver algo em <ClientOnly> — comum para widgets que dependem de APIs do navegador — significa que está ausente na resposta do servidor, mesmo em uma rota universal. Se o seu conteúdo principal, um link importante ou suas meta tags acabarem dentro de um limite somente do cliente, rastreadores e bots de IA que apenas leem o HTML bruto não o verão, independentemente da sua configuração de modo de renderização. Inspecione a resposta real, não apenas a configuração do modo de renderização.
• Códigos de status e redirecionamentos não são autocertificáveis. Uma página de erro do Nuxt renderizada no navegador, ou um redirecionamento orientado por navigateTo()/composable, não prova por si só qual status HTTP a resposta direta do servidor enviou. A orientação do Google é explícita de que códigos de status significativos importam para rastreamento e indexação — confirme o cabeçalho real com curl -I, não o que a página de erro renderizada no cliente exibe.

Nada disso é um argumento contra a renderização universal — é o lembrete de que “o HTML é renderizado no servidor” é a primeira verificação, não a última.

Nitro, presets de implantação e limites de cache

A saída do servidor do Nuxt é construída pelo Nitro, e o Nitro compila de forma diferente dependendo do preset de implantação que você segmenta (servidor Node, Cloudflare, Vercel, Netlify, estático e outros). Isso importa para SEO porque presets e adaptadores podem diferir nas APIs de runtime disponíveis, comportamento de cache, suporte a streaming, implantação regional e acesso ao sistema de arquivos — uma regra de rota ou manipulador de servidor que funciona sob um preset não é garantido que se comporte de forma idêntica sob outro. Duas consequências que valem a pena testar explicitamente em vez de assumir:

• Chaves de cache e invalidação são específicas da rota, não automáticas. Regras de rota swr e isr armazenam em cache e regeneram a saída, mas uma chave de cache errada, invalidação ausente ou um cabeçalho de cache definido pela sua plataforma de implantação pode servir HTML desatualizado, personalizado ou inconsistente para rastreadores. Verifique a idade real da resposta e quaisquer cabeçalhos Cache-Control/Age em uma URL ao vivo, não apenas a configuração routeRules.
• A paridade de produção não é garantida pelo comportamento de staging. Uma rota renderizando corretamente no dev local ou em uma implantação de preview não confirma que o preset de produção produz a mesma saída — rotas de servidor, redirecionamentos e tratamento de erros vivem na camada de servidor do Nitro, e essa camada é a parte mais provável de diferir por destino. Teste a URL de produção diretamente após qualquer mudança de implantação, da mesma forma que você verificaria o modo de renderização.

Meta tags: useSeoMeta() e useHead()

O gerenciamento de head do Nuxt roda no Unhead, e ele oferece dois composables para trabalhos diferentes.

useSeoMeta() é o que você deve usar para SEO e meta tags sociais. É uma API plana e type-safe com parâmetros tipados. Evidência desta afirmação useSeoMeta is a typed Nuxt API for SEO and social meta tags. Escopo: Current Nuxt composable. Confiança: alta · Verificado: 2026-07-14 Nuxt: useSeoMeta Ela ajuda a evitar o clássico bug do Open Graph de usar name onde você precisava de property:

useSeoMeta({
  title: 'My Page Title',
  ogTitle: 'My Page Title',
  description: 'Concise page-specific description with the key information first',
  ogDescription: 'Concise social description tailored to this page',
  ogImage: 'https://mysite.com/og-image.png', // must be an absolute URL
  twitterCard: 'summary_large_image',
})

useHead() é a ferramenta de head de uso geral para todo o resto — scripts, tags de link, atributos de body e modelos de título:

useHead({
  titleTemplate: '%s · My Site Name',
  htmlAttrs: { lang: 'en' },
})

O padrão confiável de camadas é: padrões estáticos (charset, viewport, favicon) em nuxt.config.ts → modelo de título para todo o site e padrões globais de OG em app.vue → substituições específicas de página via useSeoMeta() no componente da página. Um erro comum é colocar useSeoMeta() em um layout em vez da página, o que sobrescreve tags específicas da página com tags genéricas. E como os mecanismos de busca leem o carregamento inicial, as meta tags de SEO geralmente não precisam ser reativas — useServerHead() pula a reexecução no lado do cliente.

Qual API, e o que ela realmente prova:

Chamar um desses composables informa que a API foi executada — isso por si só não informa o que uma resposta direta do servidor ou uma mudança de rota no lado do cliente realmente emite. Confirme com Ver código-fonte ou curl, não apenas “Eu chamei useSeoMeta().”

O ecossistema de módulos @nuxtjs/seo (Harlan Wilton) — opcional, não essencial

O núcleo do Nuxt não inclui um sitemap, um robots.txt, geração de imagens OG ou Schema.org por padrão — esses estão fora das primitivas do próprio Nuxt (useHead, useSeoMeta, regras de rota, modos de renderização). A comunidade preenche essa lacuna com o @nuxtjs/seo de Harlan Wilton — um pacote guarda-chuva de terceiros, instalado separadamente (nuxtseo.com, atualmente na v5.x, mantido ativamente, direcionado ao Nuxt 3,16+ e Nuxt 4) que agrupa seis módulos. Instalá-lo fornece geração de sitemap, robots, imagem OG e schema — isso por si só não garante que a saída esteja correta para suas rotas; verifique o que ele produz da mesma forma que verificaria qualquer outra coisa:

Instale o pacote inteiro com npx nuxt module add seo, ou pegue módulos individuais (npx nuxt module add sitemap robots). Alguns comportamentos que vale a pena conhecer:

• @nuxtjs/sitemap gera automaticamente a partir do seu diretório pages/ mais rotas dinâmicas, divide em um índice de sitemap automaticamente após 50 000 URLs, suporta sitemaps multilíngues com i18n e tem suporte integrado ao IndexNow. Uma coisa para acertar: o Google ignora changefreq e priority; apenas um lastmod preciso importa, e somente quando o conteúdo realmente muda.
• @nuxtjs/robots gera robots.txt, a meta tag robots e o cabeçalho X-Robots-Tag — e por padrão ele desautoriza todos os rastreadores em ambientes não de produção, que é exatamente a armadilha de indexação em staging que afeta builds headless. Ele também oferece regras por bot, então você pode bloquear o GPTBot especificamente enquanto deixa todos os outros em paz (seja intencional — bloqueie um rastreador de IA e ele não vai citar você).
• nuxt-seo-utils lida com URLs canônicas e, utilmente, remove parâmetros de rastreamento (utm_*, fbclid, gclid) das canônicas automaticamente.

nuxt/image e Core Web Vitals

@nuxt/image é o módulo de imagens: srcset responsivo automático, formatos modernos (WebP/AVIF), otimização integrada por meio de provedores de CDN e carregamento preguiçoso. Duas regras carregam a maior parte do valor de SEO:

• Nunca faça lazy-load da imagem LCP. Sua imagem hero deve carregar com eager; fazer lazy-load atrasa seu Largest Contentful Paint.
• Sempre defina width e height para que o navegador reserve espaço e você não sofra um impacto de Cumulative Layout Shift.

<NuxtImg
  src="/hero.jpg"
  width="1200"
  height="630"
  alt="Descriptive alt text"
  :loading="isHeroImage ? 'eager' : 'lazy'"
  format="webp"
/>

As metas de 2026 a buscar (p75): LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Em apps Nuxt, INP é o que tende a sofrer porque a hidratação cria atraso de entrada — que é exatamente para isso que servem Nuxt Islands e <NuxtIsland>.

Nuxt Content + SEO

Se você está usando @nuxt/content (o módulo de conteúdo markdown/MDX), a integração com @nuxtjs/seo é direta, mas tem um detalhe de ordem: carregue @nuxtjs/seo antes de @nuxt/content no seu array de módulos. Você pode então definir SEO no frontmatter do conteúdo (title, description, robots, ogImage, schemaOrg) e puxá-lo para o seu template [slug].vue com useSeoMeta() após buscar o conteúdo. Este é a versão nativa do Nuxt do padrão headless-CMS, e a mesma disciplina de “reconstruir o que o plugin fez” se aplica.

Erros comuns de SEO no Nuxt

1. Usar o modo SPA (ssr: false) para conteúdo que você quer indexado. O erro mais caro — e o que te torna invisível para crawlers de IA.
2. URLs relativas para imagens OG. ogImage deve ser uma URL absoluta ou as prévias sociais quebram.
3. useSeoMeta() em um layout em vez da página — tags genéricas sobrescrevem as específicas da página.
4. Não verificar o HTML renderizado — View Source ≠ DevTools ≠ o que o Google renderizou. Use URL Inspection.
5. Bloquear JS/CSS no robots.txt — o Google não renderiza a partir de arquivos bloqueados.
6. Deixar o noindex/disallow de staging no lugar após o lançamento (ou, inversamente, esquecer que @nuxtjs/robots bloqueia não-prod por padrão e se perguntar por que prod está ok, mas um env customizado não está).
7. Fazer lazy-load da imagem LCP — derruba seu LCP.
8. Faltando width/height nas imagens — CLS.
9. changefreq/priority em sitemaps — o Google os ignora; apenas lastmod conta.
10. Recorrer a dynamic rendering. O Google depreciou isso — “dynamic rendering is a workaround and not a long-term solution” (tradução) «dynamic rendering é um workaround e não uma solução de longo prazo» — e isso só serve para os mecanismos que você configurar, perdendo Bing e todo crawler de IA. Com Nuxt você nunca precisa disso: SSR e SSG já entregam HTML completo para crawlers.

llms.txt e AEO

llms.txt é um arquivo de texto simples — primo do robots.txt — que ajuda ferramentas de IA a navegar seu conteúdo. O módulo nuxt-llms gera automaticamente /llms.txt e /llms-full.txt a partir do Nuxt Content. Desde o final de 2025, seus principais consumidores são servidores MCP e ferramentas de codificação com IA (Cursor, Claude Code), em vez de ChatGPT ou Perplexity diretamente, e é mais útil para sites de documentação e blogs técnicos — menos para e-commerce ou notícias. Vale a pena adicionar se você tem um site de docs/dev; não é prioridade caso contrário.

Onde isso se encaixa

SEO no Nuxt é realmente uma aplicação concreta de JavaScript SEO através das próprias convenções do Nuxt — e se sobrepõe fortemente ao tópico SEO para CMS headless quando seu frontend Nuxt puxa de um backend headless. Os princípios não mudam; o Nuxt apenas oferece bons padrões e um ecossistema forte de módulos para implementá-los.

Resumo de IA

Uma visão condensada da versão Avançada:

• Nuxt é o meta-framework do Vue, e sua vantagem de SEO é um padrão: renderização no servidor. Uma rota que mantém esse padrão entrega HTML completo, não a casca vazia que um SPA Vue simples entrega — mas é um resultado por rota, não uma garantia para todo o projeto. ssr: false ou uma substituição de routeRules pode mudar qualquer rota para CSR ou híbrido, então verifique a rota real.
• A estratégia de renderização é a base, decidida por rota — ela decide tudo antes de meta, schema ou sitemaps. Modos: SSR (padrão), SSG (nuxt generate), híbrido (routeRules), SPA (ssr: false, evite para conteúdo indexado), edge.
• routeRules híbridos misturam modos por URL; swr/isr regeneram em segundo plano; Nuxt Islands reduzem o custo de hidratação e ajudam o INP.
• Googlebot rastreia → renderiza (na fila, não instantâneo) → indexa; aplica a diretiva mais restritiva entre HTML bruto vs. renderizado. A renderização custa ~20× o rastreamento. SSR/SSG fecham a lacuna de tempo.
• A renderização por rastreadores de IA é específica do provedor — CSR depende da execução no cliente que não é coberta por um contrato compartilhado, então SSR/SSG maximiza a visibilidade para IA.
• Além do HTML de primeira carga: verifique hidratação/payload de forma independente (HTML do servidor ≠ prova de hidratação bem-sucedida ou paridade de navegação no cliente), fique atento a <ClientOnly> escondendo conteúdo dos rastreadores mesmo em rotas universais, e confirme status HTTP/redirecionamentos diretos com curl -I em vez de confiar em uma página de erro renderizada no cliente.
• Nitro e presets de implantação (Node, Cloudflare, Vercel, Netlify, estático) podem diferir em APIs de runtime, cache, streaming e regiões — teste cabeçalhos de cache e paridade de produção por rota, não presuma que os presets se comportam de forma idêntica.
• Meta tags: useSeoMeta() para SEO/social (type-safe), useHead() para o resto do head, variantes somente no servidor quando reatividade não é necessária. Camada: nuxt.config.ts → app.vue → página. Não coloque useSeoMeta() em um layout. Imagens OG precisam de URLs absolutas. Chamar uma API prova que a API rodou, não o que uma resposta direta emite — confirme com View Source/curl.
• @nuxtjs/seo (Harlan Wilton) é um kit de ferramentas opcional de terceiros (v5.x, mantido ativamente, Nuxt 3,16+/4.x) — não faz parte do núcleo do Nuxt. Ele agrupa robots, sitemap, imagem OG, Schema.org, canônico e verificador de links, mas instalá-lo não prova por si só a saída correta. Sitemap: apenas lastmod importa. Robots: bloqueia não-prod por padrão; regras de IA por bot.
• @nuxt/image + CWV: nunca faça lazy-load da imagem LCP; sempre defina width/height (CLS). Metas: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.
• Não use renderização dinâmica — o Google a descontinuou; o SSR/SSG do Nuxt já serve HTML completo.

Documentação oficial

Documentação de fonte primária do Nuxt e dos mecanismos de busca.

Nuxt

• Nuxt — Conceitos de renderização — renderização universal, no cliente e híbrida (routeRules), e por que os rastreadores preferem rotas renderizadas no servidor.
• Nuxt — SEO e Meta (primeiros passos) — useSeoMeta(), useHead() e gerenciamento de head.
• Nuxt — composable useSeoMeta — a referência da API meta type-safe, incluindo uso somente no servidor.
• Nuxt — Server Engine (Nitro) — presets de implantação, saída multiplataforma e onde o comportamento de runtime/cache pode divergir.
• Nuxt — Ciclo de vida do Nuxt — renderização no servidor, transferência de payload e hidratação como etapas distintas.
• Nuxt Image — <NuxtImg>, formatos responsivos e configuração de provedor para Core Web Vitals.
• @nuxtjs/seo no Nuxt Modules — a entrada do catálogo de módulos: versão atual, downloads e que é um pacote instalado separadamente.

Google

• Entenda os fundamentos de SEO para JavaScript — o pipeline de rastreamento → renderização → indexação e links rastreáveis (independente de framework; a documentação do Google não menciona o Nuxt pelo nome).
• Dynamic Rendering (solução alternativa obsoleta) — por que o Google o tornou obsoleto e o que usar em seu lugar (SSR, renderização estática, hidratação).

Citações da fonte

Declarações oficiais do Nuxt, do Google e de meus próprios escritos. Cada link de mecanismo de busca / Nuxt é um link profundo que salta para a passagem citada na página de origem.

Nuxt — renderização para SEO

• “Indexing and updating the content delivered via client-side rendering takes more time.” (tradução) «Indexar e atualizar o conteúdo entregue via renderização no lado do cliente leva mais tempo.» — Documentação de renderização do Nuxt. Ir para a citação
• “Web crawlers can directly index the page’s content, which makes Universal rendering a great choice for any content that you want to index quickly.” (tradução) «Os rastreadores da web podem indexar diretamente o conteúdo da página, o que torna a renderização Universal uma ótima escolha para qualquer conteúdo que você queira indexar rapidamente.» — Documentação de renderização do Nuxt. Ir para a citação

Google — processamento de JavaScript e dynamic rendering

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (tradução) «O Google processa aplicativos web JavaScript em três fases principais: 1. Rastreamento 2. Renderização 3. Indexação.» — Documentação do Google Search Central. Ir para a citação
• “Dynamic rendering is a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.” (tradução) «O dynamic rendering é uma solução alternativa e não uma solução de longo prazo para problemas com conteúdo gerado por JavaScript nos mecanismos de busca. Em vez disso, recomendamos que você use renderização no servidor, renderização estática ou hidratação como solução.» — Documentação do Google Search Central. Ir para a citação

Patrick Stox (meu próprio trabalho — JavaScript SEO: A Definitive Guide)

• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (tradução) «Qualquer tipo de configuração de SSR, renderização estática e pré-renderização será adequada para os mecanismos de busca. Gatsby, Next, Nuxt, etc., são todos ótimos.»
• “There is no fixed timeout for the renderer… It’s really patient, and you should not be concerned.” (tradução) «Não há um tempo limite fixo para o renderizador… Ele é realmente paciente, e você não deve se preocupar.»
• “JavaScript is not bad for SEO, and it’s not evil. It’s just different from what many SEOs are used to.” (tradução) «JavaScript não é ruim para SEO, e não é maligno. É apenas diferente do que muitos profissionais de SEO estão acostumados.»

Checklist de SEO para Nuxt

Uma verificação rápida para confirmar que um site Nuxt está configurado para rastreadores de busca e IA:

• O conteúdo que você quer indexar é renderizado no servidor ou no momento do build (SSR ou SSG) — não em modo SPA (ssr: false).
• Confirmado via View Source que o conteúdo importante está no HTML bruto, e via URL Inspection que o Google o renderiza.
• useSeoMeta() está em componentes de página, não em um layout compartilhado que sobrescreve as tags da página.
• ogImage usa uma URL absoluta (não relativa).
• Um template de título é definido uma vez em app.vue; títulos/descrições por página são únicos.
• @nuxtjs/sitemap está gerando um sitemap XML; lastmod está preciso e você não está dependendo de changefreq/priority.
• @nuxtjs/robots está configurado; o auto-bloqueio fora de produção não está sendo aplicado acidentalmente à produção.
• robots.txt não bloqueia seu JS/CSS.
• Canônicos são absolutos e por página (nuxt-seo-utils).
• A imagem LCP carrega eagerly (não lazy); todas as imagens têm width/height (CLS).
• Links reais <a href> / <NuxtLink> para navegação — sem roteamento via <div @click>.
• Se estiver usando @nuxt/content, @nuxtjs/seo é carregado antes dele no array de módulos.
• Renderização dinâmica não está em uso em nenhum lugar.

Os modelos mentais

1. A estratégia de renderização vem primeiro. Meta tags, schema e sitemaps são consequência de uma decisão: como o HTML é produzido. Responda “este conteúdo é renderizado no servidor, gerado estaticamente ou renderizado no cliente?” antes de depurar qualquer outra coisa.

2. SSR é o padrão — seu trabalho é principalmente não quebrá-lo. O Nuxt aponta os padrões na direção certa. A maioria das falhas de SEO no Nuxt é alguém definindo ssr: false, bloqueando JS/CSS ou injetando sinais via JavaScript que conflitam com o HTML bruto.

3. Escolha o modo de renderização pelo tipo de conteúdo.

• Majoritariamente estático (blog, docs, marketing) → SSG (prerender: true).
• Sempre fresco / dinâmico → SSR.
• Conteúdo por hora/dia querendo velocidade estática → swr/isr.
• Atrás de login, não indexado → SPA (ssr: false) é aceitável.
• Conteúdo público que você quer ranquear ou citado por IA → nunca SPA.

4. HTML primeiro, JS segundo para cada sinal. Conteúdo, meta, canônico, diretivas de robots e links pertencem ao HTML renderizado no servidor. O Google adota a diretiva mais restritiva entre bruto vs. renderizado; crawlers de IA veem apenas o bruto. SEO injetado via JS é um fallback, não o plano.

5. Use os módulos, mas entenda o que eles fazem. @nuxtjs/seo economiza trabalho, mas o auto-bloqueio de robots fora de produção, a realidade do sitemap apenas com lastmod e os canônicos de URL absoluta ainda são responsabilidade sua.

Nuxt SEO — cheat sheet

Modos de renderização

Composables

Módulos @nuxtjs/seo

Regras rápidas

• Instale tudo: npx nuxt module add seo.
• Imagens OG: somente URLs absolutas.
• Imagem LCP: loading="eager"; todas as imagens precisam de width/height (CLS).
• Metas de CWV: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.
• Nunca bloqueie JS/CSS no robots.txt.
• Renderização dinâmica: obsoleta — o SSR/SSG do Nuxt a substitui.
• Crawlers de IA: sem JavaScript → o conteúdo SPA é invisível para eles.

Veja o que uma página Nuxt realmente envia

Toda a questão de SEO do Nuxt se resume a uma verificação: o seu conteúdo está no HTML bruto que o servidor envia, ou somente depois que o JavaScript é executado? Se estiver no HTML bruto, você está fazendo renderização no servidor e os crawlers (e bots de IA) conseguem lê-lo.

Busque o HTML bruto e procure pelo seu conteúdo

macOS / Linux:

# Raw HTML as the server sends it — before any client JS runs
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your headline actually in the server HTML? (empty = client-rendered)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

Se o seu texto aparece no navegador, mas está ausente do raw.html, a página é renderizada no cliente — mude a rota para SSR ou faça a pré-renderização. (Um curl simples não executa JS; para o DOM renderizado, use a URL Inspection ou um crawler headless-Chrome.)

Confirme que você não está bloqueando JS/CSS

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_nuxt|_ipx|assets)"

Um Disallow que corresponda a /_nuxt/ (a saída de build do Nuxt) ou /_ipx/ (o otimizador @nuxt/image) quebrará a renderização — quase sempre um erro.

Trecho de configuração estática (nuxt.config.ts)

export default defineNuxtConfig({
  modules: ['@nuxtjs/seo'],          // robots, sitemap, og-image, schema-org, utils
  site: { url: 'https://mysite.com' }, // required for absolute canonicals + sitemap
  routeRules: {
    '/blog/**':  { prerender: true },  // SSG for content
    '/admin/**': { ssr: false },       // SPA for the dashboard (won't be indexed)
  },
})

Ferramentas para SEO do Nuxt

• URL Inspection (Google Search Console) — a fonte da verdade. Execute um teste ao vivo e verifique o HTML renderizado, a captura de tela e os recursos da página para confirmar que o seu conteúdo Nuxt realmente renderizou e que nada está bloqueado.
• @nuxtjs/seo / nuxtseo.com — o pacote de módulos do Harlan Wilton; o painel de ferramentas de desenvolvimento mostra os seus robots, sitemap, schema e imagens OG gerados em desenvolvimento.
• Nuxt DevTools — inspecione as tags de head, as regras de rota e qual modo de renderização cada rota está usando.
• Rich Results Test — confirme se o JSON-LD do nuxt-schema-org está presente na saída renderizada após qualquer mudança de renderização.
• Ahrefs Site Audit / Screaming Frog (modo de renderização JS) — rastreie com a renderização JS ativada vs. desativada para comparar o HTML bruto vs. o renderizado em todo o aplicativo Nuxt e detectar lacunas de CSR.
• Lighthouse / PageSpeed Insights — Core Web Vitals (LCP, INP, CLS) para o trabalho com @nuxt/image e Nuxt Islands.
• Bing Webmaster Tools — a visão de rastreamento/índice do Bing e onde as submissões do IndexNow aparecem.

Erros de SEO do Nuxt a evitar

Erros concretos que aparecem repetidamente em sites Nuxt reais — evite-os antes que entrem em produção, em vez de diagnosticá-los depois que o tráfego cair.

Ativando ssr: false em conteúdo que você quer indexar

O erro de SEO do Nuxt mais caro de todos. O modo SPA envia o mesmo problema de casca vazia que o Vue puro tem — os mecanismos de busca precisam esperar uma fila de renderização para preencher o conteúdo. Os contratos de renderização de crawlers de IA variam por provedor, então um crawler que busca apenas o HTML inicial perderá o conteúdo da página.

Por que está errado: você está abrindo mão voluntariamente do único padrão (SSR) que torna o Nuxt mais fácil de indexar do que o Vue puro.

O que fazer em vez disso: deixe ssr: true (o padrão) para qualquer coisa pública e indexável. Reserve ssr: false para superfícies genuinamente não indexadas — painéis com login, painéis administrativos — via routeRules, não com uma mudança global de configuração.

Colocando useSeoMeta() em um layout compartilhado

Definir título/descrição dentro de um componente de layout parece eficiente — um lugar, aplica-se em todos os lugares — mas significa que toda página que usa esse layout recebe as mesmas tags genéricas, e chamadas useSeoMeta() no nível da página podem ser sobrescritas dependendo da ordem de renderização.

Por que está errado: títulos e descrições únicos e específicos da página são sinais básicos de relevância; um padrão no nível do layout os colapsa todos em uma única string.

O que fazer em vez disso: defina fallbacks globais uma vez em app.vue (template de título, padrões de OG), depois chame useSeoMeta() dentro de cada componente de página com o título e a descrição reais dessa página.

Enviando uma URL ogImage relativa

ogImage: '/social.png' parece correto no navegador e falha completamente quando Facebook, LinkedIn ou X tentam buscá-la, porque os crawlers sociais não resolvem caminhos relativos contra o seu site.

Por que está errado: as plataformas sociais precisam de uma URL absoluta para buscar a imagem; um caminho relativo não resolve nada do lado delas.

O que fazer em vez disso: sempre passe uma URL completa https:// e defina site.url em nuxt.config.ts para que os módulos do @nuxtjs/seo possam construir URLs absolutas para você automaticamente.

Recorrendo à renderização dinâmica

Servir um snapshot pré-renderizado para bots conhecidos e o SPA para todos os outros era um workaround legítimo anos atrás. O Google desde então chamou isso diretamente: “dynamic rendering is a workaround and not a long-term solution.” (tradução) «renderização dinâmica é um workaround e não uma solução de longo prazo.»

Por que está errado: ele serve apenas os bots que você configura, perde todos os outros (Bing, a maioria dos crawlers de IA) e adiciona infraestrutura real para manter — para um problema que o próprio SSR/SSG do Nuxt já resolve.

O que fazer em vez disso: use SSR ou nuxt generate e pule a renderização dinâmica inteiramente. Não há cenário em que um site Nuxt precise disso.

Bloqueando /_nuxt/ ou /_ipx/ em robots.txt

Um Disallow: /assets/ genérico ou uma regra de robots excessivamente zelosa pode acidentalmente capturar o diretório de saída de build do Nuxt (/_nuxt/) ou o caminho do otimizador @nuxt/image (/_ipx/).

Por que está errado: se o Googlebot não puder buscar o JS/CSS que constrói a página, ele não pode confirmar que sua saída SSR é o que parece — e qualquer aprimoramento no lado do cliente silenciosamente para de renderizar para ele.

O que fazer em vez disso: nunca desallow caminhos de saída de build ou de otimizador de imagem. Verifique robots.txt após cada deploy que toque em configuração de rota ou módulo, não apenas uma vez no lançamento.

Deixando o bloco de robots de não produção ativo após o lançamento

@nuxtjs/robots desallow todos os crawlers em ambientes de não produção por padrão — uma boa rede de segurança para staging, mas ele lê variáveis de ambiente para decidir, e um NODE_ENV mal configurado ou uma configuração de preview-deploy pode fazer com que ele dispare em produção também.

Por que está errado: o site parece completamente normal no navegador enquanto robots.txt silenciosamente desallow tudo, e nada é indexado até que alguém perceba.

O que fazer em vez disso: após qualquer deploy ou mudança de ambiente, busque https://yoursite.com/robots.txt diretamente e confirme que não é um Disallow: / genérico.

KPIs contínuos para SEO Nuxt

Os números contínuos a acompanhar uma vez que sua configuração de renderização esteja correta — não verificações únicas, mas sinais recorrentes que capturam regressões conforme o aplicativo muda.

Core Web Vitals (LCP, INP, CLS)

O que isso diz a você: se visitantes reais estão recebendo uma página rápida e estável — diretamente afetado pelo custo de hidratação/Ilhas Nuxt (INP) e escolhas de carregamento de imagem (LCP, CLS).

Como obter: dados de campo do Chrome UX Report via /tools/crux-tracker/ ou /tools/cwv-checker/; dados de laboratório do Lighthouse para verificações pré-lançamento.

Benchmark / faixa realista: os limites “bons” publicados pelo Google são LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 no 75º percentil — essas são as linhas de aprovação/reprovação que o próprio CrUX usa, não um número que estou inventando. Onde você cai dentro de “bom” depende fortemente do peso das suas imagens e de quanto você hidrata.

Cadência: os dados de campo do CrUX atualizam em uma janela contínua de 28 dias — verifique mensalmente, e imediatamente após qualquer mudança em imagens, fontes ou hidratação.

Paridade entre HTML renderizado e bruto

O que isso indica: se o conteúdo que os mecanismos de busca e os rastreadores de IA conseguem ver (o HTML bruto) corresponde ao que um visitante vê no navegador (o DOM renderizado) — o principal risco de SEO do Nuxt se ssr for alterado ou uma rota regredir para CSR.

Como obter: /tools/render-gap/ compara o HTML bruto com o renderizado para uma URL; para a visão autoritativa do Google, use a Inspeção de URL do GSC → “Ver página rastreada”.

Referência / faixa realista: esta é uma verificação binária, não uma faixa — seu conteúdo principal (título, corpo do texto, links internos) deve estar presente no HTML bruto, ponto final. Qualquer lacuna em uma página que você queira indexada ou citada é uma regressão a corrigir, não um número a tolerar.

Frequência: após cada deploy que altere routeRules, layouts ou a configuração ssr; verifique modelos-chave mensalmente caso contrário.

Cobertura de indexação (relatório de indexação de páginas)

O que isso indica: quantas das suas URLs enviadas o Google realmente indexou e por que o restante foi excluído (duplicado, rastreado mas não indexado, bloqueado, etc.) — o sinal downstream no qual os problemas de renderização acabam se manifestando.

Como obter: Search Console → relatório de indexação de páginas, filtrado para os padrões de URL do seu site Nuxt.

Referência / faixa realista: não há uma porcentagem saudável universal — depende de quantas URLs quase duplicadas ou finas sua estrutura de rotas gera. Acompanhe a tendência e os motivos de exclusão, não um número-alvo.

Frequência: semanalmente durante e após uma migração de modo de renderização; mensalmente caso contrário.

Acesso de rastreadores de IA

O que isso indica: se GPTBot, ClaudeBot, PerplexityBot e rastreadores de IA semelhantes conseguem realmente buscar suas páginas — separado do Google, pois esses bots geralmente não executam JavaScript e leem apenas o HTML bruto que seu robots.txt permite que eles acessem.

Como obter: /tools/ai-crawler-checker/ para confirmar que nenhum user-agent de IA está bloqueado; logs do servidor para confirmar que os bots estão realmente solicitando páginas, não apenas permitidos a fazê-lo.

Referência / faixa realista: não há uma referência de taxa de citação que eu possa dar honestamente — com que frequência um mecanismo de resposta por IA cita você depende do espaço de consulta e da concorrência, não de algo que a configuração do Nuxt controle diretamente. Acompanhe o acesso (permitido vs. bloqueado), não uma porcentagem de citação inventada.

Frequência: após cada alteração de configuração do robots.txt ou @nuxtjs/robots; verificação mensal dos logs caso contrário.

Teste-se: SEO para Nuxt

Cinco perguntas rápidas sobre otimizar um site Nuxt para busca. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus artigos relacionados

• JavaScript SEO: A Definitive Guide — meu guia completo sobre renderização, paridade de DOM, a regra da diretiva mais restritiva e por que SSR/estático/prerender (incluindo Nuxt) são todos adequados para busca.
• The Beginner’s Guide to Technical SEO — onde renderização e rastreamento se encaixam no panorama geral.

Minhas palestras

• JavaScript SEO — Ungagged 2019 (SlideShare) — o Chromium evergreen do Googlebot, o custo de rastreamento cerca de 20× da renderização, History API em vez de hash routing e como o Google lida com canônicos injetados via JavaScript. (Aviso permanente: o conselho sobre renderização dinâmica nessa apresentação está desatualizado — o Google o descontinuou.)

Do setor

• Nuxt — Conceitos de renderização (oficial) — renderização universal vs. renderização no cliente e por que os crawlers preferem SSR.
• Nuxt — SEO e Meta (oficial) — useSeoMeta() e useHead(), a referência de introdução.
• Aprenda SEO com Nuxt (Harlan Wilton / nuxtseo.com) — o guia de SEO para Nuxt mais abrangente e focado em desenvolvedores, sempre atualizado.
• harlan-zw/nuxt-seo (GitHub) — a fonte do pacote de módulos @nuxtjs/seo.
• Nuxt Image (oficial) — <NuxtImg> e otimização de Core Web Vitals.
• Otimize o desempenho do Nuxt (DebugBear) — um passo a passo prático de correções de Core Web Vitals no Nuxt.
• Modos de renderização do Nuxt 3 (RisingStack) — uma comparação técnica entre SSR, SSG e renderização híbrida.
• r/TechSEO — a comunidade para depuração de renderização/indexação.

Vídeos

• Google Search Central (YouTube) — a série JavaScript SEO de Martin Splitt é o melhor passo a passo oficial de como o Google rastreia, renderiza e indexa aplicativos JS; é agnóstica de framework, mas se aplica diretamente ao Nuxt. Canal

Registro de alterações