Runbook de Resposta a Atualização de Algoritmo

Uma resposta a atualização de algoritmo é uma investigação de incidente, não um sprint de edição. Sua primeira regra é simples: confirme que a queda é real e é sua antes de reagir. “Real” significa que o declínio persiste em dados completos e comparáveis. “Sua” significa que reflete a visibilidade de busca do seu site, e não medição quebrada, demanda reduzida, layout de resultados alterado ou uma atualização que não afetou suas páginas.

Checklist: Resposta a Atualização de Algoritmo. Timebox: 60–90 minutos para triagem no primeiro dia; 2–4 horas para segmentação durante a primeira semana; uma decisão formal de agir ou esperar após sete dias completos, a menos que uma falha técnica verificada exija reparo imediato. Responsável: o líder de SEO é responsável pelo incidente e pelo registro de decisões; um analista valida os dados; a engenharia é responsável por falhas técnicas; os proprietários de conteúdo aprovam alterações nas páginas.

Use este runbook quando um declínio significativo nas buscas coincidir com uma atualização de algoritmo Google confirmada ou suspeita, ou seja, uma mudança nos sistemas de ranking do Google. Também é adequado quando nenhuma atualização foi confirmada, mas muitas URLs se movem juntas e a causa não está clara.

Por que esta fase, e por que aqui

Esta checklist consome a medição de base datada, anotações de lançamento, mapa de propriedade de páginas, inventário de templates, classificação de intenção, analytics, dados do Search Console e definições de conversão estabelecidas anteriormente no processo. Sem essas entradas, uma equipe pode ver que uma linha se moveu, mas não consegue estabelecer o que mudou, onde mudou ou se isso importa para o negócio.

A ordem importa porque falhas de medição e falhas do site podem imitar perdas de algoritmo. Uma mudança de consentimento pode remover sessões do analytics. Uma implantação pode adicionar noindex, escolher a canônica errada ou ocultar links internos. A sazonalidade pode reduzir pesquisas enquanto os rankings permanecem estáveis. Diagnosticar esses casos antes de atribuir o declínio a um sistema externo.

Executar remediação antes da segmentação causa um segundo problema: a atribuição desaparece. Se a equipe reescreve títulos, reestrutura templates, remove páginas e altera links internos na mesma semana, qualquer recuperação ou declínio posterior tem várias causas plausíveis. A resposta deve, portanto, passar da verificação para o isolamento do padrão, para uma decisão registrada de agir ou esperar, e só então para uma intervenção controlada.

Entradas e saídas

O registro de decisão é o contrato com o próximo passo. “O Google mudou algo” não é uma entregável; um padrão delimitado, uma decisão explícita e evidências que outro revisor possa inspecionar são.

A checklist

1. Confirme que a queda é real e é sua

O quê: verifique a perda em medições independentes antes de atribuir uma causa. Por quê: relatórios incompletos, falhas de rastreamento, fins de semana, sazonalidade, ciclos de notícias e mudanças na demanda podem criar um falso alarme convincente. Tráfego orgânico significa visitas não pagas de resultados de busca; ele pode cair mesmo quando os rankings não caem. Como: use dias completos, compare períodos equivalentes alinhados por dia da semana, verifique cliques e impressões do Search Console contra sessões e conversões do analytics, inspecione o contexto ano a ano onde houver sazonalidade e anote a data mais recente em que cada fonte foi finalizada. Ferramenta: dados de desempenho de busca, analytics, relatórios de conversão, logs de disponibilidade e o calendário de lançamentos. Concluído quando: pelo menos dois sinais independentes concordam na direção, os últimos três dias completos permanecem abaixo da linha de base selecionada, a atualidade dos dados é registrada e o briefing declara se a perda é de visibilidade, demanda, rastreamento, conversão ou uma mistura.

2. Exclua causas que você controla

O quê: teste falhas de site, rastreamento, segurança e indexação. Por quê: um defeito verificado merece reparo imediato, enquanto esperar uma atualização terminar prolongaria uma perda evitável. Indexabilidade é a capacidade de uma página ser incluída no índice de um mecanismo de busca. Como: inspecione URLs afetadas e não afetadas quanto a status de resposta, diretivas robots, canônica, renderização, links internos, presença em sitemap, notificações de ação manual e eventos de analytics; alinhe qualquer mudança com seu horário de lançamento. Ferramenta: inspeção de URL, logs de servidor e implantação, saída de crawler, depurador de analytics, monitor de disponibilidade e registro de alterações. Concluído quando: cada falha candidata é aprovada, refutada ou atribuída a um responsável; qualquer falha que coincida com o início é rotulada como reparar agora e separada das hipóteses de algoritmo.

