Parece que, com problemas de renderização, a IA ainda não vai tirar nosso trabalho

Este tópico foi traduzido automaticamente do espanhol. Ver original
lasapaixa

lasapaixa

Beta
Usuário com poucas negociações! Use sempre o saldo do ForoBeta!
Desta vez venho contar para vocês sobre um e-commerce em WordPress, o caso de uma migração de design (troca de tema para o Impreza).

O site parecia perfeito, as fichas de produto carregavam bem e ninguém notava nada estranho. Mas a visibilidade no Sistrix caía pouco a pouco desde a migração, as impressões e os cliques desde que a migração foi lançada foram caindo para quase 10 por dia, e o que mais me deixava ansiosa era que o cliente me dizia que tinha passado a não converter NADA, que não recebia nem um formulário nem uma ligação por dia. Caramba, é que no fim você está mexendo com o ganha-pão das pessoas.

Da minha parte eu tinha feito tudo corretamente e seguindo o cronograma. quanto ao SEO, o mapa de redirecionamentos estava perfeito e revisado 40 vezes; por parte do desenvolvimento, embora seja verdade que tivemos vários momentos de descoordenação, tudo parecia correto

Passei semanas analisando isso com o Claude. Dei dados, capturas e tudo o que me vinha à cabeça, e fomos testando hipóteses uma atrás da outra. Nenhuma era a certa. Em nenhum momento ele me sugeriu algo tão básico como olhar a página com a ferramenta de inspeção de URL do Search Console. Eu, durante a migração, é claro que auditei a renderização: em massa no SF e uma ou outra URL avulsa na ferramenta de inspeção de URLs do GSC...

Já desesperada porque o cliente começou a me ligar desesperado até nos fins de semana, liguei para uma amiga, e no fim foi ela quem insistiu que aquilo era um problema sério de usabilidade e desempenho que estava penalizando o site, que não era normal o quanto a página aparecia lenta, com aquele CLS e FOIT, entre outras maravilhas. Eu sabia disso, mas claro, durante toda essa crise tinham apontado tanto para mim e, portanto, para o WPO e as CWV, que eu mesma não queria jogar a culpa no dev; eu atribuía mais ao SEO técnico. Minha amiga me disse que não, que eu fosse pedir explicações ao dev (que, além disso, coitado, é júnior)

Acendeu a lâmpada depois de semanas de névoa mental (em que, sendo sincera, depois de tanto bloqueio e nesse ritmo de trabalho e estresse tão vertiginoso, eu quase tinha depositado toda a minha confiança no Claude e não era capaz de pensar out of the box...), e tive a ideia de passar uma ficha pela inspeção de URL e lá estava: o texto das fichas existia no HTML, mas com opacity: 0. Para o Google a ficha estava em branco.

De 859 URLs indexáveis, 851 tinham o problema, e em 750 fichas 100% do texto ficava oculto. A causa era a combinação de duas coisas que separadamente não fazem nada de mal:

as animações de entrada do tema, que colocam o conteúdo em opacity: 0 até que um script o mostre a opção do LiteSpeed Cache de atrasar o JavaScript até que o usuário interaja O Googlebot não faz scroll nem mexe o mouse, então o script nunca era executado e o conteúdo nunca aparecia.

Resolvido, e em apenas 10 dias o Sistrix já mostra em seu índice de visibilidade uma alta de mais de 200% de subida na primeira semana. Os valores ainda são baixos e é cedo, mas a tendência mudou.

Fico com duas coisas. A primeira: se vocês usam LiteSpeed com Delay JS e um tema com animações, passem uma ficha pela inspeção de URL e olhem a captura, são dois minutos. A segunda: a IA ajuda muito, mas se você não fizer a pergunta adequada ela pode te deixar semanas dando voltas. Às vezes é preciso alguém que olhe o problema de fora.

Isso, na verdade, me lembrou uma frase que li no Linkedin não faz muito tempo: "você já percebeu que a IA é realmente, realmente boa em tudo, exceto naquilo que você sabe muito?"

