Durante muito tempo, quando alguém falava em criar um blog, a resposta automática era WordPress.

E faz sentido.

O WordPress resolve muita coisa. Você instala, escolhe um tema, adiciona plugins e começa a publicar. Para muita gente, ele continua sendo uma boa escolha.

Mas eu queria uma coisa diferente para este blog.

Eu não precisava de painel cheio de botões. Não precisava de vinte plugins. Não precisava de um servidor para atualizar, banco de dados para cuidar ou uma conta mensal de hospedagem só para publicar textos.

Eu queria um lugar simples para escrever sobre tecnologia, automação, IA, vendas e os projetos que estou construindo.

E queria que ele fosse rápido.

Foi assim que troquei o WordPress por uma combinação de Astro + GitHub + Cloudflare Pages + Markdown.

O resultado foi um blog estático, barato de manter e que já nasceu muito leve. No teste mais recente do PageSpeed, ele ficou com 100 em acessibilidade, boas práticas e SEO, além de 98 em desempenho no mobile.

Não estou falando isso porque acredito que a vida é uma competição de círculo verde.

Mas porque velocidade, estrutura e simplicidade fazem parte da experiência de quem chega aqui. E porque esse resultado mostra que não precisa começar um blog com uma estrutura pesada.

O problema não era o WordPress

Quero deixar uma coisa clara: eu não troquei o WordPress porque ele é ruim.

Troquei porque ele resolvia problemas que eu não tinha e, em troca, me dava algumas preocupações que eu não queria carregar.

Um blog em WordPress normalmente envolve:

• hospedagem paga;
• atualizações de tema e plugins;
• banco de dados;
• segurança;
• backup;
• performance dependendo de cache, plugin e configuração;
• um painel que, no meu caso, eu quase não usaria.

Nada disso é um absurdo. É só infraestrutura.

Mas meu conteúdo é basicamente texto, imagens e algumas páginas institucionais. Não existe uma área logada, carrinho, comentários complexos ou cadastro de usuários.

Para esse cenário, eu preferi tratar o blog como ele realmente é: uma coleção de arquivos bem organizados que viram páginas rápidas.

O que eu usei no lugar

O projeto funciona assim:

Obsidian ou editor Markdown
        ↓
arquivo .md
        ↓
repositório GitHub
        ↓
Cloudflare Pages
        ↓
blog publicado

O Astro é a ferramenta que transforma os arquivos em site.

Ele pega um post em Markdown, aplica o layout, gera título, descrição, página do artigo, feed, sitemap e os arquivos estáticos que o navegador precisa carregar.

O GitHub guarda o projeto e o histórico das mudanças.

O Cloudflare Pages faz o deploy. Quando eu envio uma alteração para o repositório, ele gera uma nova versão e publica no domínio.

Sem servidor rodando 24 horas.

Sem banco de dados.

Sem eu precisar entrar em um painel de hospedagem para apertar um botão de publicar.

E, no estágio atual do blog, sem pagar hospedagem.

Por que Astro fez sentido para mim

Astro é uma tecnologia feita para sites orientados a conteúdo.

Isso importa porque um blog não precisa carregar um aplicativo inteiro no navegador para mostrar texto.

Em muitos sites modernos, a pessoa entra para ler um artigo e o navegador baixa JavaScript para menus, componentes, estado, bibliotecas e uma série de coisas que nem sempre são necessárias naquela página.

No Astro, a página pode ser entregue praticamente pronta.

O HTML já vem montado. O CSS vem enxuto. E o JavaScript entra apenas onde existe interação de verdade.

No nosso caso, existem pequenos recursos como busca, compartilhamento e o comportamento do sumário. O resto é conteúdo estático.

Esse detalhe parece técnico, mas tem um efeito simples para quem visita:

a página abre rápido e não fica pulando enquanto carrega.

Foi isso que ajudou o blog a ficar com CLS 0 e tempos de carregamento muito baixos no relatório do PageSpeed.

O “100 no PageSpeed” não foi o objetivo principal

