Registro de alterações do site: como anotar mudanças e achar o que mexeu no tráfego

O que é um registro de alterações do site e como ele difere do changelog dos devs?

O registro de alterações do site é um histórico feito para o marketing: tudo o que mudou no site, escrito para que qualquer pessoa olhando um gráfico de tráfego ou conversão consiga ligar uma data a uma causa. Não é o histórico do Git nem o changelog do produto.

O changelog dos desenvolvedores lista commits e versões. Quase nunca diz que aquele deploy também trocou o H1 de 40 páginas de categoria, tirou um campo do formulário ou mudou o banner de cookies de lugar. São justamente esses detalhes que explicam uma queda de cliques orgânicos ou de leads, e é isso que o registro do site guarda.

Pense nele como uma faixa de um registro de alterações de marketing mais amplo: o site, ao lado das contas de mídia, do tracking e do CRM. O site costuma ser a causa comum de mudanças que aparecem em vários canais ao mesmo tempo, porque tráfego pago, orgânico e de e-mail cai nas mesmas páginas.

O que um registro de alterações do site deve incluir?

Anote qualquer mudança que possa alterar como as páginas são rastreadas, ranqueadas, carregadas ou como o visitante converte. Na dúvida, registre: uma entrada leva um minuto, uma que falta pode custar dias de análise.

Registre também o que você não fez, mas que afeta o site: atualização automática de plugin, queda da hospedagem, atualização de ranking do Google. Esses eventos concorrem com as suas mudanças como explicação, então ficam na mesma linha do tempo.

Como montar um registro de alterações do site?

Use sempre os mesmos campos, uma entrada por mudança, e faça do registro uma etapa do deploy, não um exercício de memória depois.

1. Data e hora em que entrou no ar. Não a data em que o ticket foi fechado. Anote o fuso, porque analytics e servidor costumam usar fusos diferentes.
2. Escopo. Quais URLs, templates, seções ou países foram afetados (por exemplo, "todas as páginas /blog/" ou "checkout, só mobile").
3. O que mudou, antes → depois. "Padrão de title: Produto | Marca → Compre Produto online | Marca" ajuda. "Ajustes de SEO" não ajuda.
4. Tag de tipo. Deploy, conteúdo, redirecionamento, técnico, tracking, oferta. As tags permitem filtrar depois.
5. Responsável. A pessoa ou agência que fez a mudança, para saber a quem perguntar.
6. Motivo e efeito esperado. Uma linha: o que você esperava e em qual métrica.
7. Link. Ticket, pull request, versão do GTM ou print.

Uma planilha compartilhada resolve no começo; o nosso modelo de registro de alterações de marketing já traz as colunas. A regra que importa mais que a ferramenta: quem publica, registra. Coloque um item "registrado?" no checklist de deploy para que a entrada seja escrita no mesmo dia, não reconstruída um mês depois.

Dá para usar as anotações do GA4 ou do Search Console no lugar?

As duas ferramentas permitem marcar datas nos gráficos, o que ajuda quem vive nesses relatórios. Nenhuma substitui um registro completo, por causa dos limites de tamanho e de retenção.

No Search Console não dá para editar uma anotação depois de criada, e o Google recomenda não incluir dados pessoais, como nomes. O GA4 também cria anotações do sistema quando há um evento que afeta os dados. Use essas marcações como ponteiros ("Template de checkout v3 no ar, ver registro") e mantenha detalhe, responsável e antes/depois no seu registro. O nosso guia de anotações do GA4 mostra a configuração com mais calma.

Como usar o registro para descobrir o que causou uma mudança no tráfego ou nas conversões?

Parta da data em que a métrica mudou e coloque numa única linha do tempo todas as mudanças dos dias anteriores, de todas as fontes. Depois descarte o tracking, confira causas externas e teste uma hipótese por vez.

1. Marque a data. Ache o primeiro dia fora do normal e veja se a mudança é no site todo ou só em algumas páginas, dispositivos, países ou canais.
2. Liste tudo dos 7 a 14 dias anteriores. Entradas do site, publicações de tags e GTM, edições nas contas de mídia, mudanças no CRM ou em formulários. Um deploy e uma troca de estratégia de lances na mesma semana são suspeitos até um deles ser descartado.
3. Descarte o tracking primeiro. Se as conversões reportadas caíram mas os pedidos ou leads no CRM não, o problema está na medição, muitas vezes uma tag, formulário ou consentimento. Veja o post sobre histórico de versões do GTM para datar mudanças de tags.
4. Confira causas externas. O guia do Google sobre quedas de tráfego da Pesquisa lista atualizações de algoritmo, problemas técnicos, de segurança, de spam, mudanças no interesse de busca e migrações de site. Compare com os últimos 16 meses no relatório de performance para ver padrões sazonais.
5. Cruze escopo com escopo. Uma queda só nas páginas /blog/ aponta para uma mudança que mexeu em /blog/. Uma mudança no checkout não explica menos impressões orgânicas.
6. Teste uma hipótese. Reverta ou ajuste uma mudança, ou compare grupos de páginas afetadas e não afetadas, e acompanhe a métrica por um período justo.

Conte com atraso: o Google diz que, numa migração com troca de URLs, um site médio pode levar algumas semanas para que a maioria das páginas seja transferida, e a visibilidade pode oscilar nesse meio-tempo. Para diagnóstico só do orgânico, veja por que meu tráfego orgânico caiu.

Com deploys do site, publicações no GTM e edições nas contas de mídia numa única linha do tempo, uma queda só nas páginas de produto aparece logo ao lado do deploy do template que mexeu nelas. Crie um registro de mudanças grátis no Changeline e mantenha site e mídia no mesmo lugar.

Exemplo: ligando uma queda a um deploy de template

Exemplo ilustrativo, não é um cliente real. Um e-commerce vê as sessões orgânicas das páginas de produto caírem cerca de 20% de uma semana para outra, enquanto o blog fica estável.

• Linha do tempo dos 14 dias anteriores: deploy do novo template de produto (terça), publicação no GTM com um evento novo (quarta), aumento de orçamento no Google Ads (quinta).
• Checagem de tracking: os cliques no Search Console também caíram, não só as sessões no GA4, então não é tag. A publicação no GTM sai da lista.
• Checagem de escopo: só as páginas de produto caíram, justamente as do template. O orçamento do Google Ads não reduz clique orgânico.
• Detalhe do registro: a entrada de antes/depois mostra que o deploy trocou o bloco de descrição por uma aba que só carrega no clique.
• Teste: o time volta a descrição para o HTML inicial em metade das categorias e compara os dois grupos nas semanas seguintes.

Sem o registro, o time começaria por um chute, provavelmente a mudança mais recente ou mais visível.

Como manter mudanças do site e da mídia na mesma linha do tempo?

Junte tudo num lugar só, porque a pergunta raramente é "o que mudou no site"; é "o que mudou em qualquer lugar antes dessa métrica se mexer".

No Changeline você registra mudanças de site, tracking e CRM por projeto, com data, responsável, tags e motivo, e as alterações do Google Ads podem ser importadas automaticamente por uma conexão só de leitura, com valores de antes → depois. Integrações com o site e outras ferramentas ainda não estão disponíveis, então as mudanças do site são registradas pelo time. Os registros ficam guardados enquanto o projeto existir, o que facilita ver o que mudou nas mesmas semanas do ano passado.

Seja qual for a ferramenta, revise o registro no relatório mensal: liste as mudanças do site no período ao lado das métricas que elas deveriam mover e anote quais funcionaram.