underscores toujours déconseillés dans les URL ?

WRInaute discret
Bonjour,
Nous sommes sur la refonte de notre site avec l'urlrewriting.
Nous avons besoin de plusieurs séparateurs et utilisons - / et _

Google devais considérer l'underscore comme séparateur.
Qu'en est-il aujourd'hui ?

Pensez-vous qu'il soit rentable de remplacer le _ par + dans nos urls ?
Le site étant référencé depuis 8 ans, le gain est-il plus grand que le fait de perdre toute l'ancienneté des url ( même avec des redirections 301 bien sur ) ?

Merci d'avance pour vos avis,
Astus
 
WRInaute accro
L'url la plus simple est toujours la meilleure

Sinon l'underscore marche aussi bien que le tiret. C'est juste plus naturel pour les internautes quand il y a un tiret.
Mais depuis 12 mois je n'ai plus trop suivi l'actu google et ça a peut-être changé
 
Olivier Duffez (admin)
Membre du personnel
indigene a dit:
l'underscore marche aussi bien que le tiret
ce n'est pas ce que j'observe : Google ne considère toujours pas l'underscore comme un séparateur (ce qui semble logique du point de vue informatique).

si vous n'avez pas encore d'underscores, évitez d'en mettre dans vos URL
si vous en avez, réfléchissez bien avant de tout casser (juste pour les remplacer)
 
WRInaute accro
Google devais considérer l'underscore comme séparateur.
Qu'en est-il aujourd'hui ?

Google ne separe pas les mots, si tu n'as pas le tiret, par ex :

- mon_domaine_a_moi.com sera interprete comme : mondomaineamoi

Alors qu'avec le tiret : - mon-domaine-a-moi.com il separera bien les mots

:D
 
WRInaute discret
ok, c'est bien ce que nous pensions.

Le tout est de savoir maintenant si le gain en long train est supérieur au fait de changer les urls

Pour de pages ou l'on référence des personnes avec nom et prénoms, nous avons actuellement ( il faut tenir compte des prénoms avec espace et noms avec apostrophe:

Exemple : Jean Pierre L'ablabla

Actuellement : jean-pierre_l_ablabla.html

A transformer en : jean-pierre+l.ablabla.html

Peut-on espérer un gain en terme de référencement ?
 
WRInaute discret
Ce serait bien sur idéal mais on en ici dans le l'url rewriting ou on va générer plusieurs milliers de page avec un seul script qui va chercher les infos dans une base de donnée.
Il faut bien pouvoir détecter ce qui est le nom, le prénom et s'il y a une apostrophe.
On est ici dans un impératif technique et non pas un simple choix d'url.
Il faut donc impérativement 3 séparateurs différents, sinon on prendrais le tiret uniquement et on ne se poserai pas de question...
 
WRInaute accro
Et quand est-il du tilde ~ ?
Il serait pris comme un underscore ?
Sinon il y a également la virgule mais ça peut poser des problèmes quand on communiques les urls sur des forums : elles peuvent être tronquées au niveau de la virgule
 
Olivier Duffez (admin)
Membre du personnel
difficile de se prononcer sans connaitre le site, mais est-ce vraiment une bonne idée de casser toutes vos URL ?
 
WRInaute discret
Avec la structure de notre site, on ne peut pas modifier une seule fiche au sein d'une rubrique.
Donc pour les nouvelles fiches ou les mises à jour, on ne peut pas mélanger ( pour une rubrique, c'est un seul fichier qui génère toutes les pages à partir d'une base de donnée )
Nous venons de faire le test sur la rubrique architectes avec -+. au lieu de -_
Nous avons mis en place les redirections 301 et mis à jour le sitemap.
Le sitemap est à 0 pages indexées dans gwt, on va voir la vitesse ou il prend les pages et s'il en indexe plus ou moins qu'avant, ce sera déjà une première indication.
 
WRInaute discret
je ne sais pas si vous lisez vraiment les messages... Si nous pouvions mettre que des tirets, nous ne nous poserions même pas la question et ce topic n'existerais pas.

Une rubrique de notre site est composée d'une base de donnée avec les renseignements d'une fiche.
Le script qui génère la page appel la base avec le code postal, le nom et le prénom.

Si dans nos urls, on ne met que des tirets, cela nous donnerai quelque chose du type:

/00000/marie-aude-la-moderatrice.html

Comment on va pouvoir savoir quel est le nom et prénom pour appeler la fiche dans la base ????
prénom: marie
nom: aude la modératrice
ou alors
Prénom: marie aude la
nom: modératrice
.....
Imaginez en plus que nous avons pas mal de noms avec apostrophe....

Il nous faut donc IMPERATIVEMENT, 3 séparateurs différent, c'est la structure qui le veut.

Comme il n'existe pas 36 séparateurs qui fonctionnent et qui donnent des url propres, nous utilisons bien sur le tiret mais il en faut 2 autres.
Si nous oublions l'underscore, il nous reste apparemment d'après tous les conseils que nous avons lu, le plus et le point. La virgule posant aussi problème.

