Como refazer um site sem perder tráfego do Google

Refazer um site pode melhorar design, tecnologia e conversão, mas também pode destruir anos de sinais acumulados no Google quando a migração é feita sem planejamento.

O maior risco não é trocar WordPress, servidor ou layout. É o Google deixar de encontrar na nova estrutura aquilo que conhecia na anterior.

Uma migração de SEO começa antes da publicação.

Faça um inventário do site antigo

Antes de alterar URLs, levante o que existe.

O inventário deve combinar, quando disponíveis:

sitemap;
páginas do CMS;
Google Search Console;
Analytics;
backlinks;
URLs encontradas por crawler;
arquivos e conteúdos importantes.

O objetivo é descobrir quais páginas existem e quais realmente recebem tráfego, links ou impressões.

Não mude URLs sem necessidade

Uma URL antiga que continua representando o mesmo conteúdo normalmente deve ser preservada.

Trocar `/servicos/desenvolvimento-de-sites/` por outra URL apenas por preferência estética cria trabalho e risco sem necessariamente produzir benefício.

Quando a mudança é necessária, deve existir um mapeamento entre origem e destino.

Use redirects 301 para equivalências reais

Se uma página antiga foi substituída por outra equivalente, utilize redirecionamento permanente 301.

Exemplo:

`/empresa/` → `/sobre/`

Mas não direcione centenas de páginas sem relação para a Home.

Quando não existe substituto, retornar 404 ou 410 pode ser mais correto do que fingir equivalência.

Preserve o conteúdo que já funciona

Um redesign não exige apagar bons textos.

Identifique páginas e trechos que recebem tráfego orgânico antes de simplificar conteúdo.

O novo site pode melhorar redação e estrutura, mas mudanças relevantes precisam ser conscientes.

Canonical, noindex e robots merecem atenção

Erros simples podem impedir uma nova página de aparecer no Google.

Antes de publicar, valide:

ausência de `noindex` nas páginas públicas;
canonical apontando para a própria URL correta;
robots.txt permitindo rastreamento;
sitemap contendo as novas páginas;
ambiente de staging protegido.

Um erro particularmente perigoso é levar configurações de bloqueio do staging para produção.

Atualize o sitemap

Depois da publicação, o sitemap deve representar o novo site.

URLs removidas não devem continuar sendo anunciadas indefinidamente.

Envie ou confirme o sitemap no Google Search Console e acompanhe processamento e indexação.

Search Console é essencial depois da migração

Nas semanas seguintes, acompanhe:

páginas indexadas;
páginas não indexadas;
404;
erros 5xx;
redirects;
páginas rastreadas e não indexadas;
impressões;
cliques;
consultas;
páginas de destino.

Relatórios do Search Console podem possuir atraso, portanto não interprete mudanças de um único dia isoladamente.

Não confunda indexação com ranking

Uma página estar indexada significa que pode aparecer no Google.

Não significa que continuará na mesma posição.

Mudanças de conteúdo, estrutura, concorrência e sinais do site podem alterar rankings mesmo quando a migração técnica está correta.

O objetivo é reduzir perdas evitáveis, não prometer posição.

Checklist antes da virada

inventário das URLs antigas;
mapa de redirects;
conteúdo prioritário preservado;
metadata revisada;
canonical;
robots;
sitemap;
analytics;
formulários;
performance;
HTTPS;
páginas de erro;
staging protegido.

Conclusão

A reformulação de um site deve ser tratada como uma migração, não apenas como uma troca visual.

Quanto maior o histórico e volume de conteúdo, mais importante se torna mapear o estado anterior antes de publicar a nova versão.

Vai refazer um site ou migrar um portal?

A Jumps atua em desenvolvimento, migração, infraestrutura e SEO técnico de sites e portais.

Conversar sobre a migração →

Relacionado: Sites e Portais · Infraestrutura e Cloud.

Quanto custa desenvolver um site profissional para uma empresa?

O custo de um site profissional pode variar bastante porque “site” descreve projetos muito diferentes.

Uma landing page, um site institucional com dezenas de páginas e um portal com milhares de conteúdos podem utilizar tecnologias semelhantes, mas possuem escopos completamente diferentes.

Para entender o investimento, é preciso olhar para o que o site precisa fazer — e não apenas para quantas páginas aparecem no menu.

O que influencia o preço?

Os fatores mais comuns são:

arquitetura da informação;
quantidade e variedade de layouts;
criação ou adaptação do design;
produção e migração de conteúdo;
responsividade;
WordPress ou outro CMS;
formulários;
integrações;
busca;
áreas restritas;
SEO técnico;
performance;
acessibilidade;
infraestrutura;
migração do site antigo;
manutenção depois da publicação.

Layouts diferentes aumentam o trabalho

Dez páginas que utilizam o mesmo template são diferentes de dez páginas com estruturas completamente distintas.

Em projetos profissionais, normalmente criamos componentes reutilizáveis e tipos de página.

Isso melhora consistência e reduz custo de evolução.

Por isso, ao estimar um site, é mais útil identificar quantos tipos de layout precisam ser construídos do que simplesmente contar URLs.

Conteúdo também faz parte do projeto

Um site novo precisa de textos, imagens, projetos, serviços, notícias e outras informações.

Quando o cliente já possui conteúdo organizado, o processo é diferente de um projeto em que toda a arquitetura e redação ainda precisam ser construídas.

Em uma migração, também pode existir um volume significativo de páginas antigas que precisam ser importadas, revisadas ou redirecionadas.

WordPress deixa o site barato?

WordPress é software de código aberto, mas isso não significa que todo projeto WordPress tenha o mesmo custo.

A plataforma resolve uma parte importante da gestão de conteúdo. Ainda assim, design, desenvolvimento, integrações, performance, segurança, migração e infraestrutura continuam existindo.

WordPress pode ser a base de um site simples ou de um portal complexo.

SEO precisa entrar no orçamento?

SEO possui componentes editoriais e técnicos.

No desenvolvimento, a base deve considerar URLs, headings, metadata, canonical, sitemap, dados estruturados quando aplicáveis, links internos, performance e redirecionamentos.

Isso não garante posições no Google, mas evita começar o trabalho orgânico sobre uma base tecnicamente problemática.

O perigo de comparar apenas o preço

Duas propostas de site podem estar vendendo coisas completamente diferentes.

Pergunte:

o design será personalizado?
quem desenvolverá?
conteúdo está incluído?
haverá migração?
SEO técnico está contemplado?
performance será avaliada?
quem configura produção?
existe garantia?
manutenção está incluída?
quem será responsável depois da publicação?

A proposta mais barata pode ser adequada ao projeto. O importante é comparar escopos equivalentes.

Site é investimento inicial e operação

Depois da publicação existem domínio, hospedagem, atualizações, backups, segurança e eventuais evoluções.

Sites estratégicos também precisam de conteúdo contínuo, acompanhamento de conversão e SEO.

Planejar essa etapa evita que o projeto seja lançado e fique abandonado.

Conclusão

Para orçar corretamente um site, primeiro defina objetivos, públicos, conteúdo, funcionalidades e integrações.

A partir disso, uma software house consegue dimensionar design, desenvolvimento e infraestrutura de forma muito mais precisa.

Está planejando um novo site ou a reformulação do atual?

A Jumps desenvolve sites institucionais e portais e pode avaliar o escopo do seu projeto.

Fale sobre seu site →

Relacionado: Sites e Portais · Projetos · Contato · Como refazer um site sem perder tráfego do Google.

Core Web Vitals: por que a velocidade do site afeta o negócio

Os Core Web Vitals são um conjunto de três métricas que o Google usa para descrever a experiência real de quem acessa uma página. Elas fazem parte dos critérios de ranqueamento desde 2021 e, mais importante do que o efeito em SEO, têm relação direta com a taxa de conversão: páginas lentas perdem visitantes antes mesmo de carregar por completo.

