A mudança de plataforma de WordPress para Astro devia ser o projeto. Acabou por ser o prólogo. Exportar o conteúdo, reconstruir os templates, conseguir que um site estático compilasse e fosse implementado no Cloudflare Pages demorou semanas. Depois começou o verdadeiro ano: redirecionamentos, hreflang, paridade entre seis idiomas e um build que ultrapassou a plataforma onde estava a ser implementado. Este é um relatório sobre onde foi parar o tempo, porque o tempo não foi parar onde o planeamento dizia que iria.
A polémica, se há alguma, é com o enquadramento da mudança de plataforma como uma transposição. “Sair do WordPress para um site estático” soa a uma migração única. Para um site de conteúdo multilingue está mais perto de assumir a responsabilidade por três sistemas que o WordPress costumava esconder: a camada de encaminhamento, o build e a estrutura entre idiomas. Nenhum deles é difícil. Todos eles são contínuos.
Migração de WordPress para Astro, o custo real: TL;DR em 4 pontos
- A transposição é a parte barata. Templates e exportação de conteúdo demoraram semanas; a migração precisou de cerca de doze meses para alcançar um desempenho de pesquisa estável e sem regressões.
- A camada de redirecionamentos é a primeira surpresa. Milhares de URLs previamente indexados precisam cada um de um 301, e o volume colidiu com um limite de tamanho de ficheiro do Cloudflare Pages que descartava regras em silêncio.
- A paridade entre seis idiomas é trabalho contínuo, não uma tarefa. O hreflang, os URLs canónicos e a estrutura de secções têm de se manter alinhados em cada versão linguística, para sempre.
- O build ultrapassou o próprio runner da Cloudflare. Um teto de build de 8 GB não chega para milhares de páginas pré-renderizadas; a resposta foi construir localmente com um heap de 16 GB e implementar o artefacto acabado.
Glossário: build estático, prerender, hreflang, periferia
O relatório assenta em alguns termos de plataforma.
- Build estático - o site inteiro é renderizado para ficheiros HTML simples com antecedência, durante um passo de build, em vez de a cada pedido.
- Prerender - gerar o HTML de cada página no momento do build. Um site com seis idiomas multiplica o número de páginas pelo número de idiomas, por isso o build escala com conteúdo vezes idiomas.
- Cloudflare Pages - o alojamento. Serve os ficheiros pré-construídos a partir da periferia e também pode executar o build, dentro dos limites de memória.
- Wrangler - a ferramenta de linha de comandos da Cloudflare, usada aqui para implementar diretamente um artefacto construído localmente, contornando o passo de build da plataforma.
- Hreflang - as ligações que dizem aos motores de busca qual a página que é a versão alemã, polaca ou espanhola do mesmo artigo.
- Redirecionamento 301 - um redirecionamento permanente que transporta o sinal de classificação de um URL movido para o seu novo endereço.
Semanas: a transposição que toda a gente orça
A migração visível é a parte que é estimada, e a estimativa está mais ou menos certa. O conteúdo sai do WordPress, os templates são reconstruídos em Astro com Tailwind, um build compila, uma implementação aterra no Cloudflare Pages. Um site de conteúdo de dimensão moderada chega a um build estático funcional em semanas. Esta é a fase que demonstra bem e convence toda a gente de que o projeto está quase concluído.
Não está quase concluído. Está para lá da parte que era fácil de prever e a chegar à parte que ninguém agendou. O build funcional prova que os templates renderizam; não prova nada sobre se os URLs antigos resolvem, se os idiomas concordam entre si ou se o build ainda termina quando o conteúdo triplica.
Meses: a camada de redirecionamentos que ninguém agendou
O primeiro mês da cauda longa foi para os redirecionamentos. Cada URL que o WordPress alguma vez expôs e que o Google alguma vez indexou precisava de um 301 para o seu novo endereço Astro, ou tornava-se um 404 e o sinal de classificação evaporava-se. Num blogue de um só idioma isso é uma lista longa. Num site com seis idiomas e slugs descritivos chega aos milhares.
Esse volume bateu numa parede que tem o seu próprio relatório de campo: o Cloudflare Pages descarta em silêncio as regras de _redirects acima de um limite de tamanho de ficheiro de 100 KB, sem qualquer aviso, por isso uma parte do mapa de redirecionamentos foi implementada a verde e nunca chegou a aplicar-se. O sintoma apareceu meses mais tarde como 404s na Search Console e páginas de produto indisponíveis no Merchant Center, muito depois de a migração parecer concluída. A lição generaliza-se para além da Cloudflare: numa mudança de plataforma, o mapa de redirecionamentos não é um item de uma lista de verificação que se conclui; é um sistema que se opera, com os seus próprios modos de falha e a sua própria monitorização.
Meses: seis idiomas que têm de concordar para sempre
O WordPress, com os plugins certos, esconde a estrutura multilingue atrás de um painel de administração. Um build estático expõe-na. Seis versões linguísticas de cada artigo têm de se manter estruturalmente paralelas: os mesmos títulos de secção na mesma ordem, ligações hreflang que efetivamente resolvem para cada versão irmã, URLs canónicos que apontam para onde devem, e URLs de taxonomia que correspondem entre idiomas. Quando um idioma se desvia, o grafo de ligações entre idiomas estala na camada de indexação enquanto todas as páginas continuam a renderizar sem problemas.
Isto liga-se diretamente a um modo de falha distinto em como a tradução por IA quebra o SEO multilingue: as ferramentas de tradução que tocam em campos estruturais produzem um desvio entre idiomas que é invisível na página e caro no índice. Depois da migração, a paridade deixou de ser um marco e passou a ser uma verificação permanente, executada a cada alteração de conteúdo, porque seis idiomas não se mantêm alinhados sozinhos.
As ferramentas que reconstrói e que o WordPress dava de graça
Um custo mais discreto de sair do WordPress é que herda a responsabilidade por verificações que a plataforma e os seus plugins costumavam realizar de forma invisível. O WordPress validava ligações internas através do seu editor, mantinha um sitemap atualizado através de um plugin e avisava sobre referências quebradas no painel. Um build estático não faz nada disso por si próprio; ou o reconstrói, ou envia regressões.
Ao longo do ano isso significou uma pequena biblioteca de validadores ligada à implementação: validação de ligações internas contra a superfície real de rotas para que um slug renomeado não possa deixar ligações pendentes, verificações de dados estruturados para que o esquema no frontmatter se mantenha bem formado entre idiomas, verificações de paridade que comparam as versões irmãs em busca de secções em falta, e um gerador de sitemap e hreflang no momento do build. Cada uma delas substitui algo que o WordPress fazia em silêncio. O saldo é mais controlo e mais confiança (as verificações são explícitas, versionadas e executadas em CI), mas é engenharia a sério que a palavra migração não menciona. Quem dimensiona uma mudança de plataforma devia acrescentar esta rubrica: não está apenas a mover o conteúdo, está a reimplementar as proteções que a antiga plataforma aplicava de graça.
Meses: o build que ultrapassou o seu alojamento
A última surpresa foi mecânica. O Cloudflare Pages serve um site estático grande sem esforço, mas construir um está limitado pela memória, e o próprio runner de build da plataforma atinge o limite aos 8 GB. Um site Astro multilingue com milhares de páginas pré-renderizadas, em que cada idioma multiplica a contagem, precisa de mais heap do que isso, e o build da plataforma começou a falhar com erros de falta de memória que demoraram a ser reconhecidos pelo que eram.
A solução foi parar de construir na plataforma. O site é agora construído localmente com um heap de 16 GB e o resultado acabado é enviado para o Cloudflare Pages com o Wrangler, que implementa um artefacto sem o reconstruir. Uma máquina local da série M conclui o build de forma fiável em minutos onde o runner limitado não conseguia concluir de todo. As imagens forçaram uma disciplina relacionada: tudo o que passa pelo pipeline de assets do Astro é otimizado no momento do build, o que é excelente mas exigente em memória, por isso os fundos pré-otimizados são servidos tal e qual a partir da pasta public e só as imagens que beneficiam do processamento ficam no pipeline, mantidas com uma dimensão razoável para manter o build abaixo do seu teto.
O que a migração comprou de facto
Dito sem rodeios para que o ano não se leia como arrependimento: a mudança valeu a pena. As páginas renderizam a partir da periferia como ficheiros estáticos, o que é mais rápido e mais estável do que renderizar a pedido, a superfície de ataque encolheu para aproximadamente nada de dinâmico, e o acesso dos crawlers tornou-se previsível em vez de depender do comportamento dos plugins. Para um site de conteúdo onde a velocidade, a estabilidade e ser lido de forma fiável por crawlers de pesquisa e de IA são o ponto, essa é a troca certa.
A ressalva honesta é a mesma que devia preceder qualquer mudança de plataforma: é a troca certa para um site de conteúdo e a errada para um site que vive de funcionalidade dinâmica e com sessão iniciada, onde a renderização a pedido e o ecossistema do WordPress são a funcionalidade, não o peso. A decisão não é “estático é melhor”. É “estático é melhor para esta forma de site, e aqui está o ano de trabalho de cauda que a palavra migração esconde”. Mais relatos de engenharia desta reconstrução estão no blogue da wppoland.
