Quebra de tráfego após o redesign do site: como encontrar a alteração responsável

Porque cai o tráfego depois do redesign de um site?

O tráfego cai depois de um redesign quando o relançamento mexe em algo de que o Google ou o analytics dependem: URLs, redirecionamentos, conteúdo indexável, ligações internas ou a etiqueta de medição. Um aspeto novo, por si só, raramente explica a perda; as alterações que seguem com ele explicam.

A maioria dos redesigns junta muitas alterações numa única data. Modelos novos, outro CMS, uma estrutura de URLs “mais arrumada”, páginas fundidas, um novo banner de cookies e uma etiqueta reinstalada entram em produção ao mesmo tempo. É por isso que as primeiras semanas após o lançamento são tão difíceis de interpretar: várias causas possíveis partilham a mesma data.

Os suspeitos habituais:

• URLs alterados sem redirecionamento. Os URLs antigos devolvem 404, e o posicionamento e as ligações que tinham não passam para as páginas novas.
• Redirecionamentos errados. Redirecionamentos temporários (302, 307) onde deviam estar permanentes, cadeias com vários saltos ou muitas páginas antigas enviadas para a nova página inicial.
• Conteúdo removido ou fundido. Páginas que posicionavam para pesquisas de cauda longa foram cortadas ou reduzidas a um parágrafo de outra página.
• Restos do ambiente de testes. Um disallow no robots.txt ou uma etiqueta noindex do site de testes passou para produção.
• Modelos diferentes. Títulos, cabeçalhos ou menus novos que perderam as palavras pelas quais a página posicionava, ou menos ligações internas para páginas profundas.
• Medição avariada. A etiqueta de analytics ou a configuração de consentimento não foi migrada, e o tráfego parece menor do que é.

Se a quebra começou numa data sem relançamento, o artigo sobre porque caiu o tráfego orgânico cobre as atualizações do Google e outras causas.

A quebra é real ou o redesign avariou a medição?

Convém verificar isto primeiro, porque uma etiqueta avariada depois do relançamento é idêntica a uma perda de tráfego. Compare o GA4 com o Google Search Console: se os cliques no Search Console se mantiveram enquanto as sessões no GA4 caíram no dia do lançamento, o problema é de medição e não de visitantes.

1. Abra o site novo e acompanhe o relatório de tempo real do GA4. Segundo o Google, os dados começam a aparecer aí poucos minutos depois de a etiqueta disparar corretamente.
2. Use o DebugView ou o Tag Assistant para confirmar que as visualizações de página e os eventos principais disparam nos modelos novos, incluindo formulários e páginas de agradecimento.
3. Verifique se o banner de consentimento mudou com o redesign, já que uma configuração nova pode impedir as etiquetas de disparar.
4. Compare os cliques orgânicos do Search Console com as sessões orgânicas do GA4 nos mesmos dias. Uma diferença que se abre no dia do lançamento aponta para a medição.

Dê tempo aos relatórios padrão: o Google recomenda aguardar 24 a 48 horas pelo processamento completo, por isso não avalie o relançamento pelos relatórios do próprio dia. Para um passo a passo, leia como distinguir um problema de medição de uma perda real de visitantes e o nosso guia do Tag Assistant. Se as conversões caíram e o tráfego não, veja também os formulários e os URLs de agradecimento: o nosso artigo sobre o acompanhamento de conversões do Google Ads lista as alterações que mudam a contagem.

Quanto tempo demora o tráfego a recuperar depois de um redesign ou migração?

Se os URLs mudaram, conte com alguma oscilação. A documentação do Google sobre mudanças de site indica que haverá flutuações de posicionamento durante a migração e que, num site de dimensão média, pode demorar algumas semanas ou mais até a maioria das páginas ser transferida no índice; sites maiores demoram mais.

A migração só fica concluída quando o Googlebot visita cada URL antigo e novo pelo menos uma vez, e o Google não tem uma frequência de rastreio fixa. Assim, uma recuperação lenta e irregular é normal nas primeiras semanas. O que não é normal é uma perda concentrada em páginas cujos URLs antigos dão erro, ou em páginas que deixaram de estar indexadas.

O Google recomenda ainda manter os redirecionamentos o máximo de tempo possível, em geral pelo menos um ano, para que os sinais passem para os URLs novos (guia do Google sobre mudanças de site). Retirá-los cedo porque o tráfego “voltou” pode reabrir o problema.

Que alterações do redesign deve verificar primeiro?

Comece pelas alterações que tiram páginas do índice do Google e só depois pelas que mudam o que as páginas dizem. Erros de redirecionamento e de indexação cortam o tráfego depressa; alterações de modelo e de conteúdo tendem a surgir como uma descida mais lenta.

Redirecionamentos

O Google recomenda redirecionamentos permanentes do lado do servidor (301 ou 308) de cada URL antigo para o equivalente novo mais próximo. Os redirecionamentos temporários (302, 303, 307) dizem ao Google que o URL antigo continua a ser o canónico. Evite cadeias (idealmente no máximo 3 saltos, e menos de 5) e não envie muitos URLs antigos para uma única página sem relação, como a página inicial. Os redirecionamentos em JavaScript são o último recurso, porque a renderização pode falhar e o Google pode nunca os ver (redirecionamentos e a Pesquisa Google).

