“Se o nosso conteúdo fica numa API, o Google vai conseguir ver?” Toda equipe faz essa pergunta antes de ir para o headless, quase sempre porque alguém viu, em 2019, um app React renderizado no cliente entregar um <div> vazio para o crawler. Esse medo ficou para trás, mas a pergunta esconde outra, real: no headless, a responsabilidade pelo SEO sai do CMS e passa para você. Este post é o mapa do que agora fica por sua conta.
A resposta curta
Buscadores ranqueiam o HTML servido em URLs do seu domínio. Eles não sabem, nem se importam, se esse HTML foi montado a partir de um banco de dados, de uma API ou de arquivos Markdown. Um setup headless com renderização no servidor gera exatamente o mesmo resultado rastreável que um CMS tradicional, muitas vezes melhor, porque você controla cada byte da página.
O detalhe está na condição: com renderização no servidor. Acerte o modelo de renderização, e o resto é SEO técnico comum.
Renderização: a única decisão que importa
Três jeitos de transformar o conteúdo de uma API em páginas:
Renderização no cliente (CSR): o navegador busca o JSON e monta a página com JavaScript. O Google executa JavaScript, mas deixa a renderização para depois, e outros crawlers, prévias de links e scrapers de redes sociais se comportam cada um de um jeito. Para conteúdo que você quer ranquear, CSR é a escolha arriscada.
Renderização no servidor (SSR): o seu servidor busca o conteúdo na API a cada requisição e devolve o HTML pronto. Sempre rastreável; o conteúdo está sempre atualizado; o custo é uma busca por requisição (com o cache que você achar melhor).
Geração estática (SSG): as páginas são geradas com antecedência e servidas como arquivos. A entrega mais rápida possível; exige rebuild ou revalidação quando o conteúdo muda.
Qualquer framework moderno (Next.js, Astro, Nuxt, SvelteKit, TanStack Start) faz SSR ou SSG a partir de uma API de conteúdo como caminho padrão, com a chamada à API num loader ou no build. Se for levar uma regra só deste post, leve esta: páginas de conteúdo públicas são renderizadas no servidor.
A vantagem de domínio que ninguém menciona
Ir para o headless muitas vezes melhora o SEO por um motivo estrutural: o conteúdo passa a ficar no seu domínio principal. Plataformas hospedadas de blog e documentação ficam em subdomínios ou em domínios próprios, e a autoridade que os seus artigos conquistam se acumula lá. No headless, /blog, /help e /changelog são subdiretórios do domínio onde o seu produto vive, e cada backlink para um artigo fortalece todas as outras páginas que você tem. Só esse fator costuma pesar mais do que todos os detalhes de meta tags abaixo.
O checklist que agora é seu
Um CMS tradicional cuida de parte disso sem você ver. O headless passa isso para você: uma configuração feita uma vez, numa função auxiliar, já que tudo sai das mesmas respostas da API.
Metadados por página
Título, meta description, tags Open Graph e do Twitter, datas do artigo. Preencha esses dados em campos do CMS, junto com o conteúdo, e coloque-os no head do documento a partir da mesma busca que renderiza a página. Com um backend de conteúdo que modela campos de SEO por entrada (título, descrição, imagem), isso vira um mapeamento, não um projeto.
URLs canônicas
Cada página declara a sua URL canônica, calculada a partir do slug da entrada e nunca copiada da URL da requisição, que tornaria canônicas as variações com ?utm_source= e as diferenças acidentais de maiúsculas e minúsculas. Uma só função que gera o caminho de cada entrada, usada pelas páginas, pelo sitemap e pelos feeds, garante que eles nunca discordem.
Códigos de status reais
Um slug desconhecido precisa retornar HTTP 404, não uma página de erro estilizada com status 200. Soft 404 desperdiça orçamento de rastreamento e polui o índice. Do mesmo jeito, se a sua rota no servidor não consegue acessar a API de conteúdo, falhe com um 5xx e Cache-Control: no-store em vez de deixar um 200 vazio no cache da CDN.
Sitemap e feeds
Gere o sitemap.xml a partir dos mesmos endpoints de listagem que as suas páginas de índice usam, com lastmod real tirado das datas das entradas. Adicione RSS para o blog e o registro de alterações: feeds custam pouco, e tanto leitores quanto crawlers usam.
Dados estruturados
Gere JSON-LD (Article para posts, FAQPage onde fizer sentido, Organization na página inicial) a partir dos dados da entrada. Um detalhe ao injetar JSON-LD pelo código do servidor: escape cada < do JSON serializado como \\u003c, para que um </script> perdido num título não feche a tag script antes da hora.
Noindex no que não deve ranquear
Páginas de resultados de busca, rotas de pré-visualização e combinações paginadas de tags muitas vezes merecem noindex. Se a sua plataforma oferece um portal hospedado em domínio próprio, além da entrega por API, veja como ela trata a indexação. As páginas do portal hospedado do Kookee levam noindex de propósito: assim, a versão do mesmo conteúdo renderizada no seu domínio é a única que concorre na busca, sem ambiguidade de conteúdo duplicado.
Atualização e disciplina de cache
Com SSR, as edições publicadas aparecem na próxima requisição. Com SSG, defina por tipo de conteúdo quanto tempo ele pode ficar desatualizado: um blog pode ser regerado sem pressa; um registro de alterações ou uma página que depende de status pede revalidação em minutos. Em qualquer caso, faça cache na CDN com critério: chaves de cache pela URL, TTLs sensatos e purge na publicação, se a sua plataforma tem webhooks ou se você dispara rebuilds ao publicar.
Conteúdo multilíngue
Se você atende vários idiomas, o headless de novo entrega a versão limpa: busque as traduções da entrada na API, sirva cada idioma na própria URL e gere alternates hreflang a partir da lista de traduções. O que ele não faz é salvar você de uma tradução automática feita pela metade: publique só os idiomas que você mantém.
Um teste para fazer hoje
Pegue a sua página mais valiosa e confira, com o JavaScript desativado: o texto completo aparece no código-fonte HTML? O título, a descrição e a canonical correspondem a essa página? Um slug sem sentido retorna 404? Abra o sitemap.xml: a página está lá, com um lastmod plausível? São quinze minutos, e isso cobre 90% do que dá errado.
Headless não prejudica o SEO. JavaScript não renderizado prejudica o SEO, códigos de status errados prejudicam o SEO, e subdomínios de fornecedores cobram dele um imposto silencioso. Escolha a renderização no servidor, tire cada sinal dos dados da entrada que você já busca e mantenha a autoridade no único domínio que deveria acumulá-la: o seu.