3. Segmente por diretório, template e intenção

O quê: construa uma matriz de impacto em vez de julgar a média geral do site. Por quê: um total amplo pode esconder o padrão real: páginas de produto podem cair enquanto guias crescem, um template pode perder cliques móveis, ou consultas informacionais podem se mover enquanto a demanda de marca permanece estável. Intenção de busca é a tarefa que uma pessoa deseja realizar com uma consulta. Como: calcule mudanças antes versus depois para cliques, impressões, posição, conversões e URLs afetadas; agrupe primeiro por diretório, depois template, intenção primária, dispositivo, país, classe de consulta e função de negócio. Inclua grupos estáveis ou em crescimento como controles. Use totais absolutos ponderados além de porcentagens para que dez cliques perdidos em um segmento pequeno não superem dez mil cliques perdidos em um grande. Ferramenta: relatórios de diretório, página, consulta, movimentadores de URL e movimentadores de palavra-chave, além de uma planilha ou caderno de análise. Concluído quando: a matriz cobre pelo menos 95% dos cliques de busca, mostra segmentos afetados e de controle, registra grupos de baixo volume como inconclusivos e nomeia o padrão repetível mais restrito suportado pelos dados.

4. Inspecione vencedores e perdedores representativos

O quê: revise páginas e consultas que melhor representam cada segmento afetado e de controle. Por quê: agregados localizam o dano mas não o explicam. Uma página de resultados do mecanismo de busca pode substituir listagens clássicas por unidades de compras, resultados locais, vídeo ou respostas de IA; essa mudança pode reduzir cliques sem mostrar um defeito corrigível na página. Como: selecione pelo menos cinco perdedores de alto impacto e cinco controles estáveis ou em crescimento quando o segmento contiver URLs suficientes. Compare satisfação de intenção, originalidade, evidência, autoria, carga comercial, histórico de atualizações, roteamento interno, mudanças de snippet e formatos de resultado concorrentes. Registre observações como hipóteses, não como alegações de fator de ranking. Ferramenta: revisão de resultados ao vivo, renderização de página, registro de fonte, páginas concorrentes, dados de busca e inventário de conteúdo. Concluído quando: cada hipótese cita exemplos de perdedores e controles, evidências contraditórias são retidas e nenhuma recomendação se baseia em apenas uma página ou uma consulta.

5. Congele edições por pânico durante a primeira semana

O quê: proíba alterações amplas e especulativas enquanto continua o diagnóstico. Por quê: reescritas em massa de títulos, alterações de data de publicação, exclusão de páginas, metas de contagem de palavras em todo o site, redesenho de templates e rotatividade de links alteram múltiplas variáveis de uma só vez. Eles podem danificar páginas que não foram afetadas e tornar qualquer movimentação posterior impossível de atribuir. Como: crie uma janela de alterações de sete dias completos a partir do início observado. Permita apenas reparos verificados, correções legais ou factuais, trabalho de segurança e lançamentos já aprovados cujo adiamento acarrete maior risco; anote cada exceção. Preserve cópias das páginas atuais e exportações. Ferramenta: calendário de lançamentos, permissões do CMS, registro de incidentes e sistema de anotação. Concluído quando: o escopo, início, fim, aprovador e exceções do congelamento estão visíveis para editores e engenheiros; zero experimentos de SEO não registados são lançados dentro da janela.

6. Escolha agir, esperar ou reparar agora

O quê: tome uma decisão em um ponto de verificação nomeado. Por quê: observação interminável deixa defeitos genuínos sem tratamento, enquanto ação reflexiva converte incerteza em mudança descontrolada. Como: escolha reparar agora para uma falha técnica ou de medição reproduzida; escolha agir quando uma perda material persistir, concentrar-se em um segmento coerente e uma fraqueza de página ou sistema explicar tanto perdedores quanto controles; escolha esperar quando implementação, atraso de dados, sazonalidade, baixo volume ou segmentos contraditórios impedirem uma causa defensável. Registre as alternativas rejeitadas e as evidências que mudariam a decisão. Ferramenta: briefing do incidente, matriz de impacto, revisão representativa, avaliação de risco de negócio e aprovador. Concluído quando: o registro tem uma decisão, nível de confiança, responsável, data de revisão, links de evidência e um gatilho para reabri-lo.

