O conteúdo importante não deve depender de um clique, uma rolagem específica ou uma conexão a ser descoberta. Verifique o que a resposta inicial contém e o que aparece após a renderização. A escolha técnica deve atender tanto aos visitantes, manutenção quanto ao acesso ao motor.
Distinguir HTML inicial e página renderizada
O código recebido pelo navegador pode conter apenas um esqueleto e, em seguida, preenchido por JavaScript. O Google descreve um tratamento, incluindo exploração, renderização e indexação. O fato de um mecanismo poder executar o JavaScript não garante que todas as dependências ou interações funcionem. Portanto, compare a resposta inicial com o conteúdo renderizado nas páginas que trazem suas ofertas e suas respostas editoriais.
Teste as condições ordinárias
Abra uma página em uma sessão pública, com uma rede lenta e controle o que permanece disponível se um recurso falhar. O título, o texto decisivo e os links para páginas úteis estão presentes? Os erros da API não devem transformar um arquivo existente em uma página vazia. Verifique também se os estados de carregamento não permanecem exibidos indefinidamente.
Uma teste de aceitação em três estados na mesma página
Teste a página de seu URL direto e, em seguida, após a navegação interna e, em seguida, com uma dependência indisponível em seu ambiente de teste de aceitação. Você está procurando saber o que o visitante pode ler e fazer em cada estado. A capacidade de fazer JavaScript não dispensa erros de veiculação, links e conteúdo consistente. Os pontos de verificação a seguir se aplicam a um guia e a uma folha de produto.
| Elemento | Pergunta no HTML inicial | Pergunta após a renderização |
|---|---|---|
| Título e texto decisivo | O assunto e a resposta estão presentes? | O texto é completo e sempre consistente? |
| Links entre as páginas | Os destinos reais podem ser extraídos? | A navegação produz bons URLs? |
| Dados do produto | Os valores correspondem ao produto solicitado? | Uma interação muda a variante corretamente? |
| Erro ou falta de recursos | O status e a mensagem são apropriados? | Um erro de carregamento pode ser entendido? |
| Metadados | A página carrega sua própria identidade? | Uma atualização do lado do cliente cria uma contradição? |
Os Princípios de SEO JavaScript documentados pelo Google Distinguir entre exploração, renderização e indexação. Sua teste de aceitação deve manter essas etapas separadas. Um texto visível em seu navegador é uma descoberta de renderização nessas condições, não prova de que todas as experiências de pesquisa podem explorá-lo ou irão explorá-lo.
Torne a navegação explícita
Use links HTML com um destino real para rotas entre páginas. Um botão que altera apenas o status de um aplicativo nem sempre substitui um URL compartilhável. Para um catálogo, cada produto importante deve ser aberto diretamente. Verifique os redirecionamentos e os status retornados durante o acesso direto, não apenas ao navegar em casa.
Exemplo fictício: características em uma guia
Uma folha carrega suas dimensões somente após abrir uma guia. A equipe coloca as informações decisivas na página disponível publicamente e, em seguida, usa a guia para organizar a leitura. Ele controla o resultado no celular e na inspeção da página. O objetivo não é proibir o JavaScript, mas impedir que ações frágeis condicionem o acesso às características necessárias à decisão.
Decida o que disponibilizar sem interação
Para um artigo, a resposta principal e os links úteis geralmente podem vir com a página. Para um catálogo, a interface pode permanecer interativa, fornecendo um URL direto que identifica o produto e suas informações essenciais. As funções secundárias, como uma ferramenta de personalização, exigem uma análise limpa: torná-las interativas não significa que o restante do cartão esteja vazio no início.
- Escolha um modelo de representação e pegue seu conteúdo público. Faça uma comparação legível entre o código recebido e o conteúdo final, com a data e as condições de teste.
- Inspecione links importantes. Um link HTML com href e destino real é mais diretamente utilizável do que uma ação que altera apenas um estado interno sem url.
- No ambiente de teste, faça com que um recurso necessário falhe. Verifique a mensagem, a capacidade de tentar novamente e o que permanece acessível. Não cause voluntariamente uma quebra na produção desta demonstração.
- Primeiro corrija o defeito observado neste modelo e, em seguida, verifique as outras páginas que o utilizam. Também meça o efeito na velocidade e na manutenção antes de generalizar uma nova arquitetura.
Documento do Google em Links exploráveis Fornece exemplos de links interpretáveis. Para um projeto de recuperação, esta teste de aceitação pode ser integrada às especificações: esperamos uma resposta verificável, um estado de erro e um erro, não apenas de uma captura de tela bem-sucedida. O diagnóstico de Bloqueios de CDN Permanece adicional se o conteúdo não chegar ao navegador ou ao robô.
Escolha uma correção proporcional
Uma renderização ou geração de página do lado do servidor pode ser relevante, mas a migração total nem sempre é necessária. Comece com um template representativo, meça o acesso, o desempenho e a atualização fácil. Em seguida, verifique metadados e links em ambas as versões. Os Reduction of unnecessary javascript Pode concluir este trabalho sem confundir velocidade e indexabilidade.