Migração Next.js / Astro em Geneva

#Em que língua deve estar o site de uma empresa em Genebra?

A língua oficial de Genebra, tanto da cidade como do cantão, é o francês. A cidade fica no extremo sudoeste do lago Léman, a 1,9 km da fronteira com França, e quase toda a fronteira do cantão (103 km de 107,5 km) é com França. Quem pesquisa em Genebra escreve, por isso, sobretudo em francês, e muitos clientes e candidatos vivem do outro lado da fronteira.

Na prática, isto decide a arquitetura antes do código. Um site só em inglês, ou com o francês traduzido à pressa, perde a procura local. Na migração trato cada língua como uma árvore de URLs própria, com hreflang recíproco entre as versões, canónico por língua e um seletor que não redireciona automaticamente pela língua do browser (um redirecionamento automático impede o Googlebot de ver todas as versões). O francês de Genebra não é uma tradução do português: escreve-se para esse mercado, com a terminologia das instituições suíças.

#Que tipo de empresas em Genebra pede esta migração?

Segundo a Wikipédia, Genebra acolhe o maior número de organizações internacionais do mundo, incluindo sedes de várias agências das Nações Unidas e do Comité Internacional da Cruz Vermelha. A cidade tinha 203 856 habitantes em janeiro de 2021. Em torno dessas organizações há consultoras, associações, fundações, escritórios de advogados e fornecedores, normalmente com sites institucionais cheios de conteúdo: relatórios, páginas de programas, notícias, formulários de candidatura.

É o caso em que o Astro compensa mais. Páginas de conteúdo ficam como HTML estático, sem JavaScript por omissão, e a edição pode manter-se num CMS headless ou continuar no WordPress como backend. O Next.js entra quando há área autenticada, portal de membros ou dados que mudam a cada pedido. Não vendo uma escolha por moda: escrevo a recomendação com a justificação, para poder ser revista mais tarde.

#O que inclui, tecnicamente, uma migração para Astro ou Next.js?

Parto do site atual (WordPress, Joomla, Drupal ou uma framework antiga) e trabalho nesta ordem.

1. Inventário de URLs. Exporto o sitemap, o que a Search Console mostra como indexado e o que o rastreio encontra. Junto os URLs com ligações externas e os que ainda trazem tráfego. O inventário é a lista de tudo o que não pode desaparecer sem decisão.
2. Mapa de redirecionamentos 301. Cada URL antigo tem um destino escrito, um a um. Quando o endereço não muda, não há redirecionamento. Cadeias (A para B para C) e destinos 404 são erros do mapa, não do servidor; testo-os com um script contra a lista completa antes do lançamento.
3. Modelo de conteúdo. Tipos de conteúdo, campos, taxonomias e relações passam para coleções tipadas. Campos personalizados que ninguém usa há anos ficam de fora; os que alimentam dados estruturados ficam.
4. Dados estruturados e metadados. Títulos, descrições, Open Graph, Organization, BreadcrumbList e FAQPage onde a página tem mesmo perguntas e respostas visíveis. Comparo o JSON-LD antigo e o novo, página a página.
5. hreflang e canónicos. Pares recíprocos entre as versões linguísticas, incluindo x-default. Uma ligação que aponta só num sentido é ignorada.
6. Formulários e integrações. Contacto, newsletter, candidaturas, CRM. É onde mais coisas se partem em silêncio, por isso cada formulário é testado com um envio real.
7. Ambiente de teste. O site novo corre num endereço protegido, fora do índice, com o mapa 301 aplicado.
8. Lançamento faseado. Em sites grandes migro por secções, para que uma falha afete uma parte e não tudo. Em sites pequenos, um corte único num dia de pouco tráfego.
9. Verificação após o lançamento. Submeto o novo sitemap, acompanho a cobertura e os erros de rastreio na Search Console e comparo cliques e impressões por secção com o período anterior. Mantenho o servidor antigo acessível até o mapa estar validado.

#O que pode correr mal e como verifico

Os problemas típicos são previsíveis. URLs com parâmetros ou barras finais que o mapa não cobriu. Páginas antigas indexadas que o inventário não listava. Metadados vazios em tipos de conteúdo raros. noindex do ambiente de teste que vai para produção. Canónicos que apontam para o domínio de teste. Ficheiro robots.txt herdado.

Verifico cada um com um rastreio do site novo antes do lançamento, comparado com o inventário do antigo, e outro logo depois. Se o número de páginas indexáveis ou os títulos divergirem, paro e corrijo antes de ligar o domínio. Quedas de tráfego depois de uma migração costumam ter origem num destes itens, não no framework.

#Que regras de proteção de dados se aplicam a um site em Genebra?

Genebra está na Suíça, fora da União Europeia, pelo que o enquadramento de referência para uma empresa local é a lei federal suíça de proteção de dados, supervisionada pelo Comissário Federal para a Proteção de Dados e a Transparência (FDPIC), descrito pelo próprio organismo como autoridade independente. Segundo a Wikipédia, o Comissário supervisiona autoridades federais e entidades privadas. Um site que recolhe dados através de formulários, newsletter, estatísticas ou cookies cai neste regime.

Se o site também se dirige a pessoas na União Europeia (por exemplo, residentes em França, a poucos quilómetros), o RGPD pode aplicar-se em paralelo. A avaliação jurídica de cada caso é do seu jurista. O que faço do lado técnico: mapear que scripts e fornecedores recebem dados dos visitantes, carregar estatísticas e incorporações de terceiros só depois do consentimento quando isso for exigido, e documentar onde o site e os formulários estão alojados. Numa migração, isto é uma oportunidade: um site estático em Astro tem muito menos scripts de terceiros por omissão do que um WordPress carregado de plugins.

#Perco posições no Google ao mudar de WordPress para Astro?

Não tem de perder. O risco está nos URLs, nos metadados e nos canónicos, e todos se verificam antes do lançamento. Depois dele acompanho a Search Console por secção. Uma queda persistente numa secção indica um erro concreto no mapa, que localizo e corrijo.

#Preciso de um site em francês e em inglês?

Em Genebra, o francês é a língua oficial e a da maior parte da pesquisa local. O inglês faz sentido se vende a organizações internacionais ou a clientes que não leem francês. Cada língua tem os seus URLs, hreflang e conteúdo escrito para o público respetivo.

#A minha equipa continua a editar o conteúdo?

Sim. Posso manter o WordPress como backend de edição e usar o Astro só no frontend, ou passar para ficheiros e um CMS headless. A escolha depende de quem edita, com que frequência e que fluxo de aprovação existe.

#Quanto tempo demora?

Depende do número de URLs, de línguas e de integrações, e dou o prazo por escrito depois de ver o site atual.

#Como começo?

Envie-me o endereço do site atual, o CMS e a versão, as línguas em uso e as principais fontes de tráfego (a Search Console serve). Respondo com um âmbito escrito: o que migrar, o que remover, riscos e ordem de trabalho. Se bastar corrigir cache e plugins, digo-lho em vez de propor uma migração. Veja também a página geral de migração para Astro e Next.js e o trabalho com Astro.