10 sistemas CMS em 2026: quota de mercado, headless e o que restou de 2008

Em 2008, quando este artigo foi publicado pela primeira vez, o mercado de CMS era o Velho Oeste. O WordPress era visto sobretudo como plataforma de blogs. A lista original recomendava sistemas como Frog CMS, SilverStripe, Liferay, miaCMS, MoinMoin, ImpressCMS, MODx, Textpattern, Radiant e CMS Made Simple. A maior parte destes nomes já não diz nada a ninguém em 2026.

A categoria partiu-se em três: CMS tradicionais, CMS headless API-first e plataformas de conteúdo SaaS. Assim está o mercado em 2026 - com prática portuguesa em mente, não só percentagens globais.

#1. WordPress, o CMS mais usado (cerca de 40% dos sites)

Tipo: CMS tradicional com opções headless Licença: GPL (gratuito, open source) Linguagem: PHP Ideal para: Blog, sites empresariais, lojas WooCommerce, portais

O WordPress alimenta cerca de 40% de todos os sites. Nenhum outro CMS chega perto. O software é gratuito; paga-se hosting, plugins e tempo de trabalho. Cresceu ao diversificar:

• Gutenberg amadureceu para full site editing (FSE)
• REST API e WPGraphQL permitem headless com React, Astro ou Next.js
• WooCommerce continua dominante; em Portugal, Multibanco e MB Way costumam decidir se a loja converte
• WordPress 7.x aponta para mais assistência de IA na edição e temas de blocos mais profundos

Pontos fortes: Ecossistema de plugins (60 000+), talento abundante, escalabilidade comprovada, WooCommerce.

Pontos fracos: Monólito PHP, segurança depende dos plugins, admin UX atrasada, dívida técnica de 20 anos de compatibilidade retroativa.

Veredicto 2026: Escolha padrão quando editores não técnicos possuem o conteúdo e a loja precisa de pagamentos locais na mesma stack.

#2. Drupal para administração pública e grandes empresas

Tipo: CMS tradicional com forte suporte headless Licença: GPL Linguagem: PHP (Symfony) Ideal para: Administração pública, saúde, educação, sites enterprise complexos

O Drupal ocupa um nicho claro: modelação complexa, WCAG 2.2 rigoroso e equipas próprias. Em concursos públicos portugueses e projetos alinhados com a AMA, aparece muitas vezes porque acessibilidade e permissões são first-party.

• Drupal 10 e Drupal 11 consolidaram a base com Symfony 7, novo admin Gin e arquiteturas desacopladas (Decoupled Drupal) nativas. A integração através de JSON:API no core e módulos como Next-Drupal permite alimentar frontends em Next.js ou Astro com validação rigorosa de esquemas.
• A iniciativa Drupal CMS simplificou pacotes de instalação com receitas prontas (Recipes), reduzindo a barreira de entrada editorial face ao WordPress.
• Forte adoção na administração pública da UE (europa.eu e portais governamentais), onde a gestão de fluxos de aprovação e auditoria de segurança são mandatórias.

Pontos fortes: Modelação avançada com Entity API, permissões granulares por campo e função, conformidade nativa com WCAG e AMA, segurança enterprise robusta.

Pontos fracos: Curva de aprendizagem íngreme, ecossistema de módulos menor do que o do WordPress, custos elevados de desenvolvimento e alojamento, migrações de versão que exigem planeamento técnico detalhado.

Veredicto 2026: Vive bem no setor público e enterprise; perde mid-market para headless e WordPress.

#3. Joomla em 2026, CMS multilingue sem plugins

Tipo: CMS tradicional Licença: GPL Linguagem: PHP Ideal para: Portais comunitários, sites multilingues, associações

O Joomla foi outrora o principal concorrente do WordPress. Em 2026 é um nicho pequeno e leal:

• Joomla 5 modernizou a base com PHP 8.1+ e admin Bootstrap 5
• Multilinguismo integrado sem plugins continua a ser vantagem real
• Comunidade mais forte em partes da Europa e da América do Sul

Pontos fortes: Multilinguismo nativo, ACL flexível, extensões maduras.

Pontos fracos: Comunidade em declínio, menos extensões, imagem antiga.

Veredicto 2026: Sobrevive sem crescer. Sites existentes mantêm-se; projetos novos raramente escolhem Joomla.

#4. Ghost como CMS para newsletter e subscrições

Tipo: Plataforma de publicação especializada com API headless Licença: MIT Linguagem: Node.js Ideal para: Editores independentes, newsletters, sites de subscrição