7. Execute uma intervenção controlada

O quê: traduza uma decisão agir em um reparo ou experimento delimitado. Por quê: uma hipótese e um conjunto coerente de alterações preservam a chance de aprender; mudanças simultâneas em todo o site não. Como: defina o grupo afetado, grupo de comparação intocado quando prático, fraqueza precisa, melhoria pretendida para o leitor, métrica esperada, janela de observação, limite de aceitação e rota de reversão. Para páginas em decadência, use a checklist de atualização de conteúdo em vez de alterar datas ou expandir o texto cegamente. Ferramenta: briefing de ação, inventário de páginas, CMS, registro de QA, responsável pelo lançamento e anotações. Concluído quando: cada URL alterada mapeia para o padrão diagnosticado, a intervenção passou pelo QA, os controles permanecem inalterados ou desvios são registrados, e a anotação de lançamento declara o que deve mudar e até quando.

8. Meça, documente e feche ou itere

O quê: avalie a intervenção separadamente da narrativa da atualização. Por quê: recuperação após um lançamento é associação, não prova de que o lançamento a causou; a atualização ainda pode estar sendo implementada, concorrentes podem mudar e a demanda pode retornar. Como: compare a janela pós-declaração com a linha de base congelada, mantenha a mesma segmentação, inspecione controles e conversões, e registre fatores de confusão. Classifique o resultado como positivo, neutro, negativo ou inconclusivo. Ferramenta: resultados de anotação, relatórios de movimentadores, analytics, relatórios de conversão e o registro do incidente. Concluído quando: resultados reais versus esperados são anexados, confiança e limitações são declaradas, o responsável seleciona fechar, estender observação, reverter ou executar uma nova hipótese delimitada, e a próxima data de revisão é definida.

Ferramentas no AmICited

O AmICited torna o diagnóstico reproduzível ao preservar períodos, segmentos e intervenções. Ele não prova o que um algoritmo recompensa; use os relatórios para localizar padrões e testar decisões.

1. Abra o Organic Rank com o Relatório de Rank Orgânico para comparar demanda, posição média e cliques entre canais de busca conectados. Use-o para decidir se o incidente é amplo ou específico de canal.
2. Abra o URL Position Movers com Movimentadores de Posição de URL para identificar as páginas que estão criando a perda, comparar períodos e dividir a movimentação por dispositivo e seção.
3. Abra o Keyword Position Movers com Movimentadores de Posição de Palavra-chave para separar mudanças de ranking de consultas de perda de demanda e encontrar padrões ao nível de intenção.
4. Abra o Google Search Directories com Diretórios do Google Search para detalhar do site inteiro até os diretórios onde cliques ou impressões mudaram.
5. Use o Google Search Pages com Páginas do Google Search e o Google Search Queries com Consultas do Google Search para validar URLs representativas e as buscas exatas que elas atenderam.
6. Abra o Annotation Outcomes com Resultados de Anotação para registrar a intervenção, expectativa, ponto de verificação e resultado. Trate um resultado avaliado como evidência de associação, não prova de causalidade.

Regras de decisão

Estes são padrões de controle de incidente, não afirmações sobre como o Google pontua páginas. Seu propósito é evitar tanto a reação exagerada a ruído quanto a inação durante uma falha material. Substitua-os apenas por um limite documentado baseado na volatilidade estabelecida do site e no risco de negócio.

Porcentagens sozinhas são insuficientes. Um declínio de 50% de dois cliques para um não é operacionalmente equivalente a um declínio de 15% envolvendo milhares de visitas. Sempre mantenha volume absoluto, exposição de conversão e confiança junto com a mudança relativa.

Entregável: o pacote de incidente de atualização de algoritmo

Entregue uma pasta datada ou registro de incidente, não um slide dizendo “impacto da atualização principal”. Ele contém:

