L'arborescence, oui mais

WRInaute occasionnel
Bonjour à tous.

Lors de la structuration d’un site, on crée une arborescence et on la confronte ensuite à différents scénarios puis on vérifie finalement comment les visiteurs appréhendent la chose.

Soit par exemple les dossiers :
— DossierA contenant les pages : pageA1, pageA2, pageA3.
— DossierB contenant les pages : pageB1, pageB2, pageB3.

1. L’arborescence classique

L’arborescence du site sera alors :
Index
DossierA
\— pageA1
\— pageA2
\— pageA3
DossierB
\— pageB1
\— pageB2
\— pageB3

2. L’arborescence de stockage

Oui, mais on trouve de nombreux scripts qui mettent toutes les pages dans un seul et unique endroit.
Sur vBulletin, on verra par exemple :
http:/exemple.fr/showthread.php/4436-la-creation-de-sites
alors que le visiteurs croira que la la discussion se trouve dans le dossier forum/referencement/generalite/

Ainsi, de manière générale, les pages se nommeront alors :
DossierA-pageA1
DossierA-pageA2
DossierA-pageA3
DossierB-pageB1
DossierB-pageB2
DossierB-pageB3

3. Alors ?

Les deux méthodes ne changent rien pour le visiteur. Pour lui, l’arborescence existe. S’il n’examine pas les URL, il pensera que les pages pagesA1, pageA2, et pageA3 sont comprises dans un dossier dossierA. En fait, seule la méthode de stockage change.

Pour le référencement, (je ne parle pas de la maintenance du site) est-il préférable d’utiliser la méthode classique avec des URLS de la forme :

http:/exemple.fr/dossierA/pageA1.php
http:/exemple.fr/dossierA/pageA2.php
etc. (c’est-à-dire organiser chaque page dans des dossiers différents et tout mettre au même endroit)

ou bien

http:/exemple.fr/dossierA-pageA1.php
http:/exemple.fr/dossierA-pageA2.php
etc. (c’est-à-dire organiser chaque page avec un préfixe)

Merci pour vos explications.
 
Olivier Duffez (admin)
Membre du personnel
je ne pense pas qu'il y ait bcp d'écarts (en termes SEO) entre /dossierA/pageA1.php et /dossierA-pageA1.php
par contre, à mon avis le critère SEO le + important pour une URL est de rester stable le plus longtemps possible. Et donc éviter de faire apparaître dans l'URL l'arborescence, sauf si on pense qu'elle n'a aucune chance de changer

par exemple ce topic est sur https://www.webrankinfo.com/forum/t/larborescence-oui-mais.182663/ sans référence à l'arborescence actuelle Accueil forum > Forums référencement > Débuter en référencement

d'ailleurs, à mon humble avis, une très grande majorité des internautes se contrefichent de la structure des URL (pour ceux qui savent ce que c'est)
 
WRInaute discret
WebRankInfo a dit:
d'ailleurs, à mon humble avis, une très grande majorité des internautes se contrefichent de la structure des URL (pour ceux qui savent ce que c'est)
:lol: :lol: :lol: je m'entends encore au téléphone avec un client : "tapez mon-site.com dans la barre d'adresse" "La quoi ???". A s'arracher les cheveux par moment !

Si on modifie une url, que ce soit au niveau de l'arborescence ou du re-writing, perd elle du jus, même si elle n'a pas de BL qui pointent vers elle ? Même en faisant une 301 ?
 
WRInaute accro
En fait pour le SEO ce qui compte n'est pas l'arborescence de stockage (création de sous-répertoires sur le serveur), ni l'arborescence de présentation (afficher des sous-répertoires dans l'url, ou le nom des catégories dans l'url).
Pour le SEO, ce qui compte est l'arborescence des liens.

Par exemple si tous les articles A font des liens vers une page B2, alors B2 sera considérée comme un sous-répertoire de A bien que la page B2 se trouve physiquement dans un répertoire B.

Ce qui compte pour le SEO c'est la logique de l'organisation et non le stockage physique.

Concernant le nommage des urls :
Moi personnellement je différencie les urls en 4 parties :
- domaine (lui même constitué du sous-domaine, domaine, extension)
- chemin
- nom du document
- extension du document

Selon moi, le nom du document pèse plus lourd dans le SEO que le chemin.
Donc j'évite de mettre des noms de catégories dans le nom du document sauf si c'est vraiment important pour le ref. Je les met dans le chemin.
Exemple : si je fais une page sur les chats. je vais préférer cette forme d'url :
http://www.example.com/animaux/chats.html
à celle-ci :
http://www.example.com/animaux-chats.html

La seconde forme va noyer le mot clé important ("chats") avec d'autres mots clés qui ont moins d'importance.
Avec la première forme, le mot clé le plus important de la page prend toute sa valeur. Le mot "animaux" est en fait qu'accessoire. Il ne pèse pas très lourd dans le ref. On pourrait presque s'en passer. Il permet seulement d'organiser un peu les choses et rappelle à l'utilisateur un semblant de fil d'ariane. Donc il a son utilité, mais marginale.
L'important qu'il se trouve dans l'url c'est que l'url est affichée dans les résultats de moteurs de recherche. Ainsi un utilisateur pourra faire très facilement la différence entre une page qui s'appellerait /animaux/chats.html et une autre page qui s'appellerait /dialogue/chats.html. Dans ce derniers cas on ne parle plus du tout d'animaux mais de dialogue en ligne (autre signification du mot chat). Donc c'est clair pour l'utilisateur et ça le rassure sur le fait qu'il va bien tomber sur une page qui correspond à sa recherche.
 
WRInaute accro
Newbipastaper a dit:
Si on modifie une url, que ce soit au niveau de l'arborescence ou du re-writing, perd elle du jus, même si elle n'a pas de BL qui pointent vers elle ? Même en faisant une 301 ?

Si une url n'a aucun BL, elle n'a aucun jus.
Si il y a redirection il y a risque de perte, même minime

indigene a dit:
Exemple : si je fais une page sur les chats. je vais préférer cette forme d'url :
http://www.example.com/animaux/chats.html
à celle-ci :
http://www.example.com/animaux-chats.html

La seconde forme va noyer le mot clé important ("chats") avec d'autres mots clés qui ont moins d'importance.
Avec la première forme, le mot clé le plus important de la page prend toute sa valeur. Le mot "animaux" est en fait qu'accessoire. Il ne pèse pas très lourd dans le ref. On pourrait presque s'en passer. Il permet seulement d'organiser un peu les choses et rappelle à l'utilisateur un semblant de fil d'ariane. Donc il a son utilité, mais marginale.

Et donc, pour une raison ou pour une autre, le jour où tu as plein d'animaux et que tu transformes la structure de ton site avec "mammifères" et "reptiles" sous animaux, tu es dans l'obligation au choix :

1- d'avoir des urls qui ne correspondent plus à ta hiérarchie de liens, ce qui est mauvais, à partir du moment où cette hiérarchie est traduite dans les urls
2- de faire des redirections ce qui n'est pas top sur une grosse réorganisation de site
 
WRInaute accro
indigene a dit:
Exemple : si je fais une page sur les chats. je vais préférer cette forme d'url :
http://www.example.com/animaux/chats.html
à celle-ci :
http://www.example.com/animaux-chats.html

