Fermez vos URLs !

Fermeture des URLs pour le référencementLa mode actuelle pour les URLs consiste à ne pas mettre d’extension.
Rien ni personne ne peut interdire ces URLs dépouillées, mais la question se pose par rapport à l’accessibilité pour les moteurs de recherche

Pour aller plus loin, le slash de fermeture d’un répertoire est également concerné.

Dans un Web parfait, toutes les fantaisies seraient permises. Seulement, nous avons affaire à des moteurs de recherche qui ne sont pas forcément aussi perfectionnés qu’on peut le penser. En fait, ils sont carrément idiots sur certains aspects, notamment sur le fait qu’ils ne comprennent toujours pas ce qu’ils lisent.

En ce qui concerne les URLs, je préconise toujours d’indiquer une extension à la fin. Peu importe que ça soit .html, .htm, .php, .asp ou même .truc. L’important est d’indiquer aux moteurs qu’il a bien affaire à une page.

Même problème pour les répertoires qui ne sont pas fermés. En plus, dans ce cas, nous sommes en présence d’une véritable faiblesse dans la capacité de Google à indexer un répertoire qui n’est pas fermé. Le moteur doit absolument ajouter un slash à la fin d’un répertoire pour l’indexer.

Lorsqu’une URL ne possède ni slash ni extension, l’interprétation est laissé libre. Est-ce un répertoire ou une page ?

Le détail peut paraître futile, mais le premier niveau du travail d’un référenceur est d’optimiser l’accessibilité pour les moteurs de recherche. Le deuxième niveau étant d’accéder à la performance.

Sur ce premier niveau, tous les détails comptent et l’architecture n’est pas à négliger.

Dans ce sens, la notion de page ou répertoire n’est pas du tout la même puisque les pages s’emboîtent dans des répertoires qui s’emboîtent entre eux.

Parmi les accusés, WordPress est en bonne place pour présenter par défaut des URLs sans extension ou s’amuse à mettre un slash à la fin d’un billet lorsqu’on choisit %postname% comme Permalien. En plus, pour WordPress, la notion de page ou répertoire est plutôt floue sur certaines zones. Par exemple avec la manière de gérer les pages de commentaires.

La simplicité est la solution de 99% des problématiques sur le Web. Une infrastructure et une architecture limpides sont à la base du succès d’un site Web. Dans ce sens, je conseille vivement de signifier clairement la notion de page ou de répertoire.

Edit : 26/01/12

Tiens tiens, Matt Cutts dit exactement la même chose que moi…
Je ne dis pas que j’ai raison à chaque fois, mais expérience, logique et raisonnement me suggèrent bien souvent la bonne solution.