1. Um briefing de incidente de uma página com início, gravidade, atualização suspeita, atualidade dos dados, exposição do negócio, responsável e decisão atual.
2. Exportações congeladas ou links de relatório para os períodos de base e de incidente, incluindo filtros e fuso horário.
3. Uma matriz de impacto por diretório, template, intenção, dispositivo, país, página e consulta, com grupos afetados e de controle.
4. Um registro de exclusão de causas cobrindo medição, demanda, lançamentos, rastreamento, indexação, renderização, segurança e mudanças no layout de resultados.
5. Revisões representativas de perdedores e controles, com evidências de apoio e contraditórias para cada hipótese.
6. A decisão agir/esperar/reparar, alternativas rejeitadas, aprovador, próxima data de revisão e evidências que reabririam o incidente.
7. Para uma intervenção, o grupo exato de URLs, especificação da alteração, registro de QA, rota de reversão, anotação de lançamento, ponto de verificação e resultado final.

Use uma tabela legível por máquina para a matriz de impacto e um resumo legível por humanos para a decisão. O pacote está completo quando outro analista pode reproduzir o padrão afetado sem perguntar quais filtros foram usados, e um editor pode ver exatamente o que está aprovado sem interpretar um gráfico.

O que dá errado

A atualização se torna a explicação para tudo

Um anúncio e um declínio de tráfego ocorrem próximos um do outro, então a equipe para de testar alternativas. A solução é manter um registro de exclusão e exigir corroboração. A época estabelece uma hipótese, não a propriedade da perda.

Médias do site escondem movimentos opostos

Guias ganham enquanto páginas de categoria perdem, mas um total plano faz o evento parecer inofensivo. Ou um grande diretório cai e faz todos os templates parecerem fracos. Segmente os mesmos dados por diretório, template, intenção, dispositivo e país, e retenha grupos estáveis como controles.

Edições da primeira semana destroem a atribuição

Equipes reescrevem páginas porque agir parece mais seguro que esperar. Uma recuperação então não pode ser separada da conclusão da implementação, demanda, mudanças de concorrentes ou das próprias edições. Congele trabalho especulativo por sete dias completos e anote cada exceção.

Mudanças percentuais exageram amostras minúsculas

Um grupo de baixo volume cai de quatro cliques para dois e se torna o principal “perdedor” com 50%. Sempre emparelhe mudança relativa com cliques absolutos, impressões, contagem de URLs afetadas e valor de negócio. Marque segmentos finos como direcionais.

Controles são escolhidos após o resultado

Se páginas estáveis são selecionadas apenas depois de ver quais permaneceram estáveis, a comparação favorece a explicação preferida. Declare a lógica de controle antes da intervenção: mesmo template mas intenção diferente, mesma intenção mas template diferente, ou país/dispositivo não afetado dentro do mesmo grupo.

Várias correções são enviadas como um pacote

Títulos, corpo do texto, navegação, schema e templates mudam juntos. Mesmo um resultado positivo ensina pouco. Divida causas em intervenções separadas onde operacionalmente possível; quando não puderem ser separadas, registre o pacote e reduza a confiança da atribuição.

Recuperação é reportada como prova

A métrica melhora após um lançamento, então a ação é declarada causal. Relate a sequência com precisão: a mudança foi seguida por recuperação, os controles se comportaram de forma declarada e fatores de confusão conhecidos permanecem. Essa linguagem é mais útil do que uma certeza que as evidências não podem sustentar.

Próxima fase

Uma falha técnica verificada move-se para o proprietário de engenharia imediatamente, com o grupo afetado e condição de reteste anexados. Um problema diagnosticado de qualidade de página entra no fluxo de trabalho de atualização de conteúdo. Um incidente inconclusivo retorna à observação com uma data de revisão nomeada, em vez de entrar em um backlog indefinido.

A fase contínua de atualização e iteração contínuas precisa de quatro coisas deste runbook: o grupo afetado, a hipótese aceita ou rejeitada, o registro de ação e anotação, e a próxima data de medição. Ela usa essas saídas para priorizar o trabalho sem tratar cada flutuação de ranking como decadência.

FAQ

O responsável pelo incidente deve publicar as respostas do FAQ do frontmatter no componente FAQ da página e mantê-las alinhadas com as regras de decisão acima. O princípio orientador permanece o mesmo em cada resposta: verificar, segmentar, decidir, alterar um sistema delimitado e medir.

Responda com evidência, não com urgência

Abra o relatório Organic Rank , congele as datas de comparação e crie o primeiro briefing de incidente antes de alterar uma página. A resposta útil mais rápida é uma decisão que a equipe possa explicar depois.