Qu’est-ce qui fait une “URL conviviale”?

J’ai lu beaucoup de discussions récemment (à la fois sur ce site et ailleurs) à propos des “URL conviviales” mais je ne suis pas sûr de savoir ce qui rend une URL “conviviale” et pourquoi . Illustration:

Voici un exemple d’URL qui serait retenue par la majorité des développeurs Web actuels comme “conviviale”:

www.myblog.com/posts/123/this-is-the-name-of-my-blog-post

Considérant que cela serait considéré comme “hostile” (c’est-à-dire mauvais, néandertalien, ignorant, stupide):

www.myblog.com/posts.aspx?id=123

Mes questions:

  • L’URL “conviviale” ne contient-elle pas des informations d’identification en double sur le blog en question? En d’autres termes, une fois que vous avez l’identifiant (123) du message, pourquoi avez-vous besoin du titre? Ne serait-ce pas une violation du mantra “ne vous répétez pas”?
  • Quelle est la différence entre la forme d’une URL en ce qui concerne les utilisateurs? Les utilisateurs saisissent-ils réellement les URL complètes à la main (autres que le TLD, bien sûr)? Les utilisateurs consultent-ils l’URL d’une page pour déterminer la nature de la page? Pourquoi avons-nous besoin du titre de l’article dans l’URL? N’est-ce pas ce que sont la balise et le contenu de la page </code> ? </li> <li> J’entends souvent SEO comme une raison pour laquelle la forme d’URL “amicale” est préférée. Pourquoi une araignée de moteur de <a href="https://www.ipgirl.com/ip/recherche" title="Topics of recherche" target="_blank">recherche</a> se soucie-t-elle de l’URL? Ne sont-ils pas des logiciels automatisés qui explorent des pages (et des liens vers d’autres pages qui y figurent)? Si les moteurs de recherche étaient écrits comme les autres composants logiciels (par exemple, les composants d’access à la firebase database), l’URL ne serait qu’un identifiant sans signification (similaire à un guide de ligne dans une firebase database relationnelle). Si je concevais un schéma de firebase database avec quelque chose comme l’URL “conviviale” ci-dessus en tant que clé primaire d’une table, je serais (assez correctement) rongé. </li> </ul> <p> J’ai dit plus tôt “jusqu’à un certain point”, car les URL peuvent évidemment devenir incontrôlables. Voici une URL réelle d’Amazon.com que je ne pense pas que quiconque dans leur esprit pourrait considérer comme “amical”: </p> <blockquote> <p> http://www.amazon.com/Bissell-Kitchen-Housewares/b/ref=amb_link_5001972_17?ie=UTF8&node=694500&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=gp-center-5&pf_rd_r=1ZXNJFE0CCFFDH4B9HGH&pf_rd_t=101&pf_rd_p=405478901&pf_rd_i=510080 </p> </blockquote> </p> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <ins class="adsbygoogle" style="display:block; text-align:center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-2131274154113768" data-ad-slot="2093644592"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> <ul><li><a href="https://www.ipgirl.com/57/desactiver-le-cache-chrome-pour-le-developpement-de-sites-web.html" rel="bookmark" class="nav-link p-0">Désactiver le cache Chrome pour le développement de sites Web</a></li></ul> <div class="list-group list-group-flush"> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Tim Berners-Lee (l’architecte du WWW) a écrit un excellent article sur ce sujet il y a environ 10 ans. </p> <ul> <li> <p> Votre exemple est une mauvaise URL – mais pas seulement parce qu’elle a à la fois un identifiant et un “slug” (la forme abrégée et coupée du titre de la page). <strong>Mettre le titre de la page dans votre URL est problématique à long terme.</strong> Le contenu changera avec le temps. Si vous modifiez le titre de cet article, vous devrez choisir entre conserver l’ancienne URL ou modifier l’URL pour correspondre au nouveau titre. Changer l’URL brisera tout lien précédent vers cette page. et ne pas le changer signifie que vous aurez une URL qui ne correspond pas à la page. Ni l’un ni l’autre n’est bon pour l’utilisateur. Mieux vaut simplement aller avec <em><a href="http://www.myblog.com/posts/123" rel="nofollow ugc">http://www.myblog.com/posts/123</a></em> . </p> </li> <li> <p> Les utilisateurs ont souvent besoin de taper une URL, mais plus important encore, ils modifient parfois les URL existantes pour trouver d’autres pages de votre site. Ainsi, <strong>il est souvent bon d’avoir des URL identifiables</strong> . Par exemple, si je veux voir l’article 124, je pourrais facilement consulter l’URL actuelle et indiquer que l’URL de la page que je veux voir est <a href="http://www.myblog.com/posts/124" rel="nofollow ugc">http://www.myblog.com/posts/124</a>. C’est un niveau de convivialité qui peut être d’une grande aide pour les personnes cherchant à trouver ce qu’elles recherchent. L’inclusion d’autres informations (comme le sujet de la publication) peut rendre cela impossible, ce qui réduit mes options d’exploration. </p> </li> <li> <p> <strong>Oubliez le référencement</strong> . La technologie des moteurs de recherche réduit l’efficacité des hacks SEO depuis un certain temps. Un bon contenu est toujours roi – et à long terme, vous ne pourrez pas jouer au système. </p> </li> </ul> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Pour moi, l’ <em>URL conviviale</em> signifie que l’on a tenté d’inclure des informations sémantiques dans l’URL pour la rendre plus adaptée à la consommation humaine. C’est un exemple intéressant d’une interface ordinateur-ordinateur qui est augmentée et construite pour améliorer l’interface homme-ordinateur. </p> <p> Donc, dans vos deux exemples: </p> <ul> <li> <code>www.myblog.com/posts/123/this-is-the-name-of-my-blog-post</code> est sympathique, car vous avez inclus le titre dans l’URL – cela vous <em>indique</em> quelque chose à propos de la page. </li> <li> <code>www.myblog.com/posts.aspx?id=123</code> est désagréable car il est cryptique et obscur: il est parfaitement logique pour une firebase database, mais rien pour vous ou pour moi. </li> </ul> <p> Les URL conviviales sont fantastiques dans certaines situations et inutiles dans d’autres. Fondamentalement, si un utilisateur devait y être exposé, je ferais de la création d’URL conviviale une priorité et ce n’est pas seulement une question d’esthétique. Il est <em>beaucoup</em> plus facile de revenir aux URL à partir de la barre d’adresse si vous pouvez rapidement voir et comprendre les différentes options. De plus, il est plus évident de savoir où vous allez si vous suivez un lien à partir d’un site Web. page. </p> <p> Combinez tout cela avec la barre impressionnante de Firefox 3+ (qui vient sûrement aussi dans d’autres navigateurs), et l’auto-complétion dans la barre d’adresse devient incroyablement puissante lorsque vous traitez des URL conviviales. </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Il semble y avoir beaucoup d’informations contradictoires sur les effets de queryssortingng sur les robots, mais le consensus est que plus qu’un couple de parameters nuit à votre référencement car une variable de chaîne de requête longue indique un contenu dynamic et la plupart des moteurs de recherche seront nombreux. moins agressif en indexant votre page. </p> <p> Ajouter un slug à votre URL, comme <em>this-is-the-name-de-mon-blog-post à</em> partir de votre exemple, rend également vos liens plus différents les uns des autres qu’un simple numéro d’identification, et ajoute des mots plus significatifs dans le URL. Ce sont toutes des choses que les moteurs de recherche recherchent. </p> <p> Personnellement, je trouve que ces URL sont beaucoup plus faciles à parsingr visuellement car il y a moins de caractères de ponctuation utilisés, et les paires nom-valeur dans la chaîne de requête peuvent être très verbeuses et difficiles à mémoriser. </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> C’est un bon point sur la façon dont vous mettez des informations inutiles dans l’URL. </p> <pre> <code>http://stackoverflow.com/questions/522466/what-makes-a-friendly-url</code> </pre> <p> Une fois que l’identifiant unique 522466 est connu, le rest est inutile, il sert donc uniquement à rendre l’URL “agréable” et à donner à l’utilisateur une idée de ce à quoi la page est liée. Mais cela crée un autre problème. La plupart des sites ne “vérifient” pas cette partie de l’URL, vous pouvez donc mettre – </p> <pre> <code>http://stackoverflow.com/questions/522466/omg-goatse-bought-by-bill-gates</code> </pre> <p> Pourtant, il sera toujours lié à cet article. Vous pouvez voir comment cela peut causer <em>plus de</em> problèmes qu’ils ne le sont parce qu’ils peuvent être utilisés de manière malveillante. </p> <p> Je pense que Digg a adopté la bonne approche à cet égard. Ils n’utilisent pas les identifiants dans leurs URL. En coulisse, ils obtiennent l’ID de leur firebase database uniquement à partir du titre donné. </p> <pre> <code>http://digg.com/linux_unix/I_Like_Linux_so_my_aunt_sends_me_this_for_Christmas</code> </pre> <p> Ceci, pour moi, est l’url <strong>parfait</strong> . Cela me donne toutes les informations dont j’ai besoin pour me sentir en sécurité en cliquant sur le lien. </p> <p> En fait, les titres jouent un rôle tellement important que, dans le monde de la digg, les gens “aveuglent” le fait qu’ils aiment le titre ou s’y intéressent. Si votre URL semble intéressante, vous pourriez très bien avoir plus de trafic sur votre site. En même temps, vous le rendrez plus convivial, plus joli et les moteurs de recherche vous en remercieront. Pour autant que je sache, les URL conviviales sont gagnantes pour tout le monde. </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Mes pensées sur vos trois balles: </p> <ul> <li> Je dirais que ce n’est pas une URL optimale. Je ne sais pas pourquoi on montrerait à la fois l’identifiant de poste et le titre. Je n’inclus jamais les identifiants de poste dans mes URL, uniquement les titres et les dates (parfois) </li> <li> Pour les utilisateurs, le plus court est préférable. </li> <li> Les moteurs de recherche regardent l’url. Que ce soit logique ou non, ils le font. Avoir des mots-clés dans l’URL offrira des avantages SEO. </li> </ul> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Je suis d’accord avec vous, mais <em>chut</em> , ne le dites à personne. </p> <p> C’est juste mon humble avis, mais il me semble idiot que </p> <pre> <code>http://stackoverflow.com/questions/522466/</code> </pre> <p> et </p> <pre> <code>http://stackoverflow.com/questions/522466/what-makes-a-friendly-url</code> </pre> <p> sont la même page. Je veux dire, je peux voir que le titre de la question avec un trait d’union donne un certain contexte à l’URL, mais à moins que vous ne sachiez que cette option est facultative, l’URL s’allonge inutilement. </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Tout d’abord, ils sont sympathiques aux robots des moteurs de recherche. Google et les autres utilisateurs accordent une grande importance aux mots dans l’URL qui correspondent aux mots de la page. Par conséquent, si le titre de votre article de blog se trouve dans l’URL, cela aidera votre moteur de recherche. </p> <p> Deuxièmement, ils sont amicaux envers les gens qui ne savent pas ce qu’ils visitent. Parmi les liens que vous avez utilisés à des fins de comparaison, quels sont ceux sur lesquels vous avez le plus de chances de cliquer sur votre compte Twitter / email / IM / etc? </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Ahh … l’astuce est de savoir qui l’URL est amicale. Les moteurs de recherche perçoivent la première URL comme plus conviviale, car elle contient apparemment des informations de contenu dans l’URL et ne ressemble pas à la même page répétée avec un paramètre différent. </p> <p> Par exemple, en comparant </p> <pre> <code>www.aTvShowSite.com/show.aspx?id=123 www.aTvShowSite.com/show.aspx?id=124</code> </pre> <p> un robot va dire d’accord, je ne sais pas ce que c’est … mais ils ont la même page pour moi. </p> <p> Considérant que la comparaison </p> <pre> <code>www.aTvShowSite.com/shows/AmericanIdol www.aTvShowSite.com/shows/Lost</code> </pre> <p> les fait ressembler à des pages différentes (même si cela peut être la même page d’aspx qui les dessert), et les robots ont tendance à les classer plus haut. </p> <p> EDIT: En outre, il convient de noter que de nombreux robots examinent le texte de l’URL pour déterminer leur utilité. Par conséquent, une recherche sur “Lost” sera probablement plus fréquente que la première, même si le contenu de la page est identique. </p> </div> </li><!-- #comment-## --> <div class="list-group-item list-group-item-action flex-column align-items-start"> <p> Pour ce qui est de: </p> <blockquote> <p> <em>Ne serait-ce pas une violation du mantra “ne vous répétez pas”?</em> </p> </blockquote> <p> Cela fait référence à l’application <strong>CODE !!</strong> , pas l’application elle-même !! </p> <p> Il est tout à fait logique d’avoir </p> <ul> <li> Titre dans la balise <title>
  • Dans l’URL
  • Et comme première ligne dans le contenu.