Donc s'il vous plait, ne répondez plus de ne mettre que des tirets, répondez à la question ou ne répondez pas...
Le site est celui du profil, allez voir si vous ne comprenez pas tout.
Le site est programmé sans cms, nous programmons directement à partir du bloc note.
Merci d'avance.
 
WRInaute accro
astus a dit:
je ne sais pas si vous lisez vraiment les messages... Si nous pouvions mettre que des tirets, nous ne nous poserions même pas la question et ce topic n'existerais pas.
Excusez-moi votre excellence....

astus a dit:
Une rubrique de notre site est composée d'une base de donnée avec les renseignements d'une fiche.
Le script qui génère la page appel la base avec le code postal, le nom et le prénom.
C'est couillon si on a deux Jean Martin habitant à Paris 13 :D :D :D

astus a dit:
Il nous faut donc IMPERATIVEMENT, 3 séparateurs différent, c'est la structure qui le veut.
Ben non

partie-1--partie-2--partie-3

astus a dit:
Donc s'il vous plait, ne répondez plus de ne mettre que des tirets, répondez à la question ou ne répondez pas...
Le site est celui du profil, allez voir si vous ne comprenez pas tout.
Le site est programmé sans cms, nous programmons directement à partir du bloc note.
Merci d'avance.
Merci d'avance d'être un peu plus aimable, et de comprendre que si on insiste pour que vous n'utilisiez que les tirets, c'est pas pour des prunes...
 
WRInaute discret
Ah, merci de ce message constructif.

Le but n'était pas de vous froisser, mais d'avancer, toutes nos excuses...

Donc pour vous, il vaut mieux deux tirets qu'un plus.

Nous avons aussi écarté l'apostrophe, mais est-il vraiment gênant dans une url, pas en tant que séparateur mais comme caractère tout simplement:

Jean Michel l'ablabla deviendrais alors jean-michel--l'ablabla.html

qui serait donc mieux que jean-michel+l'ablabla.html donc...
 
WRInaute accro
Comment on va pouvoir savoir quel est le nom et prénom pour appeler la fiche dans la base ????
prénom: marie
nom: aude la modératrice
ou alors
Prénom: marie aude la
nom: modératrice

Si ta base est bien construite...en respectant 1 ordre :

Nom : Tartempion
Prenom : Marie-aude
Fonction : moderatrice

Tartempion-marie-aude-moderatrice.htm

Nom : l'ablabla
Prenom : pierre-andre
Fonction : rentier

lablabla-pierre-andre-rentier.htm

Arrete de focaliser sur l'apostrophe

je ne sais pas si vous lisez vraiment les messages...
Faut bien lire les reponses aussi
Il nous faut donc IMPERATIVEMENT, 3 séparateurs différent, c'est la structure qui le veut.
NON - revois ta structure



:D :D :D
 
WRInaute discret
le problème est que tous les prénoms ne sont pas composés et que le nom peut comporter plusieurs espaces.

albert-de-la-tronche-en-bias.html
et
albert-jean-rene-fox.html

Même avec une base bien construite, comment séparer nom et prénom. Sans avoir des séparateurs différents, impossible de découper ensuite.

même si je ne veux pas focaliser sur l'apostrophe :lol: , si dans ma base j'ai comme nom l'ablabla, si j'enlève l'apostrophe dans le rewriting, je ne pourrai pas trouver lablabla dans ma base...
 
WRInaute impliqué
Perso, je mettrai l'ID de la fiche à la fin de l'url : albert-jean-rene-fox-1234.html
Là, peu importe quel est le prénom, le nom, etc. L'ID permet de sortir la bonne fiche.
 
WRInaute accro
astus a dit:
Donc pour vous, il vaut mieux deux tirets qu'un plus.
Oui. Le + et le . sont des éléments qui ont une fonction, ce ne sont pas de simples séparateurs.

astus a dit:
Nous avons aussi écarté l'apostrophe, mais est-il vraiment gênant dans une url
Clairement. Au mieux il sera transcodé. Au pire, pas compris.

astus a dit:
jean-michel--l'ablabla.html
jean-michel--l-ablabla.html

astus a dit:
Même avec une base bien construite, comment séparer nom et prénom. Sans avoir des séparateurs différents, impossible de découper ensuite.
Je croyais que vous n'aviez pas de base ?

Vous faites une confusion entre le nom et l'identifiant

Même en ne mettant pas un identifiant numérique, ce qui serait quand même le plus simple, vous pouvez "calculer" un identifiant lablabla qui correspond à un affichage l'ablabla
Des fois, en croyant gagner du temps, on en perd. Là votre système est manifestement fragile, il faudra le faire évoluer un jour ou l'autre.
L'ID numérique étant la meilleure solution.

Après c'est du rewrite, votre excellence...
 
WRInaute discret
Nous avions effectivement envisagé l'id dans l'url mais pas retenu pour 3 raisons:
Nous avons déjà des url un peu longues, ajouter 5 ou 6 chiffres qui n'apportent rien ne nous a pas paru pertinent.
Avec l'id, il y a un risque de duplicate content car avec n'importe quel nom, on arrive sur la même page alors qu'actuellement nous maîtrisons exactement ce risque en renvoyant une 410 si un caractère de l'url n'est pas bonne.
Avec cette technique, le piratage de nos base devient très facile avec une simple boucle qui incremente l'id ( notre site comporte plus de 2 millions de pages, nos bases représentent 10 ans de travail ...)