Este artigo explica cada métrica em linguagem de negócio, mostra o que costuma derrubar a nota, descreve como priorizar as correções e discute como manter o desempenho ao longo do tempo — porque performance não é um item de checklist único, e sim algo que degrada a cada publicação se não houver disciplina.

As três métricas

LCP — Largest Contentful Paint

Mede quanto tempo leva até o maior elemento visível da página aparecer — normalmente a imagem principal, um bloco de texto grande ou o vídeo do topo. É a métrica que mais se aproxima da percepção de “o site abriu”. O alvo é até 2,5 segundos para a maioria dos acessos. Acima de 4 segundos, a experiência é considerada ruim.

INP — Interaction to Next Paint

Substituiu o antigo FID em 2024. Mede quão rápido a página responde visualmente às interações do usuário ao longo de toda a visita — cliques, toques, digitação. Se você clica em um menu e ele demora a abrir, ou se o campo de busca “engasga” enquanto você digita, o INP está alto. O alvo é até 200 milissegundos.

CLS — Cumulative Layout Shift

Mede o quanto o layout “pula” durante o carregamento. Acontece quando uma imagem sem dimensões declaradas empurra o texto para baixo, quando um banner aparece de repente ou quando uma fonte troca e muda a altura das linhas. O usuário tenta clicar em um botão e ele se move. O alvo é um índice de até 0,1.

Onde os dados vêm

É importante distinguir dois tipos de medição. Os dados de laboratório vêm de ferramentas que simulam um acesso em condições controladas — úteis para diagnosticar e testar hipóteses. Os dados de campo vêm de usuários reais, com aparelhos e conexões variados, e são o que o Google efetivamente usa para ranqueamento.

Um site pode ter nota boa em laboratório e ruim em campo, geralmente porque a maioria dos usuários acessa por celular em rede móvel, um cenário bem mais duro do que o computador do escritório. Sempre priorize os dados de campo, disponíveis no relatório de experiência do Chrome e no Search Console.

O que costuma derrubar a nota

Imagens pesadas e mal servidas — sem compressão, sem formatos modernos, sem dimensões declaradas, carregadas mesmo quando estão fora da tela.
JavaScript demais — bibliotecas grandes, scripts de terceiros, código que bloqueia a renderização enquanto executa.
Fontes personalizadas — sem estratégia de carregamento, causam texto invisível ou troca visível que gera CLS.
Servidor lento para responder — sem cache, com consultas de banco pesadas a cada requisição.
Tags de marketing e analytics — cada ferramenta adicionada via gerenciador de tags custa desempenho; poucas são realmente necessárias.
Banners e pop-ups — de consentimento, de newsletter, de promoção, que aparecem depois e deslocam o conteúdo.

Como priorizar as correções

Nem toda otimização vale o esforço. O caminho mais eficiente:

Comece pelos dados de campo: qual das três métricas está fora do alvo e em qual tipo de dispositivo.
Para LCP alto, olhe primeiro a imagem principal — formato, tamanho, prioridade de carregamento — e o tempo de resposta do servidor.
Para CLS alto, procure elementos sem dimensão reservada: imagens, iframes, anúncios, blocos que aparecem depois.
Para INP alto, identifique quais interações estão lentas e reduza o trabalho de JavaScript que acontece nelas.
Meça de novo em campo depois de cada mudança; ganhos de laboratório nem sempre se confirmam com usuários reais.

Em muitos sites, um punhado de mudanças resolve a maior parte do problema: otimizar a imagem do topo, remover dois ou três scripts desnecessários, ajustar o carregamento das fontes e ativar cache no servidor.

Por que isso importa para o negócio

A relação entre velocidade e conversão é bem documentada. Cada segundo a mais no carregamento reduz a probabilidade de o visitante continuar. Em e-commerce, isso significa carrinho abandonado antes da vitrine carregar. Em captação de leads, significa formulário nunca visto. Em conteúdo, significa taxa de rejeição alta e menos páginas por sessão.

Há também um efeito de custo. Um site mais leve consome menos banda, menos processamento no servidor e é mais barato de rastrear para os mecanismos de busca — o que ajuda a indexação de sites grandes. E há o efeito de marca: um site lento comunica desleixo, mesmo que o visitante não saiba dizer o porquê.

Performance se mantém, não se conquista

O erro mais comum é tratar performance como um projeto pontual: contrata-se uma otimização, a nota sobe, todo mundo comemora e, seis meses depois, ela caiu de novo. Isso acontece porque cada nova funcionalidade, cada plugin, cada tag de marketing e cada imagem publicada sem cuidado consome um pouco do orçamento de desempenho.

Manter os Core Web Vitals no verde exige processo:

Um “orçamento de performance” definido — tamanho máximo de página, número máximo de requisições — verificado antes de publicar.
Pipeline que mede as métricas a cada mudança e alerta quando piora.
Otimização automática de imagens no momento do upload.
Revisão periódica das tags de terceiros: cada uma ainda é necessária?
Acompanhamento mensal dos dados de campo no Search Console.

LCP em detalhe: o que atrasa o carregamento

O LCP alto quase sempre tem uma de quatro causas, e vale investigá-las nesta ordem. A primeira é o tempo de resposta do servidor: se ele demora um segundo para começar a mandar o HTML, esse segundo já entra na conta antes de qualquer imagem. Cache de página e um servidor bem dimensionado resolvem.

A segunda é o carregamento da imagem principal: formato antigo, arquivo grande, sem prioridade de carregamento, ou pior, uma imagem que só é descoberta pelo navegador depois de baixar e processar um arquivo CSS ou JavaScript. Declarar a imagem do topo com prioridade alta e servi-la em formato moderno costuma cortar segundos.

A terceira são recursos que bloqueiam a renderização — folhas de estilo e scripts que o navegador precisa processar antes de desenhar qualquer coisa. A quarta é a fonte personalizada, que pode segurar o texto ou causar um “flash” quando troca. Controlar como as fontes carregam elimina os dois problemas.

CLS em detalhe: o que faz o layout pular

O deslocamento de layout tem uma causa central: elementos que ocupam espaço na página sem que esse espaço tenha sido reservado de antemão. Os culpados mais comuns:

Imagens e vídeos sem atributos de largura e altura, ou sem proporção definida no CSS.
Anúncios e embeds de terceiros que chegam depois e empurram o conteúdo.
Banners de consentimento de cookies inseridos no topo depois do carregamento inicial.
Conteúdo carregado dinamicamente acima do que o usuário já está lendo.
Fontes que mudam a altura da linha quando a fonte final substitui a de fallback.

A correção é sempre a mesma ideia: reservar o espaço antes. Toda imagem com dimensão declarada, todo slot de anúncio com altura mínima fixa, todo elemento dinâmico inserido abaixo da área visível ou em um espaço já reservado.

INP em detalhe: o custo do JavaScript

O INP mede o tempo entre a interação do usuário e a próxima atualização visual da tela. Quando esse tempo é alto, é porque a thread principal do navegador está ocupada executando JavaScript e não consegue responder ao clique. As fontes típicas:

Handlers de evento que fazem trabalho pesado de forma síncrona.
Scripts de terceiros — chat, analytics, testes A/B — que rodam com frequência.
Renderização de listas ou tabelas grandes sem virtualização.
Frameworks que reprocessam mais do que o necessário a cada interação.

As soluções envolvem quebrar tarefas longas em pedaços, adiar o que não é urgente, reduzir o número de scripts de terceiros e, quando aplicável, mover processamento para fora da thread principal.

Ferramentas úteis

PageSpeed Insights — combina dados de laboratório e de campo para uma URL.
Search Console → Core Web Vitals — visão agregada do site inteiro, por grupo de páginas.
Chrome DevTools — aba Performance para o carregamento, aba de INP para diagnosticar interações lentas.
WebPageTest — testes detalhados em diferentes dispositivos e conexões, com cascata completa.
Relatório CrUX — dados de campo agregados, disponíveis também via BigQuery para análise histórica.