La seconde forme va noyer le mot clé important ("chats") avec d'autres mots clés qui ont moins d'importance.
Avec la première forme, le mot clé le plus important de la page prend toute sa valeur. Le mot "animaux" est en fait qu'accessoire. Il ne pèse pas très lourd dans le ref. On pourrait presque s'en passer. Il permet seulement d'organiser un peu les choses et rappelle à l'utilisateur un semblant de fil d'ariane. Donc il a son utilité, mais marginale.

Le problème est que si tu as une arborescence plus complexe, ie une catégorie "animaux à poils" et une autre "animaux à 4 pattes", tu te retrouves avec un risque de duplicité de pages, imposant un URL canonique (pour le cas le plus propre).

example.com/animaux/4-pattes/chats.html
example.com/animaux/poils/chats.html

...ce qui amène à viser des URLs comme ceci:

example.com/animaux/4-pattes/
example.com/animaux/poils/
>> example.com/chats.html
 
WRInaute occasionnel
Si je tente une synthèse...

La méthode utilisant un stockage par dossiers et sous-dossiers possède un avantage pratique qui devient prépondérant pour la maintenance du site lorsque le nombre de pages devient conséquent [du moins à partir de quelques centaines]. L’opérateur humain accède rapidement à une page avec l’ascenseur du sélecteur de fichiers, car le nombre de pages par dossier est peu important.

En ce qui concerne le référencement, même si une adresse absolue a le même poids qu’une adresse relative, cette méthode oblige cependant à utiliser nécessairement la méthode d’adressage absolu. Si l’on veut passer du fichier /animaux/cannasson/joly-jumper.php à /plantes/canne-a-sucre.php cela amènerait à écrire ../plantes/canne-a-sucre.php et ce « ..» va perturber de nombreux robots [y compris ceux de la firme publicitaire américaine] lorsqu’ils vont vouloir traduire l’adresse relative en adresse absolue. Le stockage par dossier impose donc l’utilisation d’un adressage absolu. Cela signifie donc quelque part une « déconnexion » de la page avec le site. L’arborisation de dossiers imbriqués successifs amène par ailleurs un risque de perdre le clic à chaque niveau de dossier.

Or, le stockage relatif permettrait toutefois un gain de capacité de stockage. Sur un site comme webrankinfo, si chaque message indiquait une URL, cela permettrait d’épargner dans le stockage de l’URL 22 signes pour la racine x 1 509 569 messages = 33 210 518 lettres en moins. Plus de 30 Mo.

La méthode utilisant un stockage à un seul endroit possède un avantage pratique indéniable dans le traitement des opérations automatisées : tout est au même endroit. Il suffit donc de lister le dossier pour ne rien oublier. Cette méthode rencontre par contre au moins une limitation due à son opérateur humain : devoir dérouler plein de pages pour pouvoir aller modifier l’une d’entre elles peut rapidement devenir long et fastidieux pour l’humain qui est derrière la manipulation. L’hébergeur contacté me dit quant à lui que le nombre de fichiers situés dans un même dossier n’a pas d’influence sur la rapidité d’accès à n’importe quel fichier.

Ici, le stockage relatif peut être facilement utilisé et sera toujours compris par les robots. On passera de Joly Jumper à Canne à sucre en indiquant simplement « plantes-canne-a-sucre.php ».

la méthode par stockage des pages en un seul endroit, la racine, ne peut toutefois être envisagée que si l’étude précédente avec dossiers et sous-dossiers a été réalisée

Qu’en est-il alors du renommage des pages lorsque la logique du site change et que l’on différencie les canassons des cracks ? Dans le stockage par dossier, il ne suffit pas de déplacer le fichier joly-jumper.php dans le nouveau dossier. Il faut aussi aller modifier l’URL absolue partout. Dans le stockage en un seul endroit, il en est de même : il faut non seulement changer le nom animaux-cannasson-joly-jumper.php en animaux-crack-joly-jumper.php, il faut aussi aller le changer partout, sauf que les outils de développement permettent d’automatiser plus facilement la chose.

Qu’en est-il du poids de l’URL ? La première méthode par dossiers permet de concentrer le jus sur Joly Jumper tandis que la seconde va le diluer sur animaux puis un peu moins sur canasson puis un peu moins sur Joly Jumper. Est-ce si sûr, car animaux et canasson apparaissent aussi dans l’URL ? Et si c’était le cas, est-ce un bien ou un mal ? Après tout si Joly Jumper se trouve au troisième niveau, c’est peut-être aussi parce que l’on a estimé que le plus important était d’abord l’animal puis son aspect craquant, et la bête seulement en dernier.

Enfin, le séparateur de mots, ici le trait d’union, perturberait par contre un peu Bing qui ne référençait d’ailleurs même pas les mots après le deuxième séparateur, au moins jusqu’en 2006. À cette époque, le référencement de Bing qui s’appelait alors MSN n’aurait porté que sur Animaux et sur Crack en oubliant purement et simplement joly-jumper. Cette limitation empêcherait alors la deuxième méthode.

Voilà beaucoup d’arguments contradictoires. Du coup, je ne sais toujours pas si je dois imiter la plupart des scripts ou pas et écrire :
conseils-ecriture-001-complement-objet-indirect.php
conseils-ecriture-002-complement-objet-direct.php
conseils-ecriture-003-chez-et-a.php
conseils-ecriture-004-accord-des-adjectifs-couleurs.php

ou bien :
conseils-ecriture/001-complement-objet-indirect.php
conseils-ecriture/002-complement-objet-direct.php
conseils-ecriture/003-chez-et-a.php
conseils-ecriture/004-accord-des-adjectifs-couleurs.php
 
WRInaute accro
Newbipastaper a dit:
HawkEye a dit:
Marie-Aude a dit:
Si une url n'a aucun BL, elle n'a aucun jus.

Si, en interne ;)

Oui mais si tu changes ton url, si t'es pas trop bête tu la changes aussi dans ton maillage interne, donc le jus suit non ?

Non, le jus ne "suit" pas ;)
La nouvelle page reçoit de nouveaux liens, mais l'ancienne page avait du jus, qu'il faut faire "couler" vers la nouvelle à coup de redirection 301, or la 301 ne transmet pas 100% du dit "jus" :)
 
WRInaute accro
HawkEye a dit:
Marie-Aude a dit:
Si une url n'a aucun BL, elle n'a aucun jus.

Si, en interne ;)
Des pages peuvent n'avoir aucun lien interne ^^ (pages orphelines). Si une page n'a aucun BL interne ou externe, elle n'a aucun jus :)


Newbipastaper a dit:
Oui mais si tu changes ton url, si t'es pas trop bête tu la changes aussi dans ton maillage interne, donc le jus suit non ?
Tout changement est risqué :)

Corrigeur a dit:
En ce qui concerne le référencement, même si une adresse absolue a le même poids qu’une adresse relative, cette méthode oblige cependant à utiliser nécessairement la méthode d’adressage absolu.
ça n'a strictement RIEN à voir. La méthode de saisie des urls dans le code source, à la fin, pour les robots, produit toujours une URL complète. Les urls relatives comme les urls absolues doivent être modifiées quand on change le maillage, la structure de lien, etc...

