O tráfego caiu a pique: protocolo de diagnóstico por ordem de probabilidade

A mensagem chega sempre da mesma maneira, normalmente a uma segunda-feira: o tráfego caiu, alguma coisa aconteceu, o que fazemos. O instinto é assumir uma atualização de algoritmo, porque é a explicação que não exige que ninguém tenha errado. É também, pela nossa experiência, uma das causas menos prováveis.

Este artigo é o protocolo de diagnóstico que percorremos, por ordem de probabilidade, com a plataforma Semalt a ajudar a separar as hipóteses depressa. Está desenhado para que os primeiros trinta minutos eliminem a maior parte dos candidatos.

Passo zero: a queda é real?

Antes de investigar seja o que for, confirme que o tráfego caiu mesmo. Um número relevante de emergências acaba por ser um problema de medição, e trinta segundos de verificação evitam dias de investigação inútil.

1. Confirme que o código de medição ainda lá está

   Os deploys removem etiquetas de analítica com frequência. Se as sessões caíram para perto de zero de forma abrupta em todas as páginas e origens ao mesmo tempo, é quase sempre esta a causa.

2. Compare com uma segunda fonte

   Se as impressões de pesquisa estão estáveis enquanto a analítica mostra um colapso, o tráfego está bem e a medição não. Se as duas caíram, a queda é real.

3. Verifique se é sazonal

   Compare com o mesmo período do ano passado e não com o mês anterior. Em vários setores, uma queda de quarenta por cento em agosto é o calendário e não um problema.

4. Verifique se é um país ou um dispositivo

   Uma queda confinada a um segmento aponta normalmente para algo específico — um redirecionamento, uma alteração regional, um template móvel partido — e não para uma perda geral de posição.

Parâmetros de trabalho do protocolo descrito a seguir.

Passo um: causas técnicas, por probabilidade

De longe a categoria mais comum — e a mais rápida de verificar.

A primeira linha merece ser verificada antes de tudo o resto, sempre, porque demora noventa segundos e é catastrófica quando é verdade. Um noindex de staging que chegou a produção explica mais colapsos súbitos do que todas as atualizações de algoritmo juntas.

Passo dois: causas de conteúdo e estrutura

Se nada técnico explica, olhe para o que mudou no próprio site. Páginas eliminadas numa limpeza, uma secção movida sem redirecionamentos, um template que deixou cair um bloco de texto, ligações internas removidas num redesign, um grande lote de páginas fracas publicado que mudou a leitura global do site.

Analisamos isto em detalhe em Ligações internas.

Esta categoria diagnostica-se comparando crawls ao longo do tempo. Se existir um crawl de há dois meses, a comparação responde à pergunta em minutos. Se não existir, é este o momento em que se percebe porque insistimos em guardá-los.

Passo três: causas externas

Só agora, eliminadas as duas primeiras categorias, é razoável olhar para fora.

Existem outras explicações externas que se esquecem com frequência. Um concorrente pode ter lançado algo substancial. A procura pelo tema pode ter caído mesmo — veja se as impressões caíram para todos ou só para si. Uma página de resultados pode ter ganho um elemento que absorveu os cliques, o que aparece como posições estáveis com tráfego a cair. E, raramente, aplica-se uma ação manual — o único caso que se anuncia na Search Console em vez de exigir trabalho de detetive.

Ver também: Imagens e vídeo.

O que não fazer na primeira semana

O dano nestas situações é frequentemente autoinfligido, e acontece nos primeiros dias, quando a pressão está no máximo e a informação no mínimo.

Não reescreva grandes quantidades de conteúdo de imediato. Se a queda for uma flutuação, terá alterado as páginas que estavam a funcionar — e quando as coisas recuperarem não vai saber o que as recuperou.

Não faça disavow de ligações em pânico. O disavow agressivo por palpite causou-nos, pela experiência, mais estragos do que as ligações rejeitadas.

Não lance cinco correções ao mesmo tempo. Se alguma funcionar, não vai saber qual. Mude uma coisa, registe a data e espere.

