Uma verdadeira alternativa ao WordPress? (2026)

Durante vinte anos, se um cliente precisava de um site que pudesse editar sozinho — sem ligar a um programador de cada vez que mudava um preço ou uma fotografia —, a resposta era o WordPress, com todos os seus problemas. Plugins a mais, correções de segurança constantes, uma fatura de alojamento que vai subindo e uma base de dados cheia de remendos “temporários” cuja razão já ninguém recorda. Não havia uma verdadeira alternativa, nenhuma que desse de facto a um cliente sem conhecimentos técnicos o controlo total sobre o seu próprio conteúdo.

Acho que isso está a mudar. Acabei de criar o site de uma cliente numa stack completamente diferente — um CMS orientado por schema chamado EmDash, a correr inteiramente na infraestrutura da Cloudflare — e é a primeira vez que diria com convicção a um cliente “isto substitui o WordPress”, em vez de “isto é um construtor de páginas mais simpático”.

O argumento está, na verdade, na combinação. A Cloudflare, sozinha, faz hoje discretamente o que antes exigia quatro ou cinco fornecedores diferentes: é o registo do domínio, o certificado SSL, a base de dados, o armazenamento de ficheiros, a proteção contra bots e DDoS e — com dois plugins que desenvolvi por cima dela — o email profissional e o CRM. Tudo numa só conta, tudo faturado em conjunto, tudo por poucos dólares por mês. Eis como foi, na prática, construir isto para o site de marketing bilingue de uma consultora de imagem em Lisboa.

A stack, em termos simples

Domínio + SSL — Cloudflare, no mesmo sítio que tudo o resto. Sem registo de domínios à parte, sem certificado para renovar à mão.
O CMS — EmDash, um CMS headless orientado por schema que corre como parte da própria aplicação Astro, e não como um serviço separado que é preciso manter atualizado.
A base de dados e o armazenamento de ficheiros — Cloudflare D1 (SQLite) para o conteúdo, R2 para as fotografias carregadas. Ambos vivem na mesma conta que o domínio.
Proteção contra bots e DDoS — ativa por omissão, parte da mesma conta Cloudflare, sem nada extra para configurar ou subscrever.
Email profissional, de entrada e de saída — email transacional a sério, enviado a partir do domínio da própria cliente, mais aliases de receção ilimitados nesse domínio, encaminhados como fizer sentido: uns reencaminhados diretamente para a caixa de correio que a cliente já tem, outros enviados para um Worker para tratamento à medida.
Um CRM que apanha todas as leads — um segundo plugin que transforma cada envio de formulário do site num registo real no CRM, em vez de um email que acaba soterrado.
O alojamento — Cloudflare Workers. Sem servidor para manter, sem nunca mais receber um email “por favor, atualize o núcleo do WordPress”.

Custo recorrente total: 5 $ por mês, no plano pago do Cloudflare Workers — que cobre o alojamento do site e 200 emails transacionais enviados por dia. O registo do domínio é à parte, mas modesto, e tudo o resto (base de dados, armazenamento, proteção contra bots) cabe no plano gratuito da Cloudflare com este nível de tráfego.

Como foi realmente construído

Um CMS sem servidor próprio

O backend inteiro são algumas linhas na configuração da própria aplicação — não há instalação separada do CMS, nem runtime de PHP, nem painel de administração para proteger à parte:

// astro.config.mjs
export default defineConfig({
  output: "server",
  adapter: cloudflare(),
  integrations: [
    emdash({
      database: d1({ binding: "DB", session: "auto" }),
      storage: r2({ binding: "MEDIA" }),
    }),
  ],
});

O backend é isto. A interface de administração vem incluída — login com passkey (sem palavras-passe que possam ser expostas), rascunhos e revisões, uma biblioteca multimédia a sério. Um único deploy, mais nada para instalar.

Campos com significado, não “blocos” genéricos

A armadilha habitual dos CMS headless é uma única coleção genérica “Página” com blocos de conteúdo flexíveis, porque parece reutilizável. Na prática, significa que a cliente abre um formulário de edição cheio de campos que não se aplicam ao que está a editar. Em vez disso, dei a cada tipo real de página — serviços, casos de estudo, testemunhos, artigos do blogue, a página inicial — o seu próprio schema, com campos em linguagem clara:

npx emdash schema add-field pages hero_headline --type string --required
npx emdash schema add-field pages stat_clients --type string

E não content_block_1. Quando a cliente abre o editor, cada campo é algo que ela descreveria numa frase — o título, o preço, a citação da cliente — sem nada para adivinhar.

Fotografias que se otimizam sozinhas

