IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel d'URL Rewriting (réécriture de liens)

Exemple avec phpBB 2

Tutoriel d'URL Rewriting (réécriture de liens)

Exemple avec phpBB 2


précédentsommairesuivant

II. Théorie

II-1. Introduction

La problématique : les liens courants sont peu pratiques et très peu optimisés

Il y a plusieurs raisons à cela :
  • Nous, lecteurs humains, avons du mal à lire ces adresses.
  • Elles présentent peu d'informations qui nous intéressent : par exemple, il manque presque systématiquement les mots clefs qui pourraient indiquer le sujet traité par la page liée.
  • Les paramètres peuvent être combinés à volonté et comporter autant de valeurs que l'on peut imaginer : les moteurs de recherche n'aiment pas trop s'amuser à enregistrer toutes les possibilités. Les discussions vont bon train quant à la limite (car il y a une limite) du nombre de paramètres que Google référence : trois, six, etc.
  • De même, il est possible d'intervertir l'ordre des paramètres pour donner une liste presque infinie d'adresses qui sont par ailleurs totalement identiques (si l'on demande plusieurs pages au serveur et que l'on change uniquement l'ordre des paramètres -pas leur valeur-, toutes les pages envoyées en réponse seront 100% identiques).

Le gros de la question est lié au référencement et aux moteurs de recherche : ils ont tendance à laisser de côté les liens qui comportent trop de paramètres (plus de deux, par exemple). Par conséquent, ils ne référencent pas la totalité du site. De même, le manque de mots clefs est un manque à gagner considérable...

La forme des liens pose donc un problème.
La solution est simple : il faut modifier cette apparence. Cependant, techniquement, nous sommes contraints à l'utiliser.

Exemple de lien dynamique
Sélectionnez
http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/?page=2

Une solution trop simple : ajouter un paramètre inutile

Le principe est d'ajouter un paramètre, par exemple nommé "keywords", qui permet d'ajouter une chaîne de caractères servant de mots clefs. Le script ignore ce paramètre puisqu'il est inutile, mais le fait qu'il apparaisse permet aux bots d'analyser les mots clefs de la nouvelle URI.
Tant que l'on a un minimum de contrôle sur son serveur Web, il est préférable de porter son choix sur la solution suivante. Le paramètre inutile ne doit être qu'un dernier recours et utilisé avec précaution, dans la mesure où les moteurs de recherche pourraient l'interpréter comme une tentative de les tromper.

Exemple de paramètre inutile
Sélectionnez
http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/?page=2&keywords=theorie-de-l-url-rewriting

Une meilleure solution : complètement réécrire les liens contenus dans la page Web

C'est ici qu'entre en jeu la réécriture de liens (alias URL Rewriting), un procédé dynamique servant de compromis.
En effet, cette technique modifie l'apparence des liens pour l'utilisateur (vous et moi) sans pour autant modifier la structure du site du côté du serveur Web.

Je sens qu'un exemple rendra l'explication bien plus claire :
  • Imaginons qu'un sujet de notre forum soit accessible par l'URL sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm
  • En réalité, le lien que phpBB reçoit et analyse est : viewtopic.php?t=3678

Plus techniquement, il s'agit d'intervenir avant d'envoyer la page demandée par le client, c'est-à-dire un peu avant la fin de l'exécution du fichier de pied de page. Nous envoyons au navigateur les URLs (les liens) sous une certaine forme modifiée puis, lorsque le client clique sur ces liens, nous intervenons à nouveau avant PHP. Ainsi, nous traduisons l'adresse que le client a demandée dans un format que le serveur Web et PHP pourront interpréter.

Exemple de lien réécrit
Sélectionnez
http://g-rossolini.developpez.com/tutoriels/seo/url-rewriting/page-2-theorie-de-l-url-rewriting.html

Un exemple de transaction : demande / réception d'une page Web

