Site estático ou WordPress: a pilha que eu desenhei no flip e o pipeline que eu uso no lugar

De onde eu falo

Meu nome é Josimar, sou CEO de uma empresa de tecnologia de verdade, de economia real. Eu sou sênior em engenharia de infraestrutura, quase um vibe coder na parte de código em si, mas sou programador de muitos anos: sei ler código de quase todas as sintaxes que eu já mexi. Sou do primeiro PHP. Eu já fiz sistema baseado em if e else.

Estou dando essa carteirada só pra falar de um vídeo que eu fiz antes, o do fim do WordPress. Falei: pra mim, o WordPress acabou. Foram lá e deitaram a lenha. "Você não sabe usar WordPress, você não entende WordPress." Cara, eu entendo de negócio. E o que eu vou mostrar aqui é, como negócio, muito mais fácil pra mim, que tenho estrutura e um tanto de site. Os números de mercado daquela conversa estão em fim do WordPress? A queda do maior CMS. Aqui o assunto é a pilha.

Óbvio que qualquer pessoa que entende de WordPress sabe que ele não vai acabar do dia pra noite. Tem COBOL até hoje. Será que o WordPress vai ser o novo COBOL? Um monte de lugar vai continuar usando, indefinidamente, por muito tempo. Então por que eu falei que acabou? Vem comigo no flip.

A pilha que um WordPress exige, camada por camada

Vou dar a spec da maioria das pessoas de WordPress que eu conheço, com quem eu conversei, gente de vários estados. Pode ter outra plataforma, tem n plataformas. Mas o caminho de uma visita até a sua página é este.

1. Domínio: no seu nome, não no da agência

O pessoal esquece muito: a gente tem o domínio. Você registra um domíniozinho. E é extremamente importante, amigo empreendedor, que o domínio esteja no seu nome. "Ah, Josimar, isso é óbvio." É óbvio, mas um monte de gente não faz: põe na mão da agência pra registrar e depois vira refém. Já vi isso um monte de vezes. Domínio é seu patrimônio, é o seu lote, a sua escritura. Como eu escolho o nome antes de criar, eu contei em como eu escolho o nome do site antes de criar com IA.

2. DNS na Cloudflare

Depois vem a camada de DNS. Você põe na Cloudflare, ativa o SSL lá e configura os registros bonitinho pra apontar pro seu host. Às vezes isso é feito automaticamente, mas é bom você saber como funciona.

3. IPv4 e IPv6: aponte os dois

O DNS aponta pra um IP. IPv4. O 192.168.0.1 da sua casa é IP local: tem as faixas que a RFC reserva pra rede interna. IP público é outra coisa. O nosso bloco, por exemplo, é próprio e começa com 45: foi um bloco recuperado da África, na época.

Aí começa a ter uns probleminhas, porque muita gente esquece do IPv6. O IPv4 acabou no mundo. Tem uma gambiarra pra todo mundo continuar tendo IPv4, o CGNAT, em que um monte de gente usa o mesmo IP. E muita rede, principalmente fora do Brasil, está forçando IPv6. Então você tem que apontar o IPv6 também pra resolver corretamente, senão pode perder usuário. "Ah, a minha rede aqui é só IPv4." Beleza, a do seu visitante pode não ser.

(Com IPv6, cada aparelho da sua casa ganha IP público real. Isso abre uns precedentes de segurança importantes, mas é assunto que eu já abri em IPv6 e sua casa aberta: o firewall do roteador que eu checo.)

4. Proxy reverso e load balance

O IP bate num proxy. Muita gente usa NGINX. O proxy recebe o nome, "o josimarjmv.com está apontando pro IP tal, cadê os arquivos?", e vai buscar. Dentro do proxy você manipula cabeçalho e faz load balance: se esse servidor estiver respondendo, eu jogo pra cá; se aquele estiver, jogo pra lá. Ou distribuo a carga.

"Legal, então eu tenho redundância pro meu cliente importante, que tem SLA." Pode ser. Mas e se isso tudo cair? Você tem que pôr na Cloudflare um DNS apontando pra outro lugar também e repetir a estrutura inteira. E eu nem cheguei no WordPress ainda.

