Build verde, SEO quebrado: o que um deploy pode estragar sem que nenhum teste perceba

O deploy foi feito na sexta-feira. O build ficou verde, os testes passaram, o preview estava certo e o site funciona para todo mundo que o abre. Três semanas depois, alguém percebe que os cadastros vindos do Google caíram um terço.

A causa costuma ser pequena: uma linha num layout, uma configuração copiada do ambiente de staging, um redirecionamento feito às pressas. Nada que um visitante notaria, e nada que um build ou um teste verifica, porque nenhum deles olha a página como um buscador olha.

Este artigo lista as mudanças que mais vemos, como reconhecer cada uma e uma rotina curta para depois de cada deploy em produção.

Por que os testes não pegam #

Os testes conferem se a página funciona: o botão envia, o preço fecha, a página responde 200. Os buscadores leem outras coisas, principalmente o <head> e o HTML que o servidor envia antes de qualquer JavaScript rodar. Uma página pode funcionar perfeitamente para as pessoas e, mesmo assim, dizer ao Google para não indexá-la.

E o Google demora para mostrar. Uma página que sai do índice perde o tráfego ao longo de dias, e o Search Console só avisa alguns dias depois. A essa altura, a mudança já está enterrada sob outros deploys.

Oito mudanças que quebram a busca sem quebrar o site #

1. Um noindex que veio do staging #

A linha mais cara do SEO:

<meta name="robots" content="noindex">

Ela costuma chegar por uma configuração de staging que também roda em produção, por um componente que a adiciona quando falta uma variável de ambiente, ou por um template copiado de uma página privada. A mesma instrução também pode vir num cabeçalho HTTP, X-Robots-Tag: noindex, que nem aparece no código-fonte da página.

2. Um robots.txt que bloqueia mais do que devia #

Um Disallow: / pensado para o staging, ou uma regra nova que cobre mais caminhos do que o previsto. Dois detalhes deixam isso pior do que parece: uma página bloqueada no robots.txt não pode ser rastreada, então o Google nunca vê o conteúdo dela nem o noindex; e o Google não aceita noindex dentro do robots.txt, então essa linha não faz nada.

3. Uma canonical que aponta para outro lugar #

A tag canonical diz ao Google qual é o endereço principal. Depois de um deploy, ela pode passar a apontar para a página inicial em todas as páginas, para um endereço de preview como my-project-git-main-team.vercel.app, ou para http:// em vez de https://. O Google trata a canonical como um sinal forte, e uma canonical errada pode levar o seu posicionamento para um endereço que ninguém visita.

4. Conteúdo que só aparece depois que o JavaScript roda #

Uma refatoração tira a lista de produtos ou o texto do artigo do servidor e passa para o navegador: a página parece idêntica, mas o HTML que o servidor envia agora está quase vazio. O Google até executa JavaScript, mas depois e nem sempre por completo. Para tudo o que você quer que seja encontrado, o texto no HTML do servidor é a escolha segura.

5. Redirecionamentos e códigos de status #

Uma página que respondia 200 agora responde 404, ou redireciona para a página inicial, ou passa por três redirecionamentos até chegar. Uma mudança definitiva de endereço deve ser um único 301 ou 308, direto para o endereço final. Erros do tipo 5xx que duram dias fazem o Google rastrear menos e, com o tempo, tirar páginas do índice.

6. Um sitemap que perdeu páginas #

Uma rota nova ou uma mudança no CMS gera um sitemap sem algumas das URLs que trazem tráfego, ou com endereços que agora redirecionam. O sitemap não é fator de ranqueamento, mas é por ele que o Google descobre páginas rápido e que você vê os problemas de indexação de cada página no Search Console.

7. Títulos, descrições e cabeçalhos trocados por valores padrão #

Um layout compartilhado passa a substituir o título das páginas pelo nome do site, ou todas as páginas ficam com a mesma descrição. Numa página só, não é uma tragédia; nas 20 páginas que trazem a maior parte das suas visitas, o estrago é real.

8. Versões em outros idiomas que deixaram de apontar umas para as outras #

Num site em vários idiomas, os links hreflang dizem ao Google qual versão mostrar para quem. Eles precisam ser recíprocos: se a página em japonês aponta para a em inglês, a página em inglês tem que apontar de volta. Um deploy que muda as URLs de um idioma quebra o par, e o Google pode mostrar o idioma errado nos resultados de busca.

Como verificar uma página em dois minutos #

Para uma checagem pontual, você não precisa de ferramenta. No terminal:

# Status code, redirects and the X-Robots-Tag header
curl -sIL https://www.example.com/pricing | grep -iE "^HTTP|^location|x-robots-tag"

# robots meta tag and canonical in the server HTML
curl -sL https://www.example.com/pricing | grep -ioE '<meta[^>]+robots[^>]*>|<link[^>]+canonical[^>]*>'

# robots.txt as it is now
curl -s https://www.example.com/robots.txt

Para saber se o conteúdo principal está no HTML do servidor, abra a página com Ver código-fonte da página (não com o inspetor, que mostra a página depois do JavaScript) e procure uma frase do texto. No Search Console, a ferramenta Inspeção de URL mostra a página como o Google a buscou e renderizou, e se ela pode ser indexada.

Uma rotina para cada deploy em produção #

Conferir todas as páginas à mão não é viável, então confira as que importam:

1. Liste as suas páginas principais. No Search Console, abra Desempenho, ordene as páginas por cliques nos últimos três meses e pegue as 10 a 20 primeiras. Elas são a maior parte do seu tráfego de busca.
2. Depois de cada deploy, faça as verificações acima nessas páginas: status, noindex na tag e no cabeçalho, canonical, título e uma frase do texto no HTML do servidor.
3. Olhe o robots.txt e o sitemap sempre que as rotas, o CMS ou o framework mudarem.
4. Anote como é o “normal” de cada página (status 200, canonical para ela mesma, título), para que qualquer mudança salte aos olhos.
5. Acompanhe o Search Console na semana seguinte. O relatório Páginas e os cliques das suas páginas principais vão mostrar os problemas que escaparam.

Boa parte desta lista também faz parte de uma boa manutenção mensal do site. A diferença é o momento: uma verificação logo depois do deploy encontra o problema enquanto ele ainda é um commit a reverter, e não três semanas de visitas perdidas.

Criamos o Hawk Delta para fazer exatamente isso nos sites na Vercel que mantemos: depois de cada deploy em produção, ele compara as páginas importantes com a última versão boa e envia por e-mail o que quebrou, quanto tráfego de busca está em jogo e como corrigir. Ele está agora num beta privado gratuito.