A Kiwop tinha um site em WordPress há anos. Funcionava, mas já não nos representava. Tínhamos evoluído para projetos de software à medida, arquiteturas headless e inteligência artificial aplicada, e o nosso próprio site continuava a ser um monólito PHP com plugins acumulados ao longo dos anos. Era como um carpinteiro com a porta de casa partida.
Em janeiro de 2026, decidimos parar e começar do zero. Não um redesign sobre WordPress, mas uma arquitetura completamente nova. Este artigo conta porquê, como e que resultados obtivemos.
O site anterior: o que falhava
Não é que o site estivesse avariado. Carregava, tinha boa aparência, tinha conteúdo. Mas acumulava problemas que se iam agravando:
Desempenho medíocre. WordPress com os seus plugins de cache, otimização de imagens e page builders gerava um HTML pesado. Os Core Web Vitals em dispositivos móveis não passavam de forma consistente, e o Google penaliza cada vez mais a experiência do utilizador.
Segurança exposta. WordPress é o CMS mais atacado do mundo. O painel de administração está em /wp-admin, os endpoints da API são conhecidos, e cada plugin é uma superfície de ataque potencial. Mantê-lo atualizado era um trabalho constante.
Rigidez. Alterar o design de uma secção implicava mexer em templates PHP, hooks, CSS inline do page builder e rezar para que não se quebrasse outra coisa. O conteúdo estava acoplado à apresentação.
Dívida técnica no conteúdo. Anos de publicações tinham deixado mais de 240 artigos de baixa qualidade, quase 200 duplicados do WPML sem traduzir e dezenas de páginas thin content. O Google via tudo, e a autoridade do domínio diluía-se.
A decisão: arquitetura headless
Quando dizemos "headless" não falamos de uma moda tecnológica. Falamos de separar duas coisas que não têm de andar juntas: onde se gere o conteúdo e como se mostra ao utilizador.
O que ganha o negócio com isto?
Velocidade real, não percecionada. O frontend gera HTML puro no servidor. Não há PHP a interpretar em cada pedido, não há plugins a carregar scripts desnecessários. O navegador recebe exatamente o que precisa, nada mais.
Segurança por design. O CMS onde se edita o conteúdo não está exposto à internet. Não há /wp-admin para atacar. A superfície de ataque reduz-se drasticamente.
Flexibilidade total. A equipa de design pode alterar qualquer componente visual sem tocar na base de dados do conteúdo. E a equipa editorial pode publicar sem se preocupar com a forma como é renderizado.
Escalabilidade. Servir um site em 7 idiomas a partir de um único frontend com cache multinível é viável. Com WordPress e WPML, cada idioma multiplicava a complexidade.
Astro + Payload CMS: por que esta combinação
Avaliámos várias opções. Next.js, Nuxt, Remix para o frontend. Strapi, Directus, Sanity para o CMS. Escolhemos Astro e Payload por razões muito concretas.
Astro gera HTML estático ou renderizado no servidor sem enviar JavaScript ao navegador por defeito. Se uma página não precisa de interatividade, o utilizador recebe HTML e CSS puros. O resultado: 0 milissegundos de Total Blocking Time. Zero. O thread principal do navegador fica livre.
Payload CMS é um CMS headless sobre PostgreSQL com uma API REST limpa e tipagem completa em TypeScript. Ao contrário do Strapi ou Sanity, o Payload é auto-hospedado: os nossos dados estão na nossa base de dados, não num SaaS externo. Para uma agência que gere dados de clientes, isto não é negociável.
A combinação resolve um problema real: conteúdo gerido de forma profissional, apresentado com um Lighthouse de 97 e 0 ms de bloqueio no navegador, sem dependências externas nem vendor lock-in.
O processo: 35 dias, 230 commits
Não foi um projeto de seis meses. Desde o primeiro commit a 10 de janeiro de 2026 até à versão em produção, passaram 35 dias. 230 commits. Uma equipa reduzida com objetivos claros.
Fase 1: estrutura e componentes (semanas 1-2)
Definimos a arquitetura modular: 14 componentes de secção reutilizáveis (hero, grelha de serviços, processo por etapas, FAQs, CTAs) que se combinam como blocos para construir qualquer página de serviço. Cada serviço define-se com um ficheiro de configuração por idioma, sem tocar em código.
A decisão mais importante foi não usar nenhum framework de JavaScript no cliente. Sem React, sem Vue, sem Svelte. Astro puro com islands architecture para os poucos componentes que precisam de interatividade (como o chatbot). O resultado: um bundle de JS próximo de zero para 95% das páginas.
Fase 2: multi-idioma (semana 3)
Passámos de 3 idiomas (espanhol, inglês, catalão) para 7 (acrescentámos alemão, francês, neerlandês e português). Isto implicou:
- Um sistema centralizado de traduções para toda a interface, gerido a partir de um único ficheiro.
- Hreflang correto com fallback desativado para evitar que o Google indexasse conteúdo sem tradução.
- URLs limpas por idioma sem trailing slash (1.001 URLs indexadas no Google Search Console, todas coerentes).
Um detalhe que nos custou horas: a regex de deteção de idioma nas URLs. Um padrão incorreto fazia match de /ca dentro de /casos-de-exito, quebrando as rotas em catalão. Parece trivial, mas num site com mais de 2.000 páginas, um bug assim é catastrófico para SEO.
Fase 3: migração de conteúdo e limpeza (semana 4)
Migrámos todo o blog de WordPress para Payload CMS. Mas não foi uma transferência direta: aproveitámos para fazer uma auditoria profunda ao conteúdo.
- 243 artigos tóxicos eliminados (conteúdo de baixa qualidade, irrelevante ou desatualizado)
- 199 duplicados do WPML despublicados (versões em inglês e catalão que eram cópias sem tradução do espanhol)
- 31 páginas thin content eliminadas com códigos 410 em nginx
- 3 pares de posts duplicados consolidados com redirecionamentos 301
- 885 títulos encurtados para menos de 60 caracteres
- 333 meta descriptions ajustadas para menos de 160 caracteres
Esta limpeza foi deliberada. A Helpful Content Update do Google penaliza ao nível do site. Ter 200 páginas de lixo arrasta para baixo as 700 boas.
Fase 4: SEO e desempenho (semana 5)
Auditoria de hierarquia de headings nas 2.114 páginas do site: 0 erros, 0 avisos. Cada página tem uma estrutura semântica correta, desde H1 até H4.
Implementámos um sistema de cache de 4 camadas (Payload CMS, Redis SWR, nginx SSR e Cloudflare CDN) com purga ordenada. A ordem importa: se purgas o Cloudflare mas o Payload ainda tem cache antigo, o nginx re-cacheia dados desatualizados imediatamente. Parece óbvio quando escrito, mas aprendemos isto a depurar por que razão as alterações não apareciam em produção.
O papel da IA
Seria desonesto não o mencionar: usámos IA como ferramenta de desenvolvimento durante todo o processo. Não para gerar código às cegas, mas como um par de programação que nos ajudou a auditar mais de 2.000 páginas, detetar inconsistências de SEO em escala e automatizar tarefas repetitivas como a normalização de títulos em 7 idiomas.
A IA não desenhou a arquitetura nem tomou decisões de negócio. Mas acelerou significativamente a execução, especialmente nas fases de auditoria e limpeza de conteúdo.
Resultados: os números
Desempenho (Lighthouse)
As pontuações de Lighthouse sobre o site em produção:
- Performance: 97/100 (móvel e desktop)
- Acessibilidade: 100/100
- Boas práticas: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2,2 segundos — aprovado (limiar Google: < 2,5 s)
- TBT (Total Blocking Time): 0 milissegundos — aprovado (limiar: < 200 ms)
- CLS (Cumulative Layout Shift): 0 — aprovado (limiar: < 0,1)
TBT de 0 milissegundos significa que o navegador não bloqueia em nenhum momento. CLS de 0 significa que nada se move enquanto a página carrega. Estes números não são teóricos: são medições reais sobre o site em produção.
Impacto nos motores de busca
A limpeza de conteúdo produziu um efeito esperado: menos impressões totais (eliminámos centenas de páginas), mas melhor qualidade no que permanece.
- CTR: +27,8% (de 0,17% para 0,22%)
- Posição média: +9,3 posições (de 50,6 para 41,3)
- Posição média em móvel: +13,6 posições (de 36,9 para 23,3)
Menos volume, mais qualidade. As páginas que ficam posicionam-se melhor e convertem mais. É a estratégia correta quando a prioridade é atrair clientes, não acumular visitas vazias.
Escala
- 2.114 páginas auditadas e funcionais
- 7 idiomas a partir de uma única base de código
- ~1.600 artigos de blog publicados (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Deploys sem downtime com rollback automático
O que isto significa para os nossos clientes
Este site não é apenas a nossa montra. É a demonstração prática daquilo que fazemos.
A mesma arquitetura headless que move o kiwop.com — separação de frontend e CMS, cache multinível, multi-idioma nativo, desempenho PageSpeed 97+ — é exatamente o que implementamos em projetos de clientes.
Se o seu site atual:
- Demora mais de 3 segundos a carregar em dispositivos móveis
- Depende de WordPress com 20 plugins para funcionar
- Tem problemas de segurança recorrentes
- Não escala bem para múltiplos idiomas ou mercados
- Acumula dívida técnica que trava cada alteração
Há uma alternativa comprovada. Não teórica: está a vê-la agora mesmo.
Vamos conversar? Solicite uma auditoria gratuita do seu site