Pour ce qui est de l'apostrophe, il faudra nous expliquer comment "calculer"... C'est un caractère comme un lettre qui peut se situer n'importe ou ( un breton L'Helgoualc'H ou encore Manip M'Ebobisse, ce sont des nom de médecins que nous avons sur notre site ), nous ne voyons toujours pas sans séparateur comment ensuite interroger notre base...

En tout cas merci de vos avis, ( surtout à la duchesse modératrice :lol: )

Il n'y a pas de vérité, tout est une question de compromis.
 
WRInaute accro
astus a dit:
Avec l'id, il y a un risque de duplicate content car avec n'importe quel nom, on arrive sur la même page
Non il suffit que le script de rewrite vérifie que le reste de l'url correspond bien à un identifiant connu.

astus a dit:
Avec cette technique, le piratage de nos base devient très facile avec une simple boucle qui incremente l'id ( notre site comporte plus de 2 millions de pages, nos bases représentent 10 ans de travail ...)
Oui enfin pas plus que des interrogations de vos pages de recherches avec le scrap des pages de résultat... là encore la solution est ailleurs (limitation des interrogations, etc)
 
WRInaute accro
astus a dit:
Avec l'id, il y a un risque de duplicate content car avec n'importe quel nom, on arrive sur la même page alors qu'actuellement nous maîtrisons exactement ce risque en renvoyant une 410 si un caractère de l'url n'est pas bonne.

Le script récupère l'id
accède à la base
récupère nom et prénom
reconstitue l'url
vérifie que l'url de la page correspond bien à l'url reconstituée
renvoit une 404 si pas matching

Exemple : si la page demandée est jean-martin-208.html et que l'identifiant 208 en base correspond à jacques durand, "jean-martin-208.html" <> "jacques-durand-208.html" donc ça dégage en page d'erreur 404 avant d'afficher quoi que ce soit
 
WRInaute impliqué
Une autre solution consisterait à stocker les URLs directement en base de données.
Ainsi, il te suffit de rechercher "albert-jean-rene-fox.html" pour trouver le bon.

Par contre, c'est pas très flexible car cela nécessite de régénérer toutes les URLs en cas de changement. Et niveau recherche en BDD, c'est tout de même moins performant qu'un bon ID.
 
WRInaute accro
Souci de conception ...

Perso je ne me prend pas la tête avec un id ou la pseudo reconstitution d'éléments tirés de l'url, j'ai mis l'url en base de données comme ça pas de prise de tête ... De toute façon vous aller faire une requête alors qu'est ce qui vous empêche d'avoir un champ qui règle le problème et du coup les règles de conception d'url sont distinctes des besoins d'exploitation. ça ouvre, de plus, la porte a une gestion facile des anciennes url avec un script dédié a chaque cas ... Vue la taille des bases qu'on peut avoir c'est pas un souci majeur non plu.

edit > @Blount désolé j'avais pas lu en détail ton intervention :D
 
WRInaute accro
Blount a dit:
Par contre, c'est pas très flexible car cela nécessite de régénérer toutes les URLs en cas de changement.
Pas forcement si tu associée un champ genre "type redirection" ; "nouvelle url" etc...
Blount a dit:
Et niveau recherche en BDD, c'est tout de même moins performant qu'un bon ID.
hash de l'url demandé ? > format constant, maîtrise de la taille, optimisation possible ?
 
WRInaute impliqué
zeb a dit:
Blount a dit:
Et niveau recherche en BDD, c'est tout de même moins performant qu'un bon ID.
hash de l'url demandé ? > format constant, maîtrise de la taille, optimisation possible ?
Oui, j'avais ça en tête aussi. En mettant un CHAR(32) pour le md5 ou CHAR(40) si sha1.
Je n'ai jamais fait d'essai pour voir si c'était plus performant. Il faut penser à mettre un index.

Par contre, il faut quand même conserver un champ contenant l'URL. Ça permet de l'afficher sans la générer à chaque fois.
 
WRInaute discret
Super idée Blount !
On construit l'url dans la base de donnée, cela permet de régler d'un coup les problèmes d'accent, caractères spéciaux et apostrophe.
La effectivement, on peut rewriter uniquement avec des tirets et tout le monde est content :D
C'est la solution idéale, on adopte.
Merci encore...
 
Nouveau WRInaute
Bonjour,

Il existe plusieurs façons de passer des params dans les urls, c'est d'ailleurs ce que j'utilise dans un système MVC que j'ai développé. On peut faire ça par exemple :
/section/param1/param2/blabla.html
/section/mon-beau-titre-pram1-param2-param3.html
/param-titre.html
Ext...

Ensuite il faut bien sûr développer un bon système de routage. Pour ma part tout passe par un seul fichier comme sur les framework Zend, Cakephp...
 
Nouveau WRInaute
Il faut penser "expérience utilisateur" tapez des _ n'arrive jamais donc il faut pas en mettre, préfère les -
 
Haut