Corrigeur a dit:
Or, le stockage relatif permettrait toutefois un gain de capacité de stockage. Sur un site comme webrankinfo, si chaque message indiquait une URL, cela permettrait d’épargner dans le stockage de l’URL 22 signes pour la racine webrankinfo.com x 1 509 569 messages = 33 210 518 lettres en moins. Plus de 30 Mo.

Euh... un site comme webrankinfo est un site dynamique, généré à partir de templates et d'id en base de données. Un template permet de générer des milliers de page, l'url est construite lors de l'affichage, il n'y a donc aucun impact sur le stockage.

Corrigeur a dit:
il faut aussi aller le changer partout, sauf que les outils de développement permettent d’automatiser plus facilement la chose

Heureusement, il existe des outils simples qui permettent de rechercher - remplacer dans un ensemble de dossiers avec sous dossiers, dans l'hypothèse où tu fais un site purement statique. Dans l'hypothèse d'un site dynamique, cela se gère en base de données, avec au choix un update si les urls du contenu sont stockées en dur, ou de simples modifications dans les enregistrements qui permettent de générer les urls.

Corrigeur a dit:
Qu’en est-il du poids de l’URL ? La première méthode par dossiers permet de concentrer le jus sur Joly Jumper tandis que la seconde va le diluer sur animaux puis un peu moins sur canasson puis un peu moins sur Joly Jumper.

Non

Le jus est réparti via les liens, pas via la structure d'url.


Corrigeur a dit:
Enfin, le séparateur de mots, ici le trait d’union, perturberait par contre un peu Bing qui ne référençait d’ailleurs même pas les mots après le deuxième séparateur, au moins jusqu’en 2006

Je te fais une carte de membre spéciale pour le club des webmasters qui construisent leur site avec la technique du dolmen, parler de 2006 ... neuf ans après :D tu es pire qu'indigènonichou

Accessoirement, le mot clé dans l'url a très peu d'impact, MAIS si on veut qu'il en ait un il faut qu'il soit séparé par des tirets.
 
WRInaute passionné
Pour les fichiers "en dur" à la même racine, attention a la limitation de la plupart des systemes de fichier au formatage du disque sous linux: ext3 est limité a 32 000 fichiers/dossiers à la même racine, et bon nombre de serveur sont encore sous ext2 ...

il faut alors être en ext4 pour depasser cette limite, lors du formatage et configuration de vos partitions pour installer le systeme de fichier approprié (ex sur serveur dédié chez OVH).
 
WRInaute occasionnel
Marie-Aude a dit:
La méthode de saisie des urls produit toujours pour les robots une URL complète.
Heu ! C’est justement ce que j’ai dit : lorsqu’ils vont vouloir traduire l’adresse relative en adresse absolue.

Marie-Aude a dit:
un site comme webrankinfo est un site dynamique

Je disais : si chaque message indiquait une URL.

Marie-Aude a dit:
il existe des outils simples qui permettent de rechercher - remplacer

Et le stockage au même endroit permet d’automatiser plus facilement la chose que lorsque les éléments sont éparpillés à plusieurs endroits.

Marie-Aude a dit:
Le jus est réparti via les liens, pas via la structure d'url. [...] Accessoirement, le mot clé dans l'url a très peu d'impact

Il est question ici uniquement du nom. Le mot-clé dans l’URL a un poids certes très faible, mais il existe, et lorsqu’il y a plusieurs mots, le poids de l’ensemble est alors réparti sur tous les mots avec toutefois plus de poids sur le premier et moins sur le dernier.

Marie-Aude a dit:
parler de 2006...

:lol: Et ? Ne sommes-nous pas justement 10 ans plus tard où cette limitation de l’époque aurait rendu impossible toute cette discussion ?

Marie-Aude a dit:
Accessoirement, le mot clé dans l'url a très peu d'impact, MAIS il faut qu'il soit séparé par des tirets.

:lol: Quelqu’un croit-il encore l’inverse ? Comme mur-mure mari-an-ne murmure Marianne.

longo600 a dit:
ext3 est limité a 32 000 fichiers/dossiers à la même racine
Ha ! Bon à savoir.
 
WRInaute discret
Merci pour se sujet car j'ai le même questionnement.

Je suis surpris que personne n'indique que l'URL dans le cas www.exemple.com/Animaux/chats.html, le domaine 'www.exemple.com/Animaux' est référencée à part.

C'est ce que j'ai cru comprendre en lisant un sujet sur ce forum.

Super retours car je n'ai pas pensé à la maintenance du site effectivement :) Bon il a 8 pages mais il va prendre du galon.
 
WRInaute accro
Corrigeur a dit:
Or, le stockage relatif permettrait toutefois un gain de capacité de stockage. Sur un site comme webrankinfo, si chaque message indiquait une URL, cela permettrait d’épargner dans le stockage de l’URL 22 signes pour la racine webrankinfo.com x 1 509 569 messages = 33 210 518 lettres en moins. Plus de 30 Mo.

...30 Mb sur une DB d'un tel volume c'est moins que peanuts ;)
 
WRInaute accro
Marie-Aude a dit:
Et donc, pour une raison ou pour une autre, le jour où tu as plein d'animaux et que tu transformes la structure de ton site avec "mammifères" et "reptiles" sous animaux, tu es dans l'obligation au choix :

1- d'avoir des urls qui ne correspondent plus à ta hiérarchie de liens, ce qui est mauvais, à partir du moment où cette hiérarchie est traduite dans les urls
2- de faire des redirections ce qui n'est pas top sur une grosse réorganisation de site

C'est valable pour les deux formes d'urls, avec la catégorie dans le chemin ou dans le nom du document.
Mais je pense avoir suffisamment argumenté les raisons. Si tu appelles une page seulement http://www.example.com/chats.html ça manque un peu d'information et peut prêter à confusion.
 
WRInaute accro
Marie-Aude a dit:
Je te fais une carte de membre spéciale pour le club des webmasters qui construisent leur site avec la technique du dolmen, parler de 2006 ... neuf ans après :D tu es pire qu'indigènonichou

Dénigration gratuite.
Je suis passé au responsive design et j'ai abandonné les frames pour faire des pseudo-frames en css
N'empêche que les balises <br> et <u> j'y tiens beaucoup, et même parfois <center>
 
WRInaute accro
Caine_DVP a dit:
Je suis surpris que personne n'indique que l'URL dans le cas http://www.exemple.com/Animaux/chats.html, le domaine 'www.exemple.com/Animaux' est référencée à part.

Pas de domaine, le sous-répertoire virtuel. Il ne sera "référencé" que s'il reçoit des liens (internes ou externes). Dans ce cas, deux possibilités :
- soit il existe réellement (page d'archive des contenus typiques d'un CMS) et c'est bien [ou pas, selon d'autres critères, duplicate content, etc]
- soit il n'existe pas autrement que comme un sous-répertoire dans l'url, et dans ce cas, le webmaster qui fait des liens vers lui ou qui ne s'assure pas qu'il y a une redirection ou une belle page 404 fait mal son travail :)

Corrigeur a dit:
Marie-Aude a dit:
il existe des outils simples qui permettent de rechercher - remplacer