Voici comment se passe une demande de page classique :
  1. Le navigateur demande la page viewtopic.php?t=3678
  2. Le serveur Web ne sait pas traiter la page, il l'envoie donc à PHP
  3. PHP traite le script et renvoie le résultat au serveur Web
  4. Le serveur Web transmet ce résultat au navigateur
Schéma d'une transaction Web simple
Exemple de transaction classique : demande / réception d'une page Web

Il est clair ici que le serveur Web se contente de transmettre les requêtes de pages à PHP et les réponses au navigateur. Quel fainéant...

Maintenant, voici ce que permet l'URL Rewriting :
  1. Le navigateur demande la page sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm
  2. Le serveur Web se rend compte qu'il doit effectuer une opération : il remplace l'adresse demandée par une autre afin que PHP puisse s'en occuper correctement ==> viewtopic.php?t=3678
  3. PHP traite le script et renvoie le résultat au serveur Web
  4. Le serveur Web transmet ce résultat au navigateur
Schéma d'une transaction Web avec l'URL Rewriting
Exemple de transaction d'URL Rewriting : demande / réception d'une page Web

L'URL Rewriting intercale un niveau (d'abstraction) avant PHP.
Il est clair que le serveur Web intervient davantage dans la transaction, il ne se contente plus de simplement servir de courtier.
Concrètement, l'URL Rewriting permet d'avoir des liens en français quelle que soit la technologie du site que nous utilisons (DotClear, phpBB, fait maison, etc.) et sans toucher à sa structure.
Lorsque nous cliquons sur un lien, un dispositif que nous avons mis en place du côté du serveur modifie le lien sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm (qui fait référence à un fichier fictif) en viewtopic.php?t=3678 (qui fait référence à un fichier bien réel) avant que PHP commence à traiter la demande.

En résumé