Um mito comum: nota 100 no Lighthouse

A nota de 0 a 100 do Lighthouse é um dado de laboratório e mede uma simulação, não a experiência dos seus usuários. É possível ter nota 100 e Core Web Vitals ruins em campo, e vice-versa. Perseguir os 100 pontos costuma levar a otimizações de retorno decrescente que não mexem no que o usuário sente.

O que importa é a proporção de acessos reais dentro dos alvos — idealmente acima de 75% para cada métrica, que é o critério que o Google usa para considerar a página “aprovada”. Use o Lighthouse para diagnosticar e testar hipóteses, mas decida com os dados de campo.

Como a Jumps trata

A Jumps inclui performance no escopo de sites e portais desde o início — não como um ajuste no fim — e mantém o acompanhamento na sustentação, com orçamento de performance verificado a cada publicação e revisão mensal dos dados de campo.

Se o seu site está com Core Web Vitals no vermelho ou você quer garantir que um projeto novo nasça rápido, fale com a Jumps para uma auditoria.

Como planejar a migração de um portal com muito conteúdo

Trocar a plataforma de um portal grande — um site de notícias, um portal corporativo, uma base de conhecimento com anos de conteúdo — é um dos projetos com maior potencial de dar errado de forma visível. Feito sem método, derruba o tráfego orgânico, quebra links compartilhados por anos e gera meses de retrabalho para recuperar posições. Feito com planejamento, a migração passa quase despercebida pelos usuários e pelos mecanismos de busca.

A diferença está quase toda na preparação. Este roteiro cobre as etapas que não podem faltar, na ordem em que costumam ser executadas.

1. Inventário de conteúdo e de URLs

O primeiro passo é saber exatamente o que existe. Isso significa levantar todas as URLs do site atual — não as que você acha que existem, mas as que os mecanismos de busca conhecem e as que recebem acessos. As fontes:

O rastreamento completo do site com uma ferramenta de auditoria (Screaming Frog, Sitebulb ou similar).
O relatório de páginas do Search Console, com impressões e cliques dos últimos 12 meses.
Os logs do servidor, que mostram o que realmente é acessado, inclusive por URLs antigas que não estão mais linkadas.
A analítica, para entender quais páginas trazem tráfego e conversão.
O relatório de backlinks, para identificar páginas que recebem links externos e não podem sumir.

Com esse inventário, cada URL entra em uma de três categorias: migrar como está, migrar com novo endereço ou aposentar. Páginas sem tráfego, sem links e sem valor editorial podem ser descontinuadas — mas de forma consciente, não por acidente.

2. Arquitetura de informação e padrão de URLs

A migração é a oportunidade de corrigir uma estrutura de navegação que cresceu de forma desordenada. Defina as seções, as categorias, as páginas de tópico e a hierarquia antes de pensar em layout. Uma arquitetura clara ajuda o usuário a encontrar conteúdo e ajuda o buscador a entender a cobertura do portal.

Sobre as URLs, a regra é: preserve sempre que possível. Cada URL que muda é um redirecionamento a mais para manter, um ponto a mais de risco e uma pequena perda de autoridade. Quando a mudança for inevitável — porque o padrão antigo era ruim ou porque a estrutura mudou —, o novo padrão deve ser estável, legível e sem parâmetros desnecessários.

3. Mapa de redirecionamentos 301

Para cada URL que muda de endereço, é preciso um redirecionamento 301 (permanente) da antiga para a nova. Esse mapa é o coração da migração e merece atenção obsessiva.

Um redirecionamento direto: da URL antiga para a URL nova final, nunca para uma página intermediária.
Nada de cadeias: A não deve redirecionar para B que redireciona para C. Cadeias desperdiçam autoridade e tempo de rastreamento.
Nada de redirecionar tudo para a home: uma página de artigo que sumiu deve ir para o conteúdo equivalente mais próximo ou retornar 404/410 de forma limpa.
Para conteúdo realmente removido sem substituto, um 404 com página útil (busca, links para seções principais) ou um 410 se a remoção é definitiva.

O mapa deve ser testado antes da virada: uma amostra grande de URLs antigas, verificada uma a uma para confirmar que chega ao destino certo com o código de status certo.

4. Migração de dados e mídia

O conteúdo em si — textos, imagens, documentos, metadados, datas de publicação, autoria — precisa ser transferido preservando o que importa para SEO e para o histórico. Pontos de atenção:

Datas de publicação e de atualização originais, não a data da migração.
Textos alternativos das imagens e legendas.
Títulos e meta descriptions já otimizados, quando existirem.
Tags e categorias, remapeadas para a nova taxonomia.
Comentários, se forem relevantes para o engajamento.
Mídia servida de um caminho estável, com redirecionamento se o caminho mudar.

5. SEO técnico da nova plataforma

Antes de publicar, a nova plataforma precisa estar tecnicamente pronta:

Sitemap XML completo e atualizado, pronto para ser reenviado.
Tags canônicas corretas em todas as páginas.
Dados estruturados equivalentes aos do site antigo (artigo, breadcrumb, organização).
Robots.txt liberando o que deve ser rastreado e bloqueando o que não deve.
Performance dentro dos alvos de Core Web Vitals.
Ambiente de homologação bloqueado para rastreamento, para não gerar conteúdo duplicado indexado.

6. Publicação

A virada deve acontecer em janela de baixo tráfego, com a equipe disponível para monitorar. A sequência típica: publicar a nova plataforma, ativar os redirecionamentos, verificar uma amostra de URLs em produção, reenviar o sitemap no Search Console e solicitar a reindexação das páginas mais importantes.

Não faça a migração às vésperas de um evento importante para o negócio, nem na sexta à tarde. Reserve os dias seguintes para acompanhamento intensivo.

7. Monitoramento pós-migração

Nas primeiras semanas, acompanhe de perto:

Erros de rastreamento e páginas não encontradas no Search Console.
Cobertura de indexação: quantas páginas foram indexadas versus o esperado.
Posições das palavras-chave mais importantes.
Tráfego orgânico por seção, comparado com o período anterior.
Logs do servidor, para ver o que os robôs estão rastreando e onde encontram erro.

É normal uma oscilação nas primeiras semanas enquanto o buscador reprocessa o site. O que não é normal é uma queda que não se recupera — nesse caso, quase sempre há redirecionamento faltando, cadeia de redirecionamento ou bloqueio de rastreamento indevido.

Conteúdo duplicado e canibalização

Migrações grandes costumam revelar que o site antigo tinha várias páginas competindo pelo mesmo assunto — artigos parecidos publicados em anos diferentes, uma página de serviço e um post de blog sobre o mesmo tema, versões que nunca foram consolidadas. Isso divide a autoridade e confunde o buscador sobre qual página mostrar.

A migração é o momento de resolver: consolidar os conteúdos redundantes em uma página forte, redirecionar as demais para ela e revisar os links internos para apontar todos para a versão canônica. O resultado costuma ser um ganho de posição para o tema, não uma perda.

O papel dos links internos

Os links internos distribuem autoridade pelo site e ajudam o buscador a entender a importância relativa das páginas. Numa migração, é comum que a nova estrutura de navegação mude esses links sem que ninguém perceba: uma página que era linkada de todo o rodapé passa a ser acessível só por um menu de terceiro nível.

Antes de publicar, verifique se as páginas mais importantes continuam recebendo links internos de peso — da home, das páginas de seção, de conteúdo relacionado. Uma página órfã, sem links internos, tende a perder posição mesmo com o redirecionamento correto.

Comunicação com quem depende do site

