Migração Next.js / Astro em Estugarda

Estugarda é a capital de Baden-Württemberg e sede de grupos como a Mercedes-Benz Group, a Porsche, a Bosch e a Exyte, com uma indústria de alta tecnologia centrada no setor automóvel. À volta desses grupos vivem fornecedores, gabinetes de engenharia e empresas de serviços cujos sites cresceram durante anos em WordPress, Joomla, Drupal ou num framework próprio. Quando esse site fica lento, difícil de editar ou caro de manter seguro, migro o conteúdo e as funcionalidades para Astro ou Next.js sem perder as posições que o site já tem nos motores de pesquisa.

A descrição geral do serviço está na página de migração para Astro e Next.js; aqui fica o que muda quando o cliente é uma empresa de Estugarda.

#Quando compensa migrar um site de Estugarda para Astro ou Next.js?

Compensa quando o problema está na arquitetura, não na configuração. Se o site melhora com menos plugins, uma cache bem configurada e imagens comprimidas, faço isso primeiro e poupo a migração. Os sinais de que a arquitetura é o limite costumam ser estes: o painel de administração é mais lento do que o site público, cada atualização do CMS parte um módulo, os editores evitam publicar porque o resultado é imprevisível, ou o site vive de extensões que deixaram de receber correções de segurança.

Para uma empresa industrial há um sinal extra: a documentação técnica, as fichas de produto e as páginas de carreiras crescem mais depressa do que a equipa que as mantém. O Astro gera essas páginas sem base de dados exposta ao público. O Next.js entra quando há área de cliente ou de parceiro com login, configuradores de produto ou preços e stocks que mudam a cada pedido.

#Como mantenho as posições no Google durante a migração?

Numa migração, o maior risco está nos URLs. Antes de escrever uma linha do novo frontend faço um inventário completo dos endereços atuais a partir de quatro fontes: os sitemaps, os registos do servidor, o analytics e a exportação do próprio CMS. A documentação da Google para mudanças de site com alteração de URLs pede exatamente isto e inclui imagens, PDFs e outros ficheiros, que em sites industriais costumam ser fichas técnicas descarregadas por compradores.

Cada URL antigo recebe um destino decidido por mim e registado numa tabela que o cliente revê. Nunca mando dezenas de páginas antigas para a página inicial, como a Google também desaconselha. Os redirecionamentos são 301 no servidor, diretos para o destino final, sem cadeias. Ficam num ficheiro versionado no repositório e ativos pelo menos um ano, como a Google recomenda.

No novo site cada página tem um canonical que aponta para si própria, os links internos usam já os endereços novos e o sitemap só lista URLs que respondem 200. Durante a transição mantenho também o sitemap antigo submetido no Search Console, para ver as páginas antigas a sair do índice. Se o domínio muda, uso a ferramenta de mudança de endereço do Search Console; se só mudam os caminhos, não é precisa.

#O que acontece às versões em alemão e inglês?

Se o site publica em alemão e em inglês, ou noutras línguas de exportação, numa migração as anotações hreflang são das primeiras coisas a partir-se: o CMS antigo gerava-as por plugin, o novo frontend tem de as gerar a partir do modelo de conteúdo. Defino esse modelo de forma que cada página saiba quais são as suas traduções, e verifico no HTML gerado que cada par de línguas aponta um para o outro e para os URLs novos, não para os antigos que entretanto redirecionam.

O mesmo vale para os dados estruturados. Organização, produtos, artigos, vagas de emprego e perguntas frequentes passam para componentes alimentados pelo conteúdo, com um único emissor por entidade, e valido-os antes do corte.

#Que regras alemãs entram numa migração feita em Estugarda?

Quatro pontos aparecem em quase todos os projetos, e trato-os como requisitos do novo frontend.

• Proteção de dados: O § 40 do BDSG entrega a supervisão das empresas privadas às autoridades de cada estado federado. Em Baden-Württemberg é o Landesbeauftragter für den Datenschutz und die Informationsfreiheit, com sede em Estugarda. Se a migração troca o alojamento, o analytics ou o serviço de formulários, a política de privacidade e o registo de subcontratantes mudam com ela.
• Cookies e scripts: O § 25 do TDDDG exige consentimento para guardar ou ler informação no dispositivo do utilizador, salvo quando é estritamente necessário para o serviço que o utilizador pediu. Faço a lista de cada script do site antigo, do que grava e de quem o pediu, e só passa para o novo o que tem dono e finalidade.
• Informação legal obrigatória: O § 5 do DDG obriga quem presta serviços digitais comerciais a manter certas informações sobre o fornecedor facilmente reconhecíveis, diretamente acessíveis e sempre disponíveis. Na prática o Impressum tem de estar ligado em todas as páginas do novo site, incluindo as páginas de erro e as landing pages de campanha.
• Acessibilidade: A lei alemã de acessibilidade (BFSG) aplica-se a serviços de comércio eletrónico prestados a consumidores depois de 28 de junho de 2025. Uma loja ou uma área de encomendas para particulares que passe para Next.js deve sair da migração com navegação por teclado, contraste e formulários verificados, e uma migração é a altura mais barata para o fazer.

Não dou aconselhamento jurídico. Implemento o que a política de privacidade e o responsável pela proteção de dados da empresa definem, e assinalo por escrito quando o código e o texto legal não coincidem.

#Como corre o corte para o novo site?

Em sites pequenos faço o corte de uma vez. Em sites com muitas secções corto por partes: primeiro uma secção de conteúdo com tráfego estável, depois as restantes, com o servidor a encaminhar cada caminho para o sistema certo durante a transição.

Antes de cada corte comparo o site antigo e o novo página a página: título, meta description, canonical, hreflang, dados estruturados, cabeçalhos e estado HTTP. Depois do corte acompanho no Search Console os relatórios de indexação e de páginas com redirecionamento, os erros 404 e os Core Web Vitals de campo. Se uma página importante desaparece do índice, corrijo a causa antes de mexer em mais nada.

#Com que outro trabalho se costuma combinar?

Quando o objetivo é separar o CMS de edição do frontend, o trabalho cruza-se com desenvolvimento headless CMS: o WordPress ou outro CMS continua a ser onde os editores escrevem, e o Astro ou o Next.js passa a ser o que o público vê.

No fim entrego o repositório, as variáveis de ambiente documentadas, o pipeline de publicação e um guia curto para publicar alterações, de forma que a equipa interna ou outro fornecedor possa continuar sem mim.

#Como pedir uma proposta?

Envie-me o URL do site atual, o CMS e a versão que usa, as línguas publicadas e de onde vem o tráfego (pesquisa orgânica, campanhas, links de parceiros ou portais do setor). Com isso preparo um âmbito escrito: o que migra, o que fica, que URLs mudam e quais os riscos que vejo, antes de qualquer compromisso de prazo ou de orçamento.