Les fanatiques du référencement le savent, la profondeur des url a un impact sur le référencement naturel. Dans SharePoint, les pages d’un site de publication étant situées dans une bibliothèque “Pages”, les url sont sous la forme http://www.monsite.com/sous-site/Pages/ma-page.aspx et ont donc un niveau d’arborescence inutile voir polluant d’un point de vue référencement.

Dans le cadre d’un projet de site internet hébergé sur SharePoint 2010, on m’a demandé de réfléchir à une solution d’url rewriting pour faire disparaitre /Pages/ de l’url.

Le challenge dans cette tâche était de la réaliser sans apporter de contrainte pour les auteurs du site et surtout sans impacter le fonctionnement de SharePoint.

C’est alors que j’ai découvert le plug-in Url Rewrite (actuellement en RC v2.0) pour IIS 7.0. Celui-ci a pour particularité de permettre l’url rewriting en entrée et en sortie via des règles équivalentes à des replace().

Afin de ne pas impacter le “back-office” de SharePoint, on peut étendre la web application (interne) et configurer Url Rewrite sur une 2ème web application (publique).

Les 2 web applications reposent alors sur la même base de données de contenu mais sont configurables indépendamment l’une de l’autre au niveau IIS :

• http://edit.monsite.com (Zone Default) l’application utilisée par les auteurs, accessible depuis le réseau de l’entreprise. On ne modifie pas la configuration de cette web app. 
• http://www.monsite.com (Zone Internet) l’application publique pour les internautes, sur laquelle on désactive l’authentification Windows. C’est sur celle-ci que l’on configure Url Rewriter.

Une fois Url Rewriter RC v2.0 installé, lorsqu’on sélectionne un site dans IIS, une nouvelle icone apparait permettant d’accéder à l’interface de paramétrage d’url rewriting.

L’interface de paramétrage permet de définir des règles pour le rewriting d’entrée et le rewriting de sortie basées sur des expressions régulières :

Inbound rules

La liste du haut permet de spécifier les règles de redirection selon l’url requêtée. Seule la partie relative au site est testée.

Par exemple pour  http://www.monsite.com/site1/site2/default.aspx, c’est la chaine “site1/site2/default.aspx” qui est testée avec nos expressions régulière. Lorsqu’un utilisateur requête l’application IIS, les règles sont testées (et appliquées en cas de succès) dans l’ordre affiché. En l’occurrence, nous pouvons transformer cette adresse en http://www.monsite.com/site1/site2/Pages/default.aspx, la véritable url de la page que sait interpréter SharePoint.

Dans la capture d’écran, la première règle correspond au cas de la chaine vide. Son rôle est que si l’internaute requête http://www.monsite.com, c’est la page http://www.monsite.com/Pages/default.aspx qui sera servie sans pour autant rediriger l’utilisateur via un code 302. C’est un cas particulier pour la page d’accueil.

La deuxième règle correspond au cas d’une page située dans une bibliothèque de pages (contient /Pages/). Dans ce cas l’url n’a pas besoin d’être réécrite puisqu’il s’agit du cas '”natif”, d’où le Action Type = None.

La troisième règle correspond au cas d’une page située dans /_layouts/. Là encore, on ne modifie pas l’url.

Enfin, la 4ème règle permet de convertir une url http://www.monsite.com/site1/default.aspx en http://www.monsite.com/site1/Pages/default.aspx. Les balises {R:1} et {R:2} correspondent aux groupes matchés par l’expression régulière, équivalent de $1 et $2 dans les langages classiques.

Grâce à ces 4 règles, on bénéficie d’un Url Rewriting satisfaisant permettant d’accéder aux pages de publication SharePoint sans préciser /Pages/ dans l’url, pour un référencement plus efficace.

Récapitulatif des règles d’entrée

Outbound rules

Maintenant la partie la plus fun, et la nouveauté de la RC 2.0 de Url Rewriter : le rewriting de sortie !

Les règles du 2ème bloc (de la capture plus haut) permettent de modifier le contenu HTML d’une page servie par l’application avant qu’elle ne soit renvoyée à l’utilisateur. Ce mécanisme permet de supprimer /Pages/ de toutes les url trouvées dans la réponse HTML.

Attention cependant, ce “filtre” s’applique sur tout ce qui est renvoyé par le site web. Cela inclut les images, les scripts, les fichiers… Si on ne limite pas le périmètre de notre transformation aux seuls fichiers HTML, on s’expose à des erreurs serveur.

On va donc configurer une pré-condition permettant de limiter le périmètre de notre transformation aux réponses http dont le content type  commence par “text/HTML”, comme ceci :

Une fois notre pré-condition configurée, on peut configurer notre rewriting de sortie :

Cette règle se veut très simple afin de limiter l’impact sur les performances : le processus de transformation en sortie étant gourmand en ressources, plus notre expression régulière sera simple, plus l’impact sur les performances sera faible. Cette règle va donc transformer toutes les occurrences de /Pages/nom-de-page.aspx en /nom-de-page.aspx sans se préoccuper du fait qu’il s’agisse ou non d’une url. Attention donc aux cas particuliers :)

Dans mon cas, je ne souhaite pas seulement modifier les url des liens mais aussi les url sous forme de texte, pour modifier l’affichage des résultats de recherche par exemple. Pour limiter la transformation aux liens, j’aurais pu utiliser un filtre prévu à cet effet (“Match the content within:” sur la capture ci-dessus) afin de gagner en performances.

Une dernière chose importante, d’après mes tests il faut désactiver la compression dynamique sur le site IIS sous peine d’erreurs serveur.

Règle de sortie

Conclusion

L’impact sur les performances n’est pas négligeable (traitement supplémentaire + incompatibilité avec la compression dynamique), mais dans un cas où le référencement est stratégique cette solution s’avère efficace et relativement simple à mettre en place. Sa principale force est d’être 100% transparente pour l’application SharePoint.

Compatible avec SharePoint 2007 et SharePoint 2010,  le réel pré-requis est IIS 7.0.

Des tests de montée en charge étant prévus dans les semaines à venir, je ne manquerai pas de publier un retour d’expérience sur cette solution.