Uma migração afeta mais gente do que o time técnico. A equipe de conteúdo precisa saber que o fluxo de publicação vai mudar. O marketing precisa revisar as URLs em campanhas ativas, e-mails automáticos e materiais impressos com QR code. Parceiros que linkam para o site podem precisar ser avisados. Ferramentas integradas — automação de marketing, CRM, painéis — podem ter URLs fixas que quebram.

Um levantamento dessas dependências antes da virada evita que, no dia seguinte, uma campanha em andamento aponte para o lugar errado.

Cronograma realista

Uma migração de portal grande não é um projeto de duas semanas. As fases de inventário, arquitetura e mapa de redirecionamentos costumam consumir tanto tempo quanto o desenvolvimento da nova plataforma. Um cronograma típico reserva:

Semanas iniciais para inventário, auditoria e definição de arquitetura.
O grosso do tempo para desenvolvimento, migração de dados e construção do mapa de redirecionamentos em paralelo.
Uma fase de homologação com testes de amostra de URLs, performance e SEO técnico.
A virada em janela de baixo tráfego.
De quatro a oito semanas de monitoramento intensivo pós-publicação.

Comprimir demais qualquer uma dessas fases é onde os problemas nascem.

Erros que mais causam queda de tráfego

Redirecionar todas as URLs antigas para a home em vez do conteúdo equivalente.
Esquecer de remover o bloqueio de rastreamento que existia no ambiente de teste.
Cadeias longas de redirecionamento.
Mudar o padrão de URLs sem necessidade.
Não migrar as datas originais de publicação.
Publicar sem ter testado o mapa de redirecionamentos.
Deixar páginas importantes sem links internos na nova estrutura.
Fazer a virada numa sexta-feira ou perto de uma data crítica para o negócio.

Rollback: o plano B

Toda migração precisa de um plano para o caso de algo dar muito errado nas primeiras horas. Isso significa manter o site antigo intacto e acessível internamente durante alguns dias, ter um procedimento documentado para reverter o DNS e os redirecionamentos, e definir de antemão quais indicadores dispariam a decisão de voltar atrás — uma queda abrupta de tráfego, erros em massa, funcionalidades críticas quebradas.

Na prática, um rollback completo raramente é necessário se a homologação foi bem feita. Mas ter o plano reduz a pressão da equipe no dia da virada e evita decisões ruins tomadas no susto.

O que fazer com o domínio de teste

Durante o desenvolvimento, a nova plataforma vive em um endereço de homologação. Dois cuidados: esse ambiente precisa estar bloqueado para rastreamento e para acesso público, senão o Google pode indexá-lo e gerar conteúdo duplicado; e, no dia da virada, o bloqueio de rastreamento precisa ser removido do ambiente que vira produção — esquecer isso é um dos erros mais comuns e mais difíceis de perceber, porque o site parece funcionar normalmente enquanto some da busca.

Como a Jumps conduz migrações

A Jumps já conduziu a migração e a unificação de portais de grande porte, incluindo casos com vários sites e blogs consolidados em uma única plataforma. O processo segue exatamente as etapas acima, com o mapa de redirecionamentos tratado como entregável crítico e o monitoramento pós-virada acompanhado de perto.

Se você tem um portal para migrar e não quer arriscar o tráfego construído ao longo de anos, fale com a Jumps. Veja também sites e portais.

WordPress headless: quando faz sentido para o seu site

WordPress headless — ou “desacoplado” — é uma arquitetura em que o WordPress continua sendo o painel onde o conteúdo é criado e organizado, mas o site que o visitante vê é renderizado por uma aplicação separada, geralmente construída com um framework JavaScript, que busca os dados via API REST ou GraphQL.

É uma abordagem que ganhou popularidade e que resolve problemas reais — mas também é frequentemente adotada por modismo, adicionando custo e fragilidade a projetos que não precisavam. Este artigo ajuda a decidir com base no caso concreto, não na tendência.

Como funciona na prática

No WordPress tradicional, uma única aplicação faz tudo: recebe a requisição, consulta o banco, monta o HTML com o tema e devolve a página. No headless, esse fluxo se divide: o WordPress expõe o conteúdo como dados, e uma aplicação front-end separada consome esses dados e gera as páginas — muitas vezes de forma estática, no momento da publicação, ou renderizadas no servidor sob demanda.

O editor não percebe grande diferença no dia a dia, a não ser que o preview de conteúdo precisa ser configurado à parte, já que o tema tradicional não existe mais.

Os ganhos reais

Performance — páginas pré-renderizadas servidas de uma CDN carregam muito rápido e aguentam picos de tráfego sem esforço.
Flexibilidade de front-end — a equipe usa as ferramentas que quiser, sem as amarras do sistema de temas.
Reuso de conteúdo — o mesmo WordPress alimenta o site, um aplicativo, telas físicas, uma newsletter — tudo pela mesma API.
Segurança — o WordPress fica em uma rede interna, sem exposição pública direta; o que o visitante acessa é só HTML e arquivos estáticos.
Experiências ricas — interfaces muito interativas são mais naturais de construir em um framework moderno.

Os custos que costumam ser subestimados

Duas aplicações para manter — o WordPress e o front-end, cada um com suas dependências, seu deploy e sua conta de infraestrutura.
Preview e agendamento — precisam ser reconstruídos; não vêm de graça como no tema tradicional.
Plugins — muitos plugins geram HTML e assumem o tema tradicional; no headless, boa parte não funciona ou precisa de adaptação.
Formulários, busca, comentários — recursos que “só funcionavam” agora exigem integração explícita.
Time — manter um front-end desacoplado exige desenvolvedores JavaScript; não é a mesma habilidade de manter um tema.
Complexidade de build — cada publicação pode disparar uma reconstrução; sites com milhares de páginas precisam de estratégia para isso.

Quando o headless faz sentido

O site precisa de performance de altíssimo nível e de interatividade que o tema tradicional não entrega bem.
O mesmo conteúdo alimenta vários canais além do site.
Existe (ou será contratada) uma equipe de front-end dedicada.
O tráfego tem picos extremos e imprevisíveis, e servir estático da CDN resolve isso de forma barata.
Há requisitos de segurança que pedem para o CMS não ficar exposto publicamente.

Quando o headless complica sem retorno

Para a maioria dos sites institucionais, portais de conteúdo de porte médio e blogs corporativos, o headless adiciona custo de desenvolvimento, de hospedagem e de manutenção sem um ganho proporcional. O visitante não percebe a diferença se um WordPress tradicional bem construído já entrega páginas rápidas, e a equipe de conteúdo perde recursos que funcionavam sem esforço.

Se o motivo para considerar headless é “o WordPress é lento”, vale primeiro investigar por que está lento — quase sempre é tema pesado, falta de cache, imagens não otimizadas ou plugins demais, e resolver isso é muito mais barato do que rearquitetar.

O meio-termo: WordPress tradicional bem-feito

Entre o tradicional descuidado e o headless completo existe um caminho que resolve a maioria dos casos: um WordPress com tema enxuto e sob medida, cache de página, imagens otimizadas automaticamente, poucos plugins bem escolhidos e uma CDN na frente. Esse arranjo entrega Core Web Vitals no verde, é barato de hospedar e mantém todos os recursos de edição.

Outra opção intermediária é usar o headless apenas em parte do site — uma seção muito interativa, uma área de aplicativo — mantendo o resto no modelo tradicional.

O impacto na equipe de conteúdo

No WordPress tradicional, a pessoa que escreve vê o conteúdo tomar forma no editor de blocos, publica e a página está no ar. No headless, alguns desses passos mudam. O preview precisa de uma configuração que conecte o editor ao front-end desacoplado; sem isso, quem publica não vê como a página vai ficar. O agendamento de publicações e a expiração de conteúdo podem exigir automação extra para disparar a reconstrução do site.