Et à peu près partout où le contenu en a besoin.

Qu’est-ce que “mantra” se réfère si votre code doit ressembler à ceci:

  <%=obj.getTitle()%> Reading:

<%=obj.getTitle()%>

Link to this:obj.getTitle() Etc. etc.

Au lieu d’avoir des méthodes différentes avec du code copier / coller tout autour de votre application.

L’URL “hostile” que vous montrez expose un détail d’implémentation: et si, dans le futur, vous décidiez de supprimer ASP et d’utiliser quelque chose d’autre? Vous devrez changer toutes les URL (baad!) Ou utiliser un schéma de renommage.

Le fait que le titre soit répété dans l’URL n’est peut-être pas nécessaire, mais il s’avère pratique lorsque vous faites beaucoup de collage de liens, pour vérifier que vous vous connectez au bon endroit.

Notre site Web utilise des URL dites «inamicales», mais nous créons des URL spéciales «conviviales» pour des emplacements spécifiques que le public utilise pour des fonctions spécifiques, en particulier sur des documents imprimés.

Par exemple, nos tickets de stationnement ont http://www.dnv.org/parking sur eux.

CP

Eh bien, pour commencer, essayez de garder les caractères séparés de (az, AZ, 0-9) et bien sûr: /._- hors de l’URL. Tout le monde n’a pas tous ceux sur leurs claviers (par exemple, je n’ai pas et sur mon clavier, je n’ai pas non plus)

