Pular para o conteúdo
Voltar para projetos

Modernização de sites e plataformas

Migrações de WordPress para Next.js, sites estáticos em AWS S3 e CloudFront, com preservação de SEO e ganho de performance.

Contexto

Conjunto de trabalhos de modernização de presença digital: sites e plataformas que rodavam em WordPress ou stacks legadas e precisavam de mais performance, menos superfície de manutenção e custo de operação previsível.

Desafio

Migrar sem perder o que já funcionava. Um site com histórico de indexação carrega valor de SEO acumulado: trocar a stack e perder as URLs significa jogar esse valor fora.

Meu papel

Arquitetura, desenvolvimento, infraestrutura e deploy.

Responsabilidades

  • Arquitetura da migração e do modelo de conteúdo.
  • Implementação em Next.js com export estático.
  • Infraestrutura em AWS S3 e CloudFront.
  • Pipeline de deploy.

Restrições

  • Preservação das URLs e do posicionamento já conquistado.
  • Conteúdo multilíngue com metadados corretos por idioma.
  • Orçamento de operação baixo: a solução precisa ser barata de manter.

Arquitetura

  • Export estático: sem servidor de aplicação, sem banco em runtime, sem superfície de ataque de CMS.
  • Hospedagem em S3 com distribuição por CloudFront.
  • CloudFront Function em viewer-request para reescrever URLs limpas nos objetos .html do export.
  • Metadados por idioma, com canonical e hreflang.

Principais decisões técnicas

Trocar o CMS por export estático em vez de manter WordPress.

Por quê

Para sites cujo conteúdo muda com pouca frequência, um CMS em runtime é custo permanente: servidor, banco, plugins e uma superfície de segurança que exige atenção contínua. Nada disso paga o próprio preço.

Trade-offs

  • Publicar conteúdo passa a exigir um build, em vez de um editor no navegador.
  • Não serve para quem publica muitas vezes ao dia ou para redação não-técnica.
  • Em troca: custo de operação próximo de zero, sem manutenção de servidor e sem vulnerabilidade de plugin.

Resolver URLs limpas na borda, com CloudFront Function.

Por quê

O export estático gera /pagina.html, mas a URL pública precisa continuar sendo /pagina, inclusive as que já estão indexadas. Resolver isso na borda mantém o export intacto e não exige servidor.

Trade-offs

  • Adiciona um componente de infraestrutura que precisa ser versionado e deployado junto.
  • Erro na função quebra o site inteiro, não uma página. Exige cuidado no deploy.

Implementação

  • Next.js com App Router e output estático.
  • Conteúdo multilíngue com dicionários por locale.
  • Deploy versionado para S3 com invalidação de CloudFront.
  • Este próprio site é um dos resultados dessa abordagem.

Operação em produção

  • Cache longo e imutável para assets com hash; HTML revalidável.
  • Invalidação de CDN no deploy.
  • Sem servidor de aplicação para operar ou corrigir.

Resultados

  • Eliminou o servidor de aplicação e o banco em runtime da operação desses sites.
  • Preservou as URLs e os metadados durante a troca de stack.
  • Reduziu a superfície de manutenção e de segurança ao remover o CMS.

Stack

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • AWS S3
  • AWS CloudFront
  • CloudFront Functions
  • WordPress (origem)