Migração Next.js / Astro em Viena

Uma empresa em Viena que quer sair de WordPress, Joomla, Drupal ou de um framework antigo para Astro ou Next.js arrisca sobretudo uma coisa: perder posições no Google por causa de URLs partidos, metadados esquecidos ou versões linguísticas que deixam de se ligar entre si. Faço estas migrações sozinho, do inventário ao corte, e esta página descreve o que verifico em cada fase e o que muda quando o site serve o mercado austríaco.

#Para quem escrevo isto em Viena

Viena tinha 2 040 914 habitantes com residência principal a 1 de janeiro de 2026, segundo a estatística da cidade. É capital federal e, ao mesmo tempo, um dos nove estados da Áustria, e acolhe organizações internacionais como a ONU, a OPEP e a OSCE. A agência de promoção económica da cidade, a Wirtschaftsagentur Wien, destaca entre as suas áreas as ciências da vida e as indústrias criativas e media.

Na prática, isto traduz-se em sites com duas ou mais línguas. O alemão é a língua do Estado segundo o artigo 8 da Constituição federal (B-VG), por isso a versão alemã é quase sempre a principal, e o inglês serve clientes, parceiros e candidatos internacionais. Uma migração que trate a versão inglesa como acessório costuma partir exatamente aí: hreflang em falta, páginas inglesas sem par alemão, canonicals que apontam para a língua errada.

#Quando compensa migrar para Astro ou Next.js?

Compensa quando o problema está na arquitetura e não na configuração. Antes de propor uma migração, meço o site atual: Core Web Vitals no relatório da Search Console, tempo de resposta do servidor, número de plugins ou módulos ativos e quanto tempo a equipa perde a publicar uma página.

Se a lentidão vem de um page builder, imagens sem compressão ou cache mal configurada, uma limpeza dentro do CMS atual custa menos e eu digo isso por escrito. A migração faz sentido quando:

• o tema acumulou anos de CSS e JavaScript que ninguém consegue retirar sem partir layouts;
• o CMS precisa de atualizações de segurança constantes e o site é quase só conteúdo;
• o mesmo conteúdo tem de servir site, intranet ou aplicação através de uma API;

Astro é a escolha natural para páginas de serviço, blogue, documentação e sites institucionais: gera HTML estático e só carrega JavaScript onde há interação. Next.js entra quando há sessão de utilizador, área de cliente, pesquisa com filtros sobre dados vivos ou conteúdo que muda a cada pedido.

#Como preservo o SEO durante a mudança?

O trabalho começa com uma lista completa de URLs, retirada de três fontes: um rastreio do site atual, as páginas com impressões na Search Console dos últimos 16 meses e os registos do servidor, que mostram endereços antigos ainda visitados por links externos ou favoritos.

Cada URL recebe uma decisão: mantém-se igual, recebe um 301 para o novo endereço exato ou, se não tem tráfego nem substituto, devolve 410. Nunca redireciono tudo para a página inicial. O mapa fica numa folha que o cliente pode rever, e no fim corro um script que pede cada URL antigo ao novo site e confirma o código de resposta e o destino.

Antes do corte comparo, página a página, título, meta description, canonical, cabeçalho H1, dados estruturados (Organization, LocalBusiness, BreadcrumbList, FAQPage quando existem) e as anotações hreflang de/en. Em sites austríacos com conteúdo também para a Alemanha ou a Suíça, verifico se as variantes regionais (de-AT, de-DE, de-CH) estão declaradas de forma recíproca, porque uma referência sem retorno é ignorada.

#Como funciona o corte faseado?

Em sites com várias centenas de páginas não faço tudo de uma vez. Migro primeiro uma secção com tráfego mensurável, por exemplo o blogue, e deixo o resto no sistema antigo atrás do mesmo domínio. Comparo cliques e erros de rastreio dessa secção antes de avançar.

No dia do corte submeto o novo sitemap, confirmo na inspeção de URLs da Search Console que as páginas principais estão indexáveis e vigio o relatório de páginas não indexadas. O que costuma falhar:

• parâmetros antigos (?page_id=, index.php?option=com_content) sem regra de redirecionamento;
• PDFs em /wp-content/uploads/ ou /sites/default/files/ que continuam linkados de fora;
• formulários que dependiam de um plugin e deixam de enviar e-mails;
• páginas noindex no staging que passam para produção com a mesma etiqueta.

#Que regras austríacas entram no âmbito?

Três temas aparecem em quase todos os projetos vienenses.

Acessibilidade. O Barrierefreiheitsgesetz (BaFG, BGBl. I n.º 76/2023) transpõe a Diretiva Europeia de Acessibilidade e inclui as Dienstleistungen im elektronischen Geschäftsverkehr, ou seja, lojas e serviços vendidos online a consumidores, prestados depois de 28 de junho de 2025. As microempresas que prestam serviços (menos de dez pessoas e volume de negócios ou balanço até 2 milhões de euros) estão isentas. A fiscalização cabe ao Sozialministeriumservice. Como reconstruo os templates de raiz, corrijo contraste, navegação por teclado, textos alternativos e estrutura de cabeçalhos no próprio componente, não página a página.

Impressum. O § 5 da E-Commerce-Gesetz (ECG) exige que o prestador disponibilize de forma fácil e direta nome ou firma, morada geográfica, contactos incluindo e-mail, número e tribunal do registo comercial, autoridade de supervisão e dados profissionais quando se aplicam, e o NIF de IVA. Confirmo que a página existe no novo site, que está ligada a partir de todas as páginas e que não se perdeu nenhum campo na conversão.

Proteção de dados. A autoridade competente é a Österreichische Datenschutzbehörde (DSB), com sede em Viena. Uma migração é boa altura para fazer o inventário de scripts de terceiros: fontes externas, mapas, vídeos incorporados e ferramentas de análise. O que deixa de existir sai da declaração de privacidade; o que fica passa a carregar apenas depois do consentimento, se o exigir.

Sobre o alojamento: Astro pode ser servido a partir de uma CDN, enquanto um CMS headless ou uma aplicação Next.js com servidor guarda dados pessoais algures. Indico por escrito em que região ficam a base de dados, os formulários e os registos, para que a decisão de residência de dados seja do cliente e não um efeito secundário.

#O que fica com a sua equipa depois do lançamento?

O repositório Git, as variáveis de ambiente documentadas, o pipeline de publicação e um documento curto com o modelo de conteúdo: que tipos existem, que campos têm e como se cria uma página nova em cada língua. Se o CMS antigo continua como fonte de conteúdo (WordPress headless, por exemplo), descrevo as atualizações que ainda precisa e o que acontece ao frontend quando a API não responde.

Para o contexto geral do serviço, veja a página sobre migração para Astro e Next.js; se o projeto já é Astro e precisa de desenvolvimento contínuo, a página de desenvolvedor Astro.

#Próximo passo

Envie-me o endereço do site atual, o CMS e a versão que usa, as línguas publicadas e de onde vem o tráfego (pesquisa orgânica, campanhas, links de parceiros). Com isso preparo um âmbito escrito: o que migro, o que fica, que URLs mudam e que verificações faço antes e depois do corte.