Redesenhar o site sem perder o Google: o guia de migração que ninguém lê a tempo

O padrão é deprimentemente consistente. Uma empresa investe meses num site novo e bonito, lança-o com algum orgulho, e seis semanas depois o tráfego orgânico está quarenta por cento abaixo. Ninguém avisou, porque quem construiu o site eram designers e programadores, e ninguém fez a pergunta que interessa: o que acontece às moradas que o Google já conhece?

Este artigo é a lista de verificações que usamos em migrações, com a plataforma Semalt a registar o estado anterior e a diagnosticar o posterior. Aplica-se a redesenhos, mudanças de plataforma, mudanças de domínio e — o caso de que toda a gente se esquece — grandes reestruturações da navegação de um site existente.

O que se parte de facto

A perda de tráfego depois de uma migração remete quase sempre para uma lista curta de causas. Conhecer a lista permite verificar cada uma especificamente em vez de procurar às escuras.

A quarta linha faz jus à sua reputação. Uma etiqueta noindex deixada do ambiente de testes é a falha de migração mais destrutiva e mais facilmente evitável — e acontece regularmente a equipas competentes, porque a etiqueta é invisível para todos os que revêem o site visualmente.

Parâmetros de trabalho do processo descrito a seguir.

Antes: registar a linha de base

Tudo o que torna uma migração diagnosticável acontece antes do lançamento. Duas semanas antes é confortável; na véspera não é.

1. Um crawl completo do site atual

   Todos os URL, código de estado, título e posição na estrutura. É este o mapa a partir do qual se redireciona — sem ele, está a reconstruir o site antigo de memória.

2. As páginas que realmente contam, ordenadas

   Por tráfego e por conversões. Na maioria dos sites, uma pequena fração dos URL produz quase todo o valor, e são esses cujos redirecionamentos têm de ser verificados um a um e não por regra.

3. Uma fotografia de posições e visibilidade

   Posições do conjunto acompanhado numa data fixa, para que "perdemos posições" passe a ser uma afirmação mensurável e não uma impressão.

4. O inventário de ligações externas

   Que páginas externas apontam para que URL seus. Qualquer URL com ligações externas tem de redirecionar para um equivalente verdadeiro, não para a página inicial, ou o valor dessas ligações é deitado fora.

Construir o mapa de redirecionamentos

O mapa de redirecionamentos é a migração. Tudo o resto é decoração.

Comece pela lista completa de URL, ordenada por valor. Para as páginas de topo — normalmente algumas dezenas — decida cada destino à mão e verifique-o individualmente depois do lançamento. Para a cauda longa, os padrões servem: caminhos de categoria, estruturas antigas de blog, formatos de parâmetros. O erro é tratar o site inteiro como um problema de padrões, porque as exceções estão sempre entre as páginas que mais valem.

Três verificações antes de lançar: nenhum redirecionamento aponta para um URL que por sua vez redireciona, nenhum aponta para um 404, e todos os URL com ligações externas têm destino verdadeiro. Demoram uma tarde e evitam a maior parte da perda evitável.

Dia do lançamento: a hora que conta

1. Verificar noindex imediatamente

   Primeira ação depois do deploy, antes de tudo o resto. Ver o código-fonte da página inicial, de uma categoria e de uma página profunda. Se uma etiqueta de staging sobreviveu, custa minutos agora e meses depois.

2. Confirmar o robots.txt

   Ficheiros robots de testes que bloqueiam tudo são o segundo acidente de lançamento mais comum. Confirme que o ficheiro de produção é mesmo o de produção.

3. Testar à mão os vinte principais redirecionamentos

   Não por regra — à mão, no browser. São as páginas que carregam o tráfego, e os redirecionamentos por regra têm exceções precisamente onde as exceções custam mais.

4. Submeter o novo sitemap e lançar um crawl

   Quer que a descoberta aconteça depressa e quer o seu próprio crawl a correr, para que a comparação do dia seguinte mostre o que mudou.

5. Confirmar que a analítica continua a disparar

   Uma migração que parte a medição deixa-o cego exatamente nas duas semanas em que mais precisa de ver.

As primeiras três semanas

Conte com movimento. Uma reestruturação a sério muda ligações internas, profundidade de URL e às vezes o conteúdo, e os motores levam tempo a reavaliar. Uma queda na primeira quinzena é normal e não é, por si só, prova de erro.

O que interessa é a forma. Recuperação a começar em duas ou três semanas significa que a migração correu bem e o sistema está a assentar. Um declínio que ainda se está a agravar na quarta semana significa que alguma coisa está partida e a passar despercebida.