Recursos que a equipe usava sem pensar — inserir um formulário, embutir um vídeo, montar uma galeria, usar um bloco de um plugin — podem precisar de um equivalente construído sob medida no front-end. Nada disso é impossível, mas tudo tem custo, e o custo recai sobre o orçamento do projeto e sobre a produtividade de quem publica.

Custo de infraestrutura ao longo do tempo

Um WordPress tradicional roda em uma hospedagem, com uma conta previsível. Um projeto headless tem, no mínimo, duas frentes de infraestrutura: o WordPress (que continua existindo, mesmo que sem tráfego público) e a hospedagem do front-end, que pode incluir uma plataforma de build, uma CDN e serviços de renderização sob demanda.

Para sites com muitas páginas, o processo de build merece atenção: se cada publicação reconstrói o site inteiro, o tempo e o custo crescem com o acervo. Existem estratégias — reconstrução incremental, renderização sob demanda — mas todas adicionam complexidade que precisa ser mantida.

Migrar de tradicional para headless

Se um site já existe em WordPress tradicional e a equipe considera migrar para headless, vale primeiro descartar as causas simples de insatisfação. “O site é lento” geralmente se resolve com tema enxuto, cache, otimização de imagens e menos plugins — a um custo muito menor do que rearquitetar.

Quando a migração se justifica, ela não precisa ser total nem imediata. É possível desacoplar uma seção por vez, começando pela que mais se beneficia, e manter o resto no modelo tradicional durante a transição.

Perguntas para decidir

O que exatamente o headless resolve que o tradicional bem-feito não resolve?
Quem vai manter as duas aplicações depois do lançamento?
Quais recursos de edição a equipe de conteúdo usa hoje e quais sobrevivem à mudança?
Qual o custo de infraestrutura e de build previsto para os próximos anos?
O conteúdo realmente vai alimentar outros canais, ou isso é hipotético?
A insatisfação atual é com performance? Já testamos otimizar o tradicional antes?

Segurança: o argumento mais forte a favor

De todos os motivos para adotar headless, o de segurança é o mais difícil de contestar. No modelo tradicional, o WordPress fica exposto na internet: o painel de administração, os endpoints de API, o formulário de login — tudo é alvo de tentativas automatizadas o tempo todo. Uma vulnerabilidade em um plugin pode virar um comprometimento do site.

No headless, o WordPress pode ficar em uma rede privada, acessível só pela equipe e pelo processo de build. O que o público acessa são arquivos estáticos servidos de uma CDN — não há banco de dados para injetar, não há painel para forçar, não há plugin executando código para o visitante. A superfície de ataque encolhe drasticamente.

Para setores com requisitos de segurança mais rígidos — financeiro, saúde, governo —, esse isolamento sozinho pode justificar a arquitetura.

Alternativas ao headless completo

WordPress tradicional otimizado — tema sob medida, cache de página, CDN, imagens automáticas. Resolve a maioria dos casos de “quero um site rápido”.
Cache estático agressivo — plugins ou serviços que geram HTML estático das páginas e servem da borda, mantendo o WordPress tradicional por trás. Ganha boa parte da performance do headless sem a complexidade.
Ilhas de interatividade — o site é estático, e apenas os trechos que precisam de dinamismo carregam JavaScript. Combina simplicidade com experiências ricas onde importa.
Headless parcial — só uma seção do site é desacoplada; o resto segue tradicional.

Checklist de decisão

Liste os problemas concretos que você quer resolver. Se todos forem de performance, teste otimizar o tradicional primeiro.
Verifique se você tem ou vai contratar desenvolvedores de front-end para manter a aplicação desacoplada.
Some o custo de infraestrutura das duas frentes e o custo de reconstruir preview, formulários e busca.
Confirme se o conteúdo realmente vai alimentar outros canais, ou se isso é só uma possibilidade distante.
Se há requisito de segurança que peça o CMS fora da internet pública, o headless ganha peso.
Considere as alternativas intermediárias antes de decidir pelo modelo completo.

Como a Jumps aborda

A Jumps trabalha com os dois modelos e recomenda o que faz sentido para o caso. Em sites e portais, a maioria dos projetos fica muito bem resolvida com WordPress tradicional otimizado ou com cache estático; o headless entra quando há um motivo concreto — interatividade intensa, múltiplos canais, escala extrema, requisito de segurança.

Se você está avaliando uma arquitetura para um site novo ou pensando em migrar um existente, fale com a Jumps antes de fechar a decisão.

SEO técnico para portais de notícia: arquitetura e indexação

SEO técnico para um portal de notícias tem particularidades que não aparecem em um site institucional. O volume é alto — dezenas ou centenas de publicações por dia —, a janela de relevância de cada matéria é curta, e a mesma notícia costuma existir em várias versões (web, AMP, impressão, aplicativo). Cada uma dessas características exige uma decisão técnica específica.

Este artigo cobre os pontos que mais impactam a performance orgânica de um portal editorial, do rastreamento à arquitetura de conteúdo.

Indexação rápida

Para conteúdo noticioso, ser indexado em minutos, não em dias, é o que separa aparecer na cobertura de um assunto de chegar tarde. Os mecanismos:

Sitemap de notícias — um sitemap específico, atualizado em tempo real, contendo apenas as matérias das últimas 48 horas, com data de publicação precisa.
Feeds RSS/Atom — ainda são consumidos por agregadores e ajudam na descoberta.
URLs estáveis desde a primeira publicação — nada de publicar com uma URL provisória e mudar depois.
Links internos imediatos — uma matéria nova deve ser linkada da home e da editoria correspondente assim que sai.
Estrutura leve — quanto mais rápido a página responde, mais o robô rastreia por visita.

Orçamento de rastreamento

Portais grandes têm milhões de URLs, e o robô do buscador não rastreia todas com a mesma frequência. O “orçamento de rastreamento” é limitado, e desperdiçá-lo com páginas de baixo valor significa menos atenção para o que importa. Fontes comuns de desperdício:

Paginação infinita de arquivos e tags, gerando milhares de URLs quase idênticas.
Parâmetros de URL que criam versões duplicadas (ordenação, filtros, rastreamento de campanha).
Páginas de busca interna indexáveis.
Tags criadas para uma única matéria, gerando páginas de arquivo com um item.
Versões de impressão e de compartilhamento acessíveis ao robô.

A solução combina robots.txt, meta tags de não indexação, canonical e uma política editorial de uso de tags.

Arquitetura de editorias e tópicos

A estrutura de conteúdo de um portal deve deixar claro para o buscador — e para o leitor — qual é a cobertura da publicação e como as matérias se relacionam. Os elementos:

Editorias — as seções principais (política, economia, esportes), com páginas fortes que concentram autoridade.
Páginas de tópico — páginas dedicadas a um assunto contínuo (um julgamento, uma eleição, uma empresa), que agregam todas as matérias relacionadas e tendem a ranquear bem para o termo.
Tags — usadas com parcimônia, apenas quando há volume de conteúdo que justifique uma página de arquivo útil.
Links entre matérias relacionadas — distribuem autoridade e mantêm o leitor no portal.

Páginas de tópico bem construídas são um dos ativos de SEO mais valiosos de um portal, porque acumulam relevância ao longo do tempo enquanto matérias individuais perdem tração.

Dados estruturados

Os mecanismos de busca usam dados estruturados para entender e destacar o conteúdo. Para notícias, os principais são:

Article / NewsArticle — título, data de publicação e de atualização, autor, imagem, publicação.
BreadcrumbList — a trilha de navegação até a matéria.
Organization — dados da publicação, logo, perfis oficiais.
Person — para páginas de autor, com credenciais e histórico.

Autoria clara, com página de autor real e credenciais, virou um sinal importante de confiabilidade, especialmente para temas sensíveis.

Canonical entre versões