O Ghost largou o «CMS geral» e apostou na economia de criadores:

• Newsletter com entrega de correio eletrónico integrada via Mailgun e relays SMTP.
• Gestão nativa de membros e subscrições pagas através de integração direta com o Stripe Billing.
• A Ghost Content API expõe dados apenas de leitura com tempos de resposta mínimos para frontends estáticos em Astro ou Next.js, enquanto a Ghost Admin API processa publicações automatizadas e webhooks.
• Ghost(Pro) para escritores sem necessidade de infraestrutura, com imagens oficiais Docker para quem opta por self-hosting.

Pontos fortes: Experiência de escrita focada em Markdown e cartões dinâmicos, monetização nativa, Node.js rápido, APIs REST e SDKs bem documentados.

Pontos fracos: Ecossistema de integrações reduzido, estrutura não adaptada a modelos de dados relacionais complexos, ausência de carrinho de compras além de subscrições periódicas.

Veredicto 2026: Acerta o nicho: texto, newsletter e membership na mesma stack.

#5. Strapi, CMS headless open source em Node.js

Tipo: CMS headless (API-first) Licença: MIT / Enterprise Linguagem: Node.js Ideal para: Aplicações custom, multicanal, projetos liderados por programadores

O Strapi abriu a categoria headless open source e continua entre os mais usados:

• O Strapi 5 reescreveu o motor em TypeScript nativo, introduziu o Document Service para gestão de rascunhos e versões de conteúdo, e reduziu a sobrecarga de queries SQL.
• APIs REST e GraphQL geradas automaticamente a partir dos Content Types definidos no painel ou em código.
• Ecossistema de plugins ativos para otimização SEO, fornecedores de armazenamento em nuvem (S3, Cloudflare R2), internacionalização e pesquisa avançada.
• Strapi Cloud disponível para quem prefere evitar a administração de servidores.

Agências portuguesas que já operam Node na UE gostam de manter os dados no próprio ambiente quando o cliente exige soberania e total cumprimento do RGPD.

Pontos fortes: Ecossistema maduro, comunidade internacional ativa, soberania de dados garantida pelo autoalojamento, modelação de entidades flexível.

Pontos fracos: Consumo de recursos excessivo para sites puramente institucionais simples, requer manutenção constante do runtime Node.js, não inclui camada visual pública de apresentação.

Veredicto 2026: Escolha segura para equipas Node que querem headless open source.

#6. Payload CMS para TypeScript e Next.js

Tipo: CMS headless (API-first, nativo em TypeScript) Licença: MIT Linguagem: TypeScript (Next.js) Ideal para: Apps web modernas, equipas TypeScript, projetos Next.js

O Payload é o CMS headless open source de crescimento mais rápido em 2025-2026:

• Config-as-code: tipos em TypeScript geram API, admin e tipos
• Pode correr dentro do processo Next.js
• Payload 3.0 usa React Server Components no admin
• ACL, localização, versões, rascunhos e media integrados

Pontos fortes: Tipos de ponta a ponta, boa DX, integração Next.js.

Pontos fracos: Ecossistema mais jovem, menos plugins, centrado em Next.js.

Veredicto 2026: Primeira escolha quando a equipa já está em TypeScript e Next.js.

#7. Directus como CMS headless sobre base de dados SQL

Tipo: CMS headless (wrapper em torno de SQL) Licença: BSL / GPL ao fim de 3 anos Linguagem: TypeScript Ideal para: Bases de dados existentes, ferramentas internas, apps intensivas em dados

O Directus aponta para uma SQL existente e gera admin e API:

• PostgreSQL, MySQL, MariaDB, SQLite, MS SQL, Oracle, CockroachDB
• REST e GraphQL a partir do esquema
• Permissões ao nível do campo

Pontos fortes: Dados que já possui, sem armazenamento proprietário, vários motores.

Pontos fracos: Menos opinionated; admin pesado para editores puros.

Veredicto 2026: Ideal quando a base já existe. Não é o melhor greenfield.

#8. Sanity ou Contentful como CMS headless SaaS

Sanity (SaaS proprietário) diferencia-se com colaboração em tempo real e Studio React personalizável. O GROQ dá consultas mais poderosas do que REST puro; o custo escala com API e dataset.

Contentful é o padrão enterprise multi-brand: Content Orchestration, Studio, App Framework e governance (SOC 2, ISO 27001, RGPD). Caro à escala; muitas vezes sobredimensionado para projetos pequenos em Portugal.