Erros 404 e páginas removidas

Segundo o Google, os erros 404 não prejudicam a indexação nem o posicionamento do resto do site. A perda vem dos 404 em páginas que mudaram de endereço: se o conteúdo foi movido, acrescente um redirecionamento. Exporte os URLs antigos que recebiam cliques e verifique-os um a um.

Regras de indexação

Procure um disallow no robots.txt ou uma etiqueta noindex copiada do ambiente de testes, e etiquetas canónicas que apontam para o domínio antigo ou para a página errada. A ferramenta de inspeção de URLs mostra como o Google vê cada URL.

Modelos e conteúdo

Compare títulos, cabeçalhos, texto e ligações internas antigos e novos nas principais páginas de entrada. Uma página mais curta, ou um menu que deixou de ligar às páginas de categoria, pode perder posições sem qualquer erro técnico.

Como isolar a publicação que causou a quebra de tráfego?

Date a quebra com precisão, divida-a por grupo de páginas e associe cada grupo afetado à publicação que lhe mexeu. Um redesign quase nunca é uma só alteração; é uma série de publicações, e a que coincide com a data e com as páginas é a causa.

1. Excluir um problema de medição
2. Dividir a quebra por grupo de páginas
3. Associar cada grupo a uma publicação
4. Testar uma correção de cada vez

No Search Console, compare os cliques das quatro semanas antes e depois do lançamento e filtre por página ou padrão de URL, como /blog/, /produtos/ ou /servicos/. Se só um grupo perdeu cliques, a causa está no que mudou nesse grupo: os URLs, o modelo ou os redirecionamentos. Depois verifique acontecimentos externos nos mesmos dias, como uma atualização do Google ou uma campanha em pausa, para não atribuir ao redesign aquilo que tem outra origem.

O difícil são as datas. Um relançamento costuma ser seguido de correções, lotes de redirecionamentos, um novo banner de consentimento e ajustes de conteúdo ao longo de vários dias, enquanto as campanhas pagas continuam a mudar em paralelo. Com todas as alterações numa única cronologia, veria que os redirecionamentos do blog entraram em produção na terça-feira, dois dias após o lançamento e precisamente no dia em que os cliques do blog caíram. No Changeline, a equipa regista cada publicação com data, responsável e motivo, e as alterações do Google Ads são importadas automaticamente ao lado, pelo que site e campanhas ficam na mesma cronologia.

Exemplo: um cliente pergunta porque é que os contactos orgânicos caíram 30% duas semanas depois do relançamento. Ao alinhar as alterações dos dias anteriores, a agência vê que no terceiro dia fundiu 40 páginas de serviços em 8 e redirecionou as restantes para a página inicial. Os cliques nas páginas de serviços estavam a cair desde essa data, enquanto o blog se mantinha estável. Redirecionar cada página antiga para o serviço novo mais próximo explicou a quebra ao cliente e deu uma correção clara. (Nomes e números ilustrativos.)

Como corrigir uma quebra de tráfego depois de um redesign?

Corrija primeiro o que mantém páginas fora do índice, depois recupere o conteúdo que posicionava, e altere uma coisa de cada vez para perceber o que resultou.

1. Reúna os URLs antigos a partir de sitemaps antigos, registos do servidor, analytics, CMS e Search Console, como sugere o guia do Google, e construa o mapeamento de URLs antigos para novos.
2. Crie redirecionamentos permanentes para cada URL movido e corrija cadeias e redirecionamentos para a página inicial.
3. Retire etiquetas noindex e bloqueios no robots.txt que tenham ficado e corrija as etiquetas canónicas.
4. Submeta o novo sitemap no Search Console. Mantenha o antigo durante algum tempo para ver as páginas indexadas descerem até perto de zero e depois retire-o.
5. Recupere títulos, cabeçalhos, secções e ligações internas nas páginas que mais cliques perderam.
6. Registe cada correção com a data, para mais tarde ler a recuperação à luz dela.

Se o próprio domínio mudou, use a ferramenta “Alteração de endereço” do Search Console no site antigo. O Google indica que serve para mudanças de domínio ou subdomínio, não para passar de HTTP para HTTPS, trocar o www no mesmo domínio ou mudar caminhos dentro de um domínio.

Como planear o próximo redesign com todas as alterações registadas?

Guarde uma base de referência antes do lançamento e mantenha um registo datado de cada publicação a seguir. A maioria das discussões depois de um redesign é sobre datas que ninguém apontou.

• Guarde as principais páginas de entrada por cliques e conversões dos últimos 3 meses, bem como um sitemap dos URLs antigos.
• Publique por fases sempre que possível (modelos, depois URLs, depois conteúdo), para que cada fase tenha a sua data.
• Aponte cada publicação: data e hora, páginas afetadas, o que mudou, responsável e motivo.
• Marque também o lançamento no analytics; o nosso guia das anotações no GA4 explica como.
• Combine com o cliente, antes do lançamento, quanto tempo esperar até avaliar os resultados.

Um registo de alterações do site torna isto um hábito, e o guia do registo de alterações de marketing explica como manter site e campanhas juntos. O nosso modelo de registo de alterações de marketing já traz as colunas e, quando o cliente perguntar o que aconteceu, este guia para explicar uma quebra ao cliente ajuda na conversa.