Migração Next.js / Astro em Munique

München é a capital da Baviera e a terceira cidade mais populosa da Alemanha, depois de Berlim e Hamburgo. A agência de desenvolvimento económico da cidade destaca as tecnologias de informação e telecomunicações, o setor automóvel e a mobilidade, as ciências da vida (biotecnologia e farmácia), a economia ambiental, os serviços financeiros e as indústrias criativas. Sites destes setores costumam ter anos de conteúdo, várias línguas e integrações que ninguém documentou. Migro-os de WordPress, Joomla, Drupal ou frameworks antigos para Astro ou Next.js, com cada URL e cada sinal de SEO decidido por escrito.

#Quanto tempo de vida resta ao CMS atual?

A pergunta certa antes de orçamentar uma migração é se o sistema atual ainda recebe correções de segurança e se quem edita consegue trabalhar nele. Um Drupal 7 ou um Joomla 3 já não recebem versões de segurança do projeto. Um WordPress atualizado pode estar bem; muitas vezes o problema é um tema comprado há anos, vinte plugins sobrepostos e um servidor lento mesmo com cache. Nesse caso compare o custo de arrumar o que existe com o de reconstruir o frontend. Se arrumar resolve, digo-o no âmbito e não migro.

#Que URLs e funções do site antigo preciso de mapear?

O inventário junta quatro fontes: um crawl completo, a exportação da Search Console com cliques e impressões (até 16 meses), as páginas com ligações externas e os redirecionamentos já existentes no .htaccess, na configuração do nginx ou num plugin. Um URL que falta nesta lista é um 404 no dia seguinte ao lançamento.

Ao lado vai a lista do que o CMS faz sem se ver: formulários e o destino dos dados, ligações a CRM ou ERP, pesquisa interna, área reservada, feeds, sitemaps, etiquetas de analytics e de marketing. Sites técnicos e industriais têm muitas vezes fichas em PDF com ligações de fora; esses ficheiros entram no mapa com o mesmo cuidado que as páginas.

#Astro ou Next.js para um site empresarial em München?

Astro quando o site é sobretudo conteúdo: páginas de produto e de empresa, blogue, documentação, centro de imprensa. Gera HTML estático e só envia JavaScript para os componentes interativos, o que ajuda o LCP e o INP sem truques. Next.js quando há lógica de aplicação: login de parceiros ou clientes, configuradores, conteúdo por utilizador, renderização no servidor a cada pedido. A escolha fica no âmbito com a razão escrita. A página sobre desenvolvimento com CMS headless mostra como o frontend lê o conteúdo de um CMS separado.

#O que acontece ao conteúdo, aos shortcodes e aos campos personalizados?

Do WordPress exporto artigos, páginas, taxonomias, campos ACF ou meta, autores e media. Shortcodes e blocos do Gutenberg são a parte delicada: cada tipo passa a componente ou é removido de propósito, e entrego a lista dos tipos com o número de páginas em que aparecem. Do Drupal e do Joomla o trabalho maior está nos tipos de conteúdo e nas relações entre eles.

Se a equipa publica todas as semanas, o WordPress pode ficar como CMS headless e o novo frontend lê-o pela REST API. Se as alterações são raras, o conteúdo passa para Markdown ou MDX no repositório, com validação de esquema em cada build, e um erro de campo parte o build em vez de chegar ao site.

#Como protejo os 301, o hreflang e os dados estruturados?

Cada URL antigo tem um destino: o mesmo endereço, um novo endereço com 301, ou um 410 quando a página acaba de propósito. Sem cadeias de redirecionamento, com barras finais e maiúsculas normalizadas, e com os caminhos de media como /wp-content/uploads/ tratados à parte. Antes do lançamento um script pede cada URL antigo ao ambiente de teste e compara o código de estado e o destino final com o mapa.

Muitos sites de München publicam em alemão e em inglês. Cada versão aponta no hreflang para todas as outras, recebe a ligação de volta e há um x-default; sem a ligação de volta, o Google pode ignorar as anotações. Os dados estruturados (Organization, BreadcrumbList, Article, Product, FAQPage) passam com o mesmo conteúdo e são validados nas páginas renderizadas.

#Que regras alemãs e bávaras mudam o frontend?

O RGPD aplica-se como em toda a UE. Na Baviera, o art. 18 da lei bávara de proteção de dados (BayDSG) faz do Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), com sede em Ansbach, a autoridade de controlo para entidades não públicas, ou seja, para as empresas da cidade. Três leis federais tocam no código:

• O § 25 do TDDDG só permite guardar ou ler informação no dispositivo do utilizador com consentimento informado, salvo quando é estritamente necessário para o serviço pedido. Analytics e publicidade não carregam antes do consentimento.
• O § 5 do DDG exige que o Impressum (nome e morada, contacto eletrónico, registo comercial, número de IVA quando existe) esteja sempre fácil de encontrar. Mantenho o URL ou redireciono-o, e a ligação continua em todas as páginas.
• O § 1, n.º 3 do BFSG abrange o comércio eletrónico prestado a consumidores depois de 28 de junho de 2025, o que torna a acessibilidade parte da aceitação de uma loja.

Faço a lista de todos os serviços externos que o site novo chama e de onde estão alojados, para a política de privacidade descrever o que o site faz.

#Como corre o dia da mudança?

O site novo vive primeiro num ambiente de teste com autenticação e noindex. Combino uma janela curta sem publicações no CMS antigo, baixo o TTL do DNS uns dias antes e mudo num dia útil de manhã. Em sites grandes passo secção a secção. Logo a seguir confirmo que o noindex de teste não foi para produção, que os canónicos apontam para o domínio final e que o script de redirecionamentos dá o mesmo resultado em produção.

#O que vigio na Search Console depois do lançamento?

O relatório de indexação de páginas, as estatísticas de rastreio, os cliques das páginas que já tinham tráfego e a Inspeção de URLs nas páginas principais. Os erros comuns são previsíveis: PDFs sem redirecionamento, páginas vazias que devolvem 200 e passam a soft 404, formulários que deixam de enviar e-mail, sitemaps com URLs que redirecionam. Os Core Web Vitals entram na mesma revisão, com dados de campo quando há volume. No fim, o repositório, as variáveis de ambiente, o pipeline e um documento de operação ficam com o cliente.

#Como pedir um âmbito para um site em München?

Envie-me o URL atual, o CMS e a versão, as fontes de tráfego (uma exportação da Search Console e do analytics chega), as integrações e as línguas em que publica. Devolvo um âmbito escrito com o mapa de migração, a escolha entre Astro e Next.js e os riscos que encontrei. O processo geral está na página sobre migração de WordPress para Astro e Next.js.