Foi isto que mais pesou no dia a dia. A cliente carrega o que o telemóvel produziu — um JPEG de 1 MB, em resolução total, saído diretamente de um iPhone. Um CMS que exige “por favor, comprima primeiro as imagens” como passo manual é um CMS que, mais cedo ou mais tarde, vai servir um site lento e por otimizar, porque ninguém se lembra sempre desse passo extra.

A solução acabou por ser duas definições, e não código da aplicação — uma que diz aos Workers da Cloudflare para redimensionarem e converterem de facto as imagens, outra que diz ao Astro que o domínio do próprio site pode ser otimizado:

// wrangler.jsonc
"images": { "binding": "IMAGES", "remote": true }

// astro.config.mjs
image: { domains: ["my-real-domain.com"] },

Ambas são fáceis de falhar, porque nada dá erro quando estão em falta — o site limita-se a servir, sem avisar, o ficheiro original em tamanho completo, e a falha só aparece como “porque é que o site está lento?”. Com as duas ativas, uma fotografia de telemóvel de 985 KB passa automaticamente a um ficheiro de 120 KB com as dimensões certas, sem alterar a forma de trabalhar da cliente e sem que nenhuma imagem volte a sair do site por otimizar.

Email que pertence de facto ao domínio da cliente

A maioria dos sites de pequenas empresas ou dispensa por completo o email transacional, ou acrescenta um serviço de terceiros (com conta própria, fatura própria e registos DNS próprios para manter). A Cloudflare trata nativamente dos dois sentidos do email assim que o domínio está nela — o mesmo encaminhamento que usei para configurar email profissional gratuito para a minha própria startup — e construí um plugin à volta disso: email transacional de saída enviado com o endereço da própria cliente —

await env.EMAIL.send({
  to: CONTACT_EMAIL_TO,
  from: { email: "noreply@clientdomain.com", name: "Website form" },
  subject, text, html,
});

— e encaminhamento de entrada sem limite para o número de endereços. hello@, booking@, um alias único por campanha publicitária, o que a cliente quiser — cada um é reencaminhado diretamente para a caixa de correio real ou encaminhado para um Worker que o processa em código (responde automaticamente, analisa um anexo, abre um ticket). Sem limites de caixas de correio, sem custo por alias, porque nunca foram verdadeiramente “caixas de correio” — são endereços num domínio, encaminhados como a lógica do negócio precisar.

Leads que não se perdem

O formulário de contacto avisa a cliente por email, como em qualquer site — mas o email é o sítio onde as leads vão morrer, soterradas debaixo de tudo o resto numa caixa de entrada uma semana depois. O segundo plugin escreve cada envio de formulário diretamente num CRM a sério, a par da notificação: um registo de contacto, com data e hora, etiquetado por origem, pronto para uma sequência de follow-up, e não para uma busca pela caixa de entrada acima. A cliente fica com as duas coisas — o aviso imediato por email e um registo permanente e pesquisável, que sobrevive mesmo que o email passe despercebido.

Um painel de SEO que faz realmente alguma coisa

A maioria dos CMS inclui um painel de SEO por página — título, descrição, URL canónico. É fácil esse painel existir, guardar corretamente e, simplesmente, não ser lido por nada, porque os templates das páginas constroem as meta tags a partir de outro sítio completamente diferente. Era o que acontecia aqui, até eu seguir o rasto e ligar os valores guardados no painel como uma verdadeira substituição — o valor do CMS, se a cliente o preencheu; caso contrário, um valor por omissão sensato, calculado. Agora, quando ela edita o “SEO Title” de uma página, é mesmo isso que a Google vê.

O que a cliente ganha com isto

Com o site no ar, o lado dela da relação é: iniciar sessão, editar um campo, guardar. Sem programador pelo meio para mudar um preço, juntar um testemunho ou publicar um artigo no blogue. Cada envio de formulário torna-se uma lead real num CRM real, e não uma agulha numa caixa de entrada. Cada email de notificação sai do domínio dela, e não de um remetente de terceiros com ar de spam. E, como tudo assenta na rede da própria Cloudflare, a mesma conta que trata do domínio e do SSL já está a absorver o tráfego de bots e as tentativas de DDoS antes de chegarem à aplicação — infraestrutura que, num site WordPress, exigiria três ou quatro extras pagos à parte para chegar perto.

Armadilhas em que caí

