• 1. Continuer d'assurer les liens vers les pages du site après sa restructuration (évoqué dans l'article "Friendly 404 Errors")
• 2. Créer des liens avec des noms parlants (évoqué dans l'article "Friendly 404 Errors")
• 3. "Tromper" le moteur d'indexation
• 4. Organiser des liens "magiques" permettant de connaître l'efficacité de vos mailings, par exemple

Remarques à l'article http://www.webreference.com/new/011004.html

• a) L'erreur 404 apparaît si la page demandée est statique. N'oubliez pas de paramétrer les messages d'erreur 403 pour les appels erronés des scripts asp, php, jsp ... Vous pouvez faire la redirection sur la même page de gestion de l'erreur.
  
  
• b) La page d'affichage d'erreur est, en général, unique pour tout le site web. Si IIS détecte un lien erroné dans un répertoire existant de votre site, il exécute la page d'erreur dans le contexte de ce répertoire. Si, sur votre page d'erreur vous affichez des images ou intégrez des jscripts en indiquant un chemin relatif, cela risque de ne pas marcher.
  Exemple : vous avez un répertoire www.mysite.com/products/. 
  Votre page d'erreur se trouve dans la racine du site : www.mysite.com/err_404.asp
  Sur votre page d'erreur, vous affichez le logo de la société : <img src="images/logo.gif">
  
  Si l'utilisateur demande un lien erroné www.mysite.com/abc.htm, l'image est affichée correctement. Par contre, si la demande est www.mysite.com/products/abc.htm, le script err_404.asp est exécuté, mais l'image ne sera pas affichée.
  
  Pour résoudre ce problème, utilisez des chemins url absolus ou ajoutez une redirection supplémentaire dans la page err_404.asp sur elle-même pour changer le contexte : Response.Redirect("/err_404.asp?" & Request.QueryString)

  
• c) Faites très attention aux variables "HTTP-REFERRER" et "HTTP-HOST" car ces données sont souvent cachées ou déformées par les serveurs proxy. Evitez de baser vos scripts importants sur ces variables.
  

Assurer les liens après la restructuration du site.

Votre site est connu par vos partenaires, par les moteurs de recherches et par les internautes au travers de liens vers ses différentes pages. Au fil du temps, il est amené à subir des changements au niveau de l'information mise en ligne, comme la structure de pages, scripts et images. Quand vous changez l'adresse d'une page, vous êtes obligé de soutenir en quelque sorte l'adresse précédente, car les ressources externes afficheront toujours le lien vers l'adresse précédente.

Vous pouvez créer un Jscript de redirection ou des tags <META> permettant de réaliser la redirection vers la nouvelle adresse, mais cela vous oblige à garder quand même un morceau de code à l'ancienne adresse. Le moyen d'éviter cela est d'utiliser le mécanisme de redirection de l'erreur 404.

Supposons que vous avez une page de présentation de produit à l'adresse suivante :
www.fw-application.com/quality/ml_demo.asp 

Cette présentation se développe par la suite vers une série de pages contenant la spécification, les fonctionnalités, les événements associés, vous préférez grouper ces pages sous un code de produit, par exemple 02. Les pages du sites deviennent :
www.fw-application.com/prd02_01.asp - spécification
www.fw-application.com/prd02_03.asp - fonctionnalités
...
www.fw-application.com/prd02_05.asp - démo
....

Donc, notre lien ml_demo.asp est devenu prd02_05.asp. Comment faire pour rediriger les appels de l'ancienne adresse ?

• 1. Supprimez la page ml_demo.asp
• 2. Dans le script d'affichage de l'erreur 404, avant toute réponse au client, réalisez un test de lien erroné :
  tmpExpr = Request.QueryString.Key(1)
if not instr(tmpExpr,"ml_demo.asp")=0 then
Response.Redirect("/prd02_05.asp")
end if


Votre redirection est assurée.

Pour généraliser notre petit "routeur", créons une fonction de test :
Sub RedirectRequest(RequestedPage, RedirectPage)
if not instr(tmpExpr,RequestedPage)=0 then 'variable tmpExpr étant une variable globale
Response.Redirect(RedirectPage)
end if
end sub

avec des appels :
if Request.QueryString.Count=1 then
tmpExpr = Request.QueryString.Key(1)
RedirectRequest "ml_demo.asp", "/prd02_05.asp"
end if

Pourquoi avons- nous ajouté un test sur le nombre de paramètres de type "Get" ? Parce que si la page est appelé avec plus de paramètres, cela veut dire que ce n'est pas IIS qui a fait la redirection.

Créer des liens avec des noms parlants

Dans l'exemple précédent, nous avons créé une présentation produit avec la référence suivante :
www.fw-application.com/prd02_01.asp - spécification

