Référencement de l’exploration (crawling) pour les sites de commerce électronique

Chapitres “Ecommerce SEO”:

1 – L’architecture Du Site De Commerce Électronique
2 – La Recherche De Mots-Clés
3 – Référencement De L’exploration (Crawling)
4 – Référencement Des Liens Internes
5 – Référencement De La Page D’accueil
6 – Référencement Naturel Pour Les Pages De Liste De Produits
7 – Référencement Pour Les Pages Avec Des Détails Sur Les Produits (PDP)

L’optimisation de l’action d’exploration (crawling ou l’exploration du site par les robots d’exploration) a pour but d’aider les moteurs de recherche à trouver les URLs aussi efficacement que possible. Les pages pertinentes doivent être identifiées facilement, lorsque les pages moins importantes ne devraient pas gaspiller le soi-disant « budget d’exploration » et ne devraient pas poser des pièges aux robots. Le budget d’exploration est défini comme le nombre d’URLs que les moteurs de recherche peuvent et veulent analyser.

Les moteurs de recherche attribuent un budget d’exploration à chaque site web, en fonction de son autorité. Généralement, l’autorité d’un site web est en quelque sorte proportionnelle à son PageRank.

Le concept de budget d’exploration est essentiel pour les sites web d’e-commerce, parce qu’ils comprennent, de règle générale, un nombre immense d’URLs – de quelques dizaines à des milliers et millions.

Si l’architecture technique piège les robots des moteurs de recherche (connus aussi sous le nom de robot, bot ou spider) dans des boucles infinies et d’autres embûches, le budget d’exploration sera gaspillé sur des pages qui ne présente pas d’importance pour les utilisateurs ou les moteurs de recherche. Ce gaspillage peut déterminer les moteurs de recherche à ignorer certaines pages importantes.

De plus, l’optimisation de l’opération d’exploration permet aux grands sites web de profiter de l’opportunité d’avoir seulement les pages cruciales indexées et les pages à PageRank faible analysées plus fréquemment.[1]

Le nombre d’URLs que Google peut indexer a augmenté de façon spectaculaire avec l’introduction de l’architecture Percolator[2], après l’actualisation “Caffeine”.[3] Quand même, il est encore important que vous vérifiiez les ressources que les robots des moteurs de recherche demandent et que vous prioritisez l’action d’exploration en fonction de ces ressources.

Avant de commencer, il est important de comprendre que l’action d’exploration et celle d’indexation font référence à deux processus différents. L’exploration se réfère seulement à la collecte des fichiers des sites web (fetching). L’indexation fait référence à l’analyse des fichiers et la prise d’une décision concernant leur mérite d’être incluses. Ainsi, même si les moteurs de recherche explorent une page, cela ne signifie pas nécessairement qu’ils l’indexeront.

L’exploration est influencée par plusieurs facteurs, tout comme la structure du site web, le linking interne, l’autorité du domaine, l’accessibilité des lies, la fraicheur du contenu, la fréquence des actualisations et les réglages liés à la rate d’exploration de Google Search Console ou Bing Webmaster.

Avant de détailler ces facteurs, vous devez suivre et surveiller les robots d’exploration.

Suivre et surveiller les robots de recherche

Googlebot, Yahoo! Slurp et Bingbot sont des robots polis,[4] ce que veut dire qu’ils respecteront d’abord les consignes trouvées dans les fichiers robots.txt, avant de solliciter les ressources sur le site web. Les robots polis s’identifieront au serveur web, donc vous pouvez les contrôler comme vous voulez. Les demandes des robots sont stockées dans des fichiers log et sont disponibles pour être analysées.

Les instruments, comme ceux mis à la disposition par Google et Bing, ne révèlent qu’une petite partie de ce que les robots font sur le site web – par ex., combien de pages ils explorent ou des données liées à l’utilisation de la bande passante (bandwidth). Ces informations vous sont utiles d’une certaine manière, mais elles ne sont pas suffisantes.

Pour des perspectives vraiment utiles vous devez analyser les fichiers d’enregistrement du trafic (traffic log files). Vous pourrez y trouver et extraire les informations qui vous aideront à identifier les problèmes à grande échelle.

Traditionnellement, l’analyse des fichiers log était effectuée en utilisant la ligne de commande grep avec des expressions régulières. Mais récemment il y a des solutions desktop et web qui facilitent ce type d’analyse technique et le fait plus accessible aux commerçants.

Sur les sites web d’e-commerce, les fichiers mensuels log sont immenses d’habitude – gigabytes ou même térabytes de données. Toutefois, vous n’avez pas besoin de toutes ces données des fichiers log pour suivre et surveiller les robots des moteurs de recherche. Vous n’avez besoin que des lignes générées par les demandes des robots. Ainsi, vous pouvez réduire significativement la dimension des fichiers log, de gigabytes à mégabytes.

En utilisant la commande Linux suivante (la commande est sensible à la casse), vous extrairez seulement les lignes qui contiennent “Googlebot”, d’un fichier log (access_log.processed), en autre (googlebot.log):

grep “Googlebot” access_log.processed > googlebot.log

Pour extraire des données similaires pour Bing et d’autres moteurs de recherche, remplacez „Googlebot” avec les autres noms des robots.

Le fichier log a été réduit de 162.5Mb à 1.4Mb.

Ouvrez le fichier log spécifique au robot, allez à Data Text to Columns et utilisez Delimited with Space pour introduire les données du fichier log dans un format de tableau comme celui ci-dessous :

C:\Users\Traian\AppData\Local\Temp\SNAGHTML231c431.PNG

Les données sont filtrées selon Status, pour obtenir une liste de toutes erreurs du type 404 Not Found rencontrées par Googlebot.

Note: vous pouvez importer au maximum un million de lignes en Excel ; si vous devez importer plus, utilisez MS Access ou Notepad++.

Pour identifier rapidement les problèmes d’exploration au niveau des pages de catégories, créez un diagramme des recherches Googlebot pour chaque catégorie. Est-ce que vous voyez maintenant l’un des avantages de la navigation sur la base des catégories dans la structure des URLs ?

Il semble que le répertoire /bracelets/ doit être investigué, parce qu’il y a trop peu de demandes des robots en comparaison avec les autres répertoires.

En pivotant les données des fichiers log selon les URLs et les données d’exploration, vous pouvez identifier le contenu le plus rarement exploré par Googlebot :

Les dates lorsque les URLs ont été collectées (fetched).

Dans ce tableau pivot, vous pouvez voir que même si les trois URLs sont positionnées au même niveau dans la hiérarchie, la troisième URL fait plus souvent le sujet de l’action d’exploration que les autres deux. C’est un indicateur que l’URL#3 est considéré plus important.

C:\Users\Traian\AppData\Local\Temp\SNAGHTML61a6f94.PNG

Plusieurs liens retour externes et des mentions sur les plateformes sociales pourrait conduire à une fréquence supérieure d’exploration.