Aproveitei para fazer um post e expliquei isso mais a fundo aqui, com como auditar o DOM e o que comparar entre o HTML inicial e o renderizado: https://aliciaruiz.es/dom-seo-renderizado/
 

Anexos

  • dom-caso-antes-gsc.webp
    dom-caso-antes-gsc.webp
    33,3 KB · Visitas: 17
  • dom-caso-despues-h1.webp
    dom-caso-despues-h1.webp
    29,6 KB · Visitas: 9
Última edição:
Foi útil? Participe da conversa

Com sua conta grátis você pode responder, mandar mensagem privada ao autor e comprar com Saldo retido: o pagamento é liberado quando você recebe o combinado.

Leva 30 segundos · você volta a este tópico ao terminar
É um caso muito ilustrativo de por que a IA, embora seja uma ferramenta poderosa de análise, não substitui a capacidade de diagnóstico técnico humano nem a experiência em campo. Muitas vezes, os problemas de renderização no WordPress após uma troca de tema passam despercebidos porque o navegador humano interpreta bem o CSS/JS, mas o bot do Google encontra bloqueios ou erros críticos que não se veem a olho nu.

O uso da ferramenta de inspeção de URL no Search Console é fundamental porque permite ver exatamente o que o Googlebot está renderizando. Se o problema era um bloqueio de recursos, um erro de execução de JavaScript ou um carregamento lento que o Google interpreta como falha, nenhuma IA conseguirá adivinhar isso se não receber os logs ou a captura da renderização real que o buscador vê.

No fim, esse tipo de situação demonstra que o SEO técnico continua exigindo uma validação manual rigorosa. A automação ajuda a processar dados, mas a intuição para verificar o "como o Google vê" continua sendo uma habilidade que faz a diferença nas migrações de sites.
 
Este caso me deixa uma lição que vale para qualquer trabalho de design: algo ficar bonito na sua tela não significa que exista para o Google. As animações de entrada ficam lindas, mas se o conteúdo começa em opacity: 0 e só aparece quando um script é executado ao interagir, para o rastreador essa página está em branco. E o pior é que o cliente não te diz "meu site está feio", ele te diz "não vendo nada", e a gente começa procurando o problema em qualquer lugar menos no óbvio.

O que mais me chamou a atenção é que a IA também não percebeu isso por semanas. Não é que a ferramenta seja ruim, é que se você pergunta sobre SEO técnico e redirecionamentos, ela responde sobre isso, não te diz "ei, confira a captura do Search Console". A inspeção de URL com a captura de tela leva dois minutos e ali dava para ver o problema bem claro: o texto estava no HTML, mas invisível. Desde que trabalho com vídeo penso igual: antes de entregar algo, é preciso ver como o outro vai ver, não como eu vejo no meu editor.

Para mim a regra fica assim: todo efeito que esconda conteúdo no início é suspeito até que se prove o contrário, e se for usado Delay JS, é preciso testar com a ferramenta de inspeção, não só abrindo o site no navegador. A correção aumentou a visibilidade em mais de 200% em dez dias, e isso diz tudo: o conteúdo sempre esteve ali, só que ninguém conseguia vê-lo.
 
Bom caso, e a lição vai além do LiteSpeed. Aconteceu comigo algo equivalente com um site montado em um construtor que serve tudo por JavaScript: no navegador aparecia perfeito, e na inspeção de URL o HTML chegava quase vazio. Até eu colocar prerender para bots, o Google indexava páginas em branco.
Desde então faço isto, e nesta ordem:
1. Ver o código-fonte cru e procurar o H1 e um parágrafo do texto. Se não estiverem ali, você depende da renderização.
2. Inspeção de URL em um template de cada tipo (home, categoria, página de produto), olhando a captura e a aba HTML, não uma única URL.
3. Repetir com o cache frio e quente, porque no preview costuma ir bem e em produção não.
O opacity: 0 é traiçoeiro justamente porque, se você rastreia com renderização, o texto continua no DOM e a ferramenta o conta como presente. A captura do Search Console é a única coisa que te entrega isso.
 
Voltar
Topo