Migração Next.js / Astro em Basel

Basel é a capital do cantão de Basel-Stadt, tem 177 595 habitantes (31 de dezembro de 2024) e fica junto ao ponto onde se encontram as fronteiras da Suíça, de França e da Alemanha. A língua oficial é o alemão. O cantão descreve a região como sede de mais de 800 empresas do Basel Area Life Sciences Supercluster, com a Novartis, a Roche, a Lonza, a Bayer e a Syngenta entre elas, e como base de grupos logísticos como a DSV, a DHL e a Rhenus, além do Banco de Pagamentos Internacionais. Migro sites de empresas destes setores, e de qualquer outro, de WordPress, Joomla, Drupal ou frameworks antigos para Astro ou Next.js, sem perder tráfego orgânico pelo caminho.

#O que é preciso levantar antes de mudar uma linha de código?

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

Ao mesmo tempo listo tudo o que o CMS faz e que não se vê: formulários e para onde enviam os dados, integrações com CRM ou ERP, pesquisa interna, áreas reservadas, feeds RSS, sitemaps e scripts de analytics. Documentos PDF com ligações externas também entram no mapa.

#Astro ou Next.js: qual faz sentido para um site em Basel?

Astro para sites de conteúdo: páginas institucionais, blogues, documentação, 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, áreas de cliente, conteúdo personalizado por utilizador, renderização no servidor a cada pedido. Decido isto por escrito no âmbito, com a razão ao lado, antes de começar a construir.

#Como se migra o conteúdo e o modelo de dados?

Do WordPress exporto artigos, páginas, taxonomias, campos personalizados (ACF ou meta), autores e ficheiros de media. Shortcodes e blocos do Gutenberg são o ponto delicado: cada tipo tem de ser convertido para um componente equivalente ou removido de forma consciente, e listo os que encontro com a contagem 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 publica todos os dias, o WordPress pode ficar como CMS headless e o novo frontend lê-o pela REST API ou por GraphQL. 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. A arquitetura headless está descrita em mais detalhe na página sobre desenvolvimento com CMS headless.

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

Cada URL antigo recebe um destino: o mesmo endereço, um novo endereço com 301 ou, raramente, 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 de pesquisa 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, Product, FAQ) passam com o mesmo conteúdo e são validados nas páginas renderizadas, não no código-fonte. Num site com versões em alemão para a Suíça e para a Alemanha, o hreflang tem de distinguir de-CH de de-DE, cada página tem de apontar para todas as variantes e receber a ligação de volta, e o x-default tem de existir. Sem ligação de volta, o Google pode ignorar as anotações hreflang.

#Que regras de proteção de dados contam para um site em Basel?

A lei federal suíça de proteção de dados (FADP, RS 235.1) está em vigor desde 1 de setembro de 2023. Aplica-se a situações com efeito na Suíça, mesmo que iniciadas no estrangeiro (art. 3), e é supervisionada pelo Comissário Federal de Proteção de Dados e Informação (FDPIC, ou EDÖB em alemão). Numa migração, quatro artigos tocam diretamente no frontend:

• O art. 7 exige proteção de dados desde a conceção e por defeito, o que inclui formulários que só pedem os campos necessários e scripts de terceiros que não carregam antes de haver motivo.
• O art. 19 obriga a informar o titular dos dados no momento da recolha, com a identidade do responsável e a finalidade, e o n.º 4 acrescenta o país de destino quando os dados saem da Suíça.
• O art. 16 só permite a transferência para o estrangeiro com nível de proteção adequado, decidido pelo Conselho Federal ou garantido por cláusulas contratuais, o que pesa na escolha do alojamento, da CDN e do serviço de envio de formulários.
• O art. 24 obriga a notificar o FDPIC o mais depressa possível uma violação de segurança que possa trazer um risco elevado para os titulares.

O portal das PME da Confederação acrescenta o registo das atividades de tratamento, com exceções para PME cujo tratamento tenha risco limitado. Na migração faço a lista de todos os serviços externos que o novo site chama e onde estão alojados, para que a política de privacidade corresponda ao que o site faz.

#Como decorre a passagem para produção?

O novo site vive primeiro num ambiente de teste com autenticação e noindex, para que o Google não o encontre antes do tempo. Combino com o cliente 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ã. Logo a seguir confirmo três coisas: o noindex de teste não passou para produção, os canónicos apontam para o domínio final e não para o de teste, e 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 de páginas, as estatísticas de rastreio e a evolução dos cliques nas páginas que tinham tráfego antes, 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 houver volume suficiente.

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

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.