Voici quelques problèmes et idées que vous devez prendre en considération lorsque vous analyser le comportement des robots, en utilisant les fichiers log :

  • Analysez les erreurs de réponse du serveur et identifiez la raison exacte de ces erreurs.
  • Découvrez les pages qui font inutilement le sujet de l’action d’exploration et les pièges dans l’analyse des URLs.
  • Corrélez les jours de la dernière action d’exploration aux positionnements ; lorsque vous faites des modifications sur une certaine page, assurez-vous que vous l’explorez de nouveau. Si vous n’explorez pas la nouvelle page, les actualisations ne seront pas prises en compte pour des positionnements qu’après l’exploration naturelle de Googlebot (qui peut durer des mois, sur les sites avec un grand nombre d’URLs).
  • Analysez si les produits listés dans le top des listings font plus souvent l’objet de l’action d’exploration que les produits listés sur les pages composantes (listings paginés). Prenez en considération le transfert des plus importants produits sur la première page au lieu de les laisser sur es pages composantes.
  • Vérifiez la fréquence et la profondeur de l’action d’exploration.

Le but de suivre les robots est de :

  • Déterminer les récipients du budget d’exploration.
  • Identifier les demandes inutiles (par ex., des liens du type « écrire une critique » qui ouvrent des pages avec le même contenu, à l’exception du nom du produit, par ex., mysite.com/review.php?pid=1, mysite.com/review.php?pid=2 et ainsi de suite).
  • Réparer les fuites.

Au lieu de gaspiller le budget sur des URLs inutiles (par ex., des URLs avec du contenu en double – duplicate content), concentrez-vous sur l’envoi des robots vers les pages qui comptent pour vous et pour vos utilisateurs.

Une autre application utile des fichiers log est d’évaluer la qualité des liens retour. Louez des liens de divers sites web externes et dirigez-les vers les pages sans d’autres liens retour (des pages avec des détails sur les produits ou des pages qui supportent les pages avec des détails sur les produits). Ensuite, analysez l’activité des robots sur ces pages de votre site web. Si la fréquence d’exploration augmente, ce lien-là est plus précieux qu’un lien qui n’augmente guère l’activité des robots. Une augmentation de la fréquence d’exploration sur vos pages suggère que la page d’où vous avez obtenu le lien fait aussi fréquemment l’objet de l’action d’exploration, ce que signifie que cette page-là a une bonne autorité. Dès que vous avez identifié de bonnes opportunités, essayez d’obtenir des liens naturels de ces sites-là.

La structure plate du site web

S’il n’y a pas d’autres impédiments techniques dans la voie de l’opération d’exploration des sites web de grandes dimensions (par ex., la navigation facettée qui peut faire l’objet du processus d’exploration, ou des espaces infinis[5]), une structure plate du site web peut aider l’opération d’exploration, en permettant aux moteurs de recherche d’arriver aux pages profondes dans seulement quelques pas, en utilisant donc le budget alloué d’une manière très efficiente.

La pagination – ou, pour être plus exacts – la dé-pagination, est un moyen d’aplatir l’architecture de votre site. Nous allons discuter sur la pagination plus tard, dans la section Pages de listing.

Pour plus de renseignements sur l’architecture plate du site web, voir la section Le concept d’architecture plate dans la section Architecture du Site Web.

L’accessibilité

Je parlerai de l’accessibilité de la perspective de l’optimisation pour les moteurs de recherche et non pas de l’accessibilité pour les utilisateurs.

L’accessibilité est, probablement, le facteur vital de l’opération d’exploration. Votre budget d’exploration est dicté par la manière dont le serveur répond au trafic des robots. Si l’architecture technique du site web empêche les robots des moteurs de recherche à accéder aux URLs, alors ceux URLs-là ne seront pas indexées. Les URLs qui sont déjà indexées mais qui ne peuvent pas être accédées après plusieurs tentatives infructueuses peuvent être retirées des indices des moteurs de recherche.

Google commence l’action d’exploration des sites web nouveaux d’une façon très lente et puis augmente le rythme jusqu’au niveau auquel il n’y a pas de problèmes d’accessibilité pour les utilisateurs ou votre serveur.

Alors, quels sont les éléments qui peuvent empêcher les URLs et le contenu d’être accessibles ?

DNS et problèmes de connectivité

Utilisez http://www.intodns.com/ pour vérifier les problèmes liés à DNS. Tout ce qui est marqué en rouge et jaune nécessite votre attention (même s’il s’agit d’un enregistrement MX).

Rapport d’intodns.com.

En utilisant les comptes webmaster Google et Bing, réparez tous les problèmes liés à DNS et à la connectivité:

Le rapport concernant les informations d’exploration de Bing.

C:\Users\Traian\Desktop\Site Errors Bad.png

Le rapport Erreurs du Site de Google dans l’ancienne version de GSC.[6]

Un problème DNS que vous devez prendre en considération est lié aux enregistrements DNS wildcard, ce qui veut dire que le serveur Internet répond avec un code 200 OK à toute demande des sous-domaines, même pour ceux qui n’existent pas. Un problème plus grave lié à DNS est représenté par les noms d’hôtes qui ne peuvent pas être reconnus, ce qui signifie que la recherche DNS échoue lorsqu’elle essaie le nom du domaine.

Un commerçant avait une autre configuration DNS déficitaire. Deux des domaines de top du code de pays (ccTLDs)— US (.com) et UK (.co.uk)—faisaient renvoi au même IP. SI vous avez des ccTLDs multiples, hébergez-les sur des IP différents (idéalement du pays que vous ciblez avec le ccTLD) et vérifiez la manière dont le nom du domaine est réglé.

Evidemment, si vos serveurs web ont échoué, personne ne pourra accéder au site web (y compris les robots des moteurs de recherche). Vous pouvez jeter un coup d’œil sur la disponibilité de votre site en utilisant des instruments de surveillance comme Monitor.Us, Scoutt ou Site24x7.

Host load

Host load représente le nombre maximal de connexions simultanées qu’un serveur web peut supporter. Chaque demande de chargement d’une page faite par Googlebot, Yahoo! Slurp ou Bingbot génère une connexion avec votre serveur web. Parce que les moteurs de recherche utilisent une exploration distribuée de plusieurs ordinateurs en même temps, en théorie vous pouvez atteindre la limite de connexions et le site web échouera (surtout si vous avez un plan d’hébergement partagé avec d’autres sites).

Utilisez des instruments comme ceux que vous pouvez trouver sur loadimpact.com pour vérifier combien de connexions le site web peut supporter. Toutefois, il faut faire attention : le site peut devenir indisponible ou même s’écraser pendant ce test.

Si le site web se charge en moins de deux secondes en dépit d’un grand nombre d’utilisateurs, tout va bien (graphique généré par loadimpact.com).

Le temps de chargement de la page

