Por que reconstruímos o próprio site em Next.js 16 (e o que isso muda pro cliente)

Este artigo foge um pouco do padrão dos outros textos deste blog — em vez de falar sobre o negócio do cliente, fala sobre o nosso próprio site. Vale a exceção porque a decisão por trás dele não é só uma escolha de tecnologia isolada: é o mesmo raciocínio de arquitetura que entra em qualquer projeto sob medida que a Alta Cloud constrói — e ver esse raciocínio aplicado na própria casa diz mais do que qualquer descrição genérica de processo.

O problema que motivou a reconstrução

O site anterior já cobria o essencial — conteúdo editorial, trilhas, glossário — mas tinha decisões soltas que iam se acumulando: um detalhe de CSS fazia a tipografia cair num fallback genérico (Arial/Helvetica) em vez da fonte Geist que já devia estar em uso, os scripts do Google Analytics e do AdSense carregavam como tags de script soltas no layout em vez de usar um carregamento que não atrasa a renderização inicial da página, e não existia um portal autenticado para o cliente acompanhar o próprio projeto — cada novidade dependia de mensagem avulsa em vez de um lugar único com o status atualizado. Nenhum desses pontos, isolado, justificaria recomeçar do zero. Juntos, eles apontavam para o mesmo lugar: valia mais consertar a fundação do que remendar por cima dela de novo.

Por que Next.js — e por que um app só, não dois

A escolha não foi só “framework mais popular do momento”. O critério real foi: site público (institucional, conteúdo editorial, cases, páginas de serviço) e portal do cliente (autenticado, acompanhamento de projeto) precisavam nascer como uma coisa só, com um único sistema de design e um único deploy — não dois códigos separados que começam parecidos e divergem com o tempo. O App Router do Next.js, com React Server Components, permite isso: o site público roda em rotas estáticas/renderizadas no servidor (bom para SEO e para o AdSense indexar conteúdo de verdade, não uma casca vazia), e o portal roda em rotas autenticadas dentro do mesmo projeto, compartilhando os mesmos componentes e tokens visuais.

Essa não renderização no servidor, aliás, não é um detalhe abstrato — é o mesmo problema técnico descrito em detalhe no artigo “SPA sem SSR: o erro invisível que pode custar sua indexação”, que já custou caro de verdade a outro projeto do grupo. Escolher um framework com renderização no servidor desde a fundação não é capricho técnico — é evitar um problema que, quando aparece depois, é caro de corrigir.

O que isso muda na prática — não na teoria

• Dados estruturados desde o layout, não como remendo. Cada artigo deste blog carrega JSON-LD de Article e BreadcrumbList automaticamente, porque isso faz parte do molde compartilhado de todas as páginas — não é algo que se adiciona depois, sob pressão, numa página de cada vez.
• Scripts de terceiro carregados sem travar a página. Analytics e AdSense usam o componente de carregamento de script do próprio Next.js, com a estratégia certa para cada caso — a correção específica do problema que o site anterior tinha.
• Tipografia aplicada de verdade, não só planejada. Geist Sans para o texto corrido, Geist Mono para elementos técnicos (métricas, trechos de código, labels), e uma fonte de traço mais arredondado para títulos grandes — o par tipográfico que o site anterior já sinalizava, mas não aplicava de fato.
• Conteúdo migrado preservando URL, não reescrito do zero. Artigos, trilhas e glossário publicados antes carregam autoridade de SEO acumulada — a reconstrução da infraestrutura não jogou isso fora; preservou as mesmas rotas em vez de forçar o Google a reindexar tudo como se fosse conteúdo novo.

O que isso significa para quem contrata a Alta Cloud

Não é preciso entender Next.js, React Server Components ou nenhum detalhe técnico deste artigo para contratar um projeto — isso é trabalho nosso, não do cliente. O que vale levar é o critério por trás da escolha: performance, SEO técnico e estrutura de dados corretos são tratados como parte do design desde o início, não como um ajuste de última hora depois que o site já está no ar com problema. É o mesmo critério aplicado a qualquer site institucional, landing page ou sistema sob medida que o estúdio constrói — só que aqui dá para apontar o exemplo mais próximo possível: o próprio site que está sendo lido agora.

Quem quiser ver o outro lado dessa mesma decisão — o que acontece quando um sistema já em produção precisa se conectar a outro (pagamento, WhatsApp, ERP, qualquer API externa) — encontra o detalhe em Integrações e APIs.