Il est vrai que ce type de lien à la lecture n'inspire pas beaucoup quant à son contenu.
Ce produit traite un composant multilangue, cela serait préférable d'avoir un lien du type : 
www.fw-application.com/fwa_multilingual

Avec le routeur de l'exemple précédent, aucun problème. On rajoute un test supplémentaire :
RedirectRequest "/fwa_multilingual", "/prd02_01.asp"

Ainsi notre lien est assuré. Vous pouvez maintenant référencer votre produit sur les sites spécialisés, dans vos mails et articles avec ce lien "parlant".

"Tromper" le moteur d'indexation

L'origine du problème est que les moteurs d'indexation comprennent mal les liens dynamiques. Nos sites, basés sur un affichage d'information en liaison avec une base de données se retrouvent coincés dans cet impasse. Nous affichons les fiches de nos produits, par exemple :
www.mysite.com/fiche.asp?id_prd=1 - pour produit 1
www.mysite.com/fiche.asp?id_prd=2 - pour produit 2

Nous espérons que les moteurs d'indexation viennent inspecter nos pages de produits, les référencer et les proposer en réponse aux chercheurs. Mais manque de bol, les paramètres GET (c.a.d. id_prd=..) ne sont pas toujours exploités par les moteurs d'indexation qui se contentent de visiter la page sans ces paramètres.
Ceci est un problème à résoudre.

Avec le mécanisme de redirection de l'erreur 404, on peut imaginer une petite astuce permettant de tromper les moteurs d'indexation.

Sur la page d'accueil, organisons une liste de liens vers des pages imaginaires sans paramètres get de type html, asp, jsp ou autre. Le fichier de gestion d'erreur va être exécuté à chaque appel de ce lien par le moteur d'indexation et rediriger la demande vers la bonne page. Comme le renvoi vers une autre page se passe du côté serveur, le moteur d'indexation ne s'aperçoit pas de toutes ces redirections. Il référence donc nos liens.
Quand le chercheur clique sur ce lien dans les résultats de recherche, la même procédure est répétée.

Procédure :
1. Sur la page d'accueil, ajoutons des liens : prds/prd1.htm, prds/prd2.htm (ces fichiers n'existent pas sur le site)
2. Au niveau du routeur de l'erreur 404, ajoutez les redirections :
RedirectRequest "/prd1.htm ", "/fiche.asp?id_prd=1"
RedirectRequest "/prd2.htm ", "/fiche.asp?id_prd=2"

Deux petites remarques :

• 1. Utilisez forward avec les jsp plutôt que redirect (vous serez sûr à 100% de tromper le moteur).
• 2. Ce type d'indexation peut être interprété comme du spam
• 3. Le référencement des pages du site contenant des cadres vous oblige à ajouter des petites macros jscript sur vos pages, interdisant la visualisation de la page en plein écran, comme le fait le site de Microsoft.

Organiser des retours de vos mailings en créant des liens "magiques"

Qui ne rêve pas de savoir, quelles personnes ont cliqué sur le lien proposé dans votre mailing, de connaître de quelle source viennent les internautes, en un mot, de mieux pister nos chers visiteurs.

Pour cela, un outil de lien "magique" peut apporter une aide précieuse.
Supposons que votre lien cible soit :
www.fw-application.com/prd02_01.asp - spécification du composant multilangue

Vous créez un lien "parlant" vers cette page : www.fw-application.com/fwa_multilingual (voir les détails dans le châpitre sur les liens "parlants")

Dans votre mail à Monsieur abc@hotmail.com, vous envoyez 
<A href="http://www.fw-application.com/fwa_multilingual.asp?e_mail=abc@hotmail.com">www.fw-application.com/fwa_multilingual</A>

Pour Monsieur Abc, le lien apparaît comme un simple lien vers le site. Après l'appel de ce lien, le serveur détecte l'absence de la page demandée, redirige la réponse vers la page de gestion de l'erreur 404. Dans cette page, votre macro : 

• 1. détecte la page cible : prd02_01.asp
• 2. enregistre l'événement de demande de lien avec un paramètre d'e-mail abc@hotmail.com
• 3. redirige la réponse vers la page cible

Ainsi, après votre mailing, vous savez qui a cliqué sur vos liens et combien de temps il y a eu entre votre envoi et l'arrivé sur votre site du destinataire de message.

Vous pouvez même, après une petite réflexion, organiser une sorte de confirmation de lecture de mail par le destinataire. Envoyez vos idées à l'adresse suivante : dimitri@racine-online.com 

Ces astuces de gestion de l'erreur 404 nous ont permis de construire un outil de gestion de la campagne de mailing, permettant l'envoi des mails personnalisés, la constatation de lecture du mail, du click sur un lien, etc.
Vous pouvez demander des renseignements sur l'outil "Fwa mailing stats" vous permettant d'avoir cette statistique. (le produit n'est pas présenté à l'heure actuel sur le site)