Le temps de chargement de la page n’est pas seulement un indice de l’exploration mais aussi du positionnement (ranking) et usabilité (usability). On dit qu’Amazon a augmenté ses revenus par 1% pour chaque amélioration de 100 ms du temps de chargement,[7] et Shopzilla a augmenté ses revenus par 7-12% en diminuant le temps de chargement de la page par cinq secondes.[8]

Il y a des nombreux articles sur l’optimisation de la vitesse de chargement de la page et ils peuvent être assez techniques. Voici quelques aspects synthétiques concernant la manière dont vous pouvez optimiser les temps de chargement :

  • Retardez le chargement des pages jusque l’affichage dans le navigateur est nécessaire.
  • Utilisez des CSS sprites.
  • Utilisez des protocoles HTTP2.

Amazon utilises des CSS pour minimaliser le nombre de demandes vers leur serveur.

Apple a utilisé des sprites pour la navigation principale.

  • Utilisez des réseaux de diffusion de contenu (Content Delivery Network, ou CDN) pour les fichiers média et d’autres fichiers qui ne sont pas mis à jour trop souvent.
  • Implémentez l’optimisation de la base de données et du cache (utilisez server-side caching).
  • Activez la compression HTTP et implémentez la fonctionnalité conditional GET.
  • Optimisez les images.
  • Utilisez expires headers.[9]
  • Assurez un design rapide et responsif (ou adaptable) pour réduire time to first byte (TTFB). Utilisez http://webpagetest.org/ pour mesurer TTFB. Il semble exister une corrélation claire entre les positionnements plus faibles et un taux TTFB élevé.[10]

Si les pages se chargent lentement, les moteurs de recherche peuvent interpréter cela comme un problème de connectivité, ce qui signifie qu’ils renonceront à l’opération d’exploration des URLs problématiques.

La période de temps passé par Google pour télécharger une page semble influencer le nombre de pages qu’il demandera d’un serveur. Plus le temps de téléchargement est réduit, plus de pages seront demandées/explorées.

La corrélation entre la période passée pour le téléchargement d’une page et le nombre de pages explorées par jour semble évidente dans ce graphique.

Liens brisés (broken links)

C’est évident. Lorsque vos liens internes sont rompus, les robots ne pourront pas trouver les pages correctes. Effectuez une opération complète d’exploration du site entier avec un instrument d’exploration à votre choix et réparez toutes les URLs brisées. De même, utilisez les instruments mis à disposition par les moteurs de recherche pour chercher les URLs brisées.

HTTP caching avec Last-Modified/If-Modified-Since et des en-têtes E-Tag

En ce qui concerne l’optimisation du processus d’exploration, le terme « cache » fait référence à une page stockée dans l’index d’un moteur de recherche. Notez que le caching est un problème extrêmement technique et les réglages incorrects peuvent déterminer les moteurs de recherche à explorer et indexer votre site web d’une manière chaotique.

Lorsqu’un moteur de recherche sollicite une ressource d’un site web, il fait d’abord une demande au serveur web pour identifier le statut de cette ressource-là. Le serveur repondéra avec un header response. Sur la base de ce header response, les moteurs de recherche décideront de télécharger la ressource et de la sauter.

Beaucoup de moteurs de recherche vérifient si la ressource qu’ils demandent a changé de sa dernière exploration. Si elle s’est changé, ils doivent l’extraire de nouveau (fetch) – sinon, ils la sauteront. Ce mécanisme est connu sous le nom de conditional GET (acquisition conditionnelle). Bing a confirmé qu’il utilise l’en-tête If-Modified-Since,[11] tout comme Google.[12]

Voilà ci-dessous la réponse de l’en-tête (header response) pour une page nouvellement découverte qui supporte l’en-tête If-Modified-Since, lorsqu’il y a une demande de l’accéder.

Utilisez la commande curl pour obtenir la dernière date de modification d’un document.

Lorsque le robot demande la même URL la prochaine fois, il ajoutera une demande du type If-Modified-Since. Si le document n’a pas changé, il répondra avec un code de statut 304 (Page Not Modified):

Une réponse du type 304 dans l’en-tête.

If-Modified-Since affichera 304 Not Modified si la page n’a pas été modifiée. Si la page a été modifiée, la réponse de l’header sera 200 OK et le moteur de recherche explorera la page de nouveau. L’en-tête E-Tag fonctionne d’une manière similaire, mais il est plus compliqué à gestionner.

Si votre plateforme d’e-commerce utilise la personnalisation ou si le contenu de chaque page change fréquemment, il peut être difficile d’implémenter le HTTP caching, mais même les pages dynamiques peuvent supporter If-Modified-Since.[13]

Les plans de site (Sitemaps)

Il y a deux types majeurs de sitemaps:

  • Sitemaps HTML
  • Sitemaps XML

Vous pouvez envoyer des sitemaps dans le format suivant : fichiers texte simples, RSS ou mRSS.

Si vous avez des problèmes d’exploration et indexation, notez que les sitemaps sont seulement une solution à court terme pour des problèmes plus graves, comme contenu en double, contenu pauvre (thin content) ou linking interne incorrect. La création de sitemaps est une bonne idée, mais elle ne résoudra pas ces problèmes.

Sitemaps HTML

Les sitemaps HTML sont une forme de navigation secondaire. Ils sont généralement accessibles aux personnes et robots par l’intermède d’un lien placé dans la partie inférieure du site web, dans le sous-sol (footer).

Une étude regardant l’usabilité effectuée sur plusieurs sites web, y compris les sites web d’e-commerce, a montré que les personnes rarement utilisent des sitemaps HMTL. En 2008, seulement 7% des utilisateurs ont fait appel au sitemap lorsqu’ils ont été demandé à découvrir la structure d’un site,[14] contre 27% en 2002. Aujourd’hui, le pourcentage est probablement plus faible.

Quand même, les sitemaps HTML sont utiles pour envoyer les robots vers les pages des niveaux inférieurs de la taxonomie du site web, tout comme pour la création d’un linking interne plat.

Un échantillon d’architecture plate.

Voici quelques conseils d’optimisation pour les sitemaps HTML:

Utilisez des sitemaps segmentés

Lorsque vous optimisez les sitemaps HTML pour l’exploration, il est important de noter que PageRank est divisé entre tous les liens sur une page. La division de sitemap HTML en plusieurs segments plus petits et un bon moyen de créer des pages plus faciles à utiliser pour les utilisateurs et les moteurs de recherche dans le cas des sites web de grandes dimensions, tout comme les sites d’e-commerce.

Au lieu d’une page sitemap immense qui fait un lien vers presque chaque page du site, créez une page principale sitemap d’indexation (par ex., sitemap.html) et faites un lien de cette page vers les pages composantes plus petites du sitemap (sitemap-1.html, sitemap-2.html etc.).

Vous pouvez diviser les sitemaps HTML en fonction de sujets, catégories, départements ou marques. Commencez par lister les principales catégories sur la page d’indexation. La manière dont vous diviser les pages dépend du nombre de catégories, sous-catégories et produits de votre catalogue.

