Migração Next.js / Astro em Bern

Uma migração para Astro ou Next.js troca o motor do site sem trocar o endereço que o Google, os clientes e os parceiros já conhecem. Faço este trabalho para empresas em Berna que têm hoje um site em WordPress, Joomla, Drupal ou numa framework antiga e querem um frontend mais leve, mais fácil de manter e com menos superfície de ataque.

#Quando é que uma empresa em Berna deve migrar e quando não deve?

Migrar compensa quando o problema está na arquitetura: páginas geradas pela base de dados a cada pedido, um tema que só uma pessoa sabe alterar, dezenas de plugins com atualizações em atraso, ou um admin tão lento que os editores adiam publicações. Não compensa quando o site é lento por causa de imagens pesadas, de um alojamento fraco ou de um plugin mal configurado.

Antes de propor uma migração, meço o site como está: tempo de resposta do servidor, Core Web Vitals reais, URLs indexados e páginas que trazem tráfego. Se os números não justificarem a mudança, digo-o por escrito.

#Astro ou Next.js para um site de Berna?

Astro serve sites onde o conteúdo é o produto: sites institucionais, blogues, catálogos de serviços, documentação. Gera HTML estático e, por omissão, não envia JavaScript para o browser.

Next.js serve projetos com área de cliente autenticada, dados que mudam a cada pedido ou integrações que precisam de renderização no servidor. Paga-se com mais JavaScript e um alojamento que executa código.

O conteúdo pode ficar num CMS headless (o próprio WordPress via REST API) ou passar para Markdown num repositório, conforme quem edita e em que línguas.

#Como é que a migração preserva as posições no Google?

1. Inventário. Rastreio o site atual e cruzo o resultado com o sitemap e com as páginas que recebem cliques na Search Console.
2. Mapa de URLs. Cada endereço antigo recebe um destino: o mesmo caminho, um caminho novo com redirecionamento 301, ou remoção deliberada. Sem cadeias de redirecionamentos.
3. Modelo de conteúdo. Tipos de página, campos, taxonomias e relações entre traduções passam do CMS antigo para coleções tipadas. Shortcodes e campos de plugins são verificados página a página, porque é aí que o texto desaparece.
4. Dados estruturados e metadados. Organization, BreadcrumbList, Article ou Product, conforme o site, são gerados a partir do conteúdo e validados.
5. Ambiente de teste. O site novo corre num endereço bloqueado à indexação. Rastreio-o e comparo com o inventário.
6. Corte faseado. Em sites grandes, migro secção a secção atrás do mesmo domínio.
7. Depois do lançamento. Submeto o novo sitemap, inspeciono os URLs principais na Search Console e acompanho os relatórios de indexação e de páginas com redirecionamento nas semanas seguintes.

#O que costuma correr mal numa migração e como o verifico?

• Um noindex copiado do ambiente de teste para produção. Verifico os cabeçalhos e o HTML renderizado de uma amostra de páginas no dia do corte.
• Redirecionamentos que só funcionam com barra final, ou só sem ela. Testo as duas formas.
• Formulários que deixam de enviar porque o endpoint antigo vivia no PHP do CMS. Cada formulário tem um envio de teste na lista de aceitação.

#Que regras de dados se aplicam a um site com público suíço?

A Suíça tem lei própria: a Lei federal sobre a proteção de dados (FADP, em alemão DSG), em vigor na versão revista desde 1 de setembro de 2023. É supervisionada pelo Comissário Federal para a Proteção de Dados e a Informação (FDPIC, em alemão EDÖB).

• Âmbito territorial. O artigo 3 aplica a lei a situações com efeito na Suíça, mesmo que tenham origem no estrangeiro. Um site para clientes de Berna fica abrangido, esteja alojado onde estiver.
• Dever de informar. O artigo 19 obriga o responsável a informar quem tem os dados recolhidos: identidade e contactos do responsável, finalidade e destinatários. Quando os dados vão para o estrangeiro, a informação tem de indicar o Estado de destino e, se for o caso, as garantias usadas. Ao trocar de alojamento, CDN ou ferramenta de formulários, a política de privacidade é revista ao mesmo tempo.
• Transferências para o estrangeiro. O artigo 16 permite a transferência para países que o Conselho Federal reconheceu como tendo proteção adequada; sem essa decisão, são precisas garantias como cláusulas contratuais. Por isso, no âmbito do projeto, listo onde cada serviço guarda os dados.

O artigo 24 obriga a comunicar ao FDPIC, o mais depressa possível, violações de segurança com risco elevado para as pessoas.

A avaliação jurídica cabe a um jurista suíço; eu entrego a lista exata dos serviços, cookies e transferências do site novo.

#Porque é que a língua pesa tanto num site de Berna?

Berna é a cidade federal da Suíça e a capital do cantão de Berna, que é oficialmente bilingue, alemão e francês. Na cidade, a língua dominante é o alemão. Muitos sites daqui têm versões em alemão e francês.

Numa migração isto traduz-se em trabalho concreto: um mapa de URLs por língua, hreflang recíproco entre todas as versões, um x-default decidido conscientemente e uma estrutura de pastas por idioma que não mude a meio. Se o CMS antigo usava um plugin de tradução com parâmetros no URL (?lang=fr), esses endereços também entram no mapa de redirecionamentos. Mais detalhe na página sobre migração para Astro e Next.js e o serviço de desenvolvimento com CMS headless.

#O que fica consigo no fim?

O repositório com o código, a configuração do alojamento e das variáveis de ambiente, o mapa de redirecionamentos em formato legível, e um documento curto que explica como publicar, como adicionar uma página numa nova língua e como reverter uma publicação. Trabalho sozinho, por isso tudo fica escrito.

#A lei suíça de proteção de dados aplica-se a um site alojado fora da Suíça?

Sim, quando o tratamento tem efeito na Suíça. O artigo 3 da FADP diz que a lei se aplica a situações com efeito na Suíça, mesmo que tenham origem no estrangeiro. Um CDN global não retira o site ao âmbito da lei.

#Como preserva o SEO e os redirecionamentos durante a migração?

Exporto todos os URLs antigos antes de começar e associo cada um a um destino no novo site, com redirecionamentos 301 diretos quando o endereço muda. Metadados, hreflang e dados estruturados são comparados antes do corte.

#Astro ou Next.js?

Astro para sites de conteúdo, porque por omissão não envia JavaScript para o browser. Next.js quando há área autenticada, dados que mudam a cada pedido ou muita interação. A escolha fica justificada por escrito no âmbito.

#Um site em alemão e francês complica a migração?

Complica o mapa de URLs e o hreflang, não a tecnologia. Cada versão linguística precisa do seu próprio mapa de redirecionamentos e de referências hreflang recíprocas, e verifico ambas em separado.

#Como começar?

Envie-me o endereço do site atual, o CMS e a versão que usa, as línguas publicadas e as principais fontes de tráfego (orgânico, campanhas, referências). Respondo com um âmbito escrito: o que migra, o que fica de fora, a escolha entre Astro e Next.js e os riscos que identifiquei.