71% dos times dizem que conversão é o KPI mais importante do site. Só 12% usam teste A/B.
Esse dado vem do State of Sites '26, um relatório que a Framer publicou com 1.910 profissionais que constroem e mantêm sites corporativos: designers, marketers, devs frontend, founders e agências.
O relatório tem vários números, mas o que me prendeu foi a desconexão entre o que as equipes medem e o que conseguem influenciar. 61% acompanham tráfego como métrica-chave. 56% dizem que SEO ranking importa. Mas só 12% fazem teste A/B e pouquíssimos analisam como as pessoas realmente navegam no site. A maioria está olhando para dashboards sem ter alavanca pra mover os números.
Outro dado que confirma o que eu vejo em projetos de clientes: 53% do trabalho em sites é edição e correção do que já existe. Não é construção nova. Homepage updates, blog, landing pages. O trabalho pesado é manutenção, não lançamento.
E talvez o mais revelador: 30% dos redesigns acontecem porque a marca "parecia desatualizada". Só 5% são motivados por problemas de conversão. Ou seja, o gatilho pra refazer um site é estético, não de performance. Enquanto isso, 70% dos projetos de site são depriorizados porque são lentos ou difíceis demais de executar.
A pergunta que fica: estamos medindo as coisas certas e não temos ferramenta pra agir, ou estamos medindo por hábito sem intenção de otimizar? Gastar meses num redesign motivado por estética, enquanto ninguém roda um teste A/B na página de pricing, é uma alocação estranha de recurso.
O relatório é da Framer, então naturalmente aponta pra ferramentas que reduzem o ciclo de publicação. Mas os dados em si são úteis independente de qual stack você usa.
Conversão no dashboard sem dono da intervenção
Conversão é um resultado. Ela mistura oferta, mix de tráfego, ciclo comercial, formulário e o que acontece depois do clique. Um número sozinho no GA4 ou no Looker não diz qual dessas partes a equipe consegue mexer nesta quinzena.
O padrão do relatório é familiar. Conversão entra no slide de resultados. Tráfego entra no relatório semanal. Ranking de SEO entra na pauta de conteúdo. Quase ninguém chega na reunião com uma hipótese que cabe em uma página. Sem hipótese, o KPI vira observação. Observação não disputa calendário com um pedido de redesign.
A pergunta operacional é concreta. Se a taxa cair dois pontos, quem altera o quê até sexta? Se a resposta for "vamos estudar", o indicador não tem dono de intervenção. Vale o mesmo para tráfego e SEO. Os dois também aparecem no dashboard, e os dois também dependem de páginas que alguém precisa publicar.
Poucas equipes olham o caminho real do visitante. Sem evento de clique no CTA, sem etapa do formulário, sem distinção entre visita de marca e visita de campanha, o painel mostra um total. O total esconde se o problema está no hero, na tabela de preço, no campo de telefone ou no tempo de resposta comercial.
Eu separaria as métricas em duas colunas. Na primeira, o que o time consegue alterar com um publish: texto do botão, ordem dos campos, prova social na página de planos, redirect depois do form. Na segunda, o que só se observa neste trimestre: mix de canais, sazonalidade, ciclo do time de vendas. Conversão pode existir nas duas colunas. Só a primeira justifica um teste.
Se ninguém tem autoridade para publicar uma variante, o software de experimento só gera um ticket. O gap que o relatório descreve começa em dono, evento e permissão de publish.
Manutenção e redesign competem pelo mesmo orçamento
53% do trabalho em sites é edição e correção. Homepage, blog, landing. Isso já consome calendário. Um redesign estético entra no mesmo caixa e nas mesmas pessoas. Quando o gatilho é "a marca parece desatualizada", o projeto grande ganha status. A fila de correções perde.
30% dos redesigns começam por estética. 5% por conversão. 70% dos projetos de site perdem prioridade porque executar é lento ou difícil. O redesenho promete um site novo. A manutenção promete páginas que continuam corretas. As duas disputam design, frontend e aprovação. Só uma delas costuma ter sponsor no comitê.
Separar envelopes ajuda. Um envelope cobre o site no ar: conteúdo, acessibilidade, formulários quebrados, SEO técnico, páginas de campanha com prazo. Outro cobre aprendizado: hipóteses com critério de sucesso e de abortar. Um terceiro, se existir, cobre redesign estrutural. Misturar os três no mesmo épico produz o padrão do relatório: o visual novo atrasa, a manutenção empilha, o teste nunca começa.
Redesign ainda faz sentido quando a arquitetura de informação, o CMS ou os caminhos de conversão estão quebrados em vários tipos de página. Pintar de novo um formulário que perde o lead no CRM não corrige o KPI. Trocar slug sem redirect também não.
O custo escondido do redesign é o tempo em que ninguém publica outra coisa. Se o ciclo de um site institucional já é mensal, um projeto de um trimestre elimina a chance de testar copy, ordem de blocos ou um campo a menos no form. Nesse intervalo a conversão continua no dashboard, sem alavanca.
Eu pediria, antes de aprovar o brief estético, o preço em sprints de manutenção e o preço em hipóteses abandonadas. Se esses números não cabem no slide, o redesign está sendo comprado com um orçamento que ninguém nomeou.
Fila curta de experimentos no site institucional
Um site de marketing raramente tem o volume de um produto com login diário. Muitas páginas não atingem amostra para um A/B clássico em duas semanas. Isso não impede uma fila. Impede uma fila longa.
Eu manteria no máximo três itens, visíveis para marketing, design e quem publica:
- a hipótese em uma frase, por exemplo "o CTA acima do preço aumenta o envio do form na página de planos";
- o que muda, em uma página, com o restante do site estável;
- o evento que conta sucesso, já existente no analytics;
- a janela e o critério de parar (tempo, visitas, ou conflito com campanha);
- quem publica e quem lê o resultado.
O primeiro item deveria caber no fluxo de edição que o time já usa. Trocar copy, ordem de blocos, um campo opcional, o destino do botão. Se o experimento exige um projeto de frontend de três sprints, ele voltou a ser o tipo de trabalho que o relatório diz que perde prioridade.
Campanhas pagas atrapalham a leitura. Uma landing com criativo novo toda semana não é controle. Melhor testar a página perene (planos, contato, produto) e deixar a mídia fora, ou aceitar que o resultado só descreve aquele período de tráfego pago.
Heatmap e session replay ajudam a formar hipótese. Sem o evento de conversão, o time discute palpite sobre scroll. Sem volume, um empate depois de dez dias ainda é ruído. A fila precisa de um ritual de morte: hipótese que não atingiu amostra no prazo combinado sai; hipótese que perdeu para o controle sai; hipótese que só existe como slide sai. Sem isso a lista vira backlog de ideias e o site volta a só medir.
Também vale recusar o teste que mistura cinco mudanças. Se a taxa subir, ninguém sabe o que repetir. Se cair, o próximo passo é outro pacote opaco. Um site institucional aprende mais com uma alteração por vez do que com um "pacote de otimização" trimestral.
Eventos que sobrevivem ao próximo editor
O gargalo que o relatório descreve é execução. Times querem menos etapas entre a ideia e a página no ar. Isso é verdadeiro e incompleto se o evento de conversão mora num dataLayer que o próximo editor apaga.
Antes de abrir a fila, um inventário curto evita o falso começo: quais eventos o CRM realmente usa, quais páginas têm volume, quais mudanças o CMS ou o fluxo de publish permitem sem um deploy de engenharia. Sem isso, o primeiro "teste" vira um projeto de instrumentação disfarçado, e instrumentação disfarçada compete com a manutenção do item anterior.
A instrumentação mínima para um site institucional costuma ser pequena. Visualização da página, clique no CTA principal, início e envio do formulário, e um identificador de variante se houver teste. Quatro ou cinco eventos, com nome estável, documentados junto do componente ou do bloco. O editor pode trocar o texto do botão. Não deveria trocar o nome do evento nem o destino do form.
Se a equipe não consegue garantir esses eventos, o KPI de conversão continua sendo um número de plateia: dá para reportar e não dá para atribuir a uma alteração. O próximo investimento, então, é tornar o caminho mensurável no mesmo fluxo em que o conteúdo já é editado.