Je viens de mettre en évidence les deux étapes nécessaires pour mettre en place la réécriture de liens : d'une part, modifier les pages en sortie du serveur Web vers le client (elles ne doivent plus être de la forme viewtopic.php?t=3678 mais sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm) et, d'autre part, modifier les demandes du client au serveur Web (c'est la procédure inverse).
Dès lors, une question fondamentale surgit : quelle forme doivent avoir mes nouveaux liens ?
Si nous n'avons pas la réponse, nous n'irons pas bien loin... Il est temps de se creuser la tête pour trouver les solutions les plus adéquates !

II-2. Le brainstorming

Je vais décrire la méthodologie que nous avons suivie, sur le Forum Cinéma, pour définir la forme de nos nouvelles URLs.
Quand j'ai commencé ce tutoriel, je ne pensais pas m'étendre sur le brainstorming car je me disais que ce serait pénible à lire... En fin de compte, ce sera pénible à lire mais je vais le faire néanmoins : bien choisir sa réécriture est exactement ce qui donne toute son efficacité à la technique entière !

Attention, ça va être long... Je ne vous en voudrais pas de sauter cette description !

Il faut connaître quelques petites règles d'optimisation (SEO) avant de commencer
  • Commençons par les séparateurs de mots. En effet, il est fondamental de séparer les mots (dans l'URL) afin que les moteurs de recherche puissent les confronter à leur dictionnaire et/ou aux termes de la recherche. De nombreux séparateurs sont valables, peu sont recommandés. Nous utiliserons le trait d'union "-" de préférence au slash "/" (peu pratique à gérer, techniquement parlant) et au caractère souligné "_" (déconseillé et peu lisible).
  • Vous noterez que ce tutoriel est hébergé sur "g-rossolini.developpez.com" : j'ai séparé mon prénom (Guillaume) de mon nom de famille (Rossolini), de manière à ce que les moteurs de recherche puissent faire correspondre le nom du domaine à une recherche sur mon nom de famille. Sans le trait d'union, ce nom de domaine serait bien mal optimisé car le mot obtenu aurait peu de rapport avec moi. C'est l'une des règles que nous appliquerons.
  • Il sera parfois nécessaire d'utiliser un deuxième séparateur : ce sera la virgule ",".
  • Il est préférable d'utiliser uniquement les lettres de l'alphabet anglais (aucun accent) et les chiffres arabes. Cela facilite la lecture ainsi que le travail du moteur de recherche, tout en évitant divers problèmes techniques.
  • Il faut absolument éviter d'obtenir plusieurs adresses différentes qui redirigent vers la même page (contenus identiques) : cela s'appelle duplicate content et cela pénalise largement le référencement de nos pages.
  • Il ne faut pas surcharger l'URL en mettant trop de mots clefs.

Rappelons que ce tutoriel a été rédigé en écrivant du code spécifique à phpBB2. Je vais donc illustrer mes propos à l'aide de sa structure... Bien évidemment, la démarche reste similaire quel que soit le site dont on souhaite réécrire les URLs.
Il faut répertorier tous les fichiers présents sur le serveur. Ou plutôt : répertorier tous les scripts pour lesquels nous souhaitons appliquer la réécriture de liens. Il s'agit de tous les points d'entrée du site. Pour chacun d'eux, il nous faut déterminer quels paramètres de type GET ils peuvent accepter et selon quelles combinaisons. Il faut être particulièrement minutieux, sans quoi il restera des liens non réécrits par la suite !
Puisque l'ordre des paramètres dans l'URL peut changer, j'ai trouvé plus simple de déterminer d'abord le nombre de paramètres utiles (non vides) pour pouvoir ensuite déterminer la liste des combinaisons.

Voici les templates d'URLs que nous utilisons :
  • faq.php : 0 ou 1 paramètre
    Pas de surprise, c'est une mise en jambe facile. Nous aurons évidemment deux formes de lien pour ce script : avec ou sans le paramètre.
    De plus, il se trouve que le seul paramètre est "mode" et qu'il n'a qu'une seule valeur possible, ce qui simplifie encore les choses.
    Voici ce que nous avons adopté : foire-aux-questions, bbcode
  • groupcp.php : 0 ou 1 paramètre
    Celui-ci est facile également. Le seul paramètre est "g", à savoir l'identifiant numérique du groupe souhaité. S'il est présent, il suffit de consulter la base de données et d'y récupérer le nom de ce groupe afin de l'ajouter à notre URL.
    Voici ce que nous avons adopté : groupes-d-utilisateurs, groupe-d-utilisateurs-%d-%s
  • index.php : 0 ou 1 paramètre
    Finalement, c'est assez pratique : ce script accepte au maximum un paramètre à la fois, mais ce n'est pas toujours le même. Il peut s'agir de "c" (l'identifiant numérique d'une catégorie de forums) ou bien de 'mark' (pour marquer tous les forums comme lus)
    Voici ce que nous avons adopté : index, categorie-%d-%s, marquer-tous-les-forums-comme-lus
  • login.php : 0 ou 1 paramètre
    Le seul paramètre utile est "logout" avec la valeur "true".
    Il y a une particularité : il faut ajouter l'identifiant de session lors de la construction du lien de déconnexion, sans quoi phpBB n'effacera ni les cookies ni la session.
    Voici ce que nous avons adopté : se-deconnecter-%s, se-connecter.
  • memberlist.php : 0 ou 3 paramètres
    Soit il n'y a pas de paramètre, soit il y a à la fois "mode", "start" et "order".
    Nous avons pris le parti de ne pas gérer ASC et DESC de la même manière.
    Voici ce que nous avons adopté : liste-des-membres, liste-des-membres-par-%s-a-partir-de-%d, liste-des-membres-par-%s-a-partir-de-%d-dans-l-ordre-descendant
  • posting.php : 1 ou 2 paramètres
    Voilà qui commence à devenir intéressant ^^
    Dans le cas d'un paramètre unique, il s'agit de "mode" avec la valeur "smilies"
    Dans le cas de deux paramètres, il s'agit de "mode" ayant plusieurs valeurs possibles et combiné avec "f" (identifiant numérique d'un forum), "t" (identifiant numérique d'un sujet) ou "p" (identifiant numérique d'un message).
    Gestion d'erreurs : il arrive souvent qu'un message ne possède pas de titre. Dans de tels cas, nous avons opté pour utiliser le titre du sujet en remplacement.
    Voici ce que nous avons adopté : nouveau-sujet-dans-le-forum-%d-%s, repondre-au-sujet-%d-%s, citer-le-message-%d-%s, editer-le-message-%d-%s
  • privmsg.php : de 1 à 3 paramètres
    Un seul paramètre : "mode" avec la valeur "post" ou bien 'folder' avec différentes valeurs possibles.
    Voici ce que nous avons adopté : envoyer-un-message-prive, messages-prives-recus, messages-prives-en-partance, messages-prives-envoyes, messages-prives-sauvegardes.
    Deux paramètres : "mode" avec la valeur "post" + "u" avec l'identifiant numérique du destinataire, ou bien "mode" avec diverses valeurs possibles et "p" avec l'identifiant numérique du message concerné.
    Voici ce que nous avons adopté : envoyer-un-message-prive-a-%d-%s, repondre-au-message-prive-%d-%s, citer-le-message-prive-%d-%s, editer-le-message-prive-%d-%s
    Trois paramètres : "folder" avec diverses valeurs possibles + une combinaison de "start", "p" et "mode".
    Je vais abréger le calvaire car vous avez saisi l'idée générale. De plus, tout ce que vous pourriez désirer savoir à se sujet se trouve dans les archives à télécharger.
  • viewtopic.php : de 1 à 3 paramètres
    Je voulais terminer par le plus fun de tous... Sans rentrer dans des détails excessifs, je trouve intéressant de se pencher sur ce script car c'est probablement celui qui pose le plus de problèmes.
    Il peut y avoir une combinaison de divers paramètres : "p", "t", "watch", "unwatch", "postorder", "view" et "highlight". De plus, il est possible que deux combinaisons différentes mènent à des pages en duplicate content. N'ayons crainte, utilisons l'URL Rewriting pour y remédier ! Dans le même ordre d'idée, phpBB a tendance à afficher des paramètres vides (pagination, ordre d'affichage des messages, etc.) et je ne sais pas si les moteurs de recherche les prennent en compte : si c'est le cas, cela génère encore des pages en duplicate content. Heureusement que nous filtrons les paramètres au départ du script d'URL Rewriting...
    Je me suis rendu compte que les paramètres "p" (identifiant numérique d'un message) et "t" (identifiant numérique d'un sujet) affichent parfois la même page. Ce n'est qu'une histoire de pagination. Ainsi, j'ai préféré utiliser systématiquement l'identifiant et le titre du sujet (plutôt que ceux du message) afin d'éviter d'avoir des pages en duplicate content. L'ancre (le dièse "#" à la fin de l'URL) est disponible quel que soit le cas, cela ne pose donc aucun souci.
    Afin de me simplifier la vie, j'ai utilisé la virgule pour séparer le titre (information facultative) des autres paramètres (absolument nécessaires). Il est également possible de se creuser la tête et de trouver d'autres manières de faire (surtout si vous souhaitez conserver le trait d'union) mais, là, j'ai eu la flemme.

Pour faire simple, j'ai utilisé la syntaxe de la fonction sprintf() : %d représente un nombre (généralement un identifiant numérique) et %s représente une chaîne (généralement un titre).

II-3. Le processus de réécriture

Première partie : traduire les requêtes du client

Il s'agit ici de trouver un moyen d'intercepter les requêtes du client avant qu'elles parviennent à PHP. Ce moyen s'appelle ".htaccess" si l'on a un serveur Apache ou bien "HTTPHandlerFactory" si l'on utilise le moteur ASP .NET. Je me concentrerai ici sur la solution d'Apache.
Il s'agit d'un fichier nommé ".htaccess", un simple fichier texte qui va donner des ordres à Apache. Parmi ces ordres, plus communément appelés "directives", figureront les changements à effectuer.

Schéma d'une transaction Web avec l'URL Rewriting
Rappel du schéma vu plus tôt : une transaction d'URL Rewriting


Voici ce que doit contenir le fichier .htaccess pour nos besoins :

Fichier : .htaccess
Sélectionnez
RewriteEngine on
RewriteRule ^profil-([0-9]+).* /phpBB2/profile.php?mode=viewprofile&u=$1 [L]
RewriteRule ^editer-profil.* /phpBB2/profile.php?mode=editprofile [L]
RewriteRule ^sujet-([0-9]+).* /phpBB2/viewtopic.php?t=$1 [L]
etc.

L'option L en fin de ligne indique à Apache qu'il peut s'arrêter de comparer dès qu'il trouve le résultat. Pour plus de détails, consulter le fichier complet inclus dans l'archive à télécharger.
La directive RewriteEngine est fondamentale car elle active le moteur de réécriture. Les directives suivantes, RewriteRule, sont généralement très nombreuses.
Le principe des directives RewriteRule est d'utiliser les expressions régulières. Je n'ai pas l'intention de rentrer dans les détails sur les regexp ici car le chapitre est trop long et car ce n'est pas l'objet de mon article.

Pour nos besoins, il est suffisant de savoir que :
  • [0-9]+ fait référence à un ou plusieurs chiffres à la suite
  • [a-z]+ fait référence à une ou plusieurs lettres à la suite
  • [a-z0-9]+ fait référence à un ou plusieurs caractères (lettres et chiffres confondus)
  • .* fait référence à n'importe quelle suite de caractères (quantité nulle jusqu'à l'infini)
  • Les "lettres" font référence à l'alphabet anglais (aucun accent)
  • Les parenthèses permettent de "capturer" ce qui se trouve à l'intérieur afin de le rappeler dans la suite de la directive : le contenu du premier couple de parenthèses sera appelé par $1, le second par $2 etc.
  • Lorsque plusieurs règles gèrent des chaînes similaires, il faut toujours mettre de la règle la plus précise à la plus générale. Exemple :
Fichier : .htaccess
Sélectionnez
RewriteRule ^chercher-([a-z]+).* /phpBB2/search.php?mode=$1 [L]
RewriteRule ^chercher.* /phpBB2/search.php [L]


Une fois ce fichier placé à la racine du forum, il s'occupera de traduire les adresses que nous lui enverrons plus tard en adresses classiques de phpBB.
Si une adresse réécrite (donc fictive) ne figure pas dans la liste des règles du fichier .htaccess, alors elle ne sera pas traduite, résultant en une erreur 404 ("page non trouvée").

Cette étape est terminée : passons maintenant à la suivante.

Seconde partie : modifier les pages envoyées au client

Ici, c'est déjà plus fun.
En fait, c'est simple à imaginer. La complexité vient de la grande quantité de tests à faire...

Schéma des étapes de la réécriture
Étapes de la réécriture


Il y a deux manières de modifier les liens : dynamiquement et statiquement.

  • Statiquement
    Les premières versions de l'URL Rewriting que j'ai mises en place sur le Forum Cinéma sont de la méthode statique, celle que je trouve trop peu pratique à mettre en place pour être viable... Il m'a fallu un moment pour intégrer tous les concepts et pour me motiver à refaire tout ça à ma sauce !
    La méthode statique est la plus facile et la plus longue, voire la plus frustrante à mettre en place. C'est aussi la moins informatisée et, par conséquent, la plus complexe à maintenir. Il s'agit de parcourir le code source du site complet et de modifier chaque lien à la main. C'est fastidieux et on en oublie toujours :/
    En plus, c'est aussi long à chaque fois que l'on effectue l'installation du Mod...
    L'inconvénient principal est que les mises à jour sont une vieille galère ! On oublie toujours un ancien lien quelque part, ou bien une mise à jour nous restaure un lien à l'ancienne...

  • Dynamiquement (que nous allons utiliser)
    Cette méthode est largement plus simple à mettre en place mais également largement plus complexe à concevoir : pas de souci, je m'en suis chargé pour vous.
    Il faut penser à tous les cas de figure, chose qu'il aurait fallu faire avec la méthode statique de toute manière : ils peuvent varier d'un forum phpBB à l'autre, suivant les Mods installés et/ou l'humeur de l'administrateur.
    L'idée est de laisser phpBB produire l'intégralité de son code HTML, puis d'intervenir en remplaçant d'un seul coup la totalité des liens de la page.

    Pour y parvenir, nous allons utiliser la mise en tampon du code HTML (utilisation d'un "buffer"). En effet, PHP met à disposition quelques fonctions qui permettent de manipuler le contenu destiné au navigateur, avant de l'envoyer au navigateur. C'est exactement comme si nous mettions dans une variable tout le HTML produit par PHP : rien n'est envoyé au navigateur tant que nous ne faisons pas echo de cette variable.

    Je le répète : je ne compte pas expliquer ici en détail la procédure de développement, simplement donner des points de repère.
    L'idée générale est d'appliquer une recherche à base d'expression régulière à la totalité du code HTML qui est sur le point d'être envoyé au client : cela nous permet de récupérer les liens, de les modifier et enfin d'envoyer au client le code HTML modifié.

Voici l'expression régulière que j'utilise :

Expression régulière
Sélectionnez
#<a(.+)href="([^"]+)"([^>]*)>(.*)</a>#Usi
Elle comporte quatre parties entre parenthèses, dites capturées (ce sont celles qui nous intéressent) :
  1. d'éventuelles options comme class="..." et style:"..."
  2. l'adresse complète de la cible du lien
  3. d'autres éventuelles options comme class="..." et style:"..."
  4. le texte, l'ancre du lien (ce que l'on voit affiché dans la page Web)

Ici, les # sont les délimiteurs de l'expression régulière.
Seul le deuxième couple de parenthèses est vraiment important. Les trois autres sont là uniquement pour conserver des paramètres existants, rien de vraiment fondamental. En fait, pour extraire d'autres types de liens à l'aide de mon script final, il y a principalement besoin du 2° couple de parenthèses (logiquement, le 1° est également nécessaire afin de conserver l'ordre).

S'ensuivent les modificateurs :
  • U demande à PHP de trouver autant de résultats que possible (sans quoi le .+ au centre de l'expression pourrait inclure des balises HTML, ce qui nous donnerait une page finale avec un contenu complètement ésotérique - obliger PHP à ne pas être "avare" à l'aide du modificateur Ungreedy permet d'éviter ces éventuels désagréments).
  • s demande au point d'inclure les sauts de ligne.
  • i force l'expression à ne pas tenir compte de la casse (minuscules et majuscules).

Voilà, nous avons notre expression régulière qui nous permettra d'obtenir un joli tableau PHP des liens à modifier.
Il reste le gros du travail, à savoir énumérer tous les cas possibles de combinaisons de paramètres dans l'URL...

J'ai dit plus haut que cela pouvait aller à l'infini. C'est partiellement vrai : dans le cas de phpBB (comme de la quasi totalité des sites), il y a une limite au nombre de paramètres combinés à chaque page. En outre, nous ne nous occuperons pas toujours du contenu de ces paramètres, ce qui réduit encore la charge de travail.
Il reste néanmoins une belle quantité de situations à déterminer !
Le travail ici est similaire à ce qui a été fait pour le fichier .htaccess, seulement à l'envers : il faut constuire la chaîne sujet-3678,tuto-l-url-rewriting-reecriture-de-liens.htm à partir de viewtopic.php?t=3678. On peut également imaginer d'ajouter des informations comme le nom de l'auteur du message, la date... Puisque le nom final sera considéré comme un nom de fichier tout ce qu'il y a de plus normal (j'entends par là que cela ne se verra pas qu'il puisse y avoir des paramètres), nous pouvons ajouter des informations sans avoir peur que le moteur de recherche abandonne, au contraire : cela ajoute des mots clés dont il a tendance à être friand !
Attention hein, je vous vois venir... N'ajoutez pas le message complet au lien : cela n'aurait pas d'intérêt et cela finirait par vous coûter cher en bande passante, sans parler de l'impossibilité de poster un tel lien quelque part sans déformer affreusement la mise en page ! De plus il y a une limite...

Voici comment j'ai procédé.
J'ai pris individuellement chaque fichier de phpBB (profile, viewtopic, etc.) et je me suis demandé quels paramètres GET chacun d'eux admet.
Ensuite, c'est du cas par cas. La seule opération commune à tous les fichiers est de récupérer un titre cohérent en fonction du paramètre principal.

Dans le code, j'utilise des switch imbriqués. Oui, je sais : bouh, pas beau. Il m'arrive même d'en utiliser 3 niveaux (plus des if/else)... J'ai trouvé ça à la fois plus rapide à exécuter et plus clair à relire que de mettre uniquement des if/else.
Comme dans le reste du code source d'un forum phpBB, j'utilise la fonction sprintf() et un fichier de langue (lang_urlrewrite.php). Cela permet de définir des traductions pour ce Mod et, ainsi, d'adapter automatiquement la réécriture de liens selon les préférences définies dans le profil de chaque membre (un membre allemand pourra voir des URLs en allemand) !

Il ne reste plus qu'à mettre la touche finale en convertissant les mots clefs en caractères simples (les lettres de l'alphabet anglais, les chiffres et le trait d'union) avant de les ajouter au lien.
Note : j'ai encore utilisé les expressions régulières dans cette fonction.
Consommer chaud.

En résumé

Nous avons modifié toutes les adresses affichées dans toutes les pages Web produites par un forum phpBB.

Voici les problèmes posés par les liens classiques tels qu'ils étaient à l'origine :
  • Les paramètres des liens sont un problème simplement par leur présence
    Solution apportée : les paramètres sont toujours présents mais cachés au sein du lien. Le moteur de recherche n'a pas vraiment de moyen de se rendre compte de leur présence et le lecteur humain a moins de difficultés à les lire et à les reconnaître, voire à les ignorer.

  • Il arrive que phpBB introduise des paramètres vides dans les liens
    Solution apportée : uniquement les paramètres utiles sont introduits dans les nouveaux liens. Cela permet d'éviter le problème du duplicate content.

  • Il manque des mots clefs
    Solution apportée : nous avons ajouté au texte du lien le sujet (ou le titre, le nom d'utilisateur, etc.) de la page liée.

  • L'ordre des paramètres n'est pas très pratique
    Solution apportée : cela n'est plus un problème, dans la mesure où les paramètres sont cachés. Nous les avons également réorganisés afin qu'ils soient toujours présentés dans le même ordre pour un même type de lien. Dans une certaine mesure, cela facilite encore la lecture.

  • Certains moteurs de recherche ont des règles draconiennes à propos du duplicate content
    Solution apportée : les doublons ont été supprimés (i.e. viewtopic.php?p=502#502 est remplacé par viewtopic.php?t=43#502 puis réécrit).
    Rappel : le # n'indique pas un paramètre. Il est destiné au navigateur de l'internaute car il lui permet de positionner verticalement l'affichage de la page.

précédentsommairesuivant

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2006 Guillaume Rossolini. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.