Vous pouvez utiliser la règle de « 100 liens par page » comme recommandation, mais ne vous cramponnez pas à ce nombre, particulièrement si le site web a une bonne autorité.

Si vous avez plus de 100 catégories de top, vous devrez afficher les premières 100 sur la page sitemap d’indexation et le reste sur des pages sitemap supplémentaires. Vous pouvez permettre aux utilisateurs et moteurs de recherche à naviguer en utilisant des liens vers les pages précédentes suivantes (par ex., « voir plusieurs catégories »).

Si vous avez moins de 100 catégories de niveau premier dans votre catalogue, vous aurez de la place pour lister des sous-catégories importantes, comme illustré ci-dessous :

Un exemple de sitemap HTML propre.

Les catégories de top de ce sitemap sont Photography, Computers & Solutions et Pro Audio. Parce que l’entreprise a un nombre limité de catégories de top, il y a de la place pour plusieurs sous-catégories (Digital Cameras, Laptops, Recording).

Ne faites pas des liens vers les redirections (redirects)

Les URLs auxquelles on fait un lien des pages sitemaps devraient envoyer les robots d’exploration sur les URLs finales et non pas par des redirections URL (redirects).

Enrichissez les sitemaps

Il est utile pour les utilisateurs d’ajouter quelques données supplémentaires en annotant des liens avec des informations et cela assure un certain contexte pour les moteurs de recherche aussi. Vous pouvez ajouter des données comme thumbnails pour le produit, notations des clients, noms des producteurs et ainsi de suite.

Ce ne sont que quelques-unes des suggestions pour les sitemaps HTML pour rendre les pages plus faciles à lire pour les utilisateurs et pour créer un linking facile pour les robots d’exploration. Quand même, la meilleure manière d’aider les moteurs de recherche à découvrir le contenu d’un site web est de mettre à disposition une liste d’URLs dans des formats différents de fichiers. Un tel format de fichier est XML.

Sitemaps XML

Les plateformes modernes d’e-commerce devraient auto-générer de sitemaps XML mais souvent le fichier output de base n’est pas optimisé pour l’exploration et l’analyse. Il est important donc d’analyser manuellement et d’optimiser l’output automatisé ou de générer des sitemaps selon vos propres règles.

Si vous n’avez pas de soupçons liés aux compétiteurs qui espionnent la structure URL, il est préférable de n’inclure pas la route du fichier sitemap XML dans le fichier robots.txt.

Robots.txt est sollicité par les moteurs de recherche chaque fois qu’ils commencent une nouvelle session d’exploration sur le site web. Le fichier est analysé pour voir s’il a été modifié depuis la dernière opération d’exploration. Si le fichier n’a pas été modifié, alors les moteurs de recherche utiliseront le fichier cache robots.txt existant pour déterminer les URLs qui peuvent être explorées par les robots.

Si vous ne spécifiez pas la location du sitemap XML à l’intérieur du fichier robots.txt., les moteurs de recherche ne sauront pas où la trouver (sinon vous l’avez envoyée dans le cadre des comptes webmaster). La communication de la location vers Google Search Console ou Bing Webmaster permet l’accès à plusieurs informations, tout comme le nombre des URLs envoyées, combien d’elles sont indexées et quelles erreurs possibles sont présentes dans le sitemap.

Si vous avez un taux d’indexation près de 100% probablement ce n’est pas le moment de vous inquiéter à propos de l’optimisation de l’exploration.

L’utilisation des sitemaps XML semble avoir un effet d’accélération sur le taux d’exploration:

“Au début, le nombre de visites s’est stabilisé à un taux de 20 – 30 pages par heure. Dès que le sitemap a été chargé par Webmaster Central, le robot a accéléré à environ 500 pages par heure. En quelques jours, il a atteint une valeur maximale de 2.224 pages par heure. D’une valeur moyenne de visite de 26,59 pages par heure, le robot a accéléré à une valeur moyenne de 1.257,78 pages par heure, une augmentation depas moins de 4.630,27%”.[15]

Voici quelques conseils pour l’optimisation des sitemaps XML pour les sites web de grandes dimensions :

  • Ajoutez seulement quelques URLs qui répondent par 200 OK. Trop d’erreurs et les moteurs de recherche n’auront pas confiance dans vos sitemaps. Bing a

“une tolérance de 1% pour les erreurs d’un sitemap. Les erreurs peuvent être représentées par l’apparition d’une redirection, un code 404 ou 500 lorsque nous cliquons sur une URL. Si nous voyons un niveau des erreurs de plus de 1%, nous perdons confiance dans ce sitemap-là”.[16]

Google est moins strict que Bing; ils ne se soucient guère des erreurs du sitemap.

Eliminez les liens vers contenu en double et les URLs qui canonicalisent vers d’autres URLs – gardez seulement les liens vers la destination finale.

  • Placez les images vidéo, les nouvelles et les informations mobiles dans des sitemaps séparés. Pour vidéo vous pouvez utiliser des sitemaps, mais le format mRSS est aussi supporté.
  • Segmentez les sitemaps selon le sujet, la catégorie et le sous-sujet et sous-catégorie. Par exemple, vous pouvez avoir un sitemap pour la catégorie Camping – sitemap_camping.xml, un autre pour la catégorie Bycicles – sitemap_cycle.xml, et un autre pour la catégorie Running Shoes (chaussures de course) – sitemap_running_shoes.xml. Cette segmentation n’améliore pas directement les classements organiques, mais elle aide l’indexation au niveau granulaire.
  • Créez des fichiers sitemaps séparés pour les pages de produits. Segmentez selon le plus bas niveau des catégories (leaf categories).
  • Réglez les erreurs liées au sitemap avant d’envoyer les fichiers aux moteurs de recherche. Vous pouvez faire cela dans le compte Google Search Console, en utilisant la fonction Test Sitemap:

La fonction Test Sitemap de Google Search Console.

  • Gardez des URLs spécifiques pour chaque langue dans des sitemaps différents.
  • N’attribuez pas la même importance à toutes les pages (votre score peut se baser sur la fréquence des actualisations ou d’autres règles d’affaires).
  • Auto-actualisez les sitemaps chaque fois que vous créez des URLs importantes.
  • Incluez seulement des URLs qui comprennent des filtres essentiaux et importants (voir la section Pages avec des détails sur le produit).

Vous avez observé probablement un aspect commun de ces conseils : la segmentation. C’est une bonne idée de diviser les fichiers XML autant que vous le pouvez, sans en abuser (par ex., seulement 10 URLs par fichier), pour pouvoir identifier et réparer plus facilement les problèmes liés à l’indexation.[17]

Notez que les sitemaps, soit XML ou HTML, ne doivent pas être utilisés comme un substitut pour une architecture de pauvre qualité du site web ou pour d’autres problèmes liés à l’opération d’exploration, mais seulement comme backup. Assurez-vous qu’il y a d’autres routes (par ex., des liens internes contextuels) pour que les robots de recherche puissent arriver à toutes les pages importantes d’un site web.

