Migração Next.js / Astro em Frankfurt

Frankfurt am Main é a cidade mais populosa do estado federado de Hesse e um dos principais centros financeiros e empresariais da Europa: lá têm sede o Banco Central Europeu e o Deutsche Bundesbank, e o aeroporto da cidade é o de maior movimento na Alemanha. A língua oficial da administração alemã é o alemão, e um site que fala também para fora do país precisa de versões linguísticas bem ligadas entre si. Migro sites de WordPress, Joomla, Drupal ou frameworks antigos para Astro ou Next.js, com cada URL e cada sinal de SEO tratado por escrito.

#Quando compensa sair do WordPress ou do Drupal em Frankfurt?

Compensa quando o CMS atual trava o desempenho, a segurança ou o trabalho de quem edita, e quando arrumar plugins e cache já não resolve. Os sinais que procuro: tempo de resposta do servidor alto mesmo com cache, um painel de administração mais lento do que o site, atualizações de plugins adiadas por medo de partir alguma coisa, e um Drupal 7 ou um Joomla 3 que já não recebem versões de segurança do projeto.

#O que entra no inventário antes de mudar uma linha de código?

Um URL que não está na lista é um URL que dá 404 depois do lançamento. Junto quatro fontes: um crawl completo do site atual, a exportação da Search Console com cliques e impressões (até 16 meses de histórico), as páginas com ligações externas e os redirecionamentos que já existem no .htaccess, na configuração do servidor ou num plugin.

Listo também o que o CMS faz e não se vê: formulários e para onde enviam os dados, integrações com CRM, pesquisa interna, áreas reservadas, feeds RSS, sitemaps, scripts de analytics e de marketing. Os PDFs com ligações externas entram no mapa como qualquer outra página.

#Astro ou Next.js: qual escolher?

Astro para sites de conteúdo: páginas institucionais, blogues, documentação, relatórios e catálogos com pouca interação. Gera HTML estático por omissão e só envia JavaScript para os componentes que precisam dele. Next.js quando o site tem lógica de aplicação: autenticação, área de cliente, conteúdo por utilizador, renderização no servidor a cada pedido. Decido isto no âmbito, com a razão ao lado, antes de começar a construir. A página sobre desenvolvimento em Astro explica o lado técnico com mais detalhe.

#Como passa o conteúdo do CMS antigo para o novo site?

Do WordPress exporto artigos, páginas, taxonomias, campos personalizados (ACF ou meta), autores e media. Shortcodes e blocos do Gutenberg são o ponto delicado: cada tipo é convertido num componente equivalente ou removido de forma consciente, e entrego a lista dos tipos encontrados com o número de páginas em que aparecem. Do Joomla e do Drupal o caminho é parecido, com mais trabalho nos campos e nas relações entre tipos de conteúdo.

O destino depende de quem edita. Se a equipa de marketing publica todos os dias, 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.

#O que acontece aos 301, aos dados estruturados e ao hreflang?

Cada URL antigo recebe um destino: o mesmo endereço, um novo com 301, ou um 410 quando a página deixa de existir de propósito. Evito cadeias de redirecionamento, normalizo barras finais e maiúsculas e trato à parte os parâmetros e os caminhos de media como /wp-content/uploads/. Antes do lançamento corro um script que pede cada URL antigo ao ambiente de teste e confirma o código de estado e o destino final.

Os dados estruturados (Organization, BreadcrumbList, Article, FAQPage) passam com o mesmo conteúdo e valido-os nas páginas renderizadas, não no código-fonte. Num site com versão alemã e versão noutra língua, cada página aponta no hreflang para todas as variantes, recebe a ligação de volta e tem um x-default. Sem a ligação de volta, o Google pode ignorar as anotações.

#Que leis alemãs pesam num site de uma empresa de Frankfurt?

O RGPD aplica-se como em toda a UE, mas há regras nacionais que mexem diretamente no frontend:

• O § 25 da lei alemã TDDDG só permite guardar ou ler informação no dispositivo do utilizador com consentimento informado, salvo quando isso é estritamente necessário para o serviço que o utilizador pediu. Scripts de analytics e de publicidade não carregam antes do consentimento, e confirmo isso no separador de rede do navegador.
• O § 5 da lei alemã DDG obriga quem oferece serviços digitais comerciais a manter informação de identificação sempre acessível: nome e morada, contacto eletrónico, registo comercial, número de IVA quando existe. A página do Impressum passa para o site novo com o mesmo URL ou com redirecionamento, e continua ligada a partir de todas as páginas.
• O § 1, n.º 3 da lei alemã de reforço da acessibilidade (BFSG) inclui os serviços de comércio eletrónico prestados a consumidores depois de 28 de junho de 2025. Quem vende a consumidores tem aqui um motivo para corrigir títulos, contraste, formulários e navegação por teclado durante a migração, e não depois.

A autoridade de controlo para empresas em Hesse é o HBDI, com morada postal em Wiesbaden, que fiscaliza também entidades privadas desde 1 de julho de 2011. Na migração faço a lista de todos os serviços externos que o site novo chama e de onde estão alojados, para que a política de privacidade descreva o que o site faz.

#Como decorre a passagem para produção?

O site novo vive primeiro num ambiente de teste protegido por autenticação e com noindex. Combino uma janela curta sem publicações no CMS antigo, baixo o TTL do DNS uns dias antes e faço a mudança num dia útil de manhã. Em sites grandes passo secção a secção; mudar tudo de uma vez só em sites pequenos. Logo a seguir confirmo que o noindex de teste não passou 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 pode correr mal e como o verifico?

Os problemas típicos são previsíveis: PDFs antigos sem redirecionamento, páginas vazias que devolvem 200 e o Google trata como soft 404, formulários que deixam de enviar e-mails, hreflang partido, sitemaps com URLs que redirecionam. Nas semanas seguintes acompanho na Search Console o relatório de indexação, as estatísticas de rastreio e os cliques das páginas que já tinham tráfego, e uso a Inspeção de URLs nas páginas principais. Os Core Web Vitals entram na mesma revisão, com dados de campo quando há volume suficiente. No fim, o repositório, as variáveis de ambiente, o pipeline de publicação e um documento de operação ficam com o cliente.

#Como começar a migração de um site em Frankfurt?

Envie-me o URL do site atual, o CMS e a versão, as fontes de tráfego (uma exportação da Search Console e do analytics serve), as integrações que o site tem e as línguas em que publica. Com isso preparo 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.