Veredicto 2026: Sanity para tempo real e studio flexível; Contentful quando compliance pesa mais que a licença. Com orçamento apertado, Strapi/Payload ou WordPress são mais realistas.

#9. Astro Content Collections como CMS baseado em ficheiros

Tipo: Framework web com capacidades CMS baseadas em ficheiros Licença: MIT Linguagem: TypeScript/JavaScript Ideal para: Blogs geridos por programadores, documentação, páginas de marketing

O Astro não é um CMS clássico, mas as Content Collections dão função semelhante para conteúdo em Git:

• Markdown/MDX tipados e validados por esquema
• Content Layer API (Astro 5): ficheiros, APIs ou bases de dados
• Zero JS por omissão; islands só onde é preciso
• Core Web Vitals fortes com orçamento JS apertado

Este site (wppoland.com) corre em Astro com Content Collections. Hugo e Jekyll vivem na mesma família; Astro é o que mais vemos em equipas JS novas.

Pontos fortes: Performance, conteúdo tipado, UI opcional (React, Vue, Svelte).

Pontos fracos: Sem admin visual; alterações passam por commit.

Veredicto 2026: Bom quando programadores possuem o conteúdo. Não substitui WordPress se editores sem Git publicam diariamente.

#Tabela comparativa de CMS em 2026

As percentagens são quota de todos os sites. Fonte: W3Techs, 13 de agosto de 2026. Entre sites com CMS reconhecido, o WordPress fica em 59,0 %.

#Qual é o melhor CMS gratuito em 2026?

Para a maioria dos sites, o melhor CMS gratuito em 2026 continua a ser o WordPress, mas a escolha gratuita certa depende de quem edita o conteúdo e de como este é entregue. Dos dez sistemas da tabela acima, só o Sanity e o Contentful são SaaS proprietários com planos gratuitos limitados; os outros oito podem ser alojados por conta própria sem pagar licença. Sete são open source sob GPL ou MIT, e o Directus tem código-fonte disponível sob a BSL (cada versão passa para GPL três anos depois). O custo de licença não distingue, portanto, estes oito. O que decide é o modelo de edição e a stack tecnológica.

Editores sem perfil técnico, sites gerais, e-commerce: WordPress (GPL). Tem o maior ecossistema de plugins e o WooCommerce e, entre as opções gratuitas, é aquele que uma pessoa sem formação em programação consegue gerir de ponta a ponta com mais facilidade, sem tocar em código. O Ghost, o Joomla e o Drupal também têm painéis pensados para editores, mas nenhum junta isso a um ecossistema de plugins e de e-commerce comparável.

Newsletters, subscrições, editores independentes: Ghost (MIT). O envio de e-mails integrado e as subscrições baseadas no Stripe dispensam uma ferramenta de newsletter externa.

Administração pública, modelação de conteúdo complexa, acessibilidade rigorosa: Drupal (GPL). Permissões granulares e conformidade com a WCAG 2.2 funcionam de forma nativa, sem plugins.

Sites comunitários multilingues de raiz: Joomla (GPL), que gere vários idiomas sem extensões.

Se o seu conteúdo é API-first ou gerido por programadores, a escolha gratuita passa para uma opção headless ou para o Astro (ver abaixo).

#O que aconteceu ao Frog CMS, SilverStripe e MODX?

• Frog CMS: Abandonado. Último release em 2009.
• SilverStripe: Vive como Silverstripe CMS, sobretudo no setor público da Oceânia.
• miaCMS: Morto. Fork do Mambo, abandonado por volta de 2010.
• MoinMoin: Vive como wiki em Python, irrelevante como CMS.
• ImpressCMS: Tecnicamente mantido, adoção negligenciável.
• MODx / MODX: Vive como MODX Revolution com uma comunidade pequena e dedicada.
• Textpattern: Vive com comunidade mínima.
• Radiant: Abandonado. Ruby, últimas atualizações relevantes por volta de 2014.
• CMS Made Simple: Mantido (2.x), comunidade pequena.
• Liferay: Pivotou para portal/DXP Java enterprise para bancos e grandes grupos.

#TYPO3, Grav e Concrete CMS desde 2008

O percurso desde a era pioneira de 2008 até ao mercado contemporâneo ilustra transformações profundas na arquitetura web:

