cloud / sistemas
Meu antigo site WordPress cumpriu seu papel. Ao longo dos anos, acumulou artigos, imagens e pedaços da minha história profissional. Mas manter um CMS com banco de dados para um site pessoal começou a parecer deixar um motor ligado só para acender uma luminária.
Queria algo mais rápido, mais simples de operar e mais pessoal. Também queria descobrir até onde uma parceria com IA ajudaria na migração — não com um botão mágico de “converter site”, mas enfrentando comigo as decisões reais de engenharia.
O resultado é o site que você está lendo: um portfólio feito sob medida, com arquitetura de cloud e arquivos estáticos entregues por Amazon S3 e CloudFront. Os textos antigos continuam disponíveis; o novo site acrescenta fotos, certificações, treinos, jogos e uma visão mais completa do meu trabalho.
O acerto não foi trocar WordPress por IA. Foi separar o conteúdo que merecia ficar da estrutura que já não se justificava.
Primeiro, esclarecer o que “feito com IA” significa
O site em produção não precisa de um modelo de linguagem para entregar páginas. Isso acrescentaria latência, complexidade e uma dependência sem benefício para a visita comum. O site é estático, e isso é uma vantagem.
A IA participou da engenharia: ajudou a examinar material antigo, propor a organização, escrever e revisar textos, gerar e refatorar código, encontrar inconsistências, ajustar o comportamento responsivo e transformar tarefas manuais em scripts. Eu continuei como responsável pelo produto: escolhi o material, corrigi suposições, avaliei o visual e aprovei mudanças em produção.
Por isso, “com apoio de IA” é a descrição precisa. A inteligência foi usada na construção e manutenção; o sistema entregue continua simples.
1. Inventariar antes de redesenhar
Uma migração começa com evidências, não com uma paleta de cores. Antes de mudar o visual, reuni posts, páginas, categorias e referências de mídia do WordPress. O conteúdo foi exportado para JSON estruturado, e os arquivos associados foram copiados para um acervo local.
Isso criou duas redes de proteção importantes:
- um acervo legível por máquina, que permite transformar o conteúdo sem consultar o site público repetidamente;
- uma biblioteca preservada com imagens, documentos e certificados originais.
Também revisei URLs, títulos, datas, links internos e conteúdo que nunca deveria sair por acidente. Backup completo não é site público: exports podem conter rascunhos, arquivos obsoletos, dados pessoais e credenciais. Preservar e publicar são decisões diferentes.
2. Separar conteúdo e WordPress
O bem mais valioso do WordPress não era o tema, os plugins nem o esquema do banco: era o conteúdo. Com posts em JSON e mídias numa árvore normal de arquivos, a apresentação ficou substituível.
Na página inicial, o JavaScript lê os dados selecionados e monta os cards de artigos. Cada artigo também tem uma página HTML estática. Isso combina a flexibilidade de dados estruturados com URLs normais e indexáveis, úteis tanto para buscadores quanto para quem chega por link direto.
“Preservar primeiro, selecionar depois” evitou um erro comum: jogar história fora porque o design novo não prevê onde colocá-la. O acervo sobreviveu; as escolhas editoriais vieram depois.
3. Criar o site em torno da pessoa, não do CMS
O WordPress naturalmente incentiva um site organizado como sequência de posts. Meu portfólio precisava de outro centro: apresentação, projetos, carreira, certificações, fotos, evolução de treino, artigos e um pouco de diversão.
Construímos isso diretamente em HTML semântico, CSS e JavaScript. Não há um tema genérico tentando atender milhares de sites. Navegação, tipografia, menu móvel, enquadramento de imagens e interações existem para este portfólio.
O redesign foi iterativo. Eu olhava uma prévia local, dizia que o terminal cobria meu braço, que o retrato parecia cortado ou que uma quebra de título estava estranha, e a implementação era ajustada. Esse ciclo curto foi onde a IA mais ajudou: a avaliação visual continuou humana, mas transformá-la em CSS ficou mais rápido.
4. Tratar URLs antigas e busca como dados de produção
O redesign não dá certo se a página inicial fica linda e anos de conteúdo pesquisável somem. Cada artigo escolhido recebeu URL própria, título descritivo, meta description e endereço canônico. Também há metadados Open Graph e Twitter para compartilhar e dados Schema.org que identificam o artigo técnico e seu autor.
O sitemap inclui páginas principais e artigos antigos. O site usa “Bernd Kuhlen” de forma consistente e registra “Bernhard Kuhlen” como nome alternativo. Robôs recebem instruções explícitas, mas pessoas e buscadores também seguem links normais sem executar a página inicial interativa.
Se um permalink antigo tem links externos ou histórico de busca, deve continuar válido ou redirecionar permanentemente ao substituto. O mapa de URLs faz parte do plano de migração, não da arrumação depois do lançamento.
5. Tornar a infraestrutura previsível — no bom sentido
Os arquivos finais ficam num bucket S3 privado, criptografado e versionado. O CloudFront é a entrada pública e acessa o S3 por Origin Access Control; o armazenamento não fica exposto como site público. HTTPS é obrigatório, TLS moderno é exigido e uma política fornece os principais cabeçalhos de segurança.
A infraestrutura é descrita em CloudFormation, não montada apenas por cliques no console. Na etapa descrita aqui, o script atualizava a stack, sincronizava uma lista explícita de arquivos públicos e invalidava o cache do CloudFront. Isso tornava a entrega reproduzível e revisável.
Hospedagem estática remove banco WordPress, execução de PHP e atualizações de temas e plugins do caminho da requisição. A responsabilidade operacional não some; vira um problema menor e mais observável.
6. Conferir antes de trocar a produção
Durante o trabalho, o site rodava localmente em um contêiner com Nginx. Isso permitia testar layouts de computador e celular, abrir documentos, jogar e conferir gráficos de treino antes de publicar.
Uma troca segura inclui:
- congelamento de conteúdo ou export final bem definido;
- backup completo do banco e das mídias;
- validação local e em homologação das URLs importantes;
- DNS e certificados prontos antes da troca;
- caminho de retorno à origem anterior;
- verificações após a entrega, fora da máquina de desenvolvimento.
Versionamento S3 e infraestrutura como código ajudam na recuperação, mas não substituem um procedimento de rollback pensado de antemão.
7. Adicionar observabilidade depois de remover o servidor de aplicação
Um site estático ainda pode falhar, atrair robôs ou receber tráfego inesperado. Logs do CloudFront registram requisições, status, user agents e locais de borda. Alimentam um dashboard no CloudWatch com volume e famílias HTTP, com prazo de retenção definido em vez de acúmulo ilimitado.
A visão geográfica ajuda a entender a origem aparente do tráfego, mas um local de borda, país ou cidade inferido por IP nunca deve ser confundido com uma pessoa verificada. Dados operacionais respondem sobre requisições; raramente provam identidade.
A observabilidade também cria uma referência útil. Em vez de esperar alguém avisar de um link quebrado, posso ver tendências de erro e quais caminhos estão sendo pedidos.
8. Aproveitar a migração para criar o que o WordPress não incentivava
Sem a estrutura de um tema tradicional de blog, ficou mais fácil incluir meus interesses reais. Exports do Apple Health viraram visões agregadas diárias, semanais e mensais. Certificados ganharam acervo próprio. Fotos receberam legendas. Snake e Galaga encontraram lugar em Diversão.
Tudo continua sendo entregue como arquivos estáticos e código no cliente. A mudança não foi adicionar uma plataforma mais pesada, mas criar espaço para funções pequenas e focadas conviverem.
Onde a IA ajudou — e onde precisou de supervisão
A IA foi especialmente útil em inspeções repetitivas, propostas de transformação, primeiras implementações, revisão de idioma e aplicação de feedback detalhado em vários arquivos. Ajudou a acompanhar a relação entre registros, páginas, sitemap e pacote de publicação.
Ainda assim, foi preciso verificar. Um link plausível pode estar errado. Um layout tecnicamente válido pode ficar ruim num celular real. Texto gerado pode soar genérico ou prometer mais do que o sistema faz. Comandos de infraestrutura podem ter efeitos muito maiores que um erro de digitação.
O fluxo mais produtivo foi uma conversa com disciplina: observar o sistema real, limitar a mudança, visualizar, testar e só então publicar. A IA acelerou o ciclo; não o eliminou.
Checklist de migração reproduzível
- Fazer backup do banco, uploads e configuração do WordPress.
- Exportar posts, páginas, taxonomias, datas, autores e referências de mídia.
- Classificar o conteúdo como público, privado, obsoleto ou incerto.
- Criar inventário de URLs e mapa de redirecionamentos.
- Escolher a arquitetura mais simples que atenda às necessidades reais.
- Criar um pequeno sistema visual e templates reutilizáveis.
- Gerar páginas semânticas próprias para o conteúdo que deve continuar pesquisável.
- Adicionar metadados, URLs canônicas, dados estruturados, regras para robôs e sitemap.
- Testar acessibilidade, responsividade, links, documentos e páginas de erro.
- Descrever infraestrutura e deploy em código.
- Fazer a troca com backups, monitoramento e rollback testado.
- Manter o acervo até o site novo se provar.
A escolha tem contrapartidas
Site estático não é a substituição certa para todo WordPress. Uma redação com muitos editores não técnicos, fluxos complexos, comentários ou dados de servidor que mudam sempre pode continuar se beneficiando de um CMS maduro, inclusive headless com frontend estático.
Para um portfólio mantido por código, o equilíbrio é outro. Troquei a edição no navegador por menos superfície de ataque, entrega previsível, alterações versionadas e controle da experiência. A IA reduziu o atrito desse fluxo o suficiente para tornar a troca atraente.
O aprendizado que ficou
O WordPress antigo não foi jogado fora. Foi desmontado com cuidado: conteúdo preservado, partes úteis valorizadas, apresentação reconstruída e infraestrutura simplificada.
Essa é a lição que repetiria. Em vez de perguntar qual produto de IA deve substituir o WordPress, comece pelo que precisa sobreviver, pelo que o site realmente deve fazer e pela complexidade que pode sair. Depois, use a IA como parceira de engenharia — curiosa, rápida e útil, mas sempre apoiada em arquivos reais, testes reais e julgamento humano.