Durante muito tempo, criar um site profissional quase sempre levava à mesma conversa: vamos fazer em WordPress?

Não por acaso. O WordPress continua sendo, com enorme diferença, o CMS mais utilizado da internet. Em agosto de 2026, ele está presente em cerca de 40,7% de todos os sites monitorados pela W3Techs e representa aproximadamente 58,9% do mercado de sites que utilizam algum CMS.

Mas ele não é a única opção.

Um site pode ser desenvolvido diretamente em HTML, CSS e JavaScript, sem painel administrativo. Pode usar WordPress. Pode utilizar um CMS mais moderno, como Payload. Pode separar completamente o sistema de gerenciamento de conteúdo da interface que o visitante acessa.

E nenhuma dessas escolhas é automaticamente melhor que a outra.

Depois de anos trabalhando com desenvolvimento de sites, eu prefiro começar por outra pergunta:

quem vai administrar esse site depois que ele estiver pronto?

A resposta costuma resolver boa parte da discussão.

O que muda quando um site é feito em WordPress?

A principal vantagem do WordPress, para mim, não é a quantidade de plugins nem a facilidade de encontrar temas prontos.

É o gerenciamento de conteúdo.

Quando desenvolvo um site em WordPress, procuro estruturar o painel para que aquilo que faz sentido editar realmente possa ser editado.

• Título.
• Texto.
• Imagem.
• Serviços.
• Equipe.
• Cases.
• Banners.
• Informações de contato.
• Posts.

Dependendo do projeto, praticamente todo o conteúdo pode ser organizado em campos próprios dentro do painel administrativo.

Isso significa que o cliente não precisa abrir um arquivo HTML, encontrar uma linha de código e descobrir onde trocar um telefone.

Ele entra no painel, altera o conteúdo e publica.

Esse é exatamente o papel de um CMS — Content Management System, ou sistema de gerenciamento de conteúdo.

Para empresas que atualizam frequentemente o site, possuem blog, publicam notícias, trocam equipe, adicionam projetos ou simplesmente querem autonomia, isso faz bastante diferença.

A liberdade do WordPress também é um dos seus problemas

Existe uma característica interessante no WordPress: ele deixa você fazer quase tudo.

• Existe plugin para formulário.
• Plugin para SEO.
• Plugin para cache.
• Plugin para segurança.
• Plugin para tradução.
• Plugin para criar campos.
• Plugin para criar outros plugins.

Essa liberdade ajudou a transformar o WordPress no que ele é hoje.

Mas também criou alguns dos seus maiores problemas.

É muito fácil pegar um site originalmente bem construído e, ao longo dos anos, instalar uma quantidade enorme de plugins sem avaliar direito sua qualidade, necessidade ou procedência.

Cada nova dependência adiciona código que precisa ser mantido.

E software precisa ser atualizado.

A própria documentação oficial do WordPress recomenda manter o WordPress, temas e plugins sempre atualizados e excluir plugins que não estejam sendo utilizados.

Isso não significa que WordPress seja inseguro.

Um site WordPress bem desenvolvido, atualizado, protegido e hospedado corretamente pode ser bastante seguro.

Mas ele possui uma superfície de ataque maior do que um site composto apenas por arquivos estáticos.

• Existe um painel administrativo.
• Existem usuários.
• Senhas.
• Banco de dados.
• Plugins.
• Temas.
• PHP.
• APIs.

Uma senha administrativa fraca, por exemplo, pode se transformar em um problema sério. As recomendações atuais do próprio WordPress incluem senhas fortes, autenticação em dois fatores, limitação de tentativas de login e proteção adicional contra ataques automatizados.

Ou seja: WordPress traz autonomia, mas essa autonomia vem acompanhada de manutenção.

E se o site for feito somente em HTML, CSS e JavaScript?

Existe quase uma elegância na simplicidade de um site estático.

Você desenvolve as páginas, gera os arquivos e publica.

Se aquele site não possui banco de dados, painel administrativo ou processamento no servidor, há simplesmente muito menos coisa acontecendo.