Et le stockage au même endroit permet d’automatiser plus facilement la chose que lorsque les éléments sont éparpillés à plusieurs endroits.
Ces outils simples permettent, très simplement, de rechercher sur des éléments éparpillés :D (qui sont quand même regroupés dans un dossier d'un site...)

indigene a dit:
C'est valable pour les deux formes d'urls, avec la catégorie dans le chemin ou dans le nom du document.
Mais je pense avoir suffisamment argumenté les raisons. Si tu appelles une page seulement http://www.example.com/chats.html ça manque un peu d'information et peut prêter à confusion.

Sur "example.com" peut-être, pas sur "dictionnaire-animaux[.]fr".
Par ailleurs une url se présente rarissimement seule. Title, contexte, description, c'est là que l'information complémentaire joue.

C'est d'ailleurs ça qui m'énerve avec les approches mécaniques du genre "faut-il mettre la catégorie dans l'url", "combien d'éléments dans mon menu"... un site est un tout, un ensemble logique et cohérent, et on ne va pas regarder "une" url, mais l'ensemble des urls d'un site, avec leur title, leur description, etc... pour voir comment on informe Google du contenu d'une page et si elle est suffisamment différenciée par rapport aux autres.
 
WRInaute accro
Pour rejoindre le point de Marie-Aude, on pourrait faire un site avec des URLs comme ceci:

example.com/a12ds13a51/ (catégorie)
example.com/45a6465a66/ (sous-catégorie de a12ds13a51)
example.com/11a23565/ (contenu appartenant à 45a6465a66)

... que ça ne changerait pas grand chose aux performances* :)

* si tant est que le site soit bien fait, évidemment.
 
WRInaute accro
Marie-Aude a dit:
un site est un tout, un ensemble logique et cohérent, et on ne va pas regarder "une" url, mais l'ensemble des urls d'un site, avec leur title, leur description, etc... pour voir comment on informe Google du contenu d'une page et si elle est suffisamment différenciée par rapport aux autres.

Il faut se placer du point de vue de l'internaute qui ne voit pas l'ensemble du site depuis la page de résultats des moteurs de recherche.
Je peux en effet appeler mon site "dictionnaire-animaux.com" mais je peux aussi l'appeler "zzazoo.com" et rien ne m'empêche d'avoir un forum et un chat sur un site consacré aux animaux.

Quand j'utilise google pour faire une recherche il m'arrive constamment de survoler des résultats et de cliquer sur celui d'en dessous simplement parce que j'avais un doute sur le site sur lequel j'allais tomber.
 
WRInaute accro
indigene a dit:
Quand j'utilise google pour faire une recherche il m'arrive constamment de survoler des résultats et de cliquer sur celui d'en dessous simplement parce que j'avais un doute sur le site sur lequel j'allais tomber.

Oui mais comme plusieurs personnes te l'ont déjà dit, tu n'es pas l'internaute lambda, et tu n'es pas non plus le webmaster lambda.

L'internaute n'a quasiment aucune idée de ce qu'est une url, et il clique en fonction du title, de la description et de la longueur de l'url. Après si tu as un site qui a une marque, et qu'elle est connue, l'url qui reprend cette marque peut inspirer confiance... c'est sans doute le cas de wamiz

(bon et puis regarder les urls de yelp, trip advisor, etc...)
 
WRInaute occasionnel
Tentons une nouvelle synthèse.

Il ressort de tout ce qui précède qu’il faut différencier le stockage réel, et le stockage affiché, dynamique ou pas. Le stockage réel peut effectivement différer de ce que l’on voudra finalement afficher au visiteur et donc au robot. Comment doit s’organiser notre stockage réel, avec une répartition en dossier ou tout au même endroit est un autre sujet.

Il s’agit ici uniquement de déterminer s’il vaut mieux que toutes les URL affichent au visiteur (et donc au robot) un nom

/animaux/chat.html en répartissant par dossier, ici animaux/

ou

/animaux-chat.html, donc tout à la racine.

Les points communs

Que ce soit l’une ou l’autre méthode, on voit bien que l’organisation doit transpirer d’une manière ou d’une autre, soit par un dossier /animaux/, soit par un préfixe animaux-.

Que ce soit l’une ou l’autre méthode, se pose le problème du renommage, ou ce qui revient, au même du déplacement d’un contenant à un autre

Que ce soit l’une ou l’autre méthode, se pose le problème des mauvaises organisations de départ, lorsque l’on a créé de mauvaises catégories. Le chat doit-il se mettre dans animaux de compagnie, animaux domestiques, ou dans animaux carnivores ?

Que ce soit l’une ou l’autre méthode, se pose le problème de la clarté du nom et cela peut avoir une conséquence dans le choix de l’internaute dans les SERP. Avec la méthode par préfixe, on ne peut pas nommer une page simplement chat.html comme dans la première méthode par dossier, mais nécessairement outil-chat.html, discussion-chat.html, ou vie-chat.html pour parler respectivement du chat à 9 queues, d’un chat de discussion, ou de la vie de son chat selon le contenant auquel appartient la page. La méthode par stockage au même endroit réduit donc l’incompréhension à cause du préfixe qui est obligatoire, mais elle risque à l’inverse de le rendre incompréhensible si ce nom devient trop long à cause des préfixes.

La méthode par dossiers amène certains problèmes

Il est fréquent qu’un robot essaye d’explorer un dossier, par exemple le dossier /animaux/ alors qu’il n’existe aucun lien vers la racine du dossier.

Il est fréquent qu’un robot se mélange les pinceaux avec les chemins relatifs, ce qui oblige à afficher un chemin absolu.

Il est compliquer de dicter à un internaute l’URL d’une page remplie de préfixes, alors qu’il comprendra mieux si on lui la même chose en ponctuant chaque catégorie par un « slash ». animaux slash compagnie slash chat.html sera mieux compris que animaux tiret du 6 compagnie tiret du 6 chat.html.

Le nombre de pages est limité à 32 000 dans le cas de l’ext3.

La méthode par préfixe amène aussi certains problèmes

Il devient vite fastidieux pour un humain de retrouver un fichier dans l’arborescence dès lors que le nombre de pages commence à augmenter. C’est là qu’intervient l’outil de gestion et pour lui il sera plus facile de tout lister au même endroit plutôt que d’aller chercher dans différents dossiers, quitte à créer ensuite une fausse arborescence pour le visiteur.
 
WRInaute accro
Pour une synthèse c'est assez long. C'est plus un récapitulatif.
Et je ne sais plus si on en a parlé mais il y a également la notion suivante à prendre en compte :
Les mots clés les plus proches de la racine du domaine ont plus de poids dans l'url

Une autre chose à prendre en compte : comment le webmaster travaille ?
Est-ce qu'il a ses fichiers sur son disque dur ou bien travaille-t-il uniquement dans un cms
S'il travaille dans un cms ce qui compte c'est l'organisation du système de navigation et son ergonomie. On peut facilement organiser ses fichiers par catégorie et pourtant la catégorie ne sera pas affichées dans l'url. Et il peut exister un système de recherche pour retrouver facilement un article à mettre à jour.
Pour quelqu'un qui travaille en html sur son disque dur il est préférable d'organiser les fichiers en répertoires et de conserver cette organisation physique sur le serveur et donc elle va se répercuter sur les URLs. Pour mon site c'est ce que je fais et pour répondre favorablement au premier point j'ai choisi des catégories (répertoires) avec un nom court : MOE, WEB, SEO

