# Como impedir o Googlebot de desperdiçar rastreio nos filtros do PrestaShop? > Nos catálogos com facetas por tratar, a parte do rastreio dedicada aos filtros passa muitas vezes de metade dos pedidos. Como medi-la nos registos do servidor, porque noindex e robots não chegam, e os limites a respeitar. - Página: - Idioma: pt - Publicado em: 2026-09-25 - Atualizado em: 2026-10-09 - Outros idiomas: [fr](https://www.datafirefly.com/2026/09/25/crawl-filtres-prestashop-budget-exploration/index.md), [en](https://www.datafirefly.com/en/2026/09/25/googlebot-crawl-waste-prestashop-filters/index.md), [es](https://www.datafirefly.com/es/2026/09/25/googlebot-rastreo-filtros-prestashop/index.md), [de](https://www.datafirefly.com/de/2026/09/25/googlebot-crawl-budget-prestashop-filter/index.md), [it](https://www.datafirefly.com/it/2026/09/25/googlebot-crawl-filtri-prestashop/index.md), [pl](https://www.datafirefly.com/pl/2026/09/25/googlebot-crawl-filtry-prestashop/index.md), [nl](https://www.datafirefly.com/nl/2026/09/25/crawl-filters-prestashop-crawlbudget/index.md) - Índice: Num catálogo grande, uma parte considerável dos pedidos dos robôs incide sobre combinações de filtros que não têm vocação nenhuma para ser indexadas. Esse tempo é tirado ao que teria servido para descobrir os seus produtos novos. Este artigo trata a medição e a implementação. Os critérios de escolha das facetas a abrir foram detalhados à parte. ## Medir o desperdício antes de agir Nenhuma decisão devia ser tomada sem olhar para os registos do servidor. É a única fonte que mostra o que os robôs pedem realmente, por oposição ao que pensa que pedem. O método tem três etapas. **Extrair os pedidos dos robôs** em quatro semanas, filtrando pelo agente de utilizador e verificando a autenticidade por resolução inversa do endereço. Uma parte das visitas que se declaram robô não o é. **Classificar os endereços pedidos** em quatro famílias: fichas de produto, categorias sem filtro, categorias com filtros, e o resto. Esta classificação faz-se por padrão de URL e demora alguns minutos assim que o ficheiro está carregado numa folha de cálculo ou numa base de dados. **Calcular a repartição.** Nos catálogos com facetas por tratar, a parte dedicada aos filtros passa frequentemente de metade dos pedidos, e pode chegar a 80 % nas configurações mais abertas. Dois números complementares merecem ser registados. A **frequência de passagem pelas suas fichas de produto**: se um produto só é visitado uma vez por mês, o seu orçamento de rastreio está saturado noutro lado. E o **prazo de descoberta** das últimas novidades, entre a colocação online e a primeira visita. ## O que os registos revelam Três constatações aparecem sistematicamente nos catálogos nunca tratados. **As combinações profundas.** Endereços com três, quatro ou cinco filtros em simultâneo, que não têm hipótese nenhuma de ser indexados e que representam ainda assim um volume importante. **Os parâmetros de ordenação.** A mesma lista de produtos pedida em seis ordens diferentes. Nenhum destes estados acrescenta o que quer que seja ao índice. **As facetas sem resultado.** Combinações que não devolvem produto nenhum, rastreadas mesmo assim porque a ligação existe na página. Este último ponto é o mais revelador: a sua interface propõe ligações para seleções vazias, o que já é um problema para os visitantes antes de o ser para o rastreio. ## Porque as diretivas clássicas não chegam O reflexo é pôr uma diretiva noindex nestas páginas. Resolve a indexação, não o rastreio: a página tem de ser visitada para que a diretiva seja lida. O bloqueio no ficheiro robots impede o rastreio, mas tem dois inconvenientes. As páginas já indexadas podem lá ficar, sem que o conteúdo possa ser relido para perceber que é preciso retirá-las. E o bloqueio contorna-se mal: um endereço bloqueado mas massivamente ligado a partir das suas páginas continua conhecido. Estas duas ferramentas continuam úteis. Simplesmente intervêm depois de o robô ter descoberto o endereço. ## Não dar a ligação A abordagem complementar consiste em não exprimir essas ligações como ligações. O princípio: o comportamento de navegação é produzido por um script ligado a um elemento que não é uma ligação no sentido do protocolo. O visitante clica e navega normalmente, o robô não encontra endereço nenhum para seguir. Três condições para que fique limpo. **O elemento tem de continuar acessível.** Um elemento clicável que não é uma ligação tem de carregar os atributos que o tornam utilizável por teclado e compreensível por um leitor de ecrã. Sem isso, resolve um problema de rastreio criando um problema de acessibilidade. **A navegação tem de continuar funcional.** O endereço tem de mudar, o retrocesso tem de funcionar, a ligação tem de continuar partilhável. A ofuscação incide sobre a forma como a ligação é escrita no código, não sobre o desaparecimento do endereço. **O perímetro tem de ser limitado.** Aplique este tratamento apenas às ligações que não quer ver rastreadas. A sua navegação principal, as suas categorias e as suas facetas abertas têm de continuar ligações normais. ## O que não se deve fazer com isto Dois desvios a afastar com clareza. **Ocultar ligações para conteúdo que quer indexar**, na esperança de controlar a distribuição de valor. É uma prática antiga, ineficaz, e priva as suas páginas de ligações de entrada. **Apresentar ao robô uma página diferente da do visitante.** A ofuscação de ligação não muda o conteúdo servido, muda a forma como um elemento de interface é escrito. A diferença é nítida e é preciso respeitá-la: servir um conteúdo distinto consoante o agente é uma prática sancionada. ## As outras alavancas A ofuscação não é a única ferramenta, e nem sempre é a primeira. **Reduzir o número de filtros propostos.** Muitos catálogos mostram doze facetas das quais quatro são usadas. Retirar as inúteis reduz mecanicamente a combinatória e simplifica a interface. **Ocultar os filtros sem resultado.** Um valor que não devolve nada não devia ser proposto. Elimina ligações inúteis e melhora a experiência. **Carregar os filtros a pedido.** Em mobile, o painel de filtros está muitas vezes fechado: se o conteúdo só aparece depois da abertura, as ligações não estão na página servida. **Cuidar do sitemap.** Tem de conter as suas páginas úteis e mais nada. Um sitemap que lista combinações de filtros convida explicitamente a rastreá-las. ## Controlar depois da implementação Quatro indicadores, registados antes e depois a um mês e a três meses. **A repartição dos pedidos dos robôs** por família de URL, pelo mesmo método do início. É a medida direta do efeito. **O número total de páginas rastreadas por dia**, nas estatísticas de rastreio. Atenção à interpretação: aqui uma descida é esperada e desejável, ao contrário do que normalmente se pensa. **A frequência de visita das fichas de produto**, que deve subir já que o tempo libertado se redistribui. **O prazo de descoberta das novidades**, que é o indicador final: é por ele que o trabalho é feito. Um ponto de método: deixe passar três a quatro semanas antes de concluir. A redistribuição do orçamento de rastreio não se vê de imediato. ## O que pode correr mal Três situações a vigiar depois da implementação. **Páginas úteis tornadas inacessíveis.** Se uma faceta que queria abrir acabar no perímetro ofuscado, perde as ligações de entrada. Verifique que as suas páginas abertas continuam ligadas a partir de um sítio normal. **Uma navegação partida no teclado.** O teste faz-se em trinta segundos: percorra os filtros com a tecla de tabulação e verifique que estão alcançáveis e ativáveis. **Uma descida de tráfego nas páginas de facetas.** Se tinha algumas a receber tráfego e ficaram apanhadas no perímetro, a descida aparece em três a seis semanas. Daí o interesse de registar as posições antes. O implementa este dispositivo no PrestaShop 8 e 9: tratamento seletivo das ligações de filtros e de ordenação com exclusão das facetas abertas, conservação do comportamento de navegação e dos atributos de acessibilidade, e perímetro configurável por categoria.