Par exemple, si vous faites une parsing d’URL ou quelque chose de similaire, cela aide aussi si la syntaxe de l’URL est “propre”

La 2ème URL semble plus conviviale, tandis que la première semble compatible avec les moteurs de recherche.

Les moteurs de recherche accordent une plus grande pertinence aux mots apparaissant dans l’URL. Le nom de domaine est le plus élevé (car il ne peut pas changer), le rest de l’URL est hautement prioritaire car la longueur est limitée, puis le corps du document est analysé.

Ma réponse est assez subjective, car cela dépend si vous êtes humain (facile à taper manuellement ou à lire à un ami) ou si vous êtes favorable aux moteurs de recherche (ce qui renforce votre classement).

Dans cette situation, il ne brise pas vraiment le principal DRY, car en ce qui concerne un moteur de recherche, «522466» n’est pas la même chose que «quoi-fait-un-amical-url»

Généralement, pour les sites comme StackOverflow, le jeton est la seule information qui compte; vous pouvez généralement mettre ce que vous voulez après ce moment et cela vous amènera au même endroit (ignoré par le serveur Web).

La description de la page est seulement là pour aider les moteurs de recherche à identifier le contenu de la page (ce qui est bien)

Un autre point: les gens modifient parfois manuellement les URL afin de monter dans l’arborescence des répertoires. Ils peuvent donc essayer de charger une page telle que http://site.com/a/b , obtenir une erreur “Non trouvé”, puis essayer http://site.com/a ou http://site.com . Bien sûr, si vos URL ne sont pas basées sur une arborescence de répertoires réelle, cela peut ne pas fonctionner. Mais vous pouvez toujours essayer de le supporter.

