Um dos problemas clássicos em SEO é que, enquanto esquemas de navegação complexos podem ser úteis para os usuários, esses esquemas também criam problemas para os motores de busca. Muitos editores contam com tags como rel=canonical, ou as definições de parâmetros nas ferramentas para webmasters, para tentar resolver esses tipos de problemas. No entanto, cada uma das soluções potenciais tem suas limitações. No artigo de hoje, vou delinear como você pode usar soluções em JavaScript para eliminar o problema completamente.

Note que não vou fornecer exemplos de código neste texto, mas vou delinear a forma como qualquer script deve funcionar em um nível conceitual. Se você estiver interessado em aprender mais sobre Ajax/JSON/jQuery, aqui estão alguns recursos que você pode conferir:

1. Tutorial Ajax
2. Aprenda Ajax/jQuery

Definindo o problema com a navegação facetada

Ter uma página de produtos e, em seguida, permitir que os usuários classifiquem esses produtos da maneira que quiserem (ordenados do maior para o menor preço), ou usando um filtro para escolher um subconjunto de produtos (apenas aqueles que custam mais de R$50,00, por exemplo) faz muito sentido para os usuários. Nós normalmente nos referimos a esse tipos de opções de navegação como “navegação facetada”.

No entanto, a navegação facetada pode causar problemas para os motores de busca, porque eles não podem rastrear e indexar todas as ordens de classificação diferentes ou todas as diferentes versões filtradas ou facetadas de suas páginas. O motor de busca iria acabar com muitas versões diferentes de suas páginas e que não são significativamente diferentes de uma experiência de usuário sob a perspectiva do motor de busca.

Soluções como a marcação rel=canonical e configurações de parâmetros das ferramentas para webmasters têm algumas limitações. Por exemplo, rel=canonical é considerado uma “dica” para os motores de busca, e eles não podem escolher se devem ou não aceitá-los, e mesmo se forem aceitos, os motores de busca não necessariamente continuarão rastreando essas páginas.

Uma solução melhor seria usar JSON e jQuery para implementar sua navegação facetada para que uma nova página não seja criada quando um usuário escolher um filtro ou uma ordem de classificação. Vamos dar uma olhada em como isso funciona.

Usando JSON e jQuery para filtrar os dados no lado do cliente

O principal benefício da implementação discutida a seguir é que uma nova URL não é criada quando um usuário está em uma página do site e aplica um filtro ou ordem de classificação. Quando você usa JSON e jQuery, todo o processo acontece no dispositivo do cliente sem envolver o servidor web.

Quando um usuário solicita inicialmente uma das páginas de produtos em seu site, a interação se parece com isto:

Isso transfere a página para o navegador do usuário utilizado para solicitar a página. Agora, quando um usuário escolhe uma ordem de classificação (ou filtro) nessa página, eis o que acontece:

Quando o usuário escolhe uma dessas opções, um pedido jQuery é feito para o objeto de dados JSON. Traduzindo: toda a interação acontece no navegador do cliente, e o tipo de filtro é aplicado somente lá. Simplificando, a inteligência utilizada para lidar com essa classificação ou filtro reside inteiramente dentro do código no dispositivo cliente que foi transferido com o pedido inicial para a página.

Como resultado, não há nenhuma nova página criada e nenhuma URL nova para o Google ou o Bing indexar. Quaisquer preocupações sobre o orçamento de rastreamento ou uso ineficiente do PageRank são completamente eliminados. Isso é uma coisa incrível! No entanto, continuam existindo limitações à aplicação dessas medidas.

Especificamente, se a sua lista de produtos abrange várias páginas em seu site, a classificação e a filtragem só serão aplicadas ao conjunto de dados já transferidos para o navegador do usuário com o pedido inicial. Em suma, você só pode fazer uma triagem na primeira página de produtos, e não em todo o conjunto de produtos. É possível que o objeto de dados JSON inicial contenha o conjunto completo de páginas, mas isso pode não ser uma boa ideia se o tamanho da página for grande. Nesse caso, teremos de fazer um pouco mais.

O que o Ajax faz por você

Agora vamos cavar um pouco mais fundo e delinear como o Ajax nos permitirá manipular a classificação, a filtragem e a paginação. Aviso: há alguma conversa tecnológica nesta seção, mas vou tentar seguir cada explanação técnica em conjunto com a explicação para um leigo sobre o que está acontecendo.

A implementação conceitual do Ajax se parece com isto:

Nessa estrutura, estamos usando uma camada Ajax para gerenciar as comunicações com o servidor web. Imagine que temos um conjunto de 10 páginas, o usuário tem obtido a primeira página dos 10 em seu dispositivo e, em seguida, é feito um pedido de alteração à ordem de classificação. O Ajax solicita um novo conjunto de dados no servidor web para o seu site, similar a uma transação HTML normal, exceto que ela é executada de forma assíncrona em um segmento separado.

Se você não sabe o que isso significa, o benefício é que o resto da página pode carregar completamente enquanto o processo de capturar os dados que o Ajax irá exibir está sendo executado em paralelo. Essas podem ser coisas como o seu menu principal, seus links de rodapé para produtos relacionados e outros elementos da página. Isso pode melhorar o desempenho percebido da página.