Voici quelques facteurs qui peuvent influencer le budget d’exploration :

Popularité

Les robots de recherche solliciteront les pages plus souvent s’ils découvrent des liens internes et externes vers ces pages-là.

La plupart des sites web de commerce électronique ont des difficultés dans la construction des liens externes vers les pages de catégories ou avec des détails sur les produits, mais c’est quelque chose qui doit être fait. L’hébergement des articles des invités (guest posts), les cadeaux promotionnels, l’attraction des liens (link bait), un contenu de qualité, les sollicitations directes de liens par des emails de confirmation, des programmes du type ambassadeur et des pages de catégories de vacances permanentes sont quelques-unes des stratégies qui peuvent aider à la construction des liens.

Les réglages liés au taux d’exploration

Vous pouvez modifier (généralement baisser) le taux d’exploration de Googlebot en utilisant Google Search Console. Quand même, il n’est pas recommandé de changer le taux, à moins que le robot ne ralentisse le serveur web.

Avec la fonction Crawl Control de Bing, vous pouvez régler un taux différant par jour même.

L’interface Crawl Control de Bing.

Contenu frais

L’actualisation du contenu des pages et la notification (pinging) ultérieure des moteurs de recherche (par ex., par la création des feeds pour les pages de produits et catégories) devrait attirer les robots d’exploration vers le contenu actualisé assez vite.

Si vous actualisez moins de 300 URLs par mois, vous pouvez utiliser la fonction „Fetch as Google” de Google Search Console pour avoir les URLs mises au jour explorées immédiatement par Googlebot. D’une manière similaire, vous pouvez créer régulièrement (par exemple, hebdomadairement) et envoyer un nouveau fichier Sitemap XML seulement pour les actualisations ou pour les pages nouvelles.

Il y a plus de moyens dont vous pouvez maintenir un contenu frais. Par exemple, vous pouvez inclure un extrait d’environ 100 mots des articles blog apparentés sur les pages avec les détails sur les produits. Idéalement, l’extrait devrait inclure le nom du produit et des liens vers les pages de catégories parentes. Chaque fois que vous mentionnez un produit dans une actualisation d’un article sur le blog, actualisez aussi l’extrait sur la page avec des détails sur les produits.

Vous pouvez inclure même des extraits des articles qui ne mentionnent pas directement le nom du produit, si l’article est lié à la catégorie de produits ou le produit peut être catalogué.

La section “From Our Blog” maintient la page actualisée et fraîche.

Une autre stratégie utile pour maintenir le contenu frais est de générer en permanence des critiques des produits achetés par les utilisateurs, des questions et réponses sur les produits ou d’autres formes de contenu généré par l’utilisateur.

Les notations (ratings) et les critiques sont un moyen intelligent de maintenir les pages actualisées, notamment pour les produits plus recherchés.

L’autorité du domaine

Plus l’autorité du domaine est grande, plus de visites les robots des moteurs de recherche effectueront. L’autorité de votre domaine augmente en créant un nombre plus grand de liens externes vers le site web – mais c’est plus facile à dire qu’à faire.

RSS feeds

RSS feeds représentent l’un des plus rapides moyens d’informer les moteurs de recherche sur les produits nouveaux, les catégories ou d’autres types de contenu frais sur le site web. Voici ce que Duane Forrester (ancien Webmaster Senior Product Manager de Bing) a dit sur RSS feeds:

“Des choses comme RSS deviendront une voie désirable pour nous de trouver du contenu…c’est une réduction substantielle de coût pour nous”.[18]

Vous pouvez convaincre les moteurs de recherche à effectuer l’opération d’exploration sur le nouveau contenu en quelques minutes de sa publication, à l’aide de RSS. Par exemple, si vous écrivez du contenu qui supporte des pages de catégories ou avec des détails sur les produits et si vous faites un linking intelligent de ces pages support, les moteurs de recherche solliciteront et exploreront aussi les URLs des catégories et des produits d’où vient le lien.

Zappos a un RSS feed pour les pages de marque. Les utilisateurs (et les moteurs de recherche) sont notifiés instamment chaque fois que Zappos ajoute un nouveau produit d’une certaine marque.

Le guidage des robots de recherche

La meilleure façon d’éviter le gaspillage du budget d’exploration sur des URLs à faible valeur ajoutée est d’éviter la construction des liens vers ces URLs premièrement. Quand même, cela n’est pas toujours possible. Par exemple, vous devez permettre aux utilisateurs à filtrer les produits sur la base de trois ou plusieurs attributs. Ou vous voulez permettre aux utilisateurs à envoyer un email vers un ami des pages avec des détails sur les produits. Ou peut-être vous devez offrir aux utilisateurs la possibilité d’écrire des critiques sur les produits. Si vous créez des URLs uniques avec des liens “Email to a Friend “ par exemple, vous pouvez arriver à contenu en double.

Le contenu pour les URLs ci-dessus est en double. Quand même, ces URLs ne doivent pas être accessibles aux moteurs de recherche. Bloquez le fichier email-friend.php dans robots.txt

Ces URLs du type Email to a Friend conduiront, probablement, au même formulaire web et les moteurs de recherche solliciteront et exploreront inutilement de centaines ou milliers de tels liens, en fonction de la dimension de votre catalogue. Vous allez gaspiller le budget d’exploration si vous permettez aux moteurs de recherche à découvrir et examiner ces URLs.

Vous devez contrôler quels liens seront découverts par les moteurs de recherche et quels liens ne seront pas accessibles. Plus il y a des sollicitations inutiles de la part d’un robot pour des pages sans importance, plus réduites sont les chances que le robot arrive aux URLs importantes.

Les directives pour les robots de recherche peuvent être définies aux niveaux différents, dans l’ordre suivant :

  • Au niveau du site, en utilisant robots.txt.
  • Au niveau de page, en utilisant noindex meta tag et des en-têtes (headers) HTTP (HTTP headers).
  • Au niveau d’élément, en utilisant le microformat nofollow.

Les directives au niveau du site précèdent les directives au niveau de la page et celles-ci précèdent les directives au niveau de l’élément. Il est important de comprendre cette priorité, parce que pour permettre à une directive au niveau de page à être découverte et suivie, les directives au niveau du site doivent permettre l’accès à cette page-là. La même chose s’applique aux directives au niveau de page et au niveau d’élément.

Comme observation supplémentaire, si vous voulez garder la confidentialité du contenu sur le site, l’un des meilleurs moyens est d’utiliser l’authentification sur le serveur et un mot de passe pour les zones protégées.

Robots.txt