E não prometa data de recuperação. Não a sabe, a resposta honesta é um intervalo com condições, e uma data concreta dada sob pressão passa a ser aquilo pelo qual é medido.

Gerir a conversa enquanto investiga

O trabalho técnico é só metade. A outra metade é o que diz ao cliente ou à administração nas primeiras horas, quando ainda não tem a resposta e alguém de topo quer uma.

Três coisas tornam essa conversa suportável. Diga o que sabe, o que já excluiu, e quando volta a dar notícias — por esta ordem. "Confirmámos que a queda é real, excluímos medição e indexação, e estamos a verificar o histórico de deploys; volto a atualizar às quatro" é uma resposta completa mesmo sem diagnóstico. Demonstra um processo, que é o que a pessoa está de facto a pedir.

Resista à pressão de nomear uma causa cedo. O instinto sob pressão é oferecer a explicação mais plausível disponível, que costuma ser "uma atualização do algoritmo" — e assim que é dita em voz alta passa a ser o pressuposto de todos, o que torna socialmente incómodo reportar depois que um programador lançou um noindex. Explicações provisórias são muito mais difíceis de retirar do que de não dar.

Defina expectativas de prazo com honestidade e cedo. Há causas que se encontram em trinta minutos; outras levam uma semana até haver confiança. Dizer "se for técnico sei hoje, se não for demora mais" é exato e evita os pontos de situação de hora a hora que tornam o trabalho mais lento.

E, quando encontrar, reporte a causa com clareza mesmo quando for embaraçosa para alguém. Uma queda causada por um deploy é um problema de processo que vale a pena corrigir; uma queda atribuída vagamente ao algoritmo não ensina nada a ninguém e garante a repetição.

Há um guia completo sobre o tema em Dados estruturados na prática.

Tornar a próxima mais barata

O que encarece uma queda de tráfego não é a queda; é a ausência de informação sobre o estado anterior. Três hábitos resolvem isso por completo.

Mantenha sondagens agendadas, para que as alterações técnicas apareçam como comparação em vez de terem de ser reconstruídas. Acompanhe um conjunto estável de palavras-chave, para que "perdemos posições" seja mensurável e não uma impressão. E mantenha um registo simples de deploys — mesmo que seja uma nota partilhada com datas — para que a pergunta "o que mudou" tenha resposta que não dependa da memória.

Nada disto evita quedas. Tudo isto transforma uma semana de investigação numa tarde — normalmente a diferença entre um incidente controlável e uma crise.

Conduzir a recuperação

Identificada a causa, a resposta depende da categoria em que caiu.

As avarias técnicas recuperam depressa e de forma previsível — muitas vezes poucos dias depois de a correção ser sondada, já que as páginas em si não tinham problema nenhum. É por isso que vale a pena esgotar primeiro a categoria técnica: é simultaneamente a mais provável e a mais corrigível.

As causas de conteúdo e estrutura levam mais tempo, tipicamente semanas, porque as páginas têm de ser reavaliadas. Reponha o que foi removido sempre que possível; quando não for, reconstrua o equivalente.

As quedas ligadas a algoritmos são as mais lentas e as menos sensíveis a uma correção única. A resposta produtiva é identificar que segmento foi afetado e o que têm as páginas que subiram que as suas não têm, melhorar em conformidade, e aceitar que a recuperação pode chegar com uma atualização posterior e não de imediato.

O protocolo, num parágrafo

Confirme que a queda é real. Verifique noindex, robots.txt e códigos de estado. Pergunte especificamente o que foi lançado. Compare crawls para encontrar alterações estruturais. Olhe para a forma da curva para distinguir avaria de atualização. Veja se os concorrentes mexeram. Mude uma coisa de cada vez, registe tudo, e não prometa datas.

Essa sequência resolve a grande maioria dos casos num dia — e os que não resolve ficam pelo menos corretamente classificados, que é por onde qualquer recuperação real tem de começar.

Se está nesta situação agora e não tem um crawl histórico com que comparar, corra um imediatamente: passa a ser a linha de base de tudo o que vier a seguir. Abra o painel, sonde o site e comece pela indexação.