Yvan Poulin, MBA – Vision, Réflexions et Stratégies d’affaires électroniques

Vous avez surement déjà remarqué que certains fournisseurs de services Internet ou certains services de DNS (OpenDNS par exemple) détournent les pages d’erreurs 404 afin d’offrir une page contenant de la publicité. Voilà maintenant que Google ce joint à la partie!

Voilà, si vous utilisez la barre d’outils de Google et que vous visitez un site web qui ne possède pas une page 404 personnalisée, il est fort possible que vous obteniez cette page de détournement en cas d’une erreur 404 (page non existante). À leur défense, Google croit offrir une meilleure expérience utilisateur qu’une page indicant “erreur, cette page n’existe pas, veuillez contacter le webmestre”.

Cliquer ici pour l’explication de Google au sujet de cette fonctionnalité.

Du côté d’un gestionnaire de site web, ce n’est pas vu de la même façon. Si l’on observe attentivement la page en question, on voit en fait que le visiteur a maintenant un pied à l’extérieur de notre site web et il ne lui reste plus qu’à utiliser l’outil de recherche afin d’aller ailleurs. Bye bye la clientèle!

Il existe une solution facile, il suffit de personnaliser la page 404 par défaut de votre serveur web. Il y a quelques mois, j’ai lû un billet sur le blogue de Michel Leblanc concernant la redirection des pages d’erreurs 404 à des fins publicitaires et j’ai trouvé l’idée très intéressante quoi que j’ai finalement opté pour la solution d’offrir un plan du site (sitemap) à la place de la page 404 par défaut dans mon serveur IIS. Avec la solution du sitemap, les visiteurs de mon site web ont toujours une autre option! Le sitemap présente les diverses catégories et sous-catégories de produits de l’entreprise et ils peuvent diriger leurs recherches vers les produits convoités.

written by Yvan Poulin, MBA

Pour tous les gestionnaires de sites web (commerce électronique, blogue, et autres), il est primordial d’user du maximum des outils mis à notre disposition pour améliorer notre rang au niveau des moteurs de recherche (j’entends encore mon consultant en markéting interactif me marteler les oreilles avec cette recommandation).

Tout semble si rose dans le monde de Linux/Apache et de l’utilisation de mod_rewrite. Ce qu’il ne faut pas oublier, c’est que mod_rewrite ou tout autre application qui manipule une URL le fait lorsque ladite URL est interceptée au niveau du serveur web. Du côté d’applications Linux telles que WordPress, OSCommerce, etc… contiennent déjà un module permettant de faire l’affichage et/ou la manipulation des URL. La plupart de ces applications ou modules requièrent le complément de mod_rewrite afin gérer la réécriture des liens.

Le problème du côté Microsoft IIS, est que le complément pour la manipulation des URL est très récent et pas aussi robuste que du côté Linux. De plus, 99 % des logiciels Windows ne fournissent pas le support de réécriture lors de l’affichage des hyperliens. Effectivement, il est très important de comprendre qu’à la base, une application de type mod_rewrite se fou éperdument de l’affichage des liens lors de la construction, par exemple, d’une page en mode asp.net.

Le projet (tournant sur IIIS) sur lequel j’ai travaillé a donc requis 3 étapes afin d’enrichir les URL.

1. Installer un support logiciel de type mod_rewrite sur IIS 6. Mon choix s’arrêtant sur ISAPI_Rewrite de la compagnie Helico Tech. Il existe une version légère (lite) et gratuite du logiciel qui répondait à mes besoins.
2. Il a aussi fallu modifier le générateur de pages asp.net afin de créer une structure qui permettrait l’enrichissement des URL. Par exemple : www.monsite.com/marque-du-produit-description-du-produit/code-interne-asp. C’est à cette étape que le plus gros du travail était nécessaire. Il a fallu créer une nomenclature qui à la fois permettrait d’enrichir l’hyperlien de mots clefs, et aussi à la fois de faire la conversion pour le moteur asp.net de l’application.
3. Finalement, il ne restait plus qu’à créer quelques règles normalisées dans ISAPI_Rewrite afin de faire la conversion des URL en entrée dans IIS avant le traitement par le moteur asp.net

written by Yvan Poulin, MBA