Pour ce qui concerne les robots qui accèdent à la racine du répertoire, d'ailleurs il n'y a pas que les robots, rien ne t'empêche d'y mettre un page intermédiaire d'index de la catégorie. C'est ce que j'ai fait.
Par contre, si tu prends exemple sur mon site, c'est encore une structure bien plus particulière car je tenais absolument à lui conserver un esprit "site vitrine" si bien que quand on arrive sur le site on a l'impression qu'il s'agit d'un site de 10 pages. Les onglets du menu ne mènent pas directement aux pages d'index des catégories. On y accède de façon assez détournée depuis la home. Mais quand on est sur une page article profonde, c'est très facile de revenir à l'index de la catégorie. Et ça forme ce que certains appellent une structure en silo il me semble. Merci de me corriger si je me trompe de terme. Je fais pas bien la différence entre structure en silo et structure en arbre (c'est peut-être la même chose d'ailleurs)
 
Olivier Duffez (admin)
Membre du personnel
Corrigeur a dit:
Il s’agit ici uniquement de déterminer s’il vaut mieux que toutes les URL affichent au visiteur (et donc au robot) un nom
/animaux/chat.html en répartissant par dossier, ici animaux/
ou
/animaux-chat.html, donc tout à la racine.

Tu oublies la possibilité /chat.html

et je rappelle que l'extension .html est tout à fait superflue

Corrigeur a dit:
Que ce soit l’une ou l’autre méthode, on voit bien que l’organisation doit transpirer d’une manière ou d’une autre, soit par un dossier /animaux/, soit par un préfixe animaux-.

Que ce soit l’une ou l’autre méthode, se pose le problème du renommage, ou ce qui revient, au même du déplacement d’un contenant à un autre
non, tu n'as pas ce problème si l'URL d'une fiche détaillée ne contient aucune référence à sa catégorie (/chat.html dans mon exemple).

Corrigeur a dit:
Il est compliquer de dicter à un internaute l’URL d’une page remplie de préfixes, alors qu’il comprendra mieux si on lui la même chose en ponctuant chaque catégorie par un « slash ». animaux slash compagnie slash chat.html sera mieux compris que animaux tiret du 6 compagnie tiret du 6 chat.html.
oui mais /chat.html sera encore plus facile
Corrigeur a dit:
Il devient vite fastidieux pour un humain de retrouver un fichier dans l’arborescence dès lors que le nombre de pages commence à augmenter.
dans quel cas de figure veux-tu qu'on ait à parcourir toute l'arbo ? tu parles de l'internaute ou du rédacteur du site ?
 
WRInaute accro
Corrigeur a dit:
Que ce soit l’une ou l’autre méthode, on voit bien que l’organisation doit transpirer d’une manière ou d’une autre, soit par un dossier /animaux/, soit par un préfixe animaux-.

Non, tu pars d'un présupposé qui est, encore une fois, faux.
A partir de là, je n'ai même pas lu le reste.

Corrigeur a dit:
Il devient vite fastidieux pour un humain de retrouver un fichier dans l’arborescence dès lors que le nombre de pages commence à augmenter.
Là tu es reparti sur tes problèmes de stockage. Quand tu parles de "fausse arborescence", elle n'est pas "fausse" (par rapport à quoi ? par rapport à l'organisation physique des dossiers), elle est réelle pour le visiteur, pour le bot, et c'est tout ce qui compte.

Corrigeur a dit:
C’est là qu’intervient l’outil de gestion et pour lui il sera plus facile de tout lister au même endroit plutôt que d’aller chercher dans différents dossiers, quitte à créer ensuite une fausse arborescence pour le visiteur.
Quel est le rapport entre la simplicité de l'outil de gestion et le sujet du forum "débuter en référencement"

Tu mélanges complètement deux choses totalement différentes, la solution technique (outil de gestion, stockage sur le disque dur, etc) et l'organisation et la présentation du site pour le visiteur.

Les outils de gestion, en général, sauf pour des tailleurs de dolmen comme indigènonichou, c'est une base de données (un seul endroit), un moteur de template (un seul endroit), des taxonomies et des filtres pour rechercher dans les taxonomies.

Si certains (toi ? indigenonichou, kins) font le choix d'une draisienne au lieu d'une voiture et d'un site entièrement développé à partir de fichiers physiques, c'est un choix technique, qui pose des problèmes techniques, mais pitié, arrêtez de mélanger cela avec le référencement. Et essayez de comprendre que les problèmes de "structure" (physique, outil de gestion, etc) sont justement résolus par ces sites dynamiques, et qu'il serait temps de mettre la draisienne au musée.
 
WRInaute accro
C'est un ensemble de choses qui font que les mots placés au début ont plus d'importance.
Dans certains blogs ou forum, les urls sont automatiquement tronquées. Si le mot clé se trouve plus loin dans l'url il n'aura donc aucune influence dans le référencement lorsque les internautes posent simplement une url complète pour faire un lien, sans utiliser d'ancre optimisée

Illustration de ce que je veux dire :
https://www.webrankinfo.com/forum/t/larborescence-oui-mais.182663/
ou
https://www.webrankinfo.com/forum/t/larborescence-oui-mais.182663/

Autre chose : si on part du principe que les mots clés placés en début d'un titre sont plus importants que ceux placés à la fin, on peut transposer la même règle concernant les urls. Il n'y a pas de raison pour que google accorde plus d'importance aux mots placés au début d'un titre alors que pour une url il accorde plus d'importance aux mots placés au milieu ou à la fin.
Au pire, il accorde autant d'importance à chaque mot clé de l'url. Mais le netlinking avec les urls tronquées fera toute la différence et c'est pour ça qu'il faut mettre les mots importants au début.

Donc ma préconisation pour la constitution des urls qui reprennent le title c'est de supprimer les stop word du début
Par exemple si le title est : Le marché du dimanche matin au centre-ville
Il est préférable d'utiliser une url : http://www.example.com/marche-du-dimanche-matin-au-centre-ville.html
plutôt que http://www.example.com/le-marche-du-dimanche-matin-au-centre-ville.html
 
WRInaute accro
Marie-Aude a dit:
Non, tu pars d'un présupposé qui est, encore une fois, faux.

Non, il a écrit que c'était une synthèse de ce qui a été dit dans le post. Donc ce n'est pas faux du tout. C'est ce qui a été évoqué
 
WRInaute accro
Marie-Aude a dit:
Les outils de gestion, en général, sauf pour des tailleurs de dolmen comme indigènonichou, ...

Et comment on fait avec une base de données pour retrouver la page qui contient un mot que l'on recherche ?
Recherche sql
Vu la structure des bases wordpress je ne saurai même pas dans quelle base chercher.
J'espère que wp propose des outils pour faire une telle recherche.
En html il existe des outils tels que InfoRapid Search & Replace qui fonctionnent très bien et très rapidement. Quand on utilise une technique il faut savoir se doter des bons outils
Quand je fais un site en php j'ai souvent développé un champ de recherche qui va me trouver toutes les pages rapidement et un simple lien (quand on est connecté en tant qu'admin) permet d'accéder à l'éditeur de l'administration pour éditer cette page. Pas besoin d'un CMS pour faire ça.