Isso traz algumas vantagens enormes.

Performance

Um site estático bem desenvolvido tende a ser extremamente rápido.

O servidor basicamente precisa entregar arquivos prontos para o navegador.

Não é necessário consultar um banco de dados, carregar o WordPress, executar dezenas de funções PHP e montar uma página antes de responder à requisição.

Isso não quer dizer que todo site estático seja rápido ou que todo WordPress seja lento.

Um WordPress bem construído, com boa hospedagem, cache, CDN e controle de plugins também pode atingir excelente performance.

Mas no site estático nós começamos com uma arquitetura naturalmente mais simples.

Menos manutenção

Talvez essa seja minha parte favorita.

Um site estático que funciona hoje provavelmente continuará funcionando exatamente da mesma forma daqui a bastante tempo.

Não existe uma nova versão do HTML que obrigará você a entrar no painel na terça-feira para atualizar alguma coisa.

Não existe plugin incompatível.

Não existe atualização automática quebrando um componente.

O que foi publicado tende a permanecer publicado.

Segurança

Também existe uma redução muito grande da superfície de ataque.

Se não há painel administrativo, banco de dados ou aplicação sendo executada no servidor, desaparecem diversos caminhos tradicionais utilizados para comprometer um site.

Isso não torna o site invulnerável.

A conta da hospedagem ainda pode ser comprometida. Credenciais de FTP ou SSH podem vazar. O domínio pode ser atacado. Scripts externos utilizados pelo site podem ter problemas.

Mas é uma estrutura muito menor para proteger.

Então por que não fazer tudo em HTML?

Porque alguém precisa editar o conteúdo.

E aqui aparece a principal desvantagem.

Imagine que seis meses depois alguém precise trocar:

São Paulo — SP

por:

Campinas — SP

Em WordPress, provavelmente basta entrar no painel e alterar um campo.

Em um site estático, alguém precisa modificar o arquivo correspondente e publicar novamente aquela versão.

Para quem sabe trabalhar com código, isso pode levar segundos.

Para um departamento de marketing que apenas quer substituir uma imagem do banner, é completamente inconveniente.

O problema aumenta bastante quando estamos falando de um site com dezenas ou centenas de páginas.

Por isso, quando avalio WordPress ou HTML, normalmente não penso primeiro em performance.

Penso em frequência de atualização e em quem será responsável por ela.

Quando eu escolheria um site estático?

Existem projetos em que considero essa solução excelente.

Uma empresa possui um site institucional relativamente pequeno, raramente altera o conteúdo e já sabe que qualquer mudança futura será realizada por um desenvolvedor.

Nesse caso, criar um painel administrativo que provavelmente nunca será acessado pode significar adicionar complexidade sem necessidade.

Também pode fazer sentido para landing pages, experiências especiais, páginas de campanha ou projetos em que performance e controle absoluto do frontend sejam particularmente importantes.

Nesses casos, gosto bastante da simplicidade.

Publicou.

Funcionou.

Continua funcionando.

Quando eu escolheria WordPress?

Quando existe uma necessidade clara de administrar conteúdo.

Um blog como este é um exemplo óbvio.

Uma empresa que publica notícias também.

Um escritório que frequentemente adiciona profissionais.

Uma construtora que cadastra empreendimentos.

Uma empresa que publica cases.

Uma instituição com várias pessoas responsáveis pelo conteúdo.

Nesses projetos, o CMS não é um peso desnecessário.

Ele resolve um problema real.

E existe outra enorme vantagem no WordPress que às vezes é esquecida: continuidade.

Por ser tão popular, existe uma quantidade enorme de desenvolvedores, empresas e profissionais familiarizados com a plataforma.

Se daqui a cinco anos o profissional que criou o seu site não estiver mais disponível, encontrar alguém capaz de assumir um projeto WordPress tende a ser relativamente fácil.

Isso também tem valor.

Existe ainda um terceiro caminho

A discussão fica mais interessante quando percebemos que não precisamos escolher apenas entre WordPress ou HTML puro.

