SEO para JavaScript: garanta que os links sobrevivam à renderização
O Google renderiza JavaScript com um Chromium de versão recente. O problema raramente é a renderização em si. O problema são os links que nunca se tornam âncoras e as páginas que dependem de um estado que um rastreador não possui.
Equipe de pesquisa do ArchiLinks ·
O que um rastreador vê
O Googlebot usa um Chromium de versão recente desde maio de 2019. Isso resolveu a questão de saber se ele pode executar JavaScript moderno.
Os riscos práticos são os mesmos de sempre: a renderização ocorre após o rastreamento e pode ser atrasada, o conteúdo por trás de cliques ou logins nunca aparece e um link criado a partir de um manipulador onclick em uma div não é um link. Antes de verificar backlinks em páginas do site que você moveu recentemente para um front-end React, confirme se essas páginas exibem seu conteúdo na resposta bruta ou no HTML renderizado.
SSR, SSG, CSR: o que muda para os links
| Abordagem | Conteúdo na primeira resposta | Links internos como âncoras | Bom para |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Sim | Sim, se você usar âncoras reais | Páginas públicas com dados em mudança |
| SSG ou pré-renderização | Sim | Sim | Documentação, blogs, páginas de marketing |
| Aplicativo de página única CSR | Não, estrutura vazia | Apenas após a renderização | Painéis atrás de login |
| Híbrido (SSR na página inicial, CSR no app) | Por rota | Por rota | A maioria dos produtos com uma parte pública |
Teste um: HTML bruto versus HTML renderizado
Se os links principais aparecerem na primeira resposta, a questão está encerrada. Caso contrário, compare com uma renderização headless.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
De onde vêm os links externos
Um bug de renderização oculta seu conteúdo. Ele não apaga os links que outros sites já lhe deram.
Após uma migração para Next.js, Vite ou um CMS headless, execute toppages para o host e teste as 20 URLs mais linkadas quanto a status, canonical e conteúdo visível. Faça isso primeiro. Se uma página com 40 domínios linkando retornar uma estrutura vazia ou um 404 no lado do cliente, corrija isso antes de qualquer outra coisa, porque é aí que sua autoridade chega. A página de equity de links internos versus externos mostra como comparar essa lista com seus links internos, e a lista de verificação de migração coloca o teste dentro de um plano de lançamento.
Frameworks importam menos que disciplina. Express com uma engine de template, um tema WordPress e um app router Next.js podem todos servir links indexáveis. Cada um também pode falhar se uma equipe enviar âncoras que só existem após um clique.
Lista de verificação de links e renderização
- Navegação e paginação usam
<a href>, não manipuladores de clique em outros elementos. - Cada rota retorna um código de status real. Telas de soft 404 devem retornar 404.
- Um
noindexou canonical injetado pelo JavaScript corresponde ao da resposta do servidor. - Conteúdo de fallback na primeira resposta é a página real, não um spinner que o Google pode indexar.
- Código de autenticação não redireciona rastreadores em rotas públicas.
- Arquivos CSS e JS necessários para a renderização não estão bloqueados no robots.txt.
- Carregamento preguiçoso usa IntersectionObserver ou atributos nativos de carregamento, não eventos de scroll.
Lendo as evidências do Search Console
O Search Console responde à maioria das perguntas de renderização se você fizer a pergunta ao relatório certo. Use a Inspeção de URL, depois Visualizar página rastreada.
Compare três coisas: o HTML que o Google buscou, a captura de tela e os recursos da página que falharam ao carregar. Uma página que parece completa no seu navegador, mas vazia na captura de tela, geralmente é bloqueada por um erro de script ou um recurso não permitido, e a correção está na sua build, não no seu conteúdo.
Lembre-se do atraso. Uma alteração que você envia hoje aparece na ferramenta de inspeção apenas após o Google rastrear novamente a URL, o que pode levar dias.
Quando o SSR vale a pena
Páginas públicas que precisam rankear: sim. Painéis: não.
Se uma rota deve atrair tráfego orgânico, sirva o conteúdo na primeira resposta. Se ficar atrás de um login, pule a complexidade. Escolha por rota e não por projeto, e documente a decisão para que o próximo desenvolvedor não desfaça.
- Use o teste de Resultados Enriquecidos e a Inspeção de URL para comparar a saída renderizada.
- Teste com o teste ao vivo do Search Console após cada atualização de framework.
A renderização no servidor é necessária, ou a pré-renderização é suficiente?
A renderização no servidor é opcional. É uma maneira de fazer com que a primeira resposta carregue o que um rastreador precisa. Muitos sites públicos chegam lá com pré-renderização, uma build estática ou uma renderização no servidor para as páginas que importam, e deixam as partes logadas de lado.
Digamos que suas páginas de produto e documentação sejam públicas, enquanto o painel fica atrás de um login. Pré-renderize o primeiro grupo. Deixe o painel do lado do cliente. As páginas públicas então carregam seus links na primeira resposta, e o painel pode permanecer tão complexo quanto precisar ser.
Pré-renderizando apenas a página inicial
Pré-renderizar a página inicial resolve o primeiro rastreamento, mas deixa todas as outras rotas esperando pelo navegador. Se a página inicial linkar para páginas de categoria renderizadas no cliente, os links nessas páginas ainda dependem da renderização. Verifique cada modelo que você possui, não apenas a porta de entrada.
Mantenha uma lista curta de rotas públicas com seu método de renderização. A lista mostrará lacunas mais rapidamente do que um relatório de rastreamento.
A renderização no servidor altera a visibilidade local
A renderização no servidor pode alterar a rapidez com que o primeiro conteúdo aparece, e os leitores sentem isso. Não torna uma página relevante para uma consulta local por si só. Esses sinais vêm do conteúdo da página, dos detalhes do negócio e dos links que apontam para ela.
Trate a renderização como a maneira pela qual esses sinais se tornam legíveis para um rastreador, e meça os links separadamente com a API.
Apps Vite e React que servem uma única estrutura
Uma build Vite que serve uma única estrutura HTML para cada caminho coloca todo o trabalho no cliente. Tal app ainda pode rankear para algumas consultas, mas cada rota pública precisa de um plano: pré-renderizá-la, renderizá-la no servidor ou aceitar a perda e anotar isso.
Antes de verificar backlinks nas rotas do site após uma rebuild, decida como cada rota pública obtém seu conteúdo. Caso contrário, os dados de link mostrarão links externos chegando a páginas sem nada nelas.
Testando se uma rota mostra seus links
Dois testes respondem à maioria das perguntas. A resposta bruta mostra o que um rastreador obtém antes que qualquer script seja executado. O DOM renderizado mostra o que um navegador constrói depois. Um link que aparece apenas no segundo ainda é um link, mas depende da renderização funcionar bem.
Lendo o teste ao vivo no Search Console
Execute o teste ao vivo da Inspeção de URL em uma rota de cada vez. Olhe o HTML renderizado, depois a lista de recursos que falharam ao carregar. Um script bloqueado pode remover um bloco inteiro de navegação, e a página parece fina sem mostrar nenhum erro visível.
Repita o teste após uma atualização de framework, porque um novo padrão pode alterar se os links são renderizados antes ou depois que um script é executado. O guia páginas não indexadas cobre o que fazer quando uma página renderizada ainda fica de fora.
Quando uma rota é renderizada, mas o conteúdo é um spinner
O fallback na primeira resposta importa mais do que a maioria das equipes espera. Um spinner ou um contêiner vazio significa que a página não carrega texto para o rastreador naquele momento. Coloque o título, a introdução e os links principais na primeira resposta, mesmo que uma lista detalhada carregue depois.
Um fallback que é a página real pode permanecer simples. Seu único trabalho é manter o conteúdo até que o resto chegue.
Movendo um site client-side sem perder seus links
Liste as rotas com links externos
Execute toppages para o host e anote as 50 URLs principais. Teste essas rotas primeiro, antes das alterações de código, para saber o que a rebuild deve manter.
Compare a saída bruta e renderizada
Para cada rota, verifique o HTML bruto e o DOM renderizado na build antiga e na nova. Observe qualquer link que existe em um e não no outro.
Substitua manipuladores de clique por âncoras
Transforme a navegação em âncoras reais com um endereço adequado. Trabalho de velocidade pode esperar um sprint, enquanto uma âncora ausente custa à rota seu caminho para o site.
Repita o teste após o lançamento
Uma semana após o lançamento, execute o teste ao vivo nas mesmas rotas e compare os resultados com os anteriores. Diferenças mostram onde a rebuild alterou a saída.
Códigos de status e redirecionamentos em um app client-side
Um aplicativo de página única geralmente mostra uma tela de não encontrado enquanto o servidor retorna status 200. O Google pode tratar tal página como um soft 404, e os links externos apontando para a URL ausente então pouco fazem por você. A correção pertence ao servidor.
Rotas desconhecidas que ainda retornam 200
Retorne um 404 real do servidor para qualquer rota que não exista, e mantenha a tela de não encontrado no app para visitantes que chegam por uma rota client-side. Onde existe uma substituição, envie um 301 em vez disso.
Verifique alguns endereços inventados no host ao vivo após cada lançamento. O código de resposta é o que deve ser lido, não a página que você vê no navegador.
Redirecionamentos que são executados no navegador
Um redirecionamento que é acionado após o carregamento da página, por exemplo, lendo um parâmetro de URL dentro de um componente, é uma coisa diferente de um redirecionamento de servidor. Um rastreador pode indexar a primeira resposta antes que o redirecionamento seja executado. Onde uma rota mudou permanentemente, retorne um 301 do servidor e mantenha os parâmetros que alteram o conteúdo. A receita de mapa de redirecionamento mostra como testar essas regras.