Et pour la draisienne tu as tort une fois de plus. Je possède une voiture et elle n'est même pas du siècle dernier (première mise en circulation en janvier 2000). Elle est tellement bien que j'en ai même rachetée une seconde, même modèle de la même date, pour avoir une sauvegarde (déformation d'informaticien). 386 000 km au compte pour la première. On me l'a vendue en m'assurant que je ferais 500 000. J'en approche. D'ici 5 ou 10 ans ça sera ok.
 
WRInaute accro
Marie-Aude a dit:
Ni Olivier, ni Hawkeye ni moi ne sommes d'accord avec cela. Il ne s'agit donc pas d'une synthèse juste.
Dans une synthèse on ne prend pas uniquement qu'une partie d'un ensemble, on prend tout et on synthétise.
Il faut revoir la théorie des ensembles.

Et puis j'ajouterai : heureusement que tous les webmasters et référenceurs n'ont pas les mêmes techniques, sinon il n'y aurait que les gros sites qui seraient en tête sans aucune possibilité pour les petits de percer sur quelque mot clé que ce soit.
 
WRInaute accro
indigene a dit:
Et comment on fait avec une base de données pour retrouver la page qui contient un mot que l'on recherche ?
Recherche sql
Et ?

indigene a dit:
Vu la structure des bases wordpress je ne saurai même pas dans quelle base chercher.
Ca c'est TON problème de non-compétence

indigene a dit:
J'espère que wp propose des outils pour faire une telle recherche.
Si tu n'as pas vu ces outils avec une simple installation de WordPress, tu es pire que le plus noob des débutants que je dépanne régulièrement sur le forum WordPress

Mais... tu remarqueras que je n'ai PAS parlé de WordPress, parce que, dans ce domaine, TOUS les cms proposent des fonctionnalités à peu près équivalentes.

Tu devrais sortir de dessous ton dolmen et t'intéresser à la vraie vie actuelle...

indigene a dit:
En html il existe des outils tels que InfoRapid Search & Replace qui fonctionnent très bien et très rapidement. Quand on utilise une technique il faut savoir se doter des bons outils
Même pas besoin de ça... notepad++ fait très bien des recherches multi documents / multi dossiers, avec l'option d'utiliser des regex pour remplacer...

indigene a dit:
Quand je fais un site en php j'ai souvent développé un champ de recherche qui va me trouver toutes les pages rapidement et un simple lien (quand on est connecté en tant qu'admin) permet d'accéder à l'éditeur de l'administration pour éditer cette page. Pas besoin d'un CMS pour faire ça.
Si :) en faisant ce genre de choses, tu fais un CMS. Tu voulais sans doute dire "même pas besoin d'utiliser un CMS développé par les autres pour faire ça ?"

indigene a dit:
Et pour la draisienne tu as tort une fois de plus.
OK, je vais le dire autrement : tout ce que tu racontes, les questions que tu poses prouve qu'en termes de sites webs, tes techniques de développement datent de plusieurs années. Si tes clients sont contents avec ça, tant mieux. Mais tu mets plus de temps, tu es moins évolutif, etc, etc... et ça répond sans doute à une de tes questions qui était "comment gagner sa vie en faisant des sites webs".

indigene a dit:
Dans une synthèse on ne prend pas uniquement qu'une partie d'un ensemble, on prend tout et on synthétise.
Il faut revoir la théorie des ensembles.

Donc dire

Corrigeur a dit:
Que ce soit l’une ou l’autre méthode, on voit bien que l’organisation doit transpirer d’une manière ou d’une autre, soit par un dossier /animaux/, soit par un préfixe animaux-.

est une synthèse fausse, puisque sur cinq personnes intervenant sur la discussion, trois, dont deux (Hawkeye et Olivier) ont des compétences en référencement très largement supérieures à la moyenne ont dit que la meilleure solution restait de ne pas faire apparaitre l'organisation dans l'url.
 
WRInaute accro
Marie-Aude a dit:
indigene a dit:
Et comment on fait avec une base de données pour retrouver la page qui contient un mot que l'on recherche ?
Recherche sql
Et ?
Tu crois que tous les utilisateurs d'un CMS connaissent le SQL ?

Marie-Aude a dit:
indigene a dit:
Vu la structure des bases wordpress je ne saurai même pas dans quelle base chercher.
Ca c'est TON problème de non-compétence
J'ai appris SQL en 1987 ou 1988, en même temps que les bases de données relationnelles.
Sur mes sites la base des utilisateurs s'appelle utilisateurs, la base des clients s'appelle clients, la base des articles s'appelle articles. Dans wp c'est plus opaque que les sysibm.systables de DB2. Il faut être ingénieur système ou DBA pour comprendre.
Et quand tu vois le nombre de scripts nécessaires pour gérer un simple blog. C'est effarant.
Je suis en train de mettre en place un blog sur le site de mon client. C'est deux tables. 24 scripts php pour la gestion des utilisateurs, 5 pour la gestion du blog et il y en aura 5 ou 6 pour la gestion des commentaires.


Marie-Aude a dit:
indigene a dit:
J'espère que wp propose des outils pour faire une telle recherche.
Si tu n'as pas vu ces outils avec une simple installation de WordPress, tu es pire que le plus noob des débutants que je dépanne régulièrement sur le forum WordPress
Mais qui te dis que j'ai installé wordpress ? Je ne vais pas installer un truc qui ne me sera pas d'utilité.

Marie-Aude a dit:
Mais... tu remarqueras que je n'ai PAS parlé de WordPress, parce que, dans ce domaine, TOUS les cms proposent des fonctionnalités à peu près équivalentes.
J'espère qu'ils en ont

Marie-Aude a dit:
Tu devrais sortir de dessous ton dolmen et t'intéresser à la vraie vie actuelle...
Tu veux dire regarder la télé, aller sur facebook et s'inscrire sur GG+ et même avoir une adresse Gmail ? C'est ça la vraie vie actuelle ? Ou alors avoir un smartphone ou une montre connectée ? On oublie les google-glass.

Marie-Aude a dit:
indigene a dit:
En html il existe des outils tels que InfoRapid Search & Replace qui fonctionnent très bien et très rapidement. Quand on utilise une technique il faut savoir se doter des bons outils
Même pas besoin de ça... notepad++ fait très bien des recherches multi documents / multi dossiers, avec l'option d'utiliser des regex pour remplacer...
Ne mélange pas tout. Moi je te parle d'un outil fait pour chercher et remplacer. Il ne fait rien d'autre et il le fait bien. Toi tu me parles d'un éditeur de texte très complexe par rapport à notepad.exe de windows qui fonctionne très bien. Pourquoi pas aussi eclipse ou d'autres produits de développement.
Tu vois, quand j'ai besoin de faire le plein d'essence, je vais à la station service, je vais pas à la raffinerie de Feizin.


Marie-Aude a dit:
indigene a dit:
Quand je fais un site en php j'ai souvent développé un champ de recherche qui va me trouver toutes les pages rapidement et un simple lien (quand on est connecté en tant qu'admin) permet d'accéder à l'éditeur de l'administration pour éditer cette page. Pas besoin d'un CMS pour faire ça.
Si :) en faisant ce genre de choses, tu fais un CMS. Tu voulais sans doute dire "même pas besoin d'utiliser un CMS développé par les autres pour faire ça ?"
Parce que tu crois que Search & Replace ou notepad ou windows je les ai développé moi-même ?
J'avais commencé à le faire sur mon 8086 qui n'avait pas d'interface mais seulement un accès dos. J'avais mis en place tout un système de menus pour faciliter l'accès à tous les programmes. Mais windows était en mode graphique et ils étaient plusieurs à bosser dessus. Je n'ai jamais terminé mon interface qui fonctionnait en mode texte et à la sortie de W95 j'ai abandonné.