Existem outros CMS.

Este próprio site, por exemplo, utiliza Payload CMS.

O Payload é uma plataforma open source baseada em TypeScript e Next.js que pode gerar painel administrativo, autenticação, APIs REST e GraphQL, controle de acesso, gerenciamento de arquivos e banco de dados a partir da estrutura definida pelo desenvolvedor.

Assim como faço em WordPress com campos personalizados, no Payload posso definir exatamente o que será administrável.

Um campo de título gera um título.

Uma imagem pode ganhar seu próprio campo.

Uma página pode ter blocos.

Determinadas informações podem aparecer ou desaparecer dependendo das escolhas realizadas no painel.

O próprio Payload gera sua interface administrativa a partir dessa estrutura de dados.

Isso permite uma experiência interessante: conseguimos manter a liberdade de um desenvolvimento moderno e personalizado sem abrir mão de um painel para administrar o conteúdo.

Então Payload é melhor que WordPress?

Também não.

Ele resolve problemas diferentes.

WordPress possui uma comunidade gigantesca, milhares de plugins, documentação acumulada durante décadas e uma quantidade enorme de profissionais disponíveis.

Payload é muito mais nichado.

Se uma empresa quiser trocar de fornecedor amanhã, será muito mais fácil encontrar alguém que trabalhe com WordPress do que alguém especializado em Payload.

Por outro lado, em projetos onde quero mais controle sobre arquitetura, código e integração entre frontend e CMS, ferramentas como Payload podem fazer bastante sentido.

É uma troca.

Praticamente toda decisão tecnológica é.

E o SEO?

Esse é outro ponto em que aparecem muitos mitos.

Um site não terá um bom SEO simplesmente porque usa WordPress.

E também não terá um SEO melhor automaticamente porque foi desenvolvido em HTML.

É possível criar excelentes sites para mecanismos de busca usando os dois caminhos.

Um site estático pode ter ótima performance, HTML semântico, metadados corretos, sitemap, dados estruturados e excelentes Core Web Vitals.

WordPress também.

A diferença é que no WordPress existem ferramentas que facilitam algumas dessas tarefas para quem administra o conteúdo. Em um desenvolvimento próprio, o desenvolvedor precisa construir ou configurar essas estruturas.

Tecnologia ajuda.

Mas arquitetura, conteúdo, performance e qualidade da implementação continuam sendo muito mais importantes que o nome do CMS.

WordPress ou site próprio: afinal, qual escolher?

Eu resumiria a decisão desta forma:

Mas essa tabela ainda simplifica bastante a decisão.

Já vi projetos que deveriam ter sido estáticos receberem um WordPress enorme simplesmente porque era o processo padrão de quem desenvolveu.

Também já vi empresas receberem sites completamente estáticos e descobrirem depois que precisariam chamar um desenvolvedor toda vez que quisessem alterar três linhas de texto.

Nenhuma tecnologia deveria ser escolhida apenas por hábito.

A tecnologia deveria aparecer depois do problema

Essa talvez seja a principal conclusão que anos trabalhando entre design e desenvolvimento me trouxeram.

Eu não gosto de começar um projeto dizendo:

“Vou fazer seu site em WordPress.”

Antes de entender o projeto, essa frase não significa muita coisa.

Talvez WordPress seja exatamente a melhor escolha.

Talvez um site estático resolva tudo com menos complexidade.

Talvez faça sentido utilizar Payload.

Talvez exista outra arquitetura melhor.

O interessante de conhecer diferentes ferramentas não é conseguir usar todas elas em todo projeto.

É conseguir escolher qual delas não usar.

No final, a maioria das pessoas que visita um site sequer sabe — e provavelmente nunca saberá — se aquilo está rodando WordPress, Payload, HTML estático ou alguma outra tecnologia.

E está tudo bem.

O visitante deveria perceber outra coisa:

que o site abriu rápido, foi fácil de usar, encontrou o que precisava e a empresa pareceu confiável.

A tecnologia está ali para fazer isso acontecer.

Não para ser o motivo do projeto existir.