Migração Next.js / Astro em Düsseldorf

Düsseldorf é a capital da Renânia do Norte-Vestefália e tinha 619 444 habitantes a 31 de dezembro de 2025, segundo a Wikipédia. A cidade passou da indústria pesada para serviços, telecomunicações, moda e publicidade, e a Messe Düsseldorf organiza uma parte substancial das feiras de referência mundiais. Para uma empresa que vende ou recruta neste mercado, o site é lido em alemão, por vezes em inglês, e avaliado segundo regras alemãs. Faço migrações de WordPress, Joomla, Drupal ou frameworks antigas para Astro ou Next.js com esses factos à frente do código.

#Quando faz sentido sair do CMS atual?

Faz sentido quando o CMS trava o desempenho, a segurança ou a edição, e quando limpar plugins e cache já não chega. Os sinais que verifico primeiro: tempo de resposta do servidor alto, um painel de administração mais lento do que o site, atualizações que ninguém ousa instalar e editores que evitam publicar. Antes de propor migração, meço o site atual. Se o problema se resolve com configuração, digo-o.

Escolho Astro quando o site é sobretudo conteúdo: páginas de serviços, blogue, documentação, catálogos sem carrinho. Escolho Next.js quando há áreas autenticadas, formulários complexos ou renderização dinâmica por utilizador.

#Como mapeio URLs e redirecionamentos 301?

O mapa de URLs é o documento mais importante da migração. A Google descreve o processo em passos: reunir os URLs antigos a partir de sitemaps, registos do servidor, analítica, CMS e relatório de ligações da Search Console, incluindo imagens e ficheiros de recursos, e associar cada um ao destino novo. Faço exatamente isso, numa folha de cálculo que o cliente pode rever.

Depois aplico estas regras:

• Cada URL antigo aponta diretamente para o destino final, sem cadeias de redirecionamentos.
• Páginas sem equivalente recebem 410 ou 404 deliberado, nunca um redirecionamento em massa para a página inicial.
• Canónicos, hreflang e ligações internas passam a usar os URLs novos, e o sitemap novo é submetido na Search Console.
• Os redirecionamentos ficam ativos pelo menos um ano, que é o mínimo indicado pela Google, e muitas vezes por tempo indefinido.

#O que muda se o site tiver versão em alemão e em português?

A Google exige hreflang recíproco: se a página A aponta para B, B tem de apontar para A, senão as anotações são ignoradas. Uso códigos de idioma com região quando o conteúdo difere por país (de-DE, de-AT, de-CH) e apenas o idioma (de, pt-PT) quando não difere. O código de região não existe sozinho, e “en-UK” não é válido, o correto é en-GB. Acrescento x-default para a página de escolha de idioma, se existir.

Para uma empresa portuguesa que vende em Düsseldorf, a versão alemã não é tradução do original. Tem URLs, títulos e exemplos próprios, e uma linguagem de negócio alemã. O mesmo vale para o inglês, que muitas empresas internacionais da cidade usam em contexto B2B. Na Wikipédia, Düsseldorf aparece como um dos principais centros alemães de telecomunicações, com empresas de TIC estrangeiras e a maior comunidade japonesa da Alemanha, cerca de 11 000 pessoas na cidade e arredores. Se esse público é o seu, o inglês entra no mapa de idiomas desde o início.

#Que regras alemãs afetam um site novo em Düsseldorf?

Três diplomas aparecem em quase todas as migrações para este mercado. Descrevo o que o texto da lei diz e o que implemento, sem substituir um jurista.

Cookies e rastreio. O § 25 do TDDDG permite guardar ou ler informação no equipamento do utilizador apenas com consentimento baseado em informação clara e completa, com duas exceções: a transmissão de uma mensagem e o que é estritamente necessário para um serviço pedido expressamente. Na prática, scripts de analítica, pixéis e incorporações de terceiros só carregam depois do consentimento. Num frontend estático isto é fácil de verificar: abro o HTML final e a rede do navegador antes de qualquer clique e confirmo que nada de terceiros é pedido.

Impressum. O § 5 do DDG obriga os prestadores de serviços digitais comerciais a manter disponíveis, de forma fácil de reconhecer e diretamente acessível, o nome e a morada, um contacto eletrónico rápido, o registo comercial e o número de identificação fiscal, quando existam. Garanto que a ligação está no rodapé de todas as páginas e que os URLs do Impressum e da política de privacidade sobrevivem à migração.

Acessibilidade. A BFSG aplica-se a serviços prestados a consumidores depois de 28 de junho de 2025 e inclui expressamente os serviços de comércio eletrónico. Se a sua loja vende a consumidores na Alemanha, o novo frontend deve ser construído com HTML semântico, contraste e navegação por teclado verificados. Se a sua empresa cabe em alguma exceção, é uma pergunta para o seu jurista.

A autoridade de proteção de dados do estado da Renânia do Norte-Vestefália é a LDI NRW (Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen), que se descreve como independente e livre de instruções.

#Onde ficam os dados e o alojamento?

Num site Astro estático, o HTML é servido por uma rede de distribuição e não há base de dados exposta, o que reduz a superfície de ataque. Formulários, newsletter e analítica são o que realmente guarda dados pessoais. Para clientes de Düsseldorf pergunto onde esses serviços tratam os dados e se existe contrato de subcontratação, e deixo o resultado escrito na documentação de entrega. Não prometo localização de dados que o fornecedor não declare.

#Como é feito o corte e o que verifico depois?

1. Inventário de URLs, redirecionamentos, dados estruturados e conteúdo crítico, com contagem por tipo de página.
2. Ambiente de teste com o mapa 301 aplicado e paridade de títulos, descrições, canónicos e schema, comparada por script entre o site antigo e o novo.
3. Corte por secções quando o site é grande, com reverse proxy ou regras no edge a dividir o tráfego. Um corte único só em sites pequenos.
4. No dia do lançamento: teste dos redirecionamentos por script, verificação do sitemap, inspeção de URLs na Search Console e conferência do robots.txt.
5. Nas semanas seguintes: relatório de cobertura do índice, páginas com erro 404 inesperado, evolução de impressões por secção e Core Web Vitals nos dados reais.

O que pode correr mal: parâmetros de URL antigos que o CMS gerava e que ninguém listou, páginas de arquivo ou etiquetas indexadas sem equivalente, imagens com URLs diferentes, formulários que deixam de enviar e scripts de terceiros que voltam a carregar sem consentimento. Cada um destes pontos tem uma verificação concreta na lista acima.

#Qual é o próximo passo?

Envie-me o URL atual, o CMS e a origem do tráfego (Search Console ou analítica, se tiver acesso). Respondo com um âmbito escrito: o que migrar, o que fica fora, os riscos principais e as verificações. O repositório, as variáveis de ambiente e o pipeline de publicação ficam consigo no fim. Para a visão geral do método, veja a página sobre migração para Astro e Next.js, e para o trabalho de frontend, a página do desenvolvedor Astro.