Lá em 2017 uma cliente me ligou em pânico. Ela havia construído o site de sua loja de flores no construtor de sites da GoDaddy, levou um fim de semana, ficou decente o suficiente no mobile, e ela estava orgulhosa disso. Depois ela quis adicionar um simples calendário de eventos. Só um calendário. GoDaddy não conseguia fazer. Não sem um workaround tão feio que teria envergonhado um desenvolvedor júnior. Ela acabou me pagando para migrar tudo para WordPress, e lembro de estar pensando: por que as pessoas começam aqui?
Ponto-chave: o builder da GoDaddy troca flexibilidade por simplicidade muito mais que seus concorrentes; WordPress, Webflow e Squarespace oferecem muito mais espaço para crescimento a custo comparável.
Entendo, de verdade. O pitch do GoDaddy é sedutor. Se inscreva, escolha um template, digite o nome da sua empresa, suba ao ar antes do almoço. Para quem nunca tocou em um CMS, essa velocidade parece um superpoder. Mas é tempo emprestado. E tendo construído bem mais de 12.000 sites na Seahawk, já perdi a conta de quantas migrações do GoDaddy fiz para clientes que saíram dele mais rápido do que esperavam.
Então deixa eu te contar no que eu realmente migrei clientes (e a mim mesmo), e por quê.
---
O Problema do GoDaddy Builder Não É Velocidade, São Limites
O website builder do GoDaddy é genuinamente rápido de colocar de pé. Não vou fingir o contrário. GoDaddy Airo, sua camada de IA, consegue estruturar um site marcado com logo e templates de campanha de email antes de você terminar seu café. O editor é limpo, intuitivo, e não ameaçador para pessoas que não sabem o que é uma div e não querem aprender.
Mas.
Você não pode mover seções livremente. Você não pode editar HTML ou CSS. Você não pode alterar layouts além das opções pré-configuradas. E certamente não pode instalar um plugin que não existe no seu ecossistema fechado. Como uma análise cuidadosa do construtor coloca de forma bem direta, a conveniência da configuração é real, mas no momento em que você quer qualquer coisa além do básico do design, você bate numa parede.
Essa parede é o problema. Não o construtor em si.
Tive um cliente, uma clínica de fisioterapia em Bristol, que estava na GoDaddy há três anos. Site bem bonito. Depois queriam agendamento online com formulários de intake, integração com seu software de gerenciamento de prática e uma área de membros para bibliotecas de vídeos de exercício. Gastamos duas horas auditando o que GoDaddy podia suportar nativamente. A resposta era essencialmente nada dessa lista. Três anos de conteúdo, e eles tiveram que começar do zero arquitetonicamente.
Isso não é um aviso sobre GoDaddy especificamente. É um aviso sobre escolher plataformas baseado em como rápido você consegue começar em vez de como longe você consegue ir.
---
WordPress: Ainda a Escolha Sensata para a Maioria
Pessoas vêm declarando WordPress morto durante praticamente uma década. Ainda está alimentando cerca de 40% da web inteira. Isso não é inércia, é efeito de rede em uma escala que nada conseguiu desalojar.
Por que ainda o recomendo
O ecossistema de plugins por si só já vale a pena (que é, sendo justo, gratuito). 60 mil+ plugins significa que praticamente qualquer recurso que você imagina já foi construído por alguém, testado em produção por milhares de sites e documentado até a morte no YouTube. WooCommerce para ecommerce. ACF para campos personalizados. Yoast ou Rank Math para SEO. A stack é chata e isso é genuinamente um elogio.
Para agências, o pool de talentos também importa. Posso contratar um desenvolvedor WordPress em Londres, Lagos ou Ljubljana e ter uma confiança razoável de que ele sabe o que é um custom post type. Tente fazer isso com um builder proprietário.
As Ressalvas do WordPress sobre as Quais Sou Honesto
Não é perfeito. Conflitos de plugins são reais. Manter 40 plugins atualizados sem quebrar nada é, como um comentarista do Hacker News disse, "babysitting MySQL." Segurança é uma preocupação genuína quando você está rodando uma versão antiga de um plugin mal mantido. E o editor de blocos (Gutenberg) ainda divide opiniões de formas que parecem quase teológicas.
Mas para um cliente que precisa de flexibilidade genuína, propriedade do conteúdo e um site que possa crescer com ele? WordPress continua sendo minha primeira recomendação a menos que o briefing aponte especificamente para outro lugar.
---
WordPress Headless e Jamstack: Quando o Briefing Aponta para Outro Lugar
Cerca de três anos atrás Seahawk começou a receber mais briefs que tinham "performance" como um requisito obrigatório, não um nice-to-have. Tempos de carregamento rápidos. Pontuações altas de Core Web Vitals. Conteúdo servido em múltiplas superfícies, web, app, talvez uma tela de quiosque em um ambiente de varejo. Hospedagem WordPress tradicional não ia dar conta.
Foi aí que nos aprofundamos mais na arquitetura headless.
O Que Headless Realmente Significa (Sem o Jargão)
WordPress headless significa que você mantém WordPress como o backend, o repositório de conteúdo, a interface de administração na qual seu cliente faz login, mas você desacopla completamente o frontend. O "head" (o que os usuários veem) é construído em um framework JavaScript como Next.js ou Astro. WordPress serve conteúdo via sua REST API ou GraphQL. O frontend busca esses dados e renderiza do jeito que quiser.
O resultado: carregamentos de página absurdamente rápidos, sem gargalo de renderização PHP, e total liberdade sobre a arquitetura do seu frontend. A segurança também melhora porque o painel WordPress não fica exposto publicamente da mesma forma.
O Cenário de CMS Jamstack
Se você está indo full Jamstack, você nem precisa usar WordPress como seu backend. Existe um campo sólido e crescente de opções de CMS headless construídas especificamente para essa arquitetura. Algumas que usei em produção:
- Contentful, maduro, bem documentado, um pouco caro em escala mas sólido como rocha
- Sanity, modelagem de conteúdo extremamente flexível, ótima DX, colaboração em tempo real para equipes editoriais
- Storyblok, o editor visual é genuinamente impressionante para clientes não-técnicos que querem ver as mudanças em tempo real
- Strapi, open-source, auto-hospedável, baseado em Node.js, bom se você quer manter os custos de infraestrutura baixos
- Directus, subestimado, especialmente para projetos com muitos dados que precisam de uma camada adequada de abstração de banco de dados
Nenhuma delas é perfeita para todo projeto. O visual editor do Storyblok é uma delícia para editores, mas adiciona complexidade do lado do desenvolvedor. A linguagem de query GROQ do Sanity tem uma curva de aprendizado. Escolha baseado no projeto real, não no hype.
---
EmDash: O Promissor Que Vale a Pena Acompanhar (Com Ressalvas)
Algo interessante saiu em abril de 2026. EmDash é um novo CMS apoiado por Cloudflare, se posicionando como sucessor espiritual do WordPress, construído em tecnologias web modernas, com isolamento de plugins via Cloudflare Workers, e conteúdo armazenado como dados estruturados que são nativamente legíveis por ferramentas de IA.
A proposta é genuinamente interessante. WordPress roda em PHP, que funciona mas não é exatamente o que você desenharia do zero em 2026. EmDash foi construído para implantação edge-native, conteúdo estruturado, e um mundo onde assistentes de IA são cada vez mais como as pessoas encontram informações.
Ainda não implantei EmDash em produção. Foi lançado em beta e estou acompanhando. Há algumas preocupações reais que merecem ser anotadas:
- O ecossistema é novo demais. 60.000 plugins do WordPress versus... isso aí. Ainda.
- O recurso de isolamento de plugins só funciona no runtime do Cloudflare, o que é ok se você está comprometido com essa infraestrutura, limitante se você não está.
- É um produto em beta. Risco inerente. Não coloco betas na frente de clientes que precisam de estabilidade.
O consenso honesto de pessoas que o testaram é: tecnicamente impressionante, praticamente incompleto. Vale a pena revisitar em 12-18 meses. Vou estar fazendo exatamente isso.
---
Como Realmente Escolher Entre Essas Opções
É o seguinte, a maioria do conteúdo "qual CMS é o melhor" online trata isso como uma comparação de especificações. Caixas de seleção. Matrizes de funcionalidades. Não é assim que você escolhe uma plataforma para um projeto real.
É assim que eu realmente abordo:
- Pergunte o que o cliente vai precisar em 18 meses, não hoje. Se são um florista solo, WordPress em hospedagem gerenciada provavelmente é suficiente. Se são uma startup backed por VC esperando crescimento de 10x de tráfego, arquitete para isso agora.
- Pergunte quem vai manter isso após o lançamento. Uma configuração Jamstack headless é brilhante até o gerente de marketing de 58 anos do cliente ter que atualizar um post do blog. Aí vira um ticket de suporte esperando para acontecer. Combine a complexidade técnica com o time.
- Pergunte se o conteúdo vai para mais de um lugar. Múltiplos frontends (web + app + qualquer outra coisa) quase sempre indicam headless.
- Pergunte sobre integrações. CRM, sistemas de agendamento, processadores de pagamento, análises, mapeie isso antes de se comprometer com uma plataforma, não depois.
- Pergunte sobre orçamento para manutenção contínua. Uma instância Strapi auto-hospedada precisa de alguém mantendo a versão do Node.js atualizada. Isso custa tempo ou dinheiro. Considere isso no cálculo.
---
A Realidade de Migração Que Ninguém Fala
Sair do GoDaddy (ou de qualquer builder proprietário) não é trivial. O conteúdo geralmente é exportável de alguma forma, mas a estrutura geralmente não é. GoDaddy não te dá exports limpos de banco de dados ou APIs de conteúdo. Você está tipicamente raspando, copiando e colando, ou usando ferramentas de migração de terceiros que fazem cerca de 70% do trabalho e deixam você limpando o resto manualmente.
Já migrei o suficiente dessas para ter um processo, mas não vou fingir que é elegante. Orce tempo real para isso. E absolutamente verifique que sua transferência de domínio para fora do GoDaddy é feita com cuidado, eles têm um histórico de tornar esse processo mais complicado do que precisa ser.
A boa notícia: uma vez que você sai, você sai de verdade. Clientes que migram para WordPress ou um CMS headless quase nunca voltam.
---
FAQ
O website builder da GoDaddy é bom para algo?
Honestamente, sim, para casos de uso muito específicos. Um site de uma página para um profissional local que só precisa de uma presença online e um número de telefone. Uma página de destino temporária. Algo que uma pessoa não-técnica precisa que saia do ar em horas e nunca precisará mudar significativamente. Para esses casos, a velocidade de configuração é uma vantagem real. Para qualquer coisa com ambições de crescimento, fica sem espaço rapidamente.
Preciso saber programar para migrar para WordPress?
Não necessariamente. Hospedagem WordPress gerenciada de provedores como Kinsta, WP Engine, ou até mesmo Hostinger torna o lado operacional muito mais acessível. Você ainda vai querer algum conforto com a interface de administração e idealmente alguém que você possa chamar quando as coisas quebrarem. Mas muitos pequenos empresários rodam sites WordPress sem tocar em uma linha de código.
Qual é a diferença entre CMS headless e um CMS regular?
Um CMS tradicional (como WordPress clássico) lida tanto com o armazenamento de conteúdo quanto com a renderização da página, é um sistema acoplado. Um CMS headless só lida com o armazenamento de conteúdo e o expõe via uma API. Seu frontend, construído no framework que você preferir, busca esse conteúdo e decide como exibi-lo. A vantagem é flexibilidade e performance. A desvantagem é que você precisa de um desenvolvedor frontend, não apenas um construtor de sites.
O EmDash está pronto para uso em produção?
Para a maioria das empresas, na minha visão, não. Lançou em beta em abril de 2026 e o ecossistema é genuinamente incipiente. A arquitetura subjacente é interessante e o suporte da Cloudflare dá credibilidade. Mas eu não colocaria o site principal de marketing de um cliente em um CMS em beta quando WordPress e alternativas headless comprovadas existem. Fique atento a isso em 2027.
Posso usar WordPress como um headless CMS?
Sim, e é na verdade um meio termo muito pragmático. WordPress tem uma REST API integrada e WPGraphQL é um plugin maduro que expõe seu conteúdo via GraphQL. Então você tem a interface de admin familiar que seus clientes já conhecem, o ecossistema massivo de plugins, mas constrói seu frontend em Next.js ou Astro e obtém os benefícios de performance de um setup Jamstack moderno. Enviamos vários projetos assim na Seahawk e funciona bem.
---
A florista de 2017 ainda é cliente, pelo que vale. Ela está no WordPress agora, com um plugin de agendamento decente e um calendário de eventos que funciona de verdade. Ela não me liga em pânico desde então. Esse é o objetivo mesmo, construir algo que deixe de ser um problema para as pessoas poderem cuidar do trabalho delas de verdade.
Escolha o chato. Escolha o flexível. Escolha a coisa que você pode passar adiante.