TL;DR
Um headless CMS é um sistema de gestão de conteúdos que guarda o conteúdo e o entrega por API a um site ou a uma aplicação construídos à parte, em vez de gerar ele próprio as páginas.
- Ganha-se o mesmo conteúdo em vários canais, design à medida e um painel menos exposto.
- Paga-se em desenvolvimento: formulários, pré-visualização e SEO passam a ser código, com mais peças para manter.
- Para o Google e para os robôs de IA, convém que cada página chegue já em HTML completo, renderizada no servidor ou pré-renderizada.
- Numa empresa com um só site e sem equipa técnica, um CMS tradicional chega na maioria dos casos.
O que é um headless CMS
Um headless CMS é um sistema de gestão de conteúdos que guarda e organiza textos, imagens e outros conteúdos, e os entrega através de uma API a um site ou a uma aplicação construídos à parte. É outra camada, feita à parte, que decide como esse conteúdo aparece no ecrã.
O nome vem do inglês: "head" é a camada de apresentação, o front-end, ou seja, a parte do site que o visitante vê. Um CMS tradicional traz essa camada incorporada, com temas e modelos de página. Um CMS headless dispensa-a e fica com o resto: o painel onde a equipa escreve e o repositório onde o conteúdo fica guardado.
A API (interface de programação de aplicações) é a porta por onde outros programas pedem esse conteúdo.
Em português usa-se também a ordem inversa, CMS headless, para a mesma coisa. Tudo o resto decorre desta separação entre quem gere o conteúdo e quem o mostra: as vantagens do modelo e o trabalho extra que exige.
Como funciona um headless CMS, do editor ao ecrã do visitante
Num CMS headless, o conteúdo faz um percurso em cinco passos, por três peças: o painel onde a equipa o preenche, a API que o entrega como dados e o front-end que o transforma na página que o visitante vê. Cada peça é independente, e é isso que leva o mesmo conteúdo a vários sítios. Tome-se como exemplo a ficha de um serviço de uma clínica.
- Quem edita abre o painel e preenche a ficha do serviço.
- O CMS guarda a ficha no repositório de conteúdo, o back-end.
- O site, a aplicação ou outro canal pede a ficha à API.
- A API devolve os campos da ficha em JSON, um formato de texto que qualquer programa lê.
- Cada front-end monta a ficha com o seu design e mostra-a ao visitante.
Modelo de conteúdo: tipos e campos em vez de páginas
Antes da primeira linha de texto, alguém define o modelo de conteúdo: que tipos existem (serviço, artigo, membro da equipa) e que campos tem cada um. A ficha de serviço pode ter título, resumo, duração, preço e imagem.
Quem edita preenche esses campos. Para quem vem do WordPress, em vez da página vê um formulário. Em troca, o conteúdo fica arrumado e reutilizável, porque o preço é sempre o campo preço, esteja onde estiver.
A API que entrega o conteúdo, em REST ou GraphQL
Quando o site precisa da ficha, pede-a à API do CMS. A resposta vem em JSON, organizada em pares de nome e valor ("título": "Fisioterapia").
Há duas formas comuns de fazer o pedido. Numa API REST, cada tipo de conteúdo tem um endereço próprio e a resposta traz, por defeito, a ficha inteira. Com GraphQL, o front-end diz que campos quer (só o título e o preço, por exemplo) e recebe só esses. Por isto, estes sistemas também se dizem "API-first": a API é a via principal para chegar ao conteúdo.
O front-end que monta a página, no site, na app ou noutro canal
O front-end recebe o JSON e decide tudo o que é visual. No site, a ficha pode ser uma página completa com fotografia. Na aplicação de telemóvel, um cartão com título e preço. Num ecrã na receção, só o nome e a duração.
O que muda de canal para canal é código, feito e mantido à parte do CMS por quem programa cada front-end.
Headless CMS, CMS tradicional, desacoplado e híbrido
Os quatro modelos de CMS distinguem-se por quem monta as páginas. Num CMS tradicional, o sistema de gestão de conteúdos guarda o conteúdo e gera as páginas; num headless CMS, só o guarda e o entrega por API. O CMS desacoplado e o CMS híbrido ficam entre os dois.
A tabela compara os quatro modelos pelo que mais pesa na decisão.
| Critério | Tradicional | Desacoplado | Híbrido | Headless |
|---|---|---|---|---|
| Quem monta as páginas | O tema do CMS | Um front-end incluído no CMS | O editor de páginas do CMS | Um front-end feito à parte |
| Conteúdo por API para outros canais | Parcial | Sim | Sim | Sim |
| Edição visual das páginas | Sim | Parcial | Sim | Parcial |
| Esforço técnico para arrancar | Baixo | Médio | Médio | Alto |
| Uso indicado | Um site, pouca equipa técnica | Um site principal e canais secundários | Marketing que edita páginas e precisa de outros canais | Vários canais e design à medida, com programadores |
Diferenças para um CMS tradicional como o WordPress
O WordPress clássico é o exemplo mais conhecido de CMS tradicional, também dito monolítico por juntar tudo num só sistema: o mesmo programa guarda os artigos, aplica o tema e devolve a página pronta ao browser. Mudar o aspeto do site é ajustar ou trocar o tema, e quem edita vê a página quase como vai ficar.
Num CMS headless, o tema não existe. O painel guarda as fichas e a página é construída noutro lado, pelo front-end. Ganha-se liberdade nessa camada e perde-se o que o tema e os plugins davam feito.
CMS desacoplado e CMS híbrido: o meio-termo
Um CMS desacoplado também separa o repositório de conteúdo da apresentação, mas traz um front-end por defeito, pronto a usar. A empresa tem um site a funcionar sem programar a camada visual e pode usar a API para levar o conteúdo a outros canais.
O CMS híbrido parte do lado oposto: mantém a edição visual de páginas a que a equipa de marketing está habituada e expõe o mesmo conteúdo por API. Quem publica mantém a autonomia, e os programadores têm por onde ligar uma aplicação ou um segundo site.
Vantagens de um headless CMS para uma empresa
As vantagens de um CMS headless vêm da separação entre conteúdo e apresentação: o mesmo conteúdo serve vários canais, o site é desenhado à medida e o painel de edição deixa de estar no mesmo endereço que o site público. Para a empresa, isso significa menos tempo a publicar, um canal novo mais barato de abrir e menos risco. Nenhuma é automática: todas dependem de como o front-end é feito.
O mesmo conteúdo em vários canais
Neste modelo, cada conteúdo é escrito uma vez e qualquer canal o pode pedir à API. É a base de uma presença omnicanal sem copiar textos entre sistemas e sem o site dizer uma coisa e a aplicação outra.
Num exemplo, uma clínica muda o horário para agosto:
- Quem edita altera o campo horário no painel do CMS.
- O site mostra o novo horário na página de contactos e no rodapé.
- A app de marcações deixa de propor consultas fora dessas horas.
- O ecrã da receção mostra-o na atualização seguinte.
Uma alteração chega a três canais. Acrescentar um quarto canal, como o site de uma segunda marca, é programar mais um front-end com o conteúdo que já existe.
Liberdade no design e velocidade do site
Sem tema, o front-end é desenhado à medida da marca e leva só o código de que cada página precisa, sem o peso acumulado dos plugins. As páginas podem ser geradas antecipadamente e servidas por uma CDN, uma rede de servidores que entrega os ficheiros a partir do ponto mais próximo do visitante. Isto torna possível um site rápido, mas não o garante: um front-end mal feito é lento em qualquer arquitetura. Um redesenho deixa de estar limitado ao que o tema permite.
Menos superfície de ataque
Num CMS tradicional, o painel de administração e a base de dados vivem junto do site público, e cada plugin desatualizado é uma porta possível. Num CMS headless, o visitante só chega ao front-end, e o painel fica noutro endereço, sem acesso direto a partir do site. Há menos por onde entrar, embora o CMS e a API continuem a precisar de atualizações e de acessos bem geridos. Um plugin esquecido deixa de ser um risco para o site que os clientes veem.
Equipa de conteúdo e programadores a trabalhar em paralelo
Com o modelo de conteúdo definido, a equipa de conteúdo publica enquanto os programadores renovam o design ou constroem um canal novo, sem esperarem uns pelos outros. Uma renovação do site não obriga a parar a publicação nem a migrar textos, porque o conteúdo fica no CMS e só o front-end muda.
Um CMS headless é muitas vezes uma das peças de uma arquitetura composta (composable): o site junta serviços independentes, como o CMS, a pesquisa e a loja, ligados por API.
Desvantagens de um headless CMS e o trabalho que acrescenta
As desvantagens de um CMS headless são o reverso da separação que lhe dá as vantagens: o que um CMS tradicional trazia feito passa a ser programado, quem publica perde parte da autonomia e há mais sistemas a manter. Na prática, a empresa fica mais dependente de programadores, no arranque e depois dele. Não é razão para pôr o modelo de parte, mas tem de entrar na conta.
O que o tema e os plugins faziam passa a ser desenvolvimento
Num WordPress, o formulário de contacto, a pesquisa interna, o menu, a página de erro ou o aviso de cookies resolvem-se com o tema ou com um plugin instalado numa tarde. Num CMS headless, cada uma destas peças é código no front-end, feito, testado e mantido por quem programa. Qualquer funcionalidade nova, por pequena que seja, entra na fila de desenvolvimento.
Pré-visualização e autonomia de quem publica
Quem publica preenche campos num formulário e, por defeito, só vê a página depois de ela sair. Para a ver antes, o front-end tem de ter a pré-visualização configurada, o que é mais trabalho de programação.
Alguns CMS juntam um editor visual que mostra a página enquanto se edita, como o Storyblok. Mesmo aí, criar um tipo de página ou um componente novo continua a pedir um programador, porque o modelo de conteúdo e os componentes vivem no código; quem edita só combina os blocos que já existem. Para uma equipa de marketing habituada a montar páginas sozinha, é a mudança que mais se sente no dia a dia.
Mais peças para manter e para pagar
Um site num CMS tradicional é, em regra, um só sistema num só alojamento. Um site headless junta pelo menos duas peças, cada uma com o seu alojamento, mais as integrações.
Cada peça é mais uma conta, mais um fornecedor ou mais um contrato, com atualizações próprias e um ponto de falha próprio. Quando algo deixa de funcionar, o primeiro passo é descobrir em que peça está o problema e quem a mantém.
Headless CMS e SEO: o que muda no que o Google lê
Num CMS headless, o que o Google lê depende do front-end. Se o site entrega cada página já em HTML completo, o Google trata-a como qualquer outra; se a página só se monta no browser, parte do conteúdo pode ficar por ler. Title, description, sitemap e redirects passam a ser trabalho de quem programa.
Antes de pôr um site headless no ar, confirme estes pontos:
- O HTML servido já traz o texto principal de cada página.
- Cada página tem title e description próprios, editáveis no CMS.
- Os URLs são legíveis e mantêm-se quando muda o título.
- O sitemap atualiza-se sozinho a cada publicação.
- Cada URL que muda tem um redirect 301 (reencaminhamento permanente) para o novo.
- Cada página indica o seu URL canónico, a versão que o Google deve indexar.
- Os dados estruturados (JSON-LD) dizem o mesmo que a página mostra.
- As páginas carregam depressa no telemóvel.
Páginas renderizadas no servidor, pré-renderizadas ou só no browser
Na renderização no servidor, o HTML é gerado a cada pedido. Na pré-renderização, as páginas são geradas antecipadamente e servidas como ficheiros; em regra, cada publicação no CMS volta a gerá-las. Nas duas, o robô recebe a página completa. Na terceira via, o servidor envia uma página quase vazia e é o JavaScript, no browser, que vai buscar o conteúdo à API.
O Google executa JavaScript, mas numa fase posterior ao rastreio, o que pode atrasar a indexação. Outros robôs, incluindo os de assistentes de IA, podem não o executar.
Erro comum: validar o site só no browser. Parece perfeito, mas o HTML devolvido pelo servidor tem só o menu e um espaço vazio. O código-fonte da página mostra o que recebe um robô que não executa JavaScript.
Title, description, URLs, sitemap e redirects ficam a cargo do front-end
Num CMS tradicional, um plugin de SEO trata disto. Num CMS headless, alguém tem de o programar e criar no modelo de conteúdo os campos para quem edita. Se ninguém o pedir no arranque, o site pode sair com o mesmo title em todas as páginas, e cada 301 passa a exigir um programador.
Conteúdo estruturado e respostas de IA
O modelo de conteúdo já arruma a informação em campos: preço, duração, morada, pergunta e resposta. Quando o preço, a duração e a morada vivem em campos próprios, o front-end publica-os no texto e no JSON-LD sempre iguais. Esse conteúdo estruturado não garante citações em respostas de IA, mas evita que a página diga uma coisa e os dados estruturados outra.
Plataformas de headless CMS e como se distinguem
As plataformas de headless CMS distinguem-se sobretudo por quem as aloja: umas são um serviço na cloud, outras são software que a empresa instala num servidor seu. Essa escolha decide quem trata das atualizações e onde ficam os dados.
A tabela resume sete plataformas de headless CMS, sem ordem de preferência.
| Plataforma | Modelo | Licença | Editor visual | Começa sem pagar |
|---|---|---|---|---|
| Contentful | Cloud | Proprietária | Parcial | Sim |
| Storyblok | Cloud | Proprietária | Sim | Sim |
| Sanity | Cloud | Painel open source, serviço proprietário | Sim | Sim |
| Strapi | Auto-alojado ou cloud | Open source (MIT) | Parcial | Sim |
| Directus | Auto-alojado ou cloud | Source-available (MSCL) | Sim | Sim |
| Payload | Auto-alojado | Open source (MIT) | Parcial | Sim |
| WordPress | Auto-alojado | Open source (GPL) | Parcial | Sim |
Nas auto-alojadas, o que não se paga é a licença; o servidor paga-se à parte.
Em serviço na cloud: Contentful, Storyblok e Sanity
O Contentful, o Storyblok e o Sanity são conteúdo como serviço: o fornecedor aloja o CMS e trata das atualizações. A empresa dispensa servidores próprios, mas os dados ficam com o fornecedor e as condições do plano mudam quando ele decide. No Sanity, o painel de edição é código que a equipa técnica adapta.
Open source e source-available, alojados pela empresa: Strapi, Directus e Payload
O Strapi, o Directus e o Payload instalam-se num servidor da empresa ou do fornecedor técnico. Não há subscrição obrigatória, mas alojamento, cópias de segurança e atualizações ficam a cargo de quem instala. O Directus usa uma licença própria, source-available: é gratuito para empresas abaixo de um limite de receita e de dimensão. Não é open source em sentido estrito.
O WordPress usado como headless CMS
O WordPress traz uma API REST de origem e pode servir só de back-end: a equipa escreve no painel que conhece e um front-end à parte monta o site. O tema e os plugins que mexem na página deixam de contar. Serve quem já tem conteúdo e equipa habituados ao WordPress.
Quanto custa um site com headless CMS
O custo de um site com headless CMS depende de três componentes: a licença ou o alojamento do CMS, o desenvolvimento do front-end e a manutenção. Em regra, a parte mais variável é o desenvolvimento do front-end. A conta certa soma o arranque e o que se paga todos os meses.
| Componente | De que depende | Pontual ou recorrente |
|---|---|---|
| Subscrição do CMS na cloud | Plano, número de utilizadores e de registos | Recorrente |
| Servidor do CMS open source | Alojamento, cópias de segurança, atualizações | Recorrente |
| Desenvolvimento do front-end | Tipos de conteúdo, pré-visualização, integrações, línguas | Pontual |
| Alojamento do front-end | Tráfego e forma de servir as páginas | Recorrente |
| Manutenção | Atualizações, correções, funcionalidades novas | Recorrente |
Licença ou alojamento do próprio CMS
Num CMS em serviço na cloud, paga-se uma subscrição. Os planos gratuitos têm limites, em regra de utilizadores, de registos ou de línguas, e os pagos sobem com eles. Num CMS open source, a licença pode não custar nada, mas o servidor e as atualizações pagam-se, a um fornecedor ou em horas da equipa. Antes de decidir, compare o primeiro plano pago de cada plataforma e veja o que o faz subir: utilizadores, registos ou línguas.
Desenvolvimento do front-end e manutenção
O front-end é feito à medida, por isso o preço cresce com o que tem de fazer. Cada tipo de conteúdo é mais um modelo e mais um componente, a pré-visualização é trabalho à parte, cada integração acrescenta horas e cada língua multiplica campos e testes. Depois do lançamento, a manutenção continua: atualizar dependências, corrigir o que falha, programar cada pedido novo. Para a empresa, é um custo de desenvolvimento contínuo, não só um orçamento de arranque.
Quando um headless CMS faz sentido numa empresa
Um CMS headless faz sentido quando a empresa leva o mesmo conteúdo a mais de um canal, ou precisa de um site que um tema não consegue servir, e tem quem programe e mantenha o front-end. Sem estas condições, o trabalho extra pesa mais do que o ganho.
Sinais de que a empresa precisa de um headless CMS
Responda sim ou não a cada pergunta:
- O mesmo conteúdo tem de aparecer no site e noutro canal, como uma aplicação ou um ecrã?
- A sua empresa gere várias marcas, ou um site em várias línguas, a partir do mesmo conteúdo?
- O design ou as funcionalidades pedidas ficam fora do que um tema dá sem o forçar?
- Há uma equipa técnica ou um fornecedor contratado para manter o front-end?
- Quem publica aceita preencher campos e pedir ajuda para criar páginas novas?
Se a resposta sobre a equipa técnica for não, o front-end fica sem dono e o projeto não deve avançar assim. Se for sim, cada outro sim é uma razão a favor.
Quando um CMS tradicional chega
Para uma empresa como a sua, com um só site, poucas páginas e sem equipa técnica, um CMS tradicional chega na maioria dos casos. Quem publica vê a página enquanto escreve e resolve um formulário com um plugin, sem abrir um pedido a um programador. Ter apenas um site não exclui o headless, mas tira-lhe a vantagem principal.
Passar um site existente para headless sem perder posições no Google
Numa mudança para headless, o conteúdo migra para o novo CMS e o front-end refaz-se de raiz. Para reduzir o risco de perder posições, há três cuidados:
- Manter os URLs atuais ou criar um 301 de cada URL antigo para o novo.
- Levar o title e a description de cada página para os campos do CMS.
- Testar o HTML servido pelo site novo, página a página, antes de o pôr no lugar do antigo.
Depois da troca, a checklist de SEO de um site headless (HTML servido, title, sitemap, 301, URL canónico) aplica-se ao site novo.
Perguntas frequentes sobre a arquitetura headless
Headless CMS e Jamstack são a mesma coisa?
Não. Jamstack é uma forma de construir o front-end: o site é gerado em ficheiros antes da visita e completa-se com dados pedidos a APIs. Um CMS headless é muitas vezes a fonte desse conteúdo, mas também alimenta sites feitos de outra forma, ou uma aplicação.
O que é headless commerce?
Headless commerce é a mesma separação aplicada a uma loja online. A plataforma de comércio eletrónico gere catálogo, preços, carrinho e pagamentos, e entrega-os por API a um front-end feito à parte. A loja vende no site, na aplicação ou noutro canal a partir do mesmo catálogo.
O que acontece ao site se o headless CMS deixar de responder?
Depende de como o front-end obtém o conteúdo. Se as páginas são pré-geradas e servidas por uma CDN, o site continua no ar com o último conteúdo publicado, e só as publicações novas ficam à espera. Se cada visita pede o conteúdo à API, sem cópia guardada, essas páginas falham ou aparecem vazias até o CMS voltar.
Um headless CMS serve para um site em várias línguas?
Sim, é um dos casos de uso habituais. Cada conteúdo guarda uma versão por língua nos mesmos campos, e o front-end mostra a versão certa em cada endereço. Os URLs de cada língua e a indicação ao Google de que páginas se correspondem ficam a cargo do front-end.
Posso usar um headless CMS só para o blog da empresa?
Sim. O resto do site continua no CMS atual e só o blog passa a ler os artigos de um CMS headless: é uma forma de experimentar o modelo com pouco risco. O cuidado é manter o blog no mesmo domínio e com os mesmos URLs, para não perder o que já está indexado.