Quando um usuário seleciona uma ordem de classificação diferente, o código registra um manipulador de eventos para um determinado objeto (por exemplo, elementos HTML ou outros objetos DOM) e, em seguida, executa uma ação. O navegador irá executar a ação em uma thread diferente para disparar o evento na thread principal quando apropriado. Isso acontece sem a necessidade de executar uma atualização de página inteira, apenas o conteúdo controlado pelas atualizações Ajax.

Para traduzir isso para o leitor não técnico, isso significa apenas que podemos atualizar a ordem de classificação da página, sem a necessidade de redesenhar a página inteira, ou alterar a URL, mesmo no caso de uma sequência de páginas paginadas. Isso é um benefício, porque será mais rápido do que recarregar a página inteira, e deve ser deixado claro para os motores de busca que você não está tentando obter alguma nova página em seu índice.

Efetivamente, o Ajax faz isso dentro do Document Object Model (DOM) existente, e você pode pensar em como a estrutura básica dos documentos está criada e em uma especificação para a forma como o documento é acessado e manipulado.

Como o Google vai lidar com esse tipo de implementação?

Aqueles de vocês que leram o excelente texto de Adam Audette, sobre os testes que sua equipe executou em como o Google lê o JavaScript, podem estar se perguntando se o Google ainda irá carregar todas essas variantes de página na mesma URL de qualquer maneira, e se eles não vão gostar.

Eu fiz a mesma pergunta, então fui até Gary Illyes do Google, que me deu uma resposta. Aqui está o diálogo:

Eric Enge: Eu gostaria de lhe perguntar sobre o uso de JSON e jQuery para processar diferentes ordens de classificação e filtros dentro de uma mesma URL. Ou seja, o usuário seleciona uma ordem de classificação ou algum filtro, e o conteúdo é reordenado e redesenhado na página do lado do cliente. Daí nenhuma nova URL seria criada. É efetivamente uma forma de canonicalização do conteúdo, uma vez que cada variante é um subconjunto estrito. Então há uma segunda consideração nessa abordagem, que envolve fazer a mesma coisa com a paginação. Ou seja, você tem 10 páginas de produtos, e os usuários ainda têm classificação e opções de filtragem. Para que seja possível apoiar a classificação e a filtragem em todo o conjunto de páginas, você usa uma solução Ajax, portanto, todas as páginas ainda retornam uma única URL. Então, se você está na página 1, e um usuário executa uma espécie de filtro, ele ainda estaria fisicamente em uma página. Para fazer isso funcionar direito, ir para a página 2 também iria retornar a mesma URL. Efetivamente, você estará padronizando o conjunto de 10 páginas e evidenciando que tudo está dentro de uma única URL. Isso permite a classificação, a filtragem e a paginação, sem a necessidade de usar canônica, noindex, prev/next, ou arquivos robots.txt. Se isso não era problemático para o Google, a única desvantagem é que faz a paginação não ser visível para o Google. Isso faz sentido, ou é uma má ideia?

Gary Illyes: Se você tiver apenas uma URL, e as pessoas tiverem que clicar em algum lugar para ver diferentes ordens de classificação ou filtros para ver exatamente o mesmo conteúdo sob essa URL, normalmente só veríamos o conteúdo padrão. Se você não tem informações de paginação na página, isso não é um problema, a não ser que nós não possamos ver o conteúdo nas outras páginas que não estão contidas no HTML dentro do carregamento da página inicial. O rel-prev/next deverá convergir para as páginas filhas (página 2, 3, 4 etc.) e para o grupo de páginas como um conjunto, ou para a exibição de todas as páginas, caso você tenha uma categoria geral. Se você simplesmente optar por tornar essas versões paginadas em uma única URL, que terá o mesmo impacto sob o ponto de vista dos sinais, isso significa que todos os sinais vão para uma única entidade, em vez de distribuídos a várias URLs.

Resumo

Tenha em mente que a razão pela qual o Google implementou tags como rel=canonical, NiIndex, rel=prev/next e outras é reduzir sua carga de rastreamento de página e para ajudar os sinais de localização de elementos nas páginas de entrada da melhor maneira possível. O uso de Ajax/JSON/jQuery, conforme descrito acima, faz isso de forma simples e elegante.

Na maioria dos sites de comércio eletrônico, há muitos tipos de navegação com “facetas” diferentes de como um usuário pode querer classificar e filtrar uma lista de produtos. Com a implementação no estilo Ajax, isso pode ser feito sem a criação de novas páginas. Os usuários finais obtêm o controle que estão procurando, os motores de busca não tem que lidar com páginas em excesso que não precisam indexar, e os sinais no site (tais como links) são focados nas páginas principais, onde eles devem estar.

A única desvantagem é que o Google não pode ver todo o conteúdo quando ele é paginado. Um site que tem diversos lotes de produtos muito semelhantes em uma lista paginada não tem que se preocupar muito com o Google para ver todo o conteúdo adicional, por isso não é uma preocupação muito grande se suas páginas incrementais contiverem mais do que está na primeira página. Sites que tenham conteúdo que seja materialmente diferente das páginas adicionais, no entanto, podem não querer usar essa abordagem.

Essas soluções exigem codificação e especialização em JavaScript, mas não são realmente complexas. Se você tiver a capacidade de considerar um caminho como esse, poderá se libertar de tentar compreender as várias tags, suas limitações e se realmente elas realizam o que você está procurando.

***

Eric Enge faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link https://moz.com/blog/using-ajax-json-jquery-to-implement-faceted-navigation. Esta tradução foi feita com permissão. Moz não tem qualquer afiliação com este site.