Quando a mesma matéria existe em web, AMP, aplicativo e impressão, é preciso dizer ao buscador qual é a versão principal. A tag canônica de todas as variações deve apontar para a URL canônica única. Erros aqui geram conteúdo duplicado, diluem a autoridade e podem fazer a versão errada ranquear.

Conteúdo sindicado — republicado por parceiros ou agências — também precisa de canonical apontando para a origem, senão a cópia pode superar o original.

Performance com anúncios

Portais de notícia vivem de publicidade, e anúncios são pesados: scripts, requisições, elementos que aparecem depois e deslocam o conteúdo. É o principal inimigo dos Core Web Vitals em sites editoriais.

Reservar o espaço de cada anúncio no layout, para eliminar o deslocamento (CLS).
Carregar anúncios abaixo da dobra de forma tardia.
Limitar o número de posições e auditar o peso que cada rede adiciona.
Priorizar o carregamento do conteúdo editorial sobre o dos anúncios.

Paginação e arquivos

Páginas de editoria e de tag num portal têm dezenas ou centenas de páginas de paginação (“página 2”, “página 47”). Deixá-las todas indexáveis dilui a autoridade e consome rastreamento. As abordagens comuns:

Indexar apenas a primeira página de cada arquivo e permitir que o robô siga os links para as demais sem indexá-las.
Garantir que cada matéria tenha links internos permanentes (da editoria, de conteúdo relacionado, da página de tópico), para não depender da paginação para ser descoberta.
Usar canonical de cada página de paginação para ela mesma, não para a primeira — elas são conteúdos diferentes.
Evitar rolagem infinita como único meio de navegação, porque o robô não rola a página.

Velocidade de publicação e SEO

Num portal, a redação publica sob pressão de tempo, e o SEO técnico não pode depender de cada jornalista preencher dez campos. A plataforma deve gerar automaticamente o que for possível — URL a partir do título, dados estruturados, tags canônicas, entrada no sitemap de notícias — e pedir ao editor apenas o que exige julgamento: o título, a linha-fina, a imagem, a editoria e uma ou duas tags relevantes.

Quanto mais o SEO técnico for automático e invisível, mais consistente ele será na prática de uma operação que publica dezenas de vezes por dia.

Conteúdo antigo: o acervo

Um portal com anos de operação tem um acervo enorme que continua trazendo tráfego de cauda longa. Cuidar dele significa manter as URLs estáveis, atualizar matérias antigas que ainda recebem buscas (com data de atualização visível), consolidar conteúdos redundantes sobre o mesmo assunto e remover ou desindexar o que perdeu valor e só consome orçamento de rastreamento.

Um trabalho periódico de curadoria do acervo — identificar as matérias antigas com mais potencial e melhorá-las — costuma ter retorno melhor do que produzir conteúdo novo do zero para os mesmos termos.

Google Notícias e Discover

Além da busca tradicional, portais editoriais dependem de dois canais do Google: Notícias e Discover. As regras deles se sobrepõem ao SEO comum, mas têm particularidades.

Para o Google Notícias, contam a consistência de publicação, a clareza de autoria e seções, e a ausência de conteúdo que viole as políticas de conteúdo.
Para o Discover, imagens grandes e de alta qualidade (com a marcação adequada), títulos que não sejam sensacionalistas e E-E-A-T — experiência, especialização, autoridade e confiabilidade — fazem diferença.
Nenhum dos dois aceita “otimização” no sentido clássico; o caminho é conteúdo consistente, bem estruturado e confiável.

Tráfego de Discover é volátil por natureza — pode dobrar o acesso de uma matéria em um dia e sumir no seguinte. Não é base para planejamento, mas é um bônus relevante quando o conteúdo e a parte técnica estão em ordem.

Estrutura de uma matéria bem otimizada

Título claro, com a informação principal na frente, sem clickbait.
Linha-fina que resume e complementa o título.
URL curta e estável, gerada do título no momento da publicação.
Imagem principal com dimensões adequadas, texto alternativo e crédito.
Data de publicação e, quando houver revisão, data de atualização visível.
Autor identificado, com link para a página de autor.
Subtítulos (h2, h3) organizando o texto para leitura e para os trechos em destaque.
Links para matérias relacionadas e para a página de tópico do assunto.
Dados estruturados de NewsArticle e BreadcrumbList.

O erro de tratar SEO como problema só do time de tecnologia

Boa parte do SEO de um portal está nas mãos da redação: o título que escolhem, a editoria em que classificam, as tags que aplicam, os links que colocam, a decisão de atualizar ou não uma matéria antiga. A parte técnica cria as condições — sitemap ágil, dados estruturados automáticos, performance —, mas o resultado depende de a redação entender o básico e ter ferramentas que não atrapalhem o ritmo.

Um treinamento curto e um checklist de publicação embutido no editor costumam ter mais impacto do que qualquer ajuste técnico isolado.

Métricas para acompanhar

Tempo médio entre publicação e primeira indexação.
Percentual do acervo efetivamente indexado.
Cliques e impressões por editoria e por página de tópico.
Core Web Vitals de campo, separando páginas com e sem anúncios pesados.
Erros de rastreamento e páginas com problemas de dados estruturados no Search Console.
Participação de Notícias e Discover no tráfego total.

Como a Jumps trata

A Jumps colaborou em portais jurídicos e editoriais de grande porte, onde a indexação ágil, a arquitetura de tópicos e a performance sob carga de anúncios são requisitos centrais. Esses pontos entram no escopo de sites e portais e no acompanhamento contínuo de sustentação e evolução.

Se você opera um portal de conteúdo e quer revisar a base técnica de SEO, fale com a Jumps.

Site multi-idioma no WordPress: hreflang, URLs e SEO

Um site multi-idioma bem construído atende cada mercado no idioma certo, sem que as versões concorram entre si nos resultados de busca e sem virar um pesadelo de manutenção. Um site multi-idioma mal construído gera conteúdo duplicado, confunde o buscador sobre qual versão mostrar para quem e desanda em poucos meses porque ninguém definiu quem mantém o quê.

As decisões que determinam de que lado o projeto vai cair são tomadas antes da tradução — na estrutura, não no texto.

Estrutura de URLs: as três opções

Subdiretórios

site.com/pt/, site.com/en/, site.com/es/. É a opção mais simples de implementar e manter, concentra toda a autoridade em um único domínio e é fácil de rastrear. É a escolha padrão para a maioria dos projetos, especialmente quando os idiomas atendem públicos que se sobrepõem geograficamente.

Subdomínios

pt.site.com, en.site.com. Separa mais os ambientes, o que pode ajudar quando as operações por idioma são realmente independentes, mas divide a autoridade e adiciona complexidade de configuração. Raramente é a melhor escolha para um site de porte médio.

Domínios por país

site.com.br, site.com, site.es. Sinaliza fortemente a segmentação por país e pode ajudar em mercados onde a extensão local gera confiança. Mas cada domínio começa a construir autoridade do zero, os custos se multiplicam e a manutenção é a mais pesada das três. Só compensa para operações grandes e realmente separadas por país.

Tags hreflang

A tag hreflang informa ao buscador que existem versões de uma página em outros idiomas e qual serve para cada público. É o mecanismo que evita que a versão em português apareça para quem busca em inglês e vice-versa. As regras:

Cada página deve listar todas as suas versões de idioma, incluindo uma referência a ela mesma.
As referências precisam ser recíprocas: se A aponta para B, B tem que apontar para A.
Use apenas o código de idioma (pt, en) quando o conteúdo não muda por país; use idioma-região (pt-BR, pt-PT, es-MX) quando muda.
Inclua a versão x-default para indicar o que mostrar a quem não se encaixa em nenhum idioma listado.
As URLs no hreflang devem ser absolutas e apontar para páginas que retornam 200, não redirecionamentos.

Erros de hreflang são comuns e silenciosos: o site parece funcionar, mas as versões erradas ranqueiam. O Search Console tem um relatório específico para diagnosticar.