Quando publiquei o artigo sobre quanto dinheiro uma empresa pode perder depois que um cliente chama no WhatsApp, eu rodei o PageSpeed para conferir como a página estava se comportando.

O resultado foi melhor do que eu esperava: 100 em acessibilidade, boas práticas e SEO; 98 em performance mobile.

Isso é ótimo.

Mas eu não recomendaria montar um projeto inteiro só para ganhar uma nota.

Uma nota alta é consequência de algumas decisões boas:

• usar HTML simples e bem estruturado;
• gerar imagens otimizadas em WebP;
• informar tamanho das imagens para evitar mudança de layout;
• evitar fontes e scripts desnecessários;
• não instalar plugin para tudo;
• publicar arquivos estáticos em uma rede global como a Cloudflare.

É muito mais fácil ter performance quando a arquitetura já começa simples.

Depois você pode sofisticar o que precisar. Mas começar leve evita passar semanas tentando consertar um site que nasceu pesado.

Sem pagar hospedagem não significa sem custo nenhum

Tem uma diferença importante aqui.

O blog não tem custo de hospedagem no modelo atual porque o Cloudflare Pages possui uma camada gratuita suficiente para um projeto como este. O GitHub também permite manter o código em repositório sem custo para esse uso.

Mas eu ainda tenho o domínio.

E também existe custo de tempo: montar o projeto, ajustar o visual, escrever conteúdo, revisar e manter as coisas organizadas.

O ponto não é vender a ideia de que tudo é mágico e gratuito para sempre.

O ponto é que, para um blog pessoal ou institucional simples, dá para eliminar uma despesa recorrente que muitas pessoas assumem sem precisar.

Se um dia o projeto precisar de recursos mais complexos, tráfego muito alto ou integrações específicas, a arquitetura pode evoluir. Eu prefiro pagar por infraestrutura quando ela resolve um problema real — não apenas porque sempre foi assim.

Escrever no Obsidian é melhor do que escrever dentro de um painel para mim

Aqui está uma parte que eu gosto bastante desse modelo.

Eu posso escrever os artigos no Obsidian, no mesmo lugar em que organizo ideias, notas, referências e projetos.

Cada post é apenas um arquivo .md.

Markdown é uma forma simples de escrever texto com pequenas marcações. Por exemplo:

## Um subtítulo

Um parágrafo normal.

- uma lista;
- outra ideia;
- um link.

Não preciso abrir o CMS, esperar um editor carregar, escolher bloco, ajustar espaçamento e depois descobrir por que o título ficou diferente no celular.

Eu escrevo.

Salvo o arquivo.

E o projeto transforma aquilo em página.

Cada post começa com um pequeno bloco de informações no topo:

---
title: "Título do artigo"
description: "Uma descrição curta para buscadores e compartilhamentos."
pubDate: 2026-09-07
status: draft
image: "troquei-wordpress-por-astro-cloudflare-pages.png"
tags:
  - automação
  - tecnologia
---

Depois vem o texto.

Isso deixa o conteúdo portátil. Se amanhã eu quiser trocar de ferramenta, meus artigos continuam sendo arquivos de texto legíveis. Não ficam presos em uma base de dados ou em um editor proprietário.

Como um post sai do Obsidian e chega no ar

O processo é bem menos complicado do que parece:

1. escrevo o artigo no Obsidian;
2. salvo como .md;
3. coloco o arquivo na pasta de posts do projeto;
4. reviso localmente;
5. envio a alteração para o repositório;
6. o Cloudflare Pages publica a versão nova.

O post pode ficar como draft durante a revisão. Nesse estado, ele não aparece nas listagens, no sitemap nem no RSS público.

Quando estiver pronto, eu altero uma única linha:

status: published

É uma publicação com revisão de código aplicada ao conteúdo.

Tem histórico. Tem comparação de mudanças. Dá para voltar atrás. Dá para revisar antes de colocar no ar.

Onde entra a IA nessa história

