Criar um site com IA no WordPress moderno é fechar um fluxo nativo: produto escrito, protótipo aprovado, tema de blocos, checagem na página pública e no editor, deploy com rollback. Não é pedir a página inteira em um único turno.
Pedir um site “do zero” ao agente e esperar resultado consistente em um único turno parece rápido. Na prática, o que volta costuma ser um layout solto: até parece site na página pública, mas não vira um ativo editável no WordPress moderno (tema de blocos, Editor do site, padrões de bloco). Eu passei a fechar o trabalho em etapas, com fidelidade na página pública e no editor, para alterar conteúdo e estilos pelo painel, no padrão atual do WordPress, também sem precisar da IA no dia a dia. Site novo ou refação. O contrato é o mesmo.
Este texto entrega um fluxo reproduzível (decisões → protótipo → tema de blocos → checagens → deploy), o critério de priorizar recursos nativos, e o que a IA faz bem ou mal em cada etapa. A prova pública é o hub do próprio IA+WP, alinhado ao pilar IA e WordPress: a combinação estratégica de 2026.
O que você precisa
Para acompanhar o raciocínio: noção de editor de blocos, diferença entre página estática e tema de blocos (Editor do site), e vontade de revisar visualmente o que o agente gera.
Para repetir o fluxo (pilha que eu usei em setembro/2026 neste hub):
- Ambiente WordPress local (Studio, Local by Flywheel ou equivalente)
- Editor com agente (Cursor ou similar) e acesso aos arquivos do tema
- Tema de blocos de partida (ou estrutura inicial a partir de um tema FSE que você já confia)
- Critério visual escrito (mesmo que curto): rotas, CTA, tokens
- Protótipo HTML estático aprovado antes de portar para o editor de blocos
- Backup e janela de rollback se for produção
A barreira não é “saber gerar prompt”. É ter fonte da verdade (protótipo + tokens) e checagens humanas entre etapas. Sem isso, a IA só multiplica improvisação.
O problema não é falta de IA
O atrito aparece em dois cenários parecidos:
- Site novo: o agente entrega layout em HTML, React ou CSS. O trabalho real começa depois: transformar isso em tema de blocos editável no WordPress, não apenas “colar” o visual no ar.
- Refação: o site no ar já existe, mas a composição não combina com o foco atual (conteúdo, autoridade, produto). Trocar só o visual sem mudar o contrato de edição cria outra dívida.
Nos dois casos o risco é o mesmo: velocidade fora do modelo nativo. O WordPress moderno já carrega templates, partes de template, padrões de bloco, theme.json e controles de estilo no editor. Se a IA ignora isso e “resolve” com HTML e CSS opacos, você ganha um mockup: a página pública até pode parecer certa, mas o canvas do editor mente, e trocar um título ou um espaçamento vira edição de arquivo (ou outro prompt), não uso do painel.
Construtores de página entram aqui só como outro contrato de edição. Este artigo assume tema de blocos e o que o core já oferece. Não é cruzada contra nenhuma ferramenta; é o caminho que eu documentei e publiquei.
O fluxo em seis atos
Ordem que eu fechei na prática (e que o agente segue quando o processo está escrito):
- Decisões de produto — o que a home faz, CTA, o que fica fora desta leva.
- Notas curtas de arquitetura e design — rotas + design system (tokens, tipografia, o que não inventar). Documentação viva do projeto, não um wiki separado.
- Protótipo HTML — composição e tom aprovados no navegador, sem Editor do site.
- Tema de blocos — estrutura FSE, cabeçalho e rodapé, padrões, páginas.
- Checagens de fidelidade — protótipo × página pública × canvas do editor (desktop e celular). Página pública bonita e editor quebrado = fatia incompleta.
- Deploy seletivo — backup, tema, conteúdo crítico, SEO no ar, rollback disponível.
Pulou o protótipo e foi direto ao editor? Foi aí que eu mais perdi tempo. Corrigir composição no Gutenberg custa mais do que ajustar HTML estático. Pulou a checagem do canvas? O visitante vê uma coisa; quem edita a página vê outra.
O que a IA faz bem (e o que não)
| Etapa | Faz bem | Não faz bem (sozinha) |
|---|---|---|
| Decisões | Listar opções e trocas | Fechar critério (CTA, escopo, fora de escopo) |
| Notas | Rascunhar rotas e tokens a partir do tema atual | Congelar o que é fonte da verdade |
| Protótipo | Gerar layout alinhado aos tokens | Aprovar composição e textos |
| Tema | Portar seções, padrões de bloco, theme.json, CSS residual | Garantir fidelidade na página pública e no editor; preferir blocos nativos |
| Deploy | Empacotar tema, WP-CLI, checklist | Autorizar o ar e o rollback |
O que a IA faz bem ainda precisa de aceite. O que ela não faz bem sozinha é exatamente o que costuma “passar” com confiança no chat.
Falhas que eu vi o agente cometer com confiança:
- Fechar uma fatia porque “as classes batem” na página pública, sem abrir o Editor do site ou o editor da página.
- Inventar CTA e tom (linguagem de funil quando o briefing pedia outra conversão).
- Empurrar produção sem validação humana.
- Resolver layout com CSS que o painel não expõe: o autor fica refém do agente para um ajuste de margem.
Regra operacional: Studio, Local ou equivalente são o laboratório deste teste, não a única pilha possível. Em produção, ensaio local + proteções + OK humano. Não é “nunca produção”; é não alterar o site no ar no escuro.
Nativo primeiro: página pública, editor e painel
Priorizar recursos nativos não é dogma de pureza. É o critério que deixa o site editável depois que o chat fecha.
Quando digo nativo, falo deste conjunto:
theme.jsonpara tokens (cor, tipografia, espaçamento) que o painel de estilos do Editor do site entende- Templates e partes de template para o que se repete (cabeçalho, rodapé) e para cada tipo de tela (home, artigo, arquivo, 404)
- Padrões de bloco: um por seção reutilizável; e, quando fizer sentido, um padrão de página inteira que só encaixa essas seções (sem duplicar markup)
- Blocos do core com atributos nativos (espaço, tipografia, proporção da imagem, alinhamento) antes de CSS
- Ícones da interface com a coleção do tema e o bloco de ícone do core (
core/icon), não HTML cru com SVG solto - CSS residual só onde o core não chega (grade editorial, movimento, exceções de plugin), em lista consciente do que pode ficar no CSS
Dois testes que eu uso para não me enganar:
- Fidelidade na página pública: o que o visitante vê bate com o protótipo (ou com o briefing) no desktop e no celular.
- Fidelidade no editor: no Editor do site ou no editor da página, a composição principal se comporta. Sem peça sumida, sem layout que só “funciona” na página pública e mente na edição.
Isso não significa que todo estilo vira controle do painel. A meta é explorar ao máximo o que o WordPress moderno já oferece (blocos, atributos, estilos globais, padrões). Quando o core ou o plugin não cobrem, complementamos com CSS ou JS próprio, de preferência só onde a tela precisa (sob demanda) e com o motivo documentado. No hub, por exemplo, o visual do formulário Jetpack fica no CSS do tema: não dá para “resolver” tudo no editor, e está ok.
O que precisa ser simples no dia a dia (texto, imagem, ordem de seção, espaçamento e tipografia que o painel já expõe) não deveria depender de reabrir o Cursor. O restante é complemento consciente, não improviso escondido.
Formulário e SEO: plugins do diretório quando o core não cobre. No hub: Jetpack Forms e The SEO Framework (título, descrição, dados estruturados). O mesmo critério vale para o que motores e assistentes de resposta citam: conteúdo claro, FAQ e metadados no ar, sem depender só do HTML da página.
Prova: o hub editorial do IA+WP
Em setembro/2026 eu fechei a refação do site do projeto: de landing desalinhada ao foco atual para portal editorial em tema de blocos próprio (iawp), no ar em iaewp.com.br.
O que importou no resultado:
- Arquitetura e CTA de newsletter de artigos, não de waitlist de curso
- Protótipo HTML aprovado antes do porte para o editor de blocos
- Fatias auditáveis no tema, com checagem na página pública e no editor (não só “as classes batem”)
- Preferência por recursos nativos (atributos de bloco /
theme.json) e CSS residual enxuto - Deploy seletivo, com o tema anterior disponível para rollback
- SEO e detalhes de produção conferidos no site público (
llms.txt, base de categoria, contraste)
Isso não é tutorial do meu caso. É evidência de que o fluxo aguenta ir até produção e deixa o site operável no painel.
Limite honesto
Este texto descreve um fluxo (decisões → protótipo → tema de blocos → checagens → deploy), não um site pronto em um turno nem um passo a passo de migração a partir de um construtor de página específico.
Também fica de fora desta conversa: internacionalização, automação avançada de e-mail e auditoria completa de performance ou segurança. São temas próprios; aqui o foco é montar (ou refazer) o ativo no WordPress moderno, com IA no circuito e critérios de aceite humanos.
O hub do IA+WP serve de prova de que o fluxo chega ao ar. Não é inventário do que ainda pode evoluir nele, nem manual de cada fatia do tema.
Perguntas frequentes
Posso usar construtor de página (Elementor e similares)?
Sim. Este artigo só documenta o caminho com tema de blocos e core. Construtor de página é outro contrato de edição; não é o foco aqui.
Preciso de IA no dia a dia depois do site no ar?
Não. O fluxo usa IA na montagem. Conteúdo e estilos que o painel já expõe devem ser editáveis sem reabrir o agente.
O protótipo HTML é obrigatório?
Na prática, sim para composição nova. Pular o protótipo e corrigir só no Gutenberg foi onde eu mais perdi tempo.
O que levar daqui
Criar (ou refazer) um site com IA no WordPress moderno é menos “gerar a página” e mais fechar um fluxo nativo: produto escrito, protótipo aprovado, tema de blocos com o que o core já oferece, checagem na página pública e no editor, deploy com rollback. A IA comprime as horas de montagem. O painel cobre o dia a dia do conteúdo e dos estilos que o WordPress já expõe; o restante, quando existir, fica como complemento consciente.
Se quiser a tese por trás desse fluxo: IA e WordPress: a combinação estratégica de 2026.
Se o site já está no ar e o próximo problema é operar produção com o agente no IDE: Cursor no WordPress em produção (SSH, WP-CLI e MCP).
Quer acompanhar os próximos artigos: Receber novos artigos no IA+WP.