Plugin ou arquitetura própria

No WordPress, as opções mais usadas para multi-idioma são plugins como WPML e Polylang, ou uma abordagem multisite com um site por idioma. Cada uma tem trade-offs:

Plugin de tradução — mantém tudo em uma instalação, facilita ligar conteúdos equivalentes, mas adiciona peso e pode complicar a performance e futuras migrações.
Multisite — cada idioma é um site, com mais isolamento e flexibilidade, ao custo de mais trabalho para manter a consistência e ligar as versões.
Headless com um modelo de conteúdo multi-idioma — mais controle, adequado quando o front-end já é desacoplado, mas exige time e arquitetura.

A escolha depende de quantos idiomas, quanto o conteúdo diverge entre eles e qual o perfil da equipe que vai manter.

O que traduzir e o que adaptar

Nem tudo é tradução literal. Um bom projeto multi-idioma distingue:

Traduzir — conteúdo institucional, descrições, artigos que fazem sentido em qualquer mercado.
Adaptar — exemplos, casos, moeda, formatos de data, referências legais e culturais.
Criar do zero — conteúdo específico de um mercado que não existe nos outros.
Não publicar — nem todo conteúdo precisa existir em todos os idiomas; publicar uma versão pela metade é pior do que não publicar.

Governança de conteúdo

A causa mais comum de um site multi-idioma que “desanda” é a falta de processo. Sem definição de responsabilidades, a versão principal recebe atualizações que nunca chegam às outras, e em um ano as versões contam histórias diferentes. Defina:

Quem é responsável por publicar e revisar cada idioma.
O que precisa estar sincronizado entre versões e o que pode divergir legitimamente.
Um fluxo para que uma atualização na versão principal gere uma tarefa de tradução nas outras.
Uma revisão periódica de consistência.

Detecção de idioma e redirecionamento automático

Uma tentação comum é detectar o idioma do navegador ou o país pelo IP e redirecionar o visitante automaticamente para a versão “certa”. Isso costuma causar mais problema do que resolve: um brasileiro viajando é jogado para a versão local errada, o robô do buscador (que acessa de um só lugar) só enxerga uma versão, e links compartilhados levam a lugares inesperados.

A prática recomendada é não redirecionar automaticamente. Em vez disso, ofereça um seletor de idioma visível e, opcionalmente, um aviso discreto sugerindo a versão que parece mais adequada, sem forçar. O robô deve conseguir rastrear todas as versões livremente.

Conteúdo que não deve ser traduzido por máquina e publicado

Tradução automática evoluiu, mas publicar o resultado bruto, sem revisão humana, tem custos. O texto pode conter erros sutis que minam a credibilidade, termos técnicos traduzidos fora do jargão do setor e construções que soam estranhas para um falante nativo. Para conteúdo institucional e comercial, a tradução automática serve como ponto de partida, não como versão final.

Além da qualidade, há a questão de SEO: os termos que as pessoas efetivamente buscam em cada idioma raramente são a tradução literal. Uma pesquisa de palavras-chave no idioma de destino orienta que conteúdo criar e como nomeá-lo.

Manutenção: o custo escondido

Cada idioma adicional multiplica o trabalho de manutenção. Uma correção de texto, uma atualização de preço, uma nova página institucional — tudo precisa ser replicado. Se o site tem quatro idiomas, cada mudança é quatro vezes o trabalho, ou vira uma dívida de sincronização.

Vale dimensionar isso antes de decidir quantos idiomas manter. Às vezes, dois idiomas bem mantidos servem melhor ao negócio do que cinco desatualizados.

Consolidar sites que cresceram separados

Um cenário comum não é criar um site multi-idioma do zero, mas unificar ambientes que surgiram de forma independente — um site por país, cada um com sua estrutura, seu layout e sua equipe. O resultado é inconsistência de marca, esforço redobrado para qualquer mudança estrutural e nenhuma economia de escala.

A consolidação em uma plataforma única multi-idioma resolve isso, mas é um projeto de migração com todos os cuidados que ele exige: inventário de cada ambiente, arquitetura comum, mapa de redirecionamentos por site, preservação de URLs relevantes e hreflang ligando as versões. O ganho é administrar conteúdo e evoluções de forma centralizada, com cada mercado ainda atendido no seu idioma.

SEO local dentro do multi-idioma

Estar em espanhol não é o mesmo que estar otimizado para o México, a Colômbia ou o Chile. Se o negócio atende países específicos, vale ir além do idioma: usar variações regionais no hreflang (es-MX, es-CO), adaptar exemplos e referências, ajustar informações de contato e, quando fizer sentido, segmentar geograficamente no Search Console.

O oposto também é verdade: se o público de um idioma é global e disperso, forçar uma segmentação por país pode ser contraproducente. A decisão depende de onde estão os clientes, não de onde se fala a língua.

Checklist de um projeto multi-idioma

Definir os idiomas e, para cada um, se há segmentação regional.
Escolher a estrutura de URLs (subdiretório costuma ser o padrão).
Escolher a abordagem técnica (plugin, multisite, headless).
Implementar hreflang recíproco e com x-default.
Definir o que traduzir, adaptar, criar do zero e não publicar.
Fazer pesquisa de palavras-chave em cada idioma de destino.
Estabelecer a governança: donos, fluxo de sincronização, revisão periódica.
Configurar sitemaps e Search Console.
Não redirecionar visitantes automaticamente por idioma ou país.
Planejar o custo de manutenção contínua de todas as versões.

SEO internacional além do hreflang

Segmentação geográfica no Search Console, quando o alvo é um país específico.
Meta descriptions e títulos otimizados por idioma, não traduzidos automaticamente.
Pesquisa de palavras-chave feita no idioma de destino — os termos variam por cultura, não só por tradução.
Links internos dentro de cada versão de idioma, sem misturar.
Sitemaps separados ou um sitemap com as anotações de idioma.
Moeda, formatos de data e informações de contato adequados a cada mercado.

Como a Jumps trata

A Jumps unificou os sites e blogs internacionais da QMC Telecom — Brasil, Estados Unidos e países da América Latina — em uma única plataforma WordPress multi-idioma, com estrutura de URLs preservada sempre que possível, hreflang correto e redirecionamentos 301 para o conteúdo que mudou de endereço.

Se você precisa levar um site para novos mercados ou consolidar ambientes que cresceram separados, fale com a Jumps. Veja também sites e portais.

Acessibilidade digital no Brasil: o que a LBI exige do site

A Lei Brasileira de Inclusão da Pessoa com Deficiência — Lei 13.146/2015, conhecida como LBI ou Estatuto da Pessoa com Deficiência — estabelece que sites de empresas e de órgãos públicos devem ser acessíveis a pessoas com deficiência. Além da obrigação legal e do risco de ação civil pública, acessibilidade melhora a usabilidade para todos, ajuda o SEO e amplia o público que consegue usar o seu produto.

Este artigo explica a base legal, a referência técnica que se deve seguir, o conjunto de práticas que resolve a maior parte dos problemas e por que acessibilidade não é um item que se resolve uma vez.

A base legal

A LBI, no artigo 63, determina a obrigatoriedade de acessibilidade nos sites mantidos por empresas com sede ou representação comercial no país e por órgãos do governo, para garantia de acesso à informação. O Decreto 5.296/2004 e a norma técnica de acessibilidade da ABNT complementam. Para o setor público, o eMAG (Modelo de Acessibilidade em Governo Eletrônico) é a referência oficial.

Na prática, o descumprimento pode gerar notificação de órgãos de defesa do consumidor, ação do Ministério Público e condenação por dano moral coletivo. Já houve decisões nesse sentido contra empresas de vários setores.

A referência técnica: WCAG