Certains navigateurs encouragent même cela, comme IE avec ses messages d’erreur et Safari avec un menu qui apparaît lorsque vous cliquez avec le bouton droit sur le titre de la page.

Matt et @bigmattyh: SEO n’est pas “hacks”: c’est comprendre ce que “bon contenu” signifie sur le web. Les titres de page font partie du contenu. Un bon texte d’ancrage dans les liens est un “bon contenu” (plutôt que d’utiliser des mots comme “cliquez ici” comme texte du lien). Placer des liens dans leur contexte plutôt que dans une liste est un “bon contenu”.

Les titres de page sont faciles à lire, mais ils demeurent l’un des moyens les plus faciles d’améliorer le SERP. Oui, les liens entrants (et leur qualité) sont essentiels, mais les titres peuvent faire des merveilles, en particulier à court terme. Vous n’avez pas besoin d’utiliser le titre de la page (qui peut changer de temps en temps) comme titre du message: résumez le contenu manuellement.

Ne devinez pas ce qui suit: (a) lisez des sources comme SEOmoz.org et (b) parsingz rigoureusement votre propre site.

Le terme URL lisible est également très utilisé. Utiliser des URL conviviales / lisibles est une technique de référencement naturel et c’est à ce sujet. Sinon, plus le chemin est court, mieux c’est. Faire des règles de réécriture ralentit généralement le processus d’accélération de la page vers le client.