Marie-Aude a dit:
indigene a dit:
Et pour la draisienne tu as tort une fois de plus.
OK, je vais le dire autrement...
L'histoire de la draisienne je l'avais pris pour de l'humour mais décidément tu n'as pas d'humour même quand tu écris quelque chose qui donne l'apparence que tu blagues.

Marie-Aude a dit:
indigene a dit:
Dans une synthèse on ne prend pas uniquement qu'une partie d'un ensemble, on prend tout et on synthétise.
Il faut revoir la théorie des ensembles.

Donc dire

Corrigeur a dit:
Que ce soit l’une ou l’autre méthode, on voit bien que l’organisation doit transpirer d’une manière ou d’une autre, soit par un dossier /animaux/, soit par un préfixe animaux-.

est une synthèse fausse, puisque sur cinq personnes intervenant sur la discussion, trois, dont deux (Hawkeye et Olivier) ont des compétences en référencement très largement supérieures à la moyenne ont dit que la meilleure solution restait de ne pas faire apparaitre l'organisation dans l'url.

Mais tout dépend du type de site. C'est un choix d'organisation qu'on fait à la base et après il n'y a pas de raison d'en changer.
Quand on fait un site qui traite d'un sujet unique, on peut se passer de mettre les catégories dans l'url.
Mais prenons par exemple le cas d'un ouvrier en bâtiment auto-entrepreneur qui fait un site pour présenter son activité qui tourne autour de trois grands thèmes :
- la maçonnerie
- l'électricité domestique
- l'entretien des espaces verts
Ce sont trois grandes catégories bien distinctes et ça ne mérite pas de faire 3 sites différents si c'est uniquement pour présenter les activité d'un seul bonhomme. Je trouve judicieux de bien séparer ces trois activités dans trois répertoires (en apparence) qui se reflèteront avec un mot clé dans une partie de l'url.
Quand on est une entreprise, en général on ne possède qu'un site d'entreprise, même si on a des activités diverses.

Même un groupe comme engie utilise un système avec des mots clés dans l'url
http://www.engie.com/engagements/sponsoring/voile/

Tu penses que engie n'a pas les moyens de se payer un référenceur aussi talentueux qu'Olivier ou que Hawkeye ?

Mais tu vois, il y a une différence entre faire un vrai site d'entreprise et un blog (que ce soit sous wordpress ou tout autre cms, joomla, dotclear, ...)

Chez edf.com ils ont choisi de mettre les répertoires en sous-domaine. Mais encore une fois, le nom du répertoire figure dans l'url.
 
WRInaute accro
indigene a dit:
Tu crois que tous les utilisateurs d'un CMS connaissent le SQL ?
Je pense que tous les gens qu veulent développer des gros sites où ces problèmes se posent devraient le connaître, oui.
Ici on ne parle pas d'utilisateur final.

indigene a dit:
J'ai appris SQL en 1987 ou 1988, en même temps que les bases de données relationnelles.
Sur mes sites la base des utilisateurs s'appelle utilisateurs, la base des clients s'appelle clients, la base des articles s'appelle articles. Dans wp c'est plus opaque que les sysibm.systables de DB2. Il faut être ingénieur système ou DBA pour comprendre.

Tu es donc non compétent dans ce CMS.
Et / ou en anglais, ce qui pour un informaticien "gros système" est encore pire.
Parce que la différence entre une table "articles" et une table "post"

indigene a dit:
Et quand tu vois le nombre de scripts nécessaires pour gérer un simple blog.
C'est hors sujet, on ne parle pas de WordPress on parle des CMS en général, de la fonction de recherche dans les bases de données...
Après je suis certaine que TON script est bien pour TOI.

indigene a dit:
Mais qui te dis que j'ai installé wordpress ?
Je te remercie de confirmer que tu parles et que tu critiques sans avoir aucune idée réelle de l'outil :mrgreen:

indigene a dit:
Tu veux dire regarder la télé, aller sur facebook et s'inscrire sur GG+ et même avoir une adresse Gmail ?
Quand tu veux vendre du référencement (je crois que c'est ce que tu fais ? ) oui, ça fait partie de la vraie vie actuelle (pas la télé, mais le reste)

indigene a dit:
Toi tu me parles d'un éditeur de texte très complexe par rapport à notepad.exe de windows qui fonctionne très bien.
indigene a dit:
Très complexe ? :lol: :lol: :lol: :lol: tu devrais arrêter de dire des conneries rien que pour le plaisir de me contredire.

indigene a dit:
Mais tout dépend du type de site. C'est un choix d'organisation qu'on fait à la base et après il n'y a pas de raison d'en changer.
Tiens, encore un bruit de branches mortes... je croyais qu'on parlait de la synthèse ? Là tu repars dans la discussion.
En tant qu'informaticien, je te fais le crédit d'avoir une bonne logique. Ça veut donc dire que quand dans ce genre de transformation, tu fais preuve de mauvaise foi.

Je te laisserai donc troller tout seul contre toutes les modernités du monde...
 
WRInaute accro
tumblr_mnh38phAp41s420d1o1_400.gif
 
WRInaute accro
Marie-Aude a dit:
indigene a dit:
Tu crois que tous les utilisateurs d'un CMS connaissent le SQL ?
Je pense que tous les gens qu veulent développer des gros sites où ces problèmes se posent devraient le connaître, oui.
Ici on ne parle pas d'utilisateur final.

Ici nous sommes dans le forum "Débuter en référencement"
Qui a parlé de gros sites dans ce post à part moi pour donner des exemples de gros sites, et non des moindres, qui utilisent le nom des catégories dans l'url ?
Et je te rappelle que wordpress n'est pas une compétence reconnue. Alors être incompétent en quelque chose qui n'est pas une compétence...

Dans tous les cas c'est à l'initiateur de ce fil de discussion de nous dire où il veut en venir et de fixer les limites des débats (gros sites, petit site perso ou site vitrine de son entreprise, CMS, pas CMS, etc...) Je pense qu'avant d'ouvrir un post tel que celui-ci il avait une idée derrière la tête et que les réponses conduisent à une mise en oeuvre précise pour un cas bien précis. C'est pas un sujet général lancé en l'air comme ça. A lui de préciser le périmètre. C'est pour faire la refonte du site engie.com qui en aurait bien besoin ?
 
WRInaute accro
Comme j'aime bien HawkEye, je vais essayer de lui faire faire un peu de business avec son stock :)

indigene a dit:
Ici nous sommes dans le forum "Débuter en référencement"
1- c'est pas obligatoirement super bien placé ^^
2- débuter ça veut dire commencer à progresser non ? Parce que sinon, tant qu'à faire, le crieur et la plume d'oie ça marchait bien ?

indigene a dit:
Qui a parlé de gros sites dans ce post à part moi pour donner des exemples de gros sites, et non des moindres, qui utilisent le nom des catégories dans l'url ?
Ben maintenant que tu poses la question :)