• TYPO3: Na Europa Central e em grandes instituições públicas europeias, o TYPO3 foi durante décadas a referência para portais universitários e corporativos complexos. Embora as versões v12 e v13 adotem normas modernas de PHP e conectores headless, a complexidade de configuração do TypoScript e os custos de manutenção continuam elevados. Várias entidades optam por migrar para ecossistemas WordPress ou stacks modulares para reduzir a dependência de perfis técnicos raros.
• Grav: Como sistema flat-file, o Grav dispensa por completo bases de dados relacionais SQL. Os artigos e páginas são guardados em ficheiros Markdown com frontmatter em YAML e compilados através do motor Twig. Para portfólios, manuais técnicos e sites de menor escala, o Grav oferece custos operacionais nulos e versionamento direto em Git. Encontra limitações evidentes em repositórios com dezenas de milhares de publicações ou fluxos editoriais com múltiplos níveis de aprovação.
• Concrete CMS: Conhecido anteriormente como concrete5, destacou-se pela edição contextual direta sobre a interface pública da página. Essa abordagem visual foi vanguardista na década de 2010, mas perdeu ímpeto com a consolidação de editores baseados em blocos como o Gutenberg e a separação entre backend e frontend em arquiteturas headless. Mantém hoje uma presença restrita a infraestruturas institucionais e portais educativos estabelecidos.
• Silverstripe CMS: Construído sobre uma framework PHP própria, o Silverstripe conquistou respeito técnico pelo rigor na orientação a objetos. Ao tornar-se a plataforma recomendada na Common Web Platform (CWP) do governo neozelandês, consolidou um nicho governamental sólido na Oceânia, apesar de a sua expansão global ter desacelerado face aos ecossistemas headless modernos.
• Dotclear: Lançado em França em 2002 como resposta aberta ao Movable Type e ao WordPress, o Dotclear permanece ativo graças a uma comunidade dedicada. Com uma base de código PHP limpa e requisitos de servidor modestos, continua a ser uma solução funcional para blogues pessoais, sem pretensões de disputar o mercado corporativo ou de comércio eletrónico internacional.

A lição de 2008: ecossistemas ganham, não listas de funcionalidades. O WordPress venceu porque plugins, temas, hosting e talento cresceram juntos. Drupal e Joomla sobreviveram com ecossistemas próprios; os que morreram apostaram em elegância sem comunidade. WordCamp Lisboa e WordCamp Porto mostram que a comunidade em Portugal está viva - meetups e talks, não só estrelas no GitHub.

#Que CMS escolher em vez do WordPress para um site quase estático em 2026

Um tópico no r/webdev em março de 2026 fez a pergunta que traz muitos leitores a este artigo. O autor tinha um site empresarial antigo em WordPress, queria acrescentar um catálogo de produtos e precisava de várias línguas integradas no próprio sistema (r/webdev, tópico de 6 de março de 2026).

#Statamic, Grav ou WordPress para o site de uma pequena empresa

A resposta mais detalhada apontou um sistema PHP fora dos dez acima:

Experimenta o Statamic se queres algo limpo e baseado em PHP. Lida muito bem com várias línguas logo de origem e o painel de administração é super intuitivo para quem não é programador. Além disso, podes pôr tudo sob controlo de versões, já que por defeito guarda tudo em ficheiros.

(u/Strange_Comfort_4110, resposta no r/webdev, tradução própria)

O Statamic assenta em Laravel e guarda o conteúdo em ficheiros por defeito, com um modo de base de dados para sites maiores (statamic.com). As várias línguas passam pela funcionalidade multi-site, que a documentação marca como Pro (documentação do Statamic sobre multi-site), por isso confirme a edição antes de prometer traduções a um cliente. O Grav, sugerido no mesmo tópico, já aparece acima na secção sobre TYPO3, Grav e Concrete CMS. Segundo a página do projeto, inclui também suporte multilingue e licença MIT (funcionalidades do Grav). O WordPress guarda o conteúdo em MySQL e acrescenta línguas com um plugin.

O conteúdo em ficheiros passa pelo Git junto com os templates, publicar uma versão é copiar uma pasta e não há base de dados para salvaguardar nem migrar. A base de dados justifica-se quando o catálogo precisa de filtros, de stock ou de um editor que acrescenta produtos todas as semanas. Um catálogo que um programador atualiza algumas vezes por ano cabe em ficheiros. Um catálogo com filtros e alterações diárias leva de volta ao WordPress com WooCommerce ou a um CMS com base de dados.

#Payload ou WordPress headless para uma equipa JavaScript