À mon avis, les identifiants et les UUID ne doivent jamais faire partie de l’URL, jamais.

1) Certaines bases de données NoSQL n’utilisent aucun identifiant, elles utilisent des UUID. Les UUID sont longs, les portions sont séparées par des tirets. Google traitera un tiret comme un séparateur de mots: cela signifie que votre URL aura 5 mots-clés inutiles.

2) Un être humain ne comprend pas les identifiants ou les UUID. Une personne comprend les mots et les URL parlantes.

3) Si le titre change, vous pouvez simplement faire une redirection comme le fait WordPress, comme @TRiG.

4) Enfin, n’oubliez pas d’utiliser une date, afin de pouvoir distinguer deux articles ayant le même titre et publiés dans une année, un mois ou un jour différent. Par exemple, vous pouvez avoir deux avis (première édition et deuxième édition) du même livre.

 http://example.com/2013/02/11/data-mining-concepts-and-techniques 

et

 http://example.com/2011/05/23/data-mining-concepts-and-techniques 

5) Une date aidera également tout utilisateur à déterminer si le contenu est récent ou non.

6) Une date appenda un mot-clé important à votre URL: l’année. Supposons que je veuille voir les plus belles filles du monde, je taperai dans Google: “Les plus belles filles du monde en 2014”. Mon url sera:

 http://example.com/2014/07/10/the-most-beatiful-girls-in-the-world 

7) Enfin, Chrome met en cache le site que vous avez visité, vous pouvez donc trouver le site ci-dessus en tapant simplement la barre d’adresse “girls”.

Le terme URL lisible est également très utilisé. Utiliser des URL conviviales / lisibles est une technique de référencement naturel et c’est à ce sujet. Sinon, plus le chemin est court, mieux c’est.