Tem serviço que faz tudo isso automático, como a AWS. Só que tudo que é automático custa dinheiro. Dá pra fazer com VM: uma num lugar do mundo, outra em outro, sem pagar por requisição de load balancer de nuvem. Fiz essa conta em VPS ou Vercel: a conta por requisição que eu não pago. E na VM, confere se a placa de rede tem IPv4 e IPv6 configurados. Em geral já vem, mas confere.

5. PHP rodando o tempo todo

Caí na porta 80 do WordPress. WordPress usa PHP. Adoro PHP. Só que o PHP precisa rodar com alguma coisa, o PHP-FPM, por exemplo, e tem que rodar full time. Se ele cair, quebrou o seu site. E esse cara consome CPU e consome memória, o tempo todo, com visita ou sem visita.

6. Banco de dados, o gargalo

E pro PHP funcionar começa um dos maiores gargalos do WordPress: o banco de dados. Qual é o seu? Você subiu um MariaDB num Docker na sua VM. E o disco da VM é HD, SSD ou NVMe? Se é NVMe, é NVMe de verdade, de performance, ou só na hora da contratação? Você já parou pra pensar que teria que testar isso?

Pra quem está vibe codando e não põe nada em produção, talvez seja irrelevante. Mas na hora de pôr pra valer, entregar pra cliente, fazer dinheiro, cada camada dessas vira ponto de otimização de performance. E a gente sabe que nenhum WordPress roda só com isso: sem um monte de plugin, cache e coisa, não funciona. Lento, pesado e caro.

O site estático: build local, S3 e 10 de 10

Agora, qual o tipo de site que não faz nenhum sentido no WordPress e vai morrer de fato? A landing page simples. Hoje ela funciona assim: você pega o Claude Code em qualquer dispositivo e fala "colega, eu quero um site estático". Ele builda e cospe os arquivos estáticos. Roda um web server local pra você checar. Você sobe no S3, o proxy referencia o S3 direto e entrega o arquivo. Arquivo estático servido em camada de cache no proxy e na Cloudflare: isso é 10 de 10 no Core Web Vitals.

Me dá uma justificativa plausível pra ter aquela coiserada toda do WordPress pra servir um site estático. Não faz o menor sentido.

E arquivo estático é a coisa mais básica do mundo. Quem usa cPanel conhece a pastinha pública: cria um index.html com o seu "hello world", cria uma pasta com outro index.html dentro, e pronto, é navegação estática. Eu fiz site assim com 18 anos, um site de imobiliária totalmente estático. Se você não tem VPS e quer subir assim, numa hospedagem comum, eu mostro em site com Claude Code por FTP.

Um erro gritante que eu vejo quando a galera faz back e front: põe o front num Docker e o back noutro, cada um com a sua porta, tudo separado. O front é sempre um negócio buildado, estático. Cospe o front dentro do back e pronto, muito mais performance.

O pipeline: do áudio no celular até a produção

Aí vem a parte que muda o negócio. O seu telefone conecta no Claude, e o Claude está conectado no seu computador. Você manda: "faz uma pesquisa sobre por que o WordPress vai morrer e um artigo no meu site explicando os motivos". Com a skill configurada no Claude Code, ele pesquisa, organiza, escreve, faz a landing page e sobe.

"Ah, Josimar, mas vai botar em produção?" Pois é, esse é o problema grande. Você não pode dar conexão pro Claude direto no seu S3 de produção, porque ele pode subir qualquer coisa ali. A gente está em produção, não pode subir coisa sem validar. Então a estrutura é a de empresa de desenvolvimento:

1. Sandbox: o lugar de destruir, arrebentar tudo, subir de novo. É onde eu deixo o dev júnior trabalhar.
2. Staging: ambiente mais formatado, onde o QA testa se está certo.
3. Pré-produção: projeto maior. Aqui a gente faz split no proxy: 10% do tráfego na feature nova, depois 30%, testa performance, deu boa, joga todo mundo. É assim que aquela ferramenta "vai chegando devagarinho" nos usuários do Brasil.
4. Produção.