Quoique les fichiers robots.txt puissent être utilisés pour contrôler l’accès des robots de recherche, les URLs bloquées par robots.txt. peuvent se retrouver dans les indices des moteurs de recherche à cause des liens retour externes qui indiquent vers les URLs « robotisées ». Cela suggère que les URLs bloquées par robots.txt peuvent accumuler de PageRank. Cependant, les URLs bloquées par robots.txt ne transféreront pas du PageRank, parce que les moteurs de recherche ne peuvent pas explorer et indexer le contenu et les liens sur de telles pages. Une exception est la situation des URLs indexées antérieurement, lorsqu’elles transféreront du PageRank.

Il est intéressant à noter que les pages avec des boutons Google+ (service discontinué en 2019) peuvent être visitées par Google lorsqu’un utilisateur clique sur le bouton plus, en ignorant les directives du fichier robots.txt.[19]

L’une des plus grandes méconnaissances concernant robots.txt est qu’il peut être utilisé pour contrôler le contenu en double. La vérité c’est qu’il y a des méthodes meilleures pour contrôler le contenu en double et robots.txt ne devrait pas être utilisé que pour contrôler l’accès des robots de recherche aux documents sur les serveurs. Cela dit, ils peuvent exister des cas où il est possible que nous ne puissions pas contrôler la manière dont le système de gestion du contenu (CMS) génère le contenu ou des cas où nous ne pouvons pas faire des modifications aux pages générées automatiquement. Dans de telles situations, on peut essayer en dernier recours de contrôler le contenu en double par robots.txt.

Chaque site web d’e-commerce est unique, avec ses propres exigences d’affaire spécifiques, donc il n’y a pas une règle générale en ce qui concerne les pages qui doivent être sujet de l’opération d’exploration. Indépendamment des particularités de votre site, vous devrez gestionner le contenu en double soit en utilisant rel=“canonical”, soit des http headers.

Même si les principaux moteurs de recherche n’essayeront pas « d’ajouter au panier » et ne commenceront pas un processus de paiement en ligne ou l’enregistrement d’une newsletter volontairement, les erreurs de codage peuvent les déterminer à accéder des URLs indésirables. En tenant compte de ces aspects, voici quelques types d’URLs communes auxquelles vous pouvez bloquer l’accès :

Les pages du type « panier d’achat » et les pages de paiement

Add to Cart, View Cart, et d’autres URLs de paiement en ligne peuvent être ajoutées sans problèmes en robots.txt.

Si l’URL de View Cart est mysite.com/viewcart.aspx, vous pouvez utiliser les commandes suivantes pour bloquer l’exploration des pages :

User-agent: *
# Do not crawl view cart URLs
Disallow: *viewcart.aspx
# Do not crawl add to cart URLs
Disallow: *addtocart.aspx
# Do not crawl checkout URLs
Disallow: /checkout/

Les directives ci-dessus impliquent qu’il est interdit à tous les robots d’explorer toute URL qui comprend viewcart.aspx ou addtocart.aspx. De la même manière, toutes les URLs sous le répertoire /checkout/ sont interdites.

Robots.txt permet l’utilisation limitée des expressions régulières (regular expressions, abrégé, regex) pour correspondre aux modèles d’URLs, donc vos programmateurs devraient être capables de jouer avec un spectre large des URL. Lorsque vous utilisez des expressions communes, le symbole « * » star signifie « tout », le symbole « $ » signifie « cela finit par » et le symbole « ^ » caret” signifie « cela commence par ».

Les pages avec les comptes des utilisateurs

Les URLs de compte, tout comme Account Login peuvent être bloquées aussi :