Eu não acho que todo mundo precise aprender Astro, Git, Cloudflare e Markdown antes de publicar a primeira ideia.

Existe um pouco de conhecimento técnico envolvido, sim.

Você precisa entender, pelo menos em alto nível, onde está o projeto, como o deploy acontece, o que é um domínio e como revisar uma mudança antes de publicar.

Mas a IA mudou bastante a barreira de entrada.

Ela pode ajudar a criar o projeto, explicar cada configuração, encontrar erros no deploy, montar os componentes, organizar o SEO e até transformar uma ideia bruta em um primeiro rascunho de artigo.

O cuidado é não apertar “aceitar” para tudo sem entender o que está acontecendo.

IA acelera muito quem consegue dar contexto, testar e fazer boas perguntas. Ela não elimina a necessidade de pensar no objetivo do site.

Foi exatamente assim que trabalhei neste blog: eu defini o que queria, a IA ajudou na execução e eu fui ajustando o projeto até ele ficar do jeito que faz sentido para mim.

E o Hermes pode escrever posts para mim

Essa estrutura abre uma possibilidade que eu considero muito interessante.

Meu agente Hermes pode me ajudar a transformar ideias, anotações, áudios transcritos ou briefings em posts prontos para revisão.

Ele não precisa entrar em um WordPress, clicar em menus ou lidar com um editor visual.

Ele só precisa gerar um arquivo .md com o conteúdo e os dados iniciais do post:

title: "..."
description: "..."
pubDate: 2026-09-07
status: draft
tags:
  - ...

Depois eu reviso o texto, ajusto o que for necessário e envio para o repositório.

É uma forma muito limpa de usar IA para conteúdo: ela ajuda a acelerar o trabalho, mas o material continua sendo um arquivo simples, revisável e sob meu controle.

Não existe uma automação misteriosa publicando qualquer coisa em meu nome.

Existe um fluxo claro:

ideia
↓
rascunho criado com ajuda da IA
↓
revisão humana
↓
arquivo Markdown
↓
repositório
↓
publicação

O que isso diz sobre o meu trabalho

Eu gosto de tecnologia quando ela reduz atrito.

Não me interessa usar IA, automação ou uma ferramenta nova apenas porque está na moda. Me interessa entender o processo, encontrar o desperdício e construir uma solução que seja simples de operar depois.

Neste blog, o problema era pequeno: eu queria publicar conteúdo com autonomia, boa performance e pouca manutenção.

A solução não foi “instalar mais um CMS”. Foi desenhar um fluxo que combina com a forma como eu penso e trabalho.

Esse mesmo raciocínio aparece nos projetos que desenvolvo para empresas:

• entender onde o processo está travando;
• separar ferramenta de problema;
• automatizar o que é repetitivo;
• manter uma pessoa no controle onde decisão humana importa;
• construir algo que continue funcionando depois do lançamento.

Às vezes isso significa um CRM. Às vezes significa uma automação no WhatsApp. Às vezes é um agente de IA, uma integração ou um pequeno sistema interno.

E, às vezes, como neste caso, significa apenas trocar uma ferramenta pesada por uma estrutura mais adequada.

Não é para todo mundo — e tudo bem

Se você precisa que várias pessoas sem familiaridade técnica publiquem todos os dias, com fluxo editorial complexo, permissões, agendamento e dezenas de integrações, talvez WordPress, Ghost ou outro CMS ainda seja mais adequado.

Ferramenta boa não é a que tem a maior lista de recursos.

É a que resolve o seu problema com a menor quantidade de atrito.

Para mim, um blog em Astro, versionado no GitHub e publicado na Cloudflare faz muito sentido.

Eu escrevo onde gosto de escrever.

Publico sem depender de hospedagem tradicional.

Tenho controle do conteúdo.

E posso usar agentes de IA como o Hermes para acelerar a produção sem abrir mão da revisão.

No fim, não foi apenas uma troca de WordPress por Astro.

Foi uma troca de processo.

E é essa parte que eu acho mais interessante.