Analisamos isto em detalhe em Quatro horas por semana.

O último item da direita é o diagnóstico mais útil da lista. Quando todas as páginas de um template caem enquanto os outros se aguentam, a causa está nesse template — um elemento em falta, uma estrutura de cabeçalhos alterada, um erro de canonical — e reduziu a procura do site inteiro a um ficheiro.

Meter as verificações num projeto que não controla

A realidade incómoda da maioria das migrações é que o SEO não está na sala quando se decide. A agência de design é dona do aspeto, a equipa de desenvolvimento é dona da construção, e a pesquisa é consultada no fim — ou depois do estrago. Conhecimento técnico não ajuda se chegar na semana onze de um projeto de doze.

O que funciona é tornar os requisitos poucos, específicos e antecipados. Uma lista de quarenta recomendações enviada à equipa de desenvolvimento quinze dias antes do lançamento é lida como obstrução e discretamente despriorizada. Quatro itens, formulados como critérios de aceitação, entram no plano:

• Todos os URL existentes mantêm a morada ou redirecionam, num salto, para o equivalente mais próximo.
• Produção vai para o ar sem noindex e com o robots.txt de produção — verificado após o deploy, não assumido.
• O conteúdo das páginas é transposto, não resumido. Se o design obriga a cortar texto, o corte é uma decisão de conteúdo tomada de propósito e não um efeito secundário do template.
• A exportação do crawl pré-lançamento é guardada e entregue.

Este último ponto sobre conteúdo merece ênfase, porque é onde SEO e design entram em conflito real e não apenas em desencontro. Os redesenhos reduzem quase sempre o texto — páginas mais limpas ficam melhor num portefólio. Às vezes isso está certo e a página antiga estava mesmo inchada. Outras vezes, o bloco de perguntas frequentes que foi removido era a razão pela qual a página se posicionava. A forma de resolver é nomear que secções são estruturais antes de o design ser aprovado, para que a conversa aconteça sobre um wireframe e não sobre um relatório de tráfego.

Mudança de domínio: o caso de maior risco

Mudar o próprio domínio acrescenta risco que um redesign não tem, porque todos os sinais acumulados pelo domínio antigo têm de ser transferidos em vez de preservados.

Duas regras tornam a operação sobrevivível. Mude uma coisa de cada vez — domínio agora, redesign depois, ou o inverso — porque quando ambos mudam ao mesmo tempo e o tráfego cai, não é possível saber qual deles foi. E mantenha os redirecionamentos do domínio antigo ativos indefinidamente, ou no mínimo durante anos e não meses. Redirecionamentos desligados ao fim de seis meses deitam fora as ligações que estavam a preservar, e a perda chega muito depois de alguém a associar à decisão.

Ver também: SEO B2B com ciclos de venda longos.

Quando já correu mal

Se está a ler isto depois de um lançamento que perdeu tráfego, trabalhe por esta ordem em vez de por instinto.

Primeiro, confirme que o site é sequer indexável — noindex, robots.txt e se as páginas importantes devolvem 200. Demora cinco minutos e resolve à partida uma fatia surpreendente dos casos.

Segundo, faça um crawl e compare com o registo que existir do site antigo. Cada URL antigo que agora devolve 404 ou redireciona para a página inicial é uma perda concreta e corrigível. Terceiro, verifique se foi cortado conteúdo: os redesenhos perdem rotineiramente parágrafos, perguntas frequentes e texto de apoio de que as páginas precisavam para se posicionar — e o resultado visual parece mais limpo enquanto rende menos.

Há um guia completo sobre o tema em O blog que já não rende.

Só depois destes três é que se deve falar de algoritmos ou concorrentes. Na nossa experiência, a causa está nessa lista em bem mais de noventa por cento dos casos.

A versão curta

As migrações falham por razões aborrecidas e evitáveis, e evitam-se com trabalho aborrecido feito antes do lançamento: um crawl completo, uma lista de páginas ordenada por valor, um mapa de redirecionamentos verificado à mão para as que contam, e noventa segundos de verificação de indexação no dia.

As decisões de design que toda a gente discute durante meses raramente determinam o resultado. O mapa de redirecionamentos determina.

Se há um redesign a caminho e ainda não foi registada nenhuma linha de base, é isso que tem de resolver primeiro. Abra o painel, corra um crawl completo do site atual e exporte-o antes de alguém mexer em produção.