63 réflexions sur “Fermez vos URLs !”

  1. Je te rejoins à 100%, cela clarifie les choses pour les moteurs de recherche mais également pour les internautes. Ce n’est pas ce qui fera gagner 10 places dans les SERP mais une accumulation de détails peut faire clairement la différence.

  2. Merci pour ces infos.
    C’est vrai que je n’y pense pas toujours, j’avais jamais pensé que le grand GG (ou un des ses copains) puisse avoir ce genre de petits problèmes.

  3. Explication simple et de bon sens, j’adhère.
    En revanche, ton avis sur url rewriting serait intéressant. Pour le moment je n’y vois pas franchement d’intérêts, à plus forte raison si on veut éviter la triplette du bourrin :-), mais bon, je semble être le seul à penser ça …

  4. Bien d’accord avec toi Laurent, après dans la pratique attention quand même car vouloir absolument fermer une URL peut poser des problèmes : si cela s’avère être une rustine au niveau code, cela peur fragiliser l’intégrité des patterns de construction d’URL.

  5. @Littlebuzz : optimiser les URL avec du rewriting ne veut pas dire forcément que tu fais de la triplette de bourrin. Tu peux avoir un title en « voiture d’occasion » et une url avec « /auto-occasion.htm » par exemple.

  6. Entièrement d’accord avec toi sur le principe. A ce sujet, je me suis lancé il y a quelques jours dans la mise en place d’un script pour trouver toutes les extensions indexées d’un site avec le duo de commandes site: et filetype: dans une boucle. Le but orienté sécurité était de trouver d’éventuelles extensions indexées malgré l’utilisateur (php_, php_old, xls, doc…) suite à cet article http://www.yapasdequoi.com/google/478-la-commande-filetype-de-google-amie-ou-ennemie.html
    Mais j’ai vite abandonné quand les SERP me renvoyaient des URL du genre http://domaine.com/monarticle, impossible dans ce cas de filtrer ces pages avec la commande filetype dans ma boucle, aucune extension utilisée pour faire -filetype:monarticle.

    Mais je m’égard… Pour revenir à ton article, je pense que tous les CMS sont à mettre sur le banc des accusés à partir du moment où les structures d’URL personnalisées sont paramétrables sur un bon nombre d’entre eux, le paramètre par défaut n’étant absolument pas lié à une extension particulière.

  7. Bien vu, c’est vrai que je me contentais de faire en sorte que les URL ne fassent pas 3 km de long et que j’avais pas vu ce côté lisibilité par le moteur. merci du conseil 😉

  8. Pour ma part, je distingue bien les pages et dossiers en utilisant les extensions et slash.

    Pour autant, j’étais loin de penser que cela pouvait avoir une incidence sur les moteurs de recherche.

    Mais ton explication est pleine de bon sens. Merci pour cette précision 😉

  9. Salut Laurent,

    Ta remarque est très censée.
    Dans le même ordre d’idée, j’ai remarqué que Google commençait à « spliter » les URLs pour indexer les répertoires (comme le faisait Yahoo il y a fort longtemps). En gros, avec une page du type ndd.ext/cat/post , sans faire de liens vers ndd.ext/cat/ , la page PEUT être crawlée. De là à en déduire que Google aimerait que les contenus soit groupés dans des répertoires « physiques », il n’y a qu’un pas.

  10. Merci d’avoir marqué noir sur blanc ce que je pratique ! Je navais pas recherché les incidences possibles sur le référencement mais rien que pour les utilisateurs je trouve cela indispensable, au moins on sait tout de suite à quel type de page on a affaire…
    Et dans la même veine certains sites devraient faire attention à ce que tous les « répertoires » qui peuvent être dans l’url soient accessibles quand on décompose l’url. Pas sûr que ça gêne les moteurs s’ils s’amusent à ça mais à moi ça m’arrive souvent et dans trop de cas l’url comporte de faux répertoires qui ne sont là que pour caler un maximum de mots-clés…

  11. Je ne suis pas du tout d’accord…

    Pourquoi spécifier une extension à la fin des URLs ?
    Les moteurs n’ont pas besoin d’avoir une extension pour indexer les pages …
    Utilité de ne pas mettre d’extension :
    – permet une pérennité des URLs
    – en quelque sort, une sécurité en indiquant pas quel langage on utilise

    « Le moteur doit absolument ajouter un slash à la fin d’un répertoire pour l’indexer. »

    ah bon ?
    qu’est ce qui te fait dire ça ?
    Des millions d’URLs sont indexées sans slash et sans extension…

  12. Quelle mauvaise suggestion !
    Que WP mette des slash à la fin des URL de pages simples j’en convient c’est très con, car à la fin on ne distingue plus rien.

    Ceci dit voila la belle grosse connerie que tu indique : « Peu importe que ça soit .html, .htm, .php, .asp »
    Justement. La différence est énorme.

    Un bon référencement c’est un référencement pérenne. Or conseiller d’afficher une extension relatif a une techno non standard (ici asp et php) est pas très futé.

    En effet, j’ai peut-être fait un site en PHP, mais j’aimerais bien le refondre en .Net. Je vais devoir garder le .php ? Je conviens que garder l’extension .php ne pose pas de probleme technique pour .Net mais tout de même.
    D’une manière générale, les extensions relatives à des technos de serveurs d’applications sont à proscrire simplement. Question de pérénité ET d’indépendance.

    Mon conseil :
    * Si extension
    – Utiliser .htm, .html (là on est tranquilles, est c’est de toutes facons ce qui est renvoyé par le serveur dans tous les cas)
    – Utiliser une extension freestyle perenne du genre
    laurentbourrelly.com/blog/seo-daddy.lb
    ou pap.fr/location-appartement.pap

    * Si pas d’extension
    – bien structurer les urls pour bien séparer les dossiers dans pages simples.

    Mais virez-moi ces .php .asp .cfm ! On est pas là pour faire de la pub à des technos…

  13. Beaucoup de certitudes dans cet article, et pourtant pas le moindre début de preuve de quoi que ce soit. Nous ne sommes plus en 2002, Google et les autres se débrouillent très bien avec les dossiers et pages… D’ailleurs, un dossier/repertoire n’est rien d’autre qu’une page.

  14. Personnellement, je suis un adepte de .php (même pour les sites en full HTML) car j’ai toujours rencontrés des contraintes techniques avec d’autres prestataires qui avait du mal à gérer la réécriture d’url ou la gestion des 301 lors d’une refonte. du cout dès qu’un client décide de virer une pages je lui envoi un fichier laditepage.php avec les entêtes de redirection et lui demande de la déposer sur le serveur.
    C’est bête mais c’est pour gagner du temps et pour éviter de me prendre la tête avec le prestataire du client qui souhaite facturer une demie-journée pour toucher à l’ .htaccess….

  15. Intéressant comme remarque, jamais eu de problème avec des URL non fermés toutefois :
    – mes urls non fermés finissent par des chiffres (id ou dates)
    – je crée toujours du contenu dans mes bases de dossiers (exemple pour la page : /test/test123, la page /test/ fournit un contenu)

    Je regarderai ça de près dorénavant (voir si cela a un impact)

  16. @dldstyle : voilà t’as tout compris.

    @Shelko : pourtant si…

    @Littlebuzz : le souci avec le Rewrite est que la légende urbaine dicte qu’il faille absolument réécrire les urls. Pourtant, les moteurs n’ont aucun problème avec les URLs dynamiques – jusqu’à une certaine limite où c’est n’importe quoi.
    Puis Rewrite ne veut pas forcément dire triplette. Au pire, si c’est trop chiant, tu agis sur le H1, plutôt que l’URL.

    @gaujay : bien sûr qu’il ne faut pas changer ses URLs non plus parce que j’ai dit qu’il faut les fermer. Puis comme tu dis, il y a des cas où les contraintes techniques sont impossibles à surmonter.

    @angouleme : de rien

    @Aymeric : en plus, ce détail n’est que la surface immergée de l’iceberg. Merci pour ton lien.

    @Vince : par rapport à la longueur des URLs, on sait que Google préfère crawler d’abord les courtes. Cela ne veut pas dire qu’il ne crawle par les longues, mais quand je vois certaines (vous savez celles où on peut lire le contenu de la page).

    @Hervé : le bon sens doit dicter notre ligne de conduite. C’est le seul rempart qui reste lorsqu’on se demande comme agir.

    @Didier : dans la logique d’une architecture type pyramidale, cela me semble sein de tout bien ranger comme il faut.

    @loto : je mets un bémol pour l’utilisateur car franchement qui se préoccupe réellement de regarder les URLs ?

    @Rebel : ce qui me fait dire cela est tout simplement la reco de Joachim Kupke, un googler d’un niveau bien supérieur à Matt Cutts concernant l’indexation.
    http://www.laurentbourrelly.com/blog/400.php (voir point 5).

    @Canard+ : il n’y a pas de favoritisme par rapport aux extensions de nom de fichier. La connerie est de prétendre autrement. Maintenant, si tu veux remettre en cause les fondamentaux, c’est un autre discours.

    @Tom : voir ma réponse @Rebel.

    @Yassine : tout pareil que toi.

    @Vincent : attention ! Je n’ai pas dit que les URLs non fermées étaient impossibles à référencer. Ce n’est pas non plus LE grand secret qui va te propulser en tête de gondole, mais si notre métier est d’optimiser l’accessibilité envers les moteurs, ce point me paraît fondamental.

  17.  » il n’y a pas de favoritisme par rapport aux extensions de nom de fichier. La connerie est de prétendre autrement. Maintenant, si tu veux remettre en cause les fondamentaux, c’est un autre discours. »

    Tu as bien lu mon commentaire ?
    Je parle de perennité de l’url. Et du fait d’afficher une techno web qui n’a rien de perenne et qui n’interesse personne.
    Je n’ai jamais parlé de favoritisme.
    Me parler des fondamentaux ensuite et monter sur tes chevaux… T’es énorme toi…
    Prend le temps de lire les commentaires si tu y réponds.

  18. Je suis du même avis que toi, j’aime bien avoir des URLs avec une extension (et on m’a souvent pris pour un fou pour ça). Un exemple : sur mon blog les adresses des articles se terminent en .html et les répertoires avec un slash.

    En ce qui concerne WordPress, c’est très simple d’automatiser l’ajout d’une extension dans le menu Permalinks : /%postname%.html

  19. Bon bah, j’ai tout faux… La simplicité de WordPress et ma flemme d’aller chercher plus loin. En effet, on ne peut pas distinguer sur mes sites s’il s’agit de dossiers ou de pages, surtout qu’avec leur système de pages, c’est un peu des deux…

  20. @Canard+ : c’était pour voir si tu suivais. Vu que la majorité des courageux anonymes viennent seulement pour troller.

    @Florian : oui ça prend 30 secondes de construire des URLs parfaites avec WordPress – du moment qu’on sait ce qu’on fait.

    @Argonaute : le système de publication type blog est un désastre pour l’architecture. Genre la pagination est potable si tu n’a pas une grosse cadence de publication, mais tu cours au drame autrement.

  21. @Laurent Mouais si tu veux. Enfin un anonyme qui n’est pas d’accord avec toi n’est pas directement un troll. J’ai certes un peu critiqué mais donné aussi mes recommandations. Ca s’appelle de la critique constructive (pour le débat), et non pas de la critique de rageux (troll)

  22. Personnellement je n’ai jamais constaté le moindre problème d’indexation ni de positionnement sur quelque type d’url que ce soit : rewritée avec extension, rewritée sans extension, ou même non rewritée.

    L’argument avancé le plus souvent sur l’url rewritée tient plus du « confort utilisateur » et de la lisibilité, que de la problématique « seo ».

    Cela dit d’un point de vue « confort utilisateur », mon avis est qu’il vaut mieux avoir une url rewritée la plus courte et simple possible, avec une extension connue et pérenne, à savoir « .html » (ou .htm à la rigueur), même si d’un point de vue SEO ça n’a pas d’importance…

  23. @Canard+ : sur le fond de ton propos, je suis plutôt d’accord.
    Cela dit, je parle de moteurs, donc le débat sur les standards est peut-être un peu flou ou tout du moins éloigné.

    @swtor : je n’ai jamais dit le contraire. Il s’agit d’un détail qui s’inscrit dans une logique globale.

  24. Je ne vois aucun intérêt à mettre une extension de fichier, ou alors à la limite pour le fun on peut y intégrer un mot-clé, exemple « .seo » 😉

    Je n’ai jamais entendu parlé d’une amélioration de l’indexation du fait de cette recommandation. Je n’ai même jamais entendu Google faire cette recommandation.

    A mon sens cela n’a réellement aucune importance.
    Dans les SERP, on voit bien que Google quand il « affiche » l’organisation du site, c’est bien à l’aide du fil d’Ariane et non avec les dossiers.

    Mais tes recommandations ne posent pas non plus de problèmes particuliers contrairement à ce que dit Canard+, car il est très aisé d’URL rewriter en htaccess n’importe quoi, et donc notamment d’afficher un « .php » même si l’on est d’un point de vue techno en DotNet (« .asp »).

  25. @ alex de @referencement

    Contrairement à ce que tu affimes j’ai dit la même chose que toi (« Je conviens que garder l’extension .php ne pose pas de probleme technique pour .Net mais tout de même. )

    @Laurent le seul standard dont je parle c’est HTML. Car c’est justement le seul qui importe les moteurs vu que c’est ce qui est renvoyé. Google se fout completement de la techno utilisée coté serveur pour générer le code.
    Si je prend le cas de l’asp.net, fut un temps cela générais un code dégueux qu’on ne pouvais pas toucher. Avec asp.Net MVC, impossible de savoir quelle techno utilisée (on cachera quelques en-tetes http aussi).

    L’extension affichée importe peu, mais d’un point de vu cosmétique pour l’utilisateur, je me passe bien d’un .php3 ou .asp. Encore une fois question de pérénité ET d’indépendance.

  26. Bonjour à tous, personnellement j’ai toujours privilégié les urls simples sans extension, uniquement pour une question d’esthétique… Je sais c’est con! Et puis je dois avouer que j’étais persuadé que cela ne pouvait avoir que trop peu d’incidence ( jugement personnel sans aucune preuve ), en revanche @vincent pourrais tu détailler ce contenu au sein des répertoires? J’ai peur de ne pas te suivre.
    Merci
    Loic

  27. @Raphaël : hein ?!

    @Alex : voir ma réponse @Rebel et le lien qui y figure. Ta veille n’est peut-être pas infaillible.

    @Canard+ : ça sent l’expérience perso douloureuse.

    @Loic : cela n’a pas beaucoup d’incidence.

  28. C est dingue mais je n avais jamais pensé au fait que si on ne rajoutait pas d’extensions, cela pouvait être considèré comme un dossier par GG. Je vais m empresser de corriger cela, merci Laurent

  29. Bonjour, merci pour cet article constructif. Pour un wordpress déjà configuré avec des permaliens: /%category%/%postname%/
    On ne peut pas passer à /%category%/%postname%.html les url existantes ne serait plus valide.
    Comment passer d’un slash à une extension valide sur un WP déjà structuré? Faut-il faire une redirection .htaccess ?
    Si vous avez des recommandations…

    Merci pour le partage.

  30. Pour dire simplement le fond de ma pensée, que ce soit à propos du format des urls mais aussi de bien d’autres choses (liens relatifs/absolus, organisation dossiers/pages etc …):

    1 – compliquez le travail des robots d’indexation et si vous avez des problèmes allez pas pleurer sur les forum spécialisés.

    2 – simplifiez le travail de ces mêmes robots et cela ne vous nuira en rien et peut-être ce sera même profitable.

    En plus synthétique : C’est pas dit que ce soit pénalisant, mais si ça l’est, tan-pi pour toi, fallait faire gaffe 😉

  31. Ton article de 2009 sur les 302 me convint pas du tout… 🙂

    Tout cela manque d’exemples, d’arguments et de faits réels…
    Rapporté une parole d’un mec de chez Google (qui est meilleur que Matt, ce qui n’est pas très dur), ça ne suffit pas.

    Je te laisse lire cet article de Google de 2010 donc plus récent : To slash or not to slash

  32. J’ai du mal à suivre la logique… Car sur le web, il n’existe aucune notion ni de répertoire, ni d’extension de fichier !

    En tout cas, aucun navigateur ne gère les « répertoires » qu’on croit identifier avec les / et heureusement d’ailleurs, car celui qui conçoit l’architecture d’un site prévoit la navigation adéquate, l’internaute n’a pas de raison de chercher à remonter d’un répertoire par exemple.
    Le nombre de / dans l’URL n’a pas forcément de rapport avec l’arborescence du site.

    Et la notion d’extension de fichier n’est utilisée ni par l’internaute ni par les moteurs.

    Il y a malgré tout le cas particulier de pas mal de fichiers externes utilisés par une page web (CSS, images, PDF, etc.) qui ont en général une extension.

    Des tonnes de très bons sites fonctionnent parfaitement (pour l’internaute et les moteurs) sans extension dans les URL.

    Ce qui est certain concernant ce slash en fin d’URL, c’est qu’il peut poser problème, car avec ou sans le / à la fin d’une URL, ce n’est pas la même adresse (sauf cas particulier de la home / NDD).

    Cela dit, j’ai peut-être mal interprété l’article ?

  33. @luc je pense que si tu modifies la structure de tes urls tu devras mettre des redirections 301, que tu pourrais facilement mettre en place au sein de ton htacess.
    Un pro peut confirmer?
    Merci

  34. @Olivier: Pour te convaincre que Google intègre bien la notion de répertoire (ou dossier) tu crée une page example.com/repertoire/site.html en ne mettant rien à l’url example.com/repertoire/, tu fais indexer ta page à google, tu attends un peu et tu regarde les logs d’accès et tu verra des erreur 404 sur l’url example.com/repertoire/ générés par Goglebot car pour lui si il a quelque chose à l’url example.com/repertoire/site.html, il doit y avoir quelque chose à l’url example.com/repertoire/

    note: historiquement, example.com/repertoire/ renvoyait le liste des fichier contenus dans le dossier example.com/repertoire/, le web a été conçu comme ça par défaut mais c’était bien avant que google et les référenceurs débarquent 🙂

  35. @Luc : en effet, les URLs sont différents avec un / ou .htm. Une redirection 301 est de mise. Seulement, ne change pas tes URLs seulement pour ça.

    @Blog Mestre : ah enfin un qui suit ! Merci mon ami.

    @Rebel : je ne sais pas si c’est mon anglais ou le tien, mais l’article de GG Blog n’est pas du tout en contradiction avec le mien.

    @Olivier : bien sûr que le dynamique ne respecte plus les bons vieux préceptes qui étaient indispensables lorsqu’on devait ranger les répertoires dans d’autres répertoires et les pages dans un répertoire.
    Peu importe que pleins de sites (gros ou pas gros) le font et n’ont pas de soucis d’indexation ou de référencement.
    C’est simplement une question d’accessibilité maximale et de logique.

    @Loïc : remarque doit bien y avoir un plugin pour ça.

    @Blog Mestre : pas grave 😀 Ca pointe vers http://www.iana.org/domains/example/

  36. Nulle part, il est dit de ne pas utiliser l’URL sans « / ».
    « Choose one URL as the preferred version. If your site has a directory structure, it’s more conventional to use a trailing slash with your directory URLs (e.g., example.com/directory/ rather than example.com/directory), but you’re free to choose whichever you like. »

    Ca doit être ton anglais alors 🙂

    Les 2 seuls articles qui parlent de ça, c’est ton article et l’original.

  37. Si mon anglais cloche, ton français ne doit pas être au point puisque je dis quelque chose de similaire en introduction.
    Google dit que tu peux choisir l’un ou l’autre. L’URL de leur exemple sans slash est une page. Le problème qui préoccupe l’indexation Google concerne les répertoires. Nulle part il est dit dans leur article qu’un répertoire sans slash est sain.
    Je suis désolé d’aller un peu plus loin que Google en recentrant les choses sur une logique bien plus globale et saine que ton point de vue. L’article Google ne se préoccupe pas de la logique d’architecture.

  38. Il faut aussi penser aux redirections dans le htacess ou à indiquer la page canonique parce que ce n’est pas parce qu’on a choisit un format d’URL que google va comprendre, il suffit d’un lien créé par quelqu’un d’extérieur qui enlève un slash en pensant faire bien…
    Qu’en pensez vous ?

  39. La mise en place d’une architecture avec les pages de listing terminées par un slash est justifiée, mais à mon goût pas pour l’accessibilité aux moteurs de recherche.

    Après avoir lu l’article de Maile Ohye sur le slash http://googlewebmastercentral.blogspot.com/2010/04/to-slash-or-not-to-slash.html, ainsi que le lien sur l’intervention de Joachim Kupke, il convient surtout de servir une 301 à la version avec ou sans slash (selon le choix). Que ce soit une page de listing (ou « répertoire ») ou une page de contenu.

    Je conclus en lisant les articles cités que Google paye cher ses tests de page avec slash en plus, puisque le bot doit en général télécharger la page et constater qu’elle est indentique à la version sans slash.
    En donnant direct un 301 dans les headers, pas besoin pour le bot de télécharger le contenu, il peut passer à autre chose, et le site bénéficie d’un crawl budget augmenté.
    Tout ça est très théorique mais c’est une bonne pratique, y compris pour un user qui a mal écrit l’url.

    La tâche qui consiste à déterminer le type de page présentée sur une url ne prend pas ou très peu en compte le format d’url.

  40. Cluny : le rel canonical n’est qu’une rustine. Je conseille vivement d’opter pour des solutions plus solides en amont du problème.

    @Baptiste : pourtant tu parles bien d’accessibilité pour les moteurs dans ta démonstration.

  41. Ah on a pas la même définition de l’accessibilité je pense, pour moi c’est juste rendre le contenu de son site entièrement indexable à Google (et de fait aux utilisateurs).

  42. Je ne m’étais jamais vraiment interroger sur ce point, merci en tout cas pour ces explications. Je vais désormais veiller de près à placer une extension à la fin de chaque page, même si j’utilise souvent WordPress. C’est vrai que j’avais la mauvaise manie de ne rien laisser à la fin…

  43. Voilà bien une notion à laquelle je n’avais jamais prêté une réelle attention, qui, comme tu le rappelles fait bel et bien parti de la partie accessibilité du moteur. Bon à savoir, et à corriger, merci

  44. Comme beaucoup je n’avais jamais fait attention à cette « problématique ».
    Tournant à 70% sur du wp avec des url non fermé, je ne vais pas « m’amuser » a redir 301 ses url.

    Je suis persuadé, que sur un site un prod, le jeu n’en vaut pas la chandelle (ie temps passé, proba d’erreur, « perte de transmission de « jus » par la 301 ? »)

    Néanmoins je note cette reco ,qui me semble complètement logique, pour les prochains sites ou refontes total, c’est ahma à ce moment que ses choses doivent être faites.

  45. J’avoue que je ne suis pas du tout d’accord avec cet article, et pour plusieurs raisons…

    D’abord, je suis assez d’accord avec ce qui est dit dans les commentaires, à savoir qu’une URL avec extension implique de conserver la même technologie sur le site Ad Vitam Eternam.

    Mais au delà de ça, Google se fout complètement de savoir si c’est un répertoire ou non. Certes, la présence de plusieurs niveau dans une adresse (séparée avec des slashs) va l’inciter à essayer d’indexer des niveaux inférieurs, mais cela s’arrête là.

    Le web est tellement vaste que Google ne se préoccupe plus vraiment du type de contenu, que ce soit un forum, un blog, une page de commentaire, un contenu aléatoire, une homepage, un article, un formulaire, une catégorie ou autre.

    Ce qui compte, c’est :
    – le contenu de la page
    – la popularité de celle-ci (nombre, diversité et pertinence des ancres)
    – la popularité et l’ancienneté du site
    – le maillage interne
    – une bonne conception du code source (sans freins).

    La fin de l’URL, il s’en fout comme de l’an 40… Par contre, l’utilisateur lambda va préférer les URLs les plus courtes possibles, avec un simple slash, car elles se lisent plus vite, se recopient plus vite et se comprennent plus vite.

    Cependant, malgré ce que je viens de dire, les urls avec extensions ne sont pas plus mauvaises que les autres, mais en aucun cas elles ne sont meilleurs que les URLs se terminant par un slash.

  46. Je ne m’étais jamais penché sur cette question. Merci en tout cas de soulever cette problématique. Cependant, je trouve que rajouter l’extension rend l’url visuellement moins attractive, notamment pour monsieur tout le monde pour qui .php ou .html ne veut rien dire du tout. Après, je serais curieux de voir l’impact (s’il existe) des extensions des pages web dans les urls.

  47. @Daniel Roch : libre à toi de penser que le chemin signifié dans l’URL n’a pas besoin d’être en corrélation avec la réalité du maillage interne. D’ailleurs, je n’ai pas dit le contraire. Cependant, c’est clairement un plus si c’est le cas.
    Encore une fois, je n’ai jamais parlé de facteur bloquant, mais seulement d’un facteur ralentissant. Il faut savoir faire la différence entre ce que fait un moteur contraint et forcé et le bonheur de lui faciliter le travail.

  48. Knol, YouTube qui sont de très gros site de Google n’indique pas l’extension et je ne parle pas de Wikipedia l’un des sites les mieux indexés par Google…

    Encore un article pour faire polémique ?

  49. Salut,

    Moi non plus, je ne suis absolument pas d’accord avec cet article.

    Premièrement : une url de type : google.com/test/ représente un dossier et jamais une page !

    Deuxièmement si le crawler détecte un dossier, il cherchera une page index dedans sinon il retournera une erreur 404.

    Troisièmement : Il n’existe aucune preuve que Google traite les répertoires. il suit le fil d’Ariane et rien d’autre. Et tout cas dans la représentation des urls qu’il offre au utlisateur. (Peut-etre qu’il scanne quand même les répertoires mais ca c’est une autre histoire…)

    Quatrièmement, il faudrait vraiment etre couillon pour mettre un lien vers un document pdf par exemple et ne pas mettre l’extension pdf.

    Cinquièmement soit on affiche des urls en dur sur le site et donc il est recommandé qu’elles soient complètes (en vue d’un copier /coller) etc … sinon ca n’a aucun intéret de les afficher en dur… soit l’url s’affiche dans un href et ce que voit l’utilisateur est un mot clé ou une phrase clé (ou n’importe quoi de parlant) bien plus compréhensible pour lui qu’une url… Donc encore une fois les remarques sur la fermeture de l’url ne se posent pas

    Ce genre d’article ne fait que de créer de la polémique et ne repose sur rien de fondamental. Son but est atteint lorsque l’on voit la liste des commentaires…

  50. merci pour ce conseil je n’avais jamais fait attention au fait qu’il est nécessaire de faire la différence entre dossier et répertoire.
    C’est vrai qu’une URL sans extension est plus propre pour les utilisateurs mais doit on faire pour les moteurs ou les utilisateurs….

  51. @Laurent : Suite à ma remarque et à ta réponse http://www.laurentbourrelly.com/blog/#comment-8119

    A mon sens, il y a une différence entre ta recommandation (utiliser une extension type .php pour ses pages) et celle de dire qu’il faut éviter le duplicate content lorsque vous avez deux pages avec la même URL, ex : http://monsite.com/mapage/ et http://monsite.com/mapage »

    WordPress le gère d’ailleurs par bien http://seo-campus.org/jeu-concours-facebook/ renvoi vers http://seo-campus.org/jeu-concours-facebook

    @Canard+ : Oui effectivement, en relisant ton commentaire je vois et du coup ne comprends plus ton problème 😉

    Par ailleurs, je vois Laurent que ton article fait débat, alors qu’il semble bien inoffensif, comme quoi 😉

  52. Je me souviens qu’à une époque… lointaine, je créais des répertoire contenant le mot-clé, et le premier fichier dedans était un index
    Je faisais mes liens sur le répertoire, et ça rankait bien.

    Sinon, les urls correctement terminées, c’est un peu comme la conformité W3C, ca ne mange pas de pain et c’est plus clean.

    Maintenant je ne sais pas si Google est freiné par cela d’une manière ou d’une autre, c’est un glouton, il indexe tout 🙂

  53. Il ne faut pas sous-estimer l’interprétation des moteurs de recherche. Tous les blogs wordpress non pas par défaut des urls fermées et la plupart s’en sorte très bien pour ce qui est du référencement…

  54. Tout à fait d’accord avec l’article ! Le référencement est parfois une affaire de détails… Et même si les algorithmes sont de plus en plus performants (parait-il…), il vaut mieux mettre toutes les chances du côté du site pour être le mieux référencé possible.

    Il est toutefois très difficile d’expliquer cela à des clients qui partent du principe qu’à partir du moment où le navigateur parvient à afficher la page, tout va bien…

  55. toucher l’HTAccess de wordpress c’est pas toujours pratique et on risque vite une erreur 500 … Avant de mettre des Slash dans tous les sens, j’aurai bien aimé savoir si quelqu’un aurait fait un test croisé. pour une même page . en tout cas si cela s’avere vrai l’idée de Forian me parait interessant. faut uil choisir une extension en php ou html ou autre ?

  56. Merci pour cet article plutôt intéressant ! Il y a tellement de petites choses à savoir pour le référencement qu’il est compliqué de tous savoir.

  57. Tout à fait d’accord avec toi !

    @ATYQ: C’est pas une question de sous-estimer les capacités d’interprétation des moteurs mais plutôt que même les petites choses ont une importance.

    Si on suis ce raisonnement, il existe encore des sites bâtis avec des qui sont encore (très) bien référencés donc pourquoi s’ennuyer avec le CSS, sprite et compagnie pour alléger le code.

    C’est un ensemble de petites choses qui font les grandes… (surtout en seo :D)

  58. Bonne idée que de débattre sur le sujet. En revanche, je ne te rejoins pas forcément sur le fait de séparer un répertoire d’une page.

    A mon avis, Google est suffisamment intelligent aujourd’hui pour analyser ton cœur de page et voir si celle-ci est une page de contenu ou alors une page de liste.

    Pour ma part, sur mes sites, je ferme le / pour les répertoires et je laisse ouvert pour les articles mais sans .html ou .php ou autre .xxx car si un jour il y a migration, c’est toujours la galère ce truc.

    As-tu un cas pratique à nous présenter pour illustrer tes propos ?

    Merci 🙂

Laisser un commentaire