Um tópico de fevereiro de 2026 perguntava se uma equipa devia passar para o Payload ou manter o WordPress como backend atrás do Next.js (r/webdev, tópico de 26 de fevereiro de 2026). A resposta mais curta:

Payload se a tua equipa vive em JS. WP headless se a tua equipa de conteúdos já conhece o WordPress. A arquitetura conta menos do que a adoção.

(u/jesusonoro, resposta no r/webdev, tradução própria)

O Payload descreve-se como nativo de Next.js, com o backend a correr dentro da aplicação Next.js (payloadcms.com). A definição dos tipos de conteúdo em código está na secção sobre o Payload acima. O WordPress headless mantém os plugins e o editor que o cliente já conhece, e duplica as bases de código. O WordPress serve o conteúdo por REST ou GraphQL, um frontend separado apresenta-o e cada campo novo tem de ser criado dos dois lados. O nosso guia de arquitetura headless WordPress detalha essa divisão. Num site empresarial quase estático, é mais maquinaria do que o conteúdo pede. Compensa quando o mesmo conteúdo alimenta vários frontends.

#Quem atualiza o conteúdo depois da entrega

Um terceiro tópico, de abril de 2026, veio de um programador que quer passar sites antigos de clientes para algo mais recente (r/webdev, tópico de 9 de abril de 2026). Uma das respostas propôs ficar no WordPress:

Se queres continuar com o WordPress, vê como criar blocos Gutenberg personalizados com o ACF. A interface é bem mais simples do que a do Divi

(u/Eaglesfan1174, resposta no r/webdev, tradução própria)

Quem edita depois do lançamento pesa mais na escolha do CMS do que a tecnologia do frontend. Um cliente que altera conteúdo todas as semanas precisa de um painel que consiga aprender: WordPress com alguns blocos próprios, como na citação, ou o painel de controlo do Statamic. Quando é um programador a fazer todas as alterações, o conteúdo em ficheiros (Astro Content Collections, em que este site corre, ou Grav) tira a base de dados da montagem. Passar os editores para um painel novo custa ao cliente tempo de formação, e durante algum tempo os pedidos de alteração voltam para si.

#Como escolher entre WordPress, headless e Drupal

Escolha WordPress quando os editores não programam ou precisa de WooCommerce com Multibanco/MB Way.

Escolha headless (Strapi/Payload) quando o frontend é React/Next.js/Astro ou a equipa prefere TypeScript e API-first.

Escolha SaaS (Contentful/Sanity) quando precisa de infraestrutura gerida ou governance enterprise - e o orçamento aguenta.

Escolha Astro Content Collections quando programadores possuem o conteúdo via Git e a performance é prioridade (blog, docs, marketing).

Escolha Drupal quando WCAG e permissões granulares são first-party, não algo que se cola depois.

Ferramentas diferentes cobrem necessidades diferentes. Para pesar WordPress clássico contra headless num projeto concreto, veja a programação WordPress da WPPoland.

#Qual é o melhor CMS open source para programadores?

Para programadores, o melhor CMS open source em 2026 depende da stack: Payload para equipas de TypeScript e Next.js, Strapi para projetos Node independentes de framework e Astro Content Collections para conteúdo estático gerido via Git. Os três são gratuitos e open source (MIT), por isso o que conta é a forma como constrói o frontend.

Payload (MIT, TypeScript) é a melhor opção quando já trabalha com Next.js. Os tipos de conteúdo definidos como configuração em código geram a API, o painel de administração e tipos de ponta a ponta a partir dos mesmos ficheiros TypeScript, e o Payload pode correr dentro do processo do servidor Next.js. Em contrapartida, o ecossistema de plugins é mais jovem e o desenho está centrado no Next.js.

Strapi (MIT, Node.js) é a escolha mais segura quando o frontend não usa Next.js. Gera REST e GraphQL automaticamente a partir dos tipos de conteúdo, tem uma comunidade e um marketplace de plugins maiores e pode ser alojado por conta própria, por soberania dos dados. Para sites pequenos, é mais pesado do que o Payload.

Directus (BSL, passa para GPL ao fim de três anos) ganha quando já tem uma base de dados SQL e quer uma camada de administração e uma API sobre ela, em vez de um modelo de conteúdo criado de raiz. Astro Content Collections (MIT) é a escolha quando os programadores gerem o conteúdo via Git e querem desempenho sem JavaScript no browser, com a contrapartida de não haver painel visual para editores sem perfil técnico. Para uma camada de API headless puramente open source, Strapi e Payload são os dois primeiros a avaliar.