User-agent: *
# Do not crawl login URLs
Disallow: /store/account/*.aspx$

La directive ci-dessus signifie que toutes les pages du répertoire /store/account/ ne doivent pas être explorées par les robots des moteurs de recherche.

Vous avez ci-dessous quelques types d’URLs que vous pouvez bloquer.

C:\Users\traiann\Gdrive traianneacsu\carte\capitole\04 Crawl Optimization\Images\CO fig 25 robots.png

Quelques types de pages que vous pouvez bloquer.

Quelques observations sur les ressources surlignées en jaune:

  • Si vous gérez un site web d’e-commerce sur WordPress, permettez aux robots de recherche d’explorer les URLs du répertoire tag; il y avait des jours quand il fallait bloquer les pages tag, mais ils appartiennent au passé.
  • Le répertoire /includes/ devrait ne pas comprendre des scripts qui sont utilisés pour rendre (rendering) le contenu sur les pages. Bloquez-le seulement si vous hébergez les scripts nécessaires pour créer des liens introuvables dans le cadre de /includes/.
  • La même chose s’applique pour les répertoires /scripts/ et /libs/– ne les bloquez pas s’ils contiennent des ressources nécessaires pour rendre le contenu.

Les problèmes liés au contenu en double ou presque en double, tout comme la pagination et le triage, ne sont pas adressés d’une manière optimale par robots.txt.

Avant de charger le fichier robots.txt, je vous recommande de le tester sur les URLs existantes. D’abord, générez une liste des URLs sur le site web, en utilisant l’une des méthodes ci-dessous :

  • Demandez l’aide de vos programmateurs.
  • Explorez le site entier à l’aide du logiciel préféré.
  • Utilisez des fichiers log.

Ensuite ouvrez cette liste dans un éditeur de texte qui permet la recherche en fonction de certaines expressions régulières. Des logiciels RegexBuddy, RegexPal ou Notepad++ sont quelques bons choix. Vous pouvez tester les modèles utilisés dans le fichier robots.txt en utilisant ces logiciels, mais notez qu’il est possible que vous deviez réécrire un peu le modèle regex que vous avez utilisé en robots.txt, en fonction du logiciel utilisé.

Disons que vous souhaitez bloquer l’accès des robots sur les pages de destination pour les campagnes d’email marketing, localisées sous le répertoire /ads/. Le fichier robots.txt va inclure les lignes suivantes :

User-agent: *
# Do not crawl view cart URLs
Disallow: /ads/

Avec RegexPal, vous pouvez tester la liste des URLs un utilisant ce regex simple : /ads/

RegexPal souligne automatiquement le modèle commun.

Si vous travaillez avec des fichiers volumineux, qui comprennent des centaines de milliers d’URLs, utilisez Notepad++ pour découvrir les URLs avec des expressions régulières, parce que Notepad++ peut gestionner facilement les fichiers de grande taille.

Par exemple, disons que vous voulez bloquer toutes les URLs qui finissent par l’extension .js. Le fichier robots.txt inclura la ligne :

Disallow: /*.js$

Pour découvrir les URLs de votre liste qui correspondent aux directives robots.txt en utilisant Notepad++, vous allez introduire “\.js” dans le champ “Find what” et puis utiliser le moyen de recherche selon des expressions régulières :

Moyen de recherche selon des expressions régulières en Notepad++.

Un rapide coup d’œil sur les URLs surlignées en jaune peut éliminer les doutes concernant les URLs qui doivent être exclues par robots.txt.

Lorsque vous devez bloquer les robots de recherche à accéder des matériaux, tout comme les matériaux vidéo, des images ou fichiers .pdf, utilisez X-Robots-Tag HTTP header[20] au lieu du fichier robots.txt.

Notez quand même que si vous souhaitez solutionner les problèmes liés au contenu en double pour les documents non-HTML, utilisez des en-têtes HTTP rel=“canonical”.[21] (rel=”canonical” HTTP header)

Le paramètre d’exclusion

Avec cette technique vous pouvez ajouter sélectivement un paramètre (par ex., crawler=no) ou une ligne (ex., ABCD-9) aux URLs que vous désirez inaccessibles et puis bloquer ce paramètre-là ou ligne en utilisant robots.txt.

D’abord, décidez sur les URLs que vous voulez bloquer.

Disons que vous voulez contrôler l’exploration par les robots de recherche de la navigation facettée, en les interdisant d’explorer les URLs générées par l’application de plusieurs valeurs de filtration dans le cadre du même filtre (connue aussi sous le nom de multi-select). Dans ce cas, vous ajouteriez le paramètre crawler=no à toutes les URLs générées lorsqu’une deuxième valeur du filtre est sélectée sur le même filtre.

Si vous souhaitez bloquer les robots lorsqu’ils essaient d’explorer une URL générée par l’application de plus de deux valeurs de filtrations sur des filtres différents, vous ajouteriez le paramètre crawler=no à toutes les URLS générées lorsqu’une troisième valeur du filtre est sélectée, indépendamment des options sélectées et l’ordre de leur sélection. Voici un scénario pour cet exemple :

Le robot est sur la page de sous-catégorie Battery Chargers.

La hiérarchie est: Home > Accessories > Battery Chargers

L’URL de la page est: mysite.com/accessories/motorcycle-battery-chargers/

Puis, le robot « selecte » l’une des valeurs du filtre Brands: Noco. C’est la première valeur de filtration et vous permettez alors au robot à accéder cette page.

L’URL pour cette sélection ne comprend pas le paramètre d’exclusion :

mysite.com/accessories/motorcycle-battery-chargers?brand=noco

Le robot vérifie ensuite une des valeurs du filtre Style: cables. Parce que c’est la deuxième valeur appliquée, vous permettez encore au robot à accéder l’URL.

L’URL ne comprend pas encore un paramètre d’exclusion: Il ne comprend que les paramètres URL brand et style:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables

Maintenant le robot « selecte » une des valeurs du filtre Pricing: 1. Parce que c’est la troisième valeur de filtration, vous ajouterez le paramètre crawler=no à l’URL.

L’URL devient:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables&pricing=1&crawler=no

Si vous souhaitez bloquer l’URL ci-dessus, le fichier robot.txt comprendra :

User-agent: *
Disallow: /*crawler=no

La méthode décrite ci-dessus empêche l’exploration des URLs générées par la navigation facettée lorsqu’on applique plus de deux valeurs de filtration, mais ne permet pas un contrôle spécifique sur quels filtres seront explorés ou non. Nous allons discuter sur la navigation facettée plus en détail dans la section Navigation facettée du chapitre Pages de listing.

Le management des paramètres URL

Les paramètres URL peuvent poser des problèmes d’efficience au processus d’exploration, tout comme des problèmes liés au contenu en double. Par exemple, si vous implémentez le triage, la filtration et la pagination en utilisant des paramètres, vous aurez finalement un grand nombre d’URLs qui vont gaspiller le budget d’exploration. Google nous montre[22] qu’un nombre de 158 produits sur googlestore.com a généré un chiffre incroyable de 380.000 URLs pour les robots de recherche.

Le contrôle des paramètres URL en Google Search Console et Bing Webmaster Tools peut améliorer l’efficience du processus d’exploration mais ne résoudra pas la cause du contenu en double. Vous devrez résoudre les problèmes liés à la canonicalisation à la source. Quand même, parce que les sites web d’e-commerce utilisent des paramètres URL multiples, leur contrôle correct à l’aide des instruments webmaster peut s’avérer difficile et courant des risques ,incertain . Si vous ne savez pas exactement ce que vous faites, il est mieux d’utiliser un réglage conservateur ou les réglages de base.

Le management des paramètres URL est utilisé le plus souvent pour décider quelles pages doivent être indexées et vers quelle page on doit canonicaliser.

L’un des avantages du management des paramètres URL dans le cadre des comptes webmaster est que les directives au niveau de page (i.e. rel=“canonical” ou méta no-index) s’appliqueront encore, tant que les pages qui comprennent de telles directives ne soient pas bloquées par robots.txt ou d’autres méthodes. Même s’il est possible d’utiliser des expressions régulières d’une manière limitée dans le cadre du fichier robots.txt pour empêcher le processus d’exploration des URLS avec des paramètres, robots.txt écrasera les directives au niveau de page et d’élément.

Notification de Google Search Console regardant les paramètres URL.

Parfois il y a des cas où vous ne devez pas jouer avec les réglages des paramètres URL. Dans la capture d’écran ci-dessus, vous pouvez voir un message qui dit que Google n’a pas de problèmes avec le classement des paramètres URL. Si Google peut explorer sans difficulté le site entier, vous pouvez laisser les réglages de base tels qu’ils sont. Si vous voulez régler les paramètres, cliquez sur le lien Configure URL parameters.

Cette capture d’écran est pour un site web d’e-commerce avec moins de 1.000 SKUs. Vous pouvez voir la manière dans laquelle la navigation facettée a généré des millions d’URLs.

Dans l’image ci-dessus, le paramètre limit (utilisé pour modifier le nombre de produits listés sur une page de catégorie) a généré 6,6 millions d’URLs en combinaison avec d’autres paramètres possibles. Toutefois, parce que le site web a une autorité forte, il reçoit beaucoup d’attention et « amour » de la part de Googlebot et n’a pas de s problèmes d’exploration ou indexation.

Lorsque vous gérez des paramètres, la première chose que vous devez décider est quels paramètres modifient le contenu (paramètres actifs) et quels paramètres ne le modifient pas (paramètres passifs). Le plus efficient serait de faire cela avec les programmateurs du site, parce qu’ils connaissent le mieux l’utilisation des paramètres. Les paramètres qui n’affectent pas la manière dont le contenu est affiché sur la page (par ex., les paramètres de surveillance de l’action de l’utilisateur sur le site – tracking parameters) sont une cible claire en vue de l’exclusion.

Même si Google se débrouille très bien avec l’identification des paramètres qui ne modifient pas le contenu, il vaut la peine de les régler manuellement.

Pour changer les réglages pour de tels paramètres, cliquez sur Edit:

Le contrôle des paramètres URL de Google Search Console.

Dans notre exemple, le paramètre utm_campaign a été utilisé pour suivre la performance des promotions internes et ne modifie pas le contenu sur la page. Dans ce scénario, choisissez “No: Does not affect page content (ex: track usage)”.

Les paramètres Urchin Tracking Module (connus plutôt comme paramètres UTMs) peuvent être consolidés sans problème avec les URLs représentatives.

Pour être sûrs que vous ne bloquez pas les paramètres incorrects, testez les URLs échantillon en le chargeant dans le navigateur. Chargez l’URL et voyez ce qui se passe si vous enlevez les paramètres de surveillance. Si le contenu ne change pas, ce paramètre-là peut être exclu.

Accessoirement, le monitoring des promotions internes par des paramètres UTM n’est pas le choix idéal. Les paramètres UTM sont créés pour des campagnes de surveillance en dehors de votre site web. Si vous souhaitez surveiller la performance interne des bannières de marketing, utilisez d’autres noms de paramètres ou utilisez la fonction event tracking.

D’autres paramètres communs que vous pouvez prendre en considération pour l’exclusion sont les noms d’identification de la session (session IDs), les paramètres UTM (utm_source, utm_medium, utm_term, utm_content et utm_campaign) et les IDs des affiliés.

Un avertissement est nécessaire ici, venu directement de Google.[23]

“La configuration des paramètres du site peut avoir des effets sévères, involontaires, sur la manière dont Google explore et indexe les pages. Par exemple, imaginez-vous qu’un site web d’e-commerce utilise storeID pour l’identification du magasin, tout comme pour vérifier la disponibilité d’un produit dans un magasin:

/store-locator?storeID=123
/product/foo-widget?storeID=123

Si vous configurez storeID de sorte qu’il ne fasse pas l’objet du processus d’exploration, alors /store-locator comme /foo-widget seront affectés. Par conséquent, il est possible que Google ne puisse indexer les deux types d’URLs et ne le montre pas dans les résultats de la recherche. Si ces paramètres sont utilisés pour des buts différents, on recommande l’utilisation des noms différents de paramètres ”.

Dans le scénario ci-dessus, vous pouvez garder la location du magasin dans un cookie.

Les choses se compliquent davantage lorsque les paramètres changent la manière dont le contenu est affiché sur une page.

Un réglage sûr pour les paramètres qui changent le contenu est de suggérer à Google la manière dont le paramètre affecte la page (par ex., triage, filtre, spécification, pagination et ainsi de suite) et d’utiliser l’option de base Let Google decide. Cette approche permettra à Google d’explorer toutes les URLs qui incluent le paramètre visé.

Un réglage sûr est d’informer Google regardant le fait qu’un paramètre change le contenu et de laisser Google décider ce qu’il fait avec ce paramètre-là.

Dans l’exemple ci-dessus, je savais que le paramètre mid modifie le contenu sur la page, donc j’ai mentionné pour Google que le paramètre sorte les produits. Quand même, lorsqu’une décision est prise sur les URLs qui doivent être explorées par Googlebot, je laisse Google à prendre une décision.

La raison pour laquelle je vous recommande à laisser Google décider est due à la manière dont Google choisit les URLs canoniques : il groupe les URLs à contenu en double dans des clusters sur la base du linking interne (PageRank), la popularité du lien externe et du contenu. Puis Google trouve la meilleure URL à indiquer dans les résultats de recherche pour chaque cluster de contenu en double. Puisque Google ne vous informe pas concernant le graphique complet de liens de votre site web, vous ne saurez pas quelles URLs ont réalisé les plus de liens, donc vous ne pouvez pas choisir toujours l’URL appropriée à canonicaliser.

  1. Google Patent On Anchor Text And Different Crawling Rates, http://www.seobythesea.com/2007/12/google-patent-on-anchor-text-and-different-crawling-rates/ ↑
  2. Large-scale Incremental Processing Using Distributed Transactions and Notifications, http://research.google.com/pubs/pub36726.html ↑
  3. Our new search index: Caffeine, http://googleblog.blogspot.ca/2010/06/our-new-search-index-caffeine.html ↑
  4. Web crawler , http://en.wikipedia.org/wiki/Web_crawler#Politeness_policy ↑
  5. To infinity and beyond? No!, http://googlewebmastercentral.blogspot.ca/2008/08/to-infinity-and-beyond-no.html ↑
  6. Crawl Errors: The Next Generation, http://googlewebmastercentral.blogspot.ca/2012/03/crawl-errors-next-generation.html ↑
  7. Make Data Useful, http://www.scribd.com/doc/4970486/Make-Data-Useful-by-Greg-Linden-Amazon-com ↑
  8. Shopzilla’s Site Redo – You Get What You Measure, http://www.scribd.com/doc/16877317/Shopzilla-s-Site-Redo-You-Get-What-You-Measure ↑
  9. Expires Headers for SEO: Why You Should Think Twice Before Using Them, http://moz.com/ugc/expires-headers-for-seo-why-you-should-think-twice-before-using-them ↑
  10. How Website Speed Actually Impacts Search Ranking, http://moz.com/blog/how-website-speed-actually-impacts-search-ranking ↑
  11. Optimizing your very large site for search — Part 2, http://web.archive.org/web/20140527160343/http://www.bing.com/blogs/site_blogs/b/webmaster/archive/2009/01/27/optimizing-your-very-large-site-for-search-part-2.aspx ↑
  12. Matt Cutts Interviewed by Eric Enge, http://www.stonetemple.com/articles/interview-matt-cutts-012510.shtml ↑
  13. Save bandwidth costs: Dynamic pages can support If-Modified-Since too, http://sebastians-pamphlets.com/dynamic-pages-can-support-if-modified-since-too/ ↑
  14. Site Map Usability, http://www.nngroup.com/articles/site-map-usability/ ↑
  15. New Insights into Googlebot, http://moz.com/blog/googlebot-new-insights ↑
  16. How Bing Uses CTR in Ranking, and more with Duane Forrester, http://www.stonetemple.com/search-algorithms-and-bing-webmaster-tools-with-duane-forrester/ ↑
  17. Multiple XML Sitemaps: Increased Indexation and Traffic, http://moz.com/blog/multiple-xml-sitemaps-increased-indexation-and-traffic ↑
  18. How Bing Uses CTR in Ranking, and more with Duane Forrester, http://www.stonetemple.com/search-algorithms-and-bing-webmaster-tools-with-duane-forrester/ ↑
  19. How does Google treat +1 against robots.txt, meta noindex or redirected URL, https://productforums.google.com/forum/#!msg/webmasters/ck15w-1UHSk/0jpaBsaEG3EJ ↑
  20. Robots meta tag and X-Robots-Tag HTTP header specifications, https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag ↑
  21. Supporting rel=”canonical” HTTP Headers, http://googlewebmastercentral.blogspot.ca/2011/06/supporting-relcanonical-http-headers.html ↑
  22. Configuring URL Parameters in Webmaster Tools, https://www.youtube.com/watch?v=DiEYcBZ36po&feature=youtu.be&t=1m50s ↑
  23. URL parameters, https://support.google.com/webmasters/answer/1235687?hl=en ↑