A norma internacional de acessibilidade para conteúdo web é o WCAG (Web Content Accessibility Guidelines), publicado pelo W3C. A versão de referência atual é a 2.1 (com a 2.2 já disponível), organizada em três níveis: A (mínimo), AA (recomendado e adotado como alvo pela maioria das legislações) e AAA (mais rigoroso, nem sempre viável para todo o conteúdo).

O alvo realista para a maioria dos projetos é o nível AA da WCAG 2.1. Ele cobre os obstáculos que realmente impedem o uso, sem exigir o que seria impraticável em um site grande.

Os quatro princípios do WCAG

Perceptível — a informação precisa poder ser percebida por diferentes sentidos: texto alternativo em imagens, legendas em vídeos, contraste suficiente.
Operável — tudo deve funcionar pelo teclado, sem depender do mouse; o usuário deve ter tempo suficiente e não ser exposto a conteúdo que pisca.
Compreensível — texto legível, comportamento previsível, ajuda para evitar e corrigir erros em formulários.
Robusto — o código deve funcionar com tecnologias assistivas (leitores de tela) hoje e no futuro.

O que resolve a maior parte dos casos

Uma parcela grande dos problemas de acessibilidade se concentra em poucos pontos. Endereçar esta lista já coloca o site em uma situação muito melhor:

Texto alternativo em imagens que comunicam informação; imagens puramente decorativas devem ter alt vazio.
Contraste de pelo menos 4,5:1 entre texto e fundo (3:1 para texto grande).
Navegação por teclado completa, com indicador de foco sempre visível e ordem de tabulação lógica.
Estrutura de títulos coerente: um único h1, seguido de h2 e h3 encadeados sem pular níveis.
Formulários com rótulos associados a cada campo, instruções claras e mensagens de erro que dizem o que corrigir.
Links com texto descritivo — “baixar o relatório de 2025”, não “clique aqui”.
Legendas e transcrições em conteúdo de áudio e vídeo.
Landmarks e HTML semântico — usar cabeçalho, navegação, conteúdo principal e rodapé como elementos, não apenas divs.

O que não substitui um trabalho real

Existem “overlays” de acessibilidade — scripts que prometem tornar qualquer site acessível com uma linha de código, adicionando um menu flutuante de ajustes. Órgãos e especialistas de acessibilidade são amplamente críticos a essas ferramentas: elas não corrigem os problemas de fundo, às vezes atrapalham quem já usa tecnologia assistiva própria e podem dar uma falsa sensação de conformidade que não protege juridicamente.

Acessibilidade de verdade está no HTML, no CSS e no comportamento das interações — não em uma camada por cima.

Componentes interativos: onde a acessibilidade costuma quebrar

Texto e imagens são a parte mais simples. Os problemas se concentram nos componentes que o time constrói: menus suspensos, abas, acordeões, modais, carrosséis, tabelas com ordenação, campos com autocomplete. Para cada um deles, é preciso garantir:

Que funciona inteiramente pelo teclado, com uma ordem de foco previsível.
Que o estado (aberto, selecionado, expandido) é comunicado para tecnologias assistivas com os atributos corretos.
Que o foco é gerenciado — ao abrir um modal, o foco vai para dentro dele; ao fechar, volta para onde estava.
Que não há armadilhas de foco: o usuário sempre consegue sair de um componente.

Reutilizar componentes acessíveis já testados, em vez de construir cada um do zero, reduz muito o risco.

Acessibilidade e SEO andam juntas

Boa parte do que torna um site acessível também o torna mais fácil de entender para os mecanismos de busca: HTML semântico, estrutura de títulos coerente, texto alternativo em imagens, links descritivos, legendas e transcrições de vídeo. Um investimento em acessibilidade quase sempre melhora a base técnica de SEO como efeito colateral.

O contrário também vale: práticas ruins de SEO — texto escondido, títulos usados só para estilo, links vazios — costumam ser barreiras de acessibilidade.

Documento de acessibilidade e canal de contato

Além do site em si, é boa prática (e em alguns contextos, exigência) publicar uma página que declare o nível de conformidade buscado, as limitações conhecidas e um canal para que usuários reportem barreiras. Isso demonstra compromisso, ajuda na defesa em caso de questionamento e gera um retorno valioso: quem usa tecnologia assistiva encontra problemas que nenhuma auditoria pega.

Conteúdo: a responsabilidade de quem publica

Muitos problemas de acessibilidade não estão no código, e sim no conteúdo publicado no dia a dia. Uma imagem sem texto alternativo, um PDF que é só uma digitalização sem texto reconhecível, um vídeo sem legenda, um título usado só porque “fica maior”, links repetidos de “clique aqui”. Nenhuma auditoria técnica resolve isso de forma permanente se a equipe de conteúdo não incorporar o básico.

O que ajuda: campos obrigatórios de texto alternativo no upload de imagem, um guia curto de boas práticas, revisão de acessibilidade como parte do fluxo editorial e a orientação de que documentos importantes sejam publicados como páginas HTML sempre que possível, não como PDF.

PDFs e documentos

PDF é uma fonte recorrente de barreiras. Um PDF acessível precisa ter texto real (não imagem digitalizada), estrutura de títulos marcada, ordem de leitura correta, texto alternativo nas imagens e tabelas marcadas como tabelas. Criar PDFs assim dá trabalho e poucos são feitos corretamente.

A recomendação geral é preferir conteúdo em HTML — que é mais fácil de tornar acessível, responsivo e indexável — e reservar o PDF para o que realmente precisa ser um documento para download ou impressão, cuidando da acessibilidade nesses casos.

Prazo e abordagem para adequar um site existente

Adequar um site que não nasceu acessível não precisa ser um projeto único e paralisante. Uma abordagem realista:

Auditoria para mapear os problemas e classificá-los por gravidade e por esforço.
Correção imediata do que é crítico e barato — contraste, alt, foco visível, rótulos de formulário.
Plano em ondas para o que exige mais trabalho — componentes interativos, revisão de templates.
Ajuste do fluxo de conteúdo para não gerar novos problemas.
Verificação automática no pipeline e auditoria manual periódica das áreas mais usadas.

O objetivo é sair de “inacessível” para “utilizável” rápido, e depois evoluir para conformidade plena de forma sustentável.

Testar: automático e manual

Ferramentas automáticas (axe, WAVE, Lighthouse) detectam cerca de um terço dos problemas — contraste, alt faltando, rótulos ausentes, alguns erros de estrutura. O restante exige teste manual:

Navegar o site inteiro só com o teclado, verificando se o foco está sempre visível e se nada fica inacessível.
Usar um leitor de tela (NVDA no Windows, VoiceOver no Mac, TalkBack no Android) nas páginas e fluxos principais.
Verificar a página com 200% de zoom e com o espaçamento de texto ampliado, sem perda de conteúdo ou de função.
Conferir se o conteúdo faz sentido sem depender de cor (para diferentes tipos de daltonismo).
Testar os formulários preenchendo errado de propósito, para ver se os erros são claros e localizáveis.

Acessibilidade se mantém, não se conquista

Um site pode ser auditado e ajustado para conformidade e regredir em semanas: um novo banner sem contraste, uma imagem publicada sem alt, um componente interativo novo que não funciona no teclado. Manter o padrão exige processo:

Checklist de acessibilidade na revisão de cada nova funcionalidade.
Campo de texto alternativo obrigatório no fluxo de publicação de imagens.
Verificação automática no pipeline, que barra regressões óbvias.
Treinamento da equipe de conteúdo sobre títulos, links e alt.
Auditoria manual periódica das áreas mais usadas.

Como a Jumps trata

A Jumps trata acessibilidade como parte do desenvolvimento em sites e portais, com o alvo de WCAG 2.1 nível AA, e mantém a verificação no ciclo de sustentação e evolução para que o padrão não se perca a cada publicação.

Se o seu site precisa de uma auditoria de acessibilidade ou de adequação à LBI, fale com a Jumps.