Falhas silenciosas em vez de erros ruidosos. Tanto o pipeline de imagens como (à parte) o roteamento bilingue do site se comportavam de forma diferente em local e depois de publicados — nada rebentava, simplesmente faziam a coisa errada sem avisar. Teste sempre a build realmente publicada, e não só o servidor de desenvolvimento local.
Um formulário de administração que “funciona” não é o mesmo que uma funcionalidade que funciona. O painel de SEO guardou dados e apresentou-os corretamente durante meses, sem que nada os lesse. Siga cada campo do CMS até ao template que é suposto usá-lo.
O Google Fonts é uma questão de RGPD, não apenas de desempenho. Carregar tipos de letra a partir da CDN da Google envia o IP de cada visitante à Google em cada visualização de página — um verdadeiro problema de conformidade para uma empresa da UE. Alojar os mesmos ficheiros de tipos de letra no próprio site eliminou o pedido externo e, com ele, a questão da conformidade.
Até a infraestrutura “gratuita” tem uma linha paga ao consumo. Aqui, tudo é gratuito com este nível de tráfego, exceto as transformações de imagem, que são gratuitas até 5000 redimensionamentos por mês e custam 0,50 $ por cada 1000 a partir daí — convém sabê-lo antes de prometer a um cliente “0 $/mês”, mesmo que na prática ande lá perto.

É mesmo um substituto do WordPress?

Para um site de marketing em que o cliente precisa de controlo total e fácil sobre conteúdo real — texto, preços, fotografias, casos de estudo, leads, email — e não precisa de um marketplace de plugins nem de uma loja de temas: sim, sem reservas. Aquilo de que se abdica é exatamente o que torna o WordPress frágil — o enorme ecossistema de plugins e a superfície de ataque que vem com ele. Em troca, recebe-se um site mais rápido de raiz, mais barato de manter, que já traz CRM e email profissional a funcionar e que nunca mais vai precisar de um email “por favor, atualize os seus plugins”.

Se o seu site é o que está em WordPress e prefere gastar menos tempo a remendá-lo e mais a fazê-lo crescer, é exatamente o tipo de projeto que aceito — veja como trabalho com clientes.

Atualização, setembro de 2026: entretanto, o EmDash chegou à versão estável 1.0 e passámos o próprio nesmachny.com para ele. O que isso mudou, em números.

Perguntas frequentes

O EmDash CMS é mesmo uma alternativa ao WordPress?

Para um site de marketing ou institucional em que o cliente edita conteúdo real — texto, preços, fotografias — e não precisa de um ecossistema de plugins, sim. O EmDash é orientado por schema e corre dentro da própria aplicação, e não como um servidor PHP separado, o que elimina a maior fonte do peso contínuo de manutenção e segurança do WordPress.

O que inclui, ao certo, a stack da Cloudflare?

Registo de domínio, SSL, uma base de dados SQL (D1), armazenamento de ficheiros (R2), alojamento serverless (Workers), otimização de imagens e proteção contra bots e DDoS, tudo numa só conta e numa só fatura — e ainda, com dois plugins feitos à medida, email profissional a sério, transacional e de receção, no domínio da própria cliente e um CRM que regista todas as leads do site.

Quanto custa manter um site destes?

5 $ por mês cobrem o alojamento em Workers e 200 emails transacionais enviados por dia. A base de dados, o armazenamento e a proteção contra bots cabem no plano gratuito da Cloudflare com o tráfego de uma pequena empresa; o registo do domínio é a única despesa à parte, e modesta.

O cliente pode receber email no seu próprio domínio sem um fornecedor de caixas de correio completo?

Sim — o encaminhamento de email da Cloudflare permite endereços ilimitados num domínio, sem custo por caixa de correio. Cada endereço pode ser reencaminhado para uma caixa de correio existente ou encaminhado para um Worker para processamento à medida, e é também assim que o email transacional de saída (notificações de formulários, confirmações) é enviado a partir do endereço do próprio cliente, e não de um remetente de terceiros.

O que acontece a uma lead enviada pelo formulário de contacto do site?

É escrita num CRM a sério como registo de contacto — com data e hora e etiquetada por origem — no mesmo momento em que o cliente recebe a notificação por email. Assim, a lead sobrevive mesmo que o email de notificação passe despercebido ou fique soterrado, e está lá para uma sequência de follow-up como deve ser, em vez de uma busca na caixa de entrada.

Porque é que a otimização de imagens precisou de configuração especial, em vez de simplesmente funcionar?

O serviço de imagens do Astro para a Cloudflare precisa de um binding explícito à funcionalidade de transformação de imagens da Cloudflare e de uma lista explícita dos domínios que pode otimizar. Nenhum dos dois vem ativo por omissão, e nenhum dá erro quando falta — o site serve, em silêncio, o ficheiro original por otimizar, o que só se nota porque o site parece lento.

Existe finalmente uma verdadeira alternativa ao WordPress? (2026)