1- le premier à avoir parlé de gros volumes, c'est Corrigeur dans ce message https://www.webrankinfo.com/forum/t/larborescence-oui-mais.182663/#p1528673
2- le premier à avoir donné des exemples de gros sites, c'est moi dans ce message https://www.webrankinfo.com/forum/t/larborescence-oui-mais.182663/#p1528731

Ouirais-je une sorte de bruit de branches cassées ? :lol: :lol:

indigene a dit:
Et je te rappelle que wordpress n'est pas une compétence reconnue. Alors être incompétent en quelque chose qui n'est pas une compétence...

Je te rappelle, pour la seconde fois, ne pas avoir parlé de WordPress, mais de CMS. Juste pour dire qu'il y a le choix : http://www.cmsmatrix.org/ (et c'est sans compter les CMS maisons, ou non distribués, comme InfiniCMS).

C'est toi qui est parti en vrille là dessus...

Tu as donc mérité ton premier point WordPress :)

Code:
 __          _______     _____      _       _   
 \ \        / /  __ \   |  __ \    (_)     | |  
  \ \  /\  / /| |__) |  | |__) |__  _ _ __ | |_ 
   \ \/  \/ / |  ___/   |  ___/ _ \| | '_ \| __|
    \  /\  /  | |       | |  | (_) | | | | | |_ 
     \/  \/   |_|       |_|   \___/|_|_| |_|\__|

Adjugé à toute personne qui se met en rogne contre WP alors que ce n'est pas le sujet, ou qui, au contraire, le met dans un sujet comme un cheveux sur la soupe ^^^

Sinon, sur le fond, pour ouvrir le deuxième sac de pop-corn, WordPress n'est peut être pas une compétence "reconnue par l'état", mais c'est aussi le cas de référenceur, de community manager ou même de webmaster, ça n'empêche pas des tas de gens de gagner leur vie avec. Parce que, en pratique, sur les sites de recrutement ou de sous-traitance c'est une compétence, et sur les sites de formation en ligne, c'est une matière.

Sérieusement, relis le fil et regarde jusqu'où ça t'emporte, l'envie de me contredire ^^ mais tu as gagné, comme le pop corn c'est mauvais pour la ligne, maintenant, en dehors de la distribution des points WP, je te laisse t'amuser tout seul :)
 
WRInaute occasionnel
C'est quoi les billes jaunes dans les sacs ?
Si c'est du maïs Monsanto, on est mal parti pour l'arborescence de ce sujet (qui part en vrille, mais c'est bien sympa)...
 
WRInaute occasionnel
Et le vainqueur est...

Bah ! Mon classement est un peu orienté et je me dirige donc vers un classement apparent de toutes les pages à la racine. Cela ne laisse en rien préjuger de la façon dont c’est effectivement organisé en arrière-plan. Je pense néanmoins que je stockerai là aussi toutes les pages au même endroit en scindant d’un côté la page elle-même et de l’autre ses conteneurs.

Ayant travaillé sur la gestion des nœuds lors de la création de ce que l’on appelait alors tout juste le langage de balisage d’hypertexte, j’avais rapidement découvert que dans une arborescence les outils savaient facilement lister une liste de même niveau [domestique, sauvage], un peu moins les conteneurs [animaux], et beaucoup moins les contenus [chat, chien, furet]. Si en plus les éléments se retrouvent dans des endroits épars, cela complique encore la chose et rend de plus possibles les oublis.

Pourquoi la racine et pas dans un dossier réservé, par exemple "/page/" ? Tout simplement parce que la page index.php doit nécessairement se trouver à la racine, ce qui amène donc toutes les autres pages a figurer également ici.

Les contraintes de la classification par arborescence

On voit bien que ce type de classification amène deux contraintes de classement.

1. L’organisation par arborescence imagine un seul conteneur à chaque embranchement : le genre chat appartient à la sous-famille petit félin de la famille félin du sous-ordre féliformes de l’ordre carnivore de l’infra-classe eutherien de la classe mammifère du sous-embranchement vertébré de l’embranchement chordé du règne animal. Or, on peut vouloir classer également un chat selon d’autres types de classement : un chat peut être mâle ou femelle. Il peut être jeune ou vieux. Il peut être né dans le Loir-et-Cher ou dans le Puy-de-Dôme.
Concrètement, qui n’a pas voulu un jour réorganiser son forum ou son blogue ? Si toutes les pages semblent placées au même niveau, la suppression de l’arborescence supprime le problème et se borne à restructurer quelques liens des pages correspondant à la classification sans changer les chemins d’accès de tous les autres contenus.

2. Et puis bon, dans la vraie vie, un contenu possède plusieurs conteneurs, au moins 2 dans le cas le plus simple. Le chat a par exemple deux parents : son père et sa mère. Cela ne peut pas ressortir dans l’arborescence. C’est plus facile si tout se trouve au même endroit, le conteneur comme le contenu.

Les avantages d’un seul contenant

1. Il rend possible l’écriture relative qui décharge singulièrement le travail de maintenance. On n’a plus à prévoir des "../" qui perturbent tant les robots, ni d’ajouter des couches ou des éléments pour détourner les mauvais élèves [robots humains ou logiciels] qui voudront voir le contenu de "sauvage/" parce que l’URL qu’on livre sera "sauvage/chat" et que nous on ne veut pas qu’il voie tout le contenu de "sauvage/".

2. Il rend plus facile [Newbispastaper] la dictée de l’URL.
— Tapez animal/chorde/vertebre/eutherien/carnivore/feliforme/felin/chat
— Heu... euthe quoi ?
Tandis que :
— Tapez chat.
— Haaaa...

3. Il permet des noms plus longs [Indigene]. Cela permet d’éviter plus facilement la troncature de l’URL dans la citation des URL pour un SERP, un blogue, un forum, etc.
L’écriture que l’on voit souvent sur Internet pour les liens "animal/.../chat" n’a ici plus de raison d’être.

4. Il évite les redirections [Marie-Aude]. Les URL des pages ne changent pas de place [Webrankinfo].

5. Il n’est plus limité en quantité [Longo600] puisque la majorité des hébergeurs utilisent le ext4 [cela dit, 32 000, c’était déjà beaucoup].

6. Il concentre la part infime du jus SEO du nom sur le nom de la page elle-même et non sur sa catégorisation [Indigene]. Cet élément peut toutefois être un inconvénient ou un avantage.
À propos du nom lui-même, à noter que le Schtroumpf à lunette, celui qui porte un pull rouge avant de pouvoir enfin porter un bonnet rouge à la place du Grand-Schtroumpf, déclare qu’il préfère les noms de pages avec une extension. https://www.youtube.com/watch?v=dSG6C33GwsE.

7. Les outils de développement permettent un accès rapide à la page sans un déroulement laborieux de toutes les URL [Marie-Aude] pour en retrouver une dans un grand nombre d’autres pages. Sur mon forum [WMP] qui utilise un tel système [vBulletin], l’administrateur comme le visiteur peut ainsi très facilement retrouver une page.

8. Il n’y a plus le problème de savoir comment créer la structure de l’URL et la répartition des mots dans ce nom [Indigene] puisque le nom sera court et n’a pas besoin d’un affixe de catégorie [Webrankinfo].
 
Discussions similaires
Haut