Quem controla isso é o Git. No meu caso eu gosto muito do GitLab: merge pra sandbox, merge pra staging, merge pra produção. Pra site você não precisa de pré-produção.

E quem faz o merge? Eu subo uma VM pra desenvolvimento e automação, isolada, com o Claude dentro. Crio um usuário no Git pra ele, com permissão definida, igual eu daria pra um dev júnior. Ele faz o site, abre o navegador com Playwright, confere, faz o merge pra sandbox, o deploy do Git roda e sobe. Aí ele me manda pronto pra eu validar. Uma automação no Telegram, que é de graça, me mostra o merge request e eu autorizo dali.

Você pode estar jogando bola na praia. Não é migué: eu faço isso na academia. Estou na academia mandando atualização de site que o pessoal me pede. Como isso ficou quando eu migrei três sites da empresa num pipeline desses, e como a aprovação pelo telefone funciona no dia a dia, eu contei em um site por dia com Claude Code. Por que a VM isolada e não a sua máquina, em eu rodo o Claude Code dentro de uma VM no Proxmox.

O blog é o segundo a sair do WordPress

O pipeline serve pro segundo cenário em que o WordPress vai morrer: o blog. "Ah, mas eu tenho o cara que vai lá digitar e fazer pesquisa." Pois é. Eu não estou pensando só no WordPress, estou pensando na operação inteira. O que é fazer um artigo hoje?

Primeiro, pesquisa: quem já fez isso, quais palavras-chave estão indexando, quem já fez vídeo, qual a transcrição. Aí você formata o conteúdo. E não é pra ficar copiando igual papagaio de pirata. Tudo que você for fazer na vida com IA é IA mais você, IA mais o seu DNA. Se for IA pura, os papagaios vão estar aí, todo mundo na mediocridade, e você não ganha destaque. Eu mesmo fiz a pesquisa antes de gravar esse vídeo.

Depois, imagem. Ou você tira foto sua, ou produz, ou pede pra IA gerar. Com as skills certinhas, quase toda agência de marketing hoje você resolve mandando um áudio: "Claudio, gera o artigo tal pra mim." Ele faz tudo aquilo sozinho. É por isso que o WordPress vai morrer.

O SEO eu travo no merge

"Mas você esqueceu do SEO." Não esqueci. Na hora que eu entro no SEO é covardia. Você deixa o checklist pronto no Claude: description, H1, H2, H3, o llms.txt, o sitemap, o envio pro Search Console. E se tem medo dele pular o checklist, põe um script fixo no merge. Ele confere se tem title e quantos caracteres, se tem H1, H2, H3, se o H1 está certo, a densidade de palavra-chave, o alt das imagens, se o sitemap XML foi atualizado no build. Não passou, não sobe.

Por que eu insisto nisso? Porque o maior erro que existe em SEO é o bendito checklist não cumprido. O cara esqueceu o title, fez o artigo e esqueceu o H1, subiu imagem com o nome errado, puxou conteúdo duplicado de outro lugar sem prestar atenção. Você pode mandar a IA fazer e checar na mão, ou, preferencialmente, trava ali.

Teste A/B em cinco minutos

"Claude, pega a landing page tal e troca o botão de amarelo pra verde." Quantas vezes a gente sabe que a conversão melhora só com isso? Pensa a trabalheira que era pegar alguém pra fazer isso no WordPress. Aqui são 5 minutos, ele faz o merge, você aprova, está em produção e você nem pôs a mão no computador. Não dá pra ignorar isso, meu amigo do WordPress.

E site multi-idioma, que pra quem vende fora é o maior trampo: muito melhor fazer em português e pedir pra IA fazer as outras versões. Sem sombra de dúvida.

Onde o WordPress ainda brilha

Agora, onde o WordPress continua brilhando, com absoluta certeza: site dinâmico. O maior exemplo é o e-commerce. Você tem o e-commerce configurado, o pagamento, milhares, milhões de produtos cadastrados, plugin, SEO. Não faz sentido nenhum reinventar a roda e fazer um back-end inteiro de novo.

E, meu amigo vibe coder: se tem uma coisa que você deve evitar mexer a todo custo, chama dinheiro. Transação bancária, pagamento, coisa que você não tem segurança: não bota a mão. Vão descobrir, vão usar a conta, vão fraudar. A exceção é trabalhar com um Stripe da vida, um troço fácil em que ele assume os tokens, ou o plugin solidificado e oficial da empresa de pagamento no WordPress. Aí faz sentido.

E se você não quer ou não pode sair do WordPress, o mesmo pipeline funciona: em vez de buildar e postar no S3, a IA faz o artigo e publica pela REST API do WordPress. Vale lembrar que WordPress exposto tem o seu preço: o meu foi hackeado três vezes, e eu contei o que aprendi em meu WordPress foi hackeado três vezes.

Site de notícias com milhões de acessos

"Mas site de notícia, cara, é bomba." Vamos lá. Você pode manter o editor que o pessoal do jornalismo está acostumado, o Elementor, o Gutenberg, o que for. Eles sobem a matéria e as imagenzinhas normalmente, e você põe um builder que cospe o arquivo estático.

"Mas isso é o que o WP Rocket faz." É. Ele e vários plugins de cache criam a pasta com o nome do slug e o HTML lá dentro, que é o que eu acabei de falar, porque ele sabe que isso não pesa. Só que num site com milhões de acessos, o WordPress agacha. E aí olha o tamanho do estudo pra ele aguentar porrada:

• DNS redundante, dois proxies, duas estruturas de PHP e banco;
• monitoramento e observabilidade: log, Grafana, Loki, Prometheus;
• Redis pra cache dinâmico do PHP, cache de banco, cache de todos os estáticos (imagem, JS, CSS).

Pra quê, se você pode ter tudo estático e eliminar banco, PHP e metade dessas camadas? Só se for realmente necessário. Hoje, pra mim, não faz sentido. Quanto custava cada plugin que eu tirei, eu somei em eliminei R$ 5.000 por ano em plugins de WordPress com IA.

A minha conta como negócio

Eu acredito que esse pipeline de site estático engloba 70%, 80% dos sites WordPress no mundo. É estimativa minha, de quem vive disso, não estatística. Hoje eu devo ter mais de 10 sites no WordPress, sites de 10, 12 anos, com migração de blog e layout feito com vários temas diferentes. Eu sofri muito disso. E a gente sabe fazer plugin, sabe fazer tema, tem estrutura pra suportar tudo. Só que não faz sentido nenhum eu subir um WordPress pra isso.

Um exemplo de economia real. Você que atende restaurante: com esse pipeline, vai almoçar no seu cliente, tira foto do prato novo, manda pro Claude: "faz a página desse prato novo". Antes de sair dali você chega pro dono: "vi que esse prato não estava no site, acabei de atualizar pra você". O valor que você gera pro cara não tem preço.

E dá pra automatizar o próprio setup. A partir do momento em que você tem uma VM fechadinha com o Claude, é variável de ambiente: muda a URL, a access key e a secret key do S3, o CLAUDE.md do site, dá o play com ferramenta de orquestração de infraestrutura e pronto. Estrutura replicável e escalável pra vender site.

Aceito opinião contrária. Gravei direto, sem edição, posso ter esquecido alguma coisa. Mas é isso que eu uso hoje.

Nota de cronologia

Gravei esse vídeo em 27 de maio de 2026, e este texto saiu em 14 de outubro de 2026. Na gravação eu disse que ia abrir um formulário de pré-cadastro e, se tivesse gente suficiente, um aulão ao vivo, mão na massa, de um sábado inteiro, pra ensinar esse pipeline. Isso virou a Imersão de Sites, cuja 1ª turma foi em 15/08/2026. O valor que eu chutei no vídeo era de antes de a imersão existir; o que vale é o da página dela.

Perguntas frequentes