Actuellement, l'URL de la page d'un utilisateur est la suivante:
website.com/user/bob
Mais je pense changer cela pour être:
website.com/bob
Sans la partie /user/
. Cela semble être plus facile et plus facile à accéder, car les pages utilisateur sont l’une des pages les plus visitées sur mon site.
J'ai cependant quelques questions:
.htaccess
ou une autre méthode?Merci.
Faites le style / user/bob, car il existe une très bonne raison pour laquelle vous ne devriez pas utiliser / bob.
Concrètement, cela signifie que vous ne pouvez pas avoir d’autres chemins sur votre site Web, car ils pourraient entrer en collision avec un nom d’utilisateur. Par exemple, quelqu'un pourrait se nommer "images" et maintenant votre dossier / images ne fonctionne pas. Ou quelqu'un dont le nom est "John Smith" mais veut être l'utilisateur "js" entre maintenant en collision avec votre dossier / js où vous avez mis JavaScript.
Oui, certainement avec les configurations de routage que vous pourriez autoriser, de sorte que / images/foo.jpg fonctionne et vous donne l’image "foo.jpg" dans le répertoire des images, mais ensuite / images vous obtiendrez l'utilisateur nommé images. Ce serait fondamentalement très déroutant du point de vue de la conception technique.
Je sais que cela n'arrivera pas souvent, mais en général, il est tout simplement mauvais d'avoir un schéma qui, vous le savez, peut échouer dans certains cas.
Si vous n'aimez pas la dénomination hostile de / user, essayez quelque chose d'autre comme / home ou toute autre chose à laquelle vous pourriez penser qui pourrait être un peu moins utilitaire.
Placer l'utilisateur/membre avant le nom affecte les sentiments des utilisateurs. Imaginez que les utilisateurs contribuent à un site Web tel que Facebook, Quora, Twitter, etc. Les utilisateurs de ces portails ne sont pas que des utilisateurs; ils sont aussi des contributeurs.
Ainsi, lui donner une impression personnalisée stimulera l’affection des utilisateurs envers ce site Web. J'aime la façon dont Facebook personnalise les URL
La partie user/
de l'URL sert d'identificateur d'espace de nom en séparant les profils utilisateur des autres ressources ou entités accessibles. Supposons que votre application comporte également des groupes. Ensuite, un utilisateur Ana peut être distingué d'un groupe Ana par les identificateurs d'espace de nom, par exemple /user/ana
et /group/ana
.
Si l'utilisateur de Word doit éviter pour une raison quelconque, vous pouvez envisager des alternatives telles que profile/
, gamer/
, member/
etc.
En ce qui concerne le référencement, conserver user/
dans l'URL est bénéfique, car il ajoute un mot clé supplémentaire et augmente les chances que l'URL soit correctement classée par les moteurs de recherche.
Cela ressemble à une question de type opinion personnelle, cependant, il présente quelques défauts potentiels de conception/développement.
Je ne vois pas en quoi cela pourrait être bénéfique pour le référencement. En fait, cela pourrait rendre plus difficile d'associer cette URL à un "profil utilisateur" puisqu'il n'y a pas de segment de chemin parent (subjectif)? Mais il est difficile d’imaginer qu’une page de profil d’utilisateur serait aussi importante (en termes de référencement) pour votre site?
Sans en savoir plus sur votre site, je laisserais vos URLs sous la forme /user/bob
au lieu de simplement /bob
. Réduire l'URL simplement en /<username>
pourrait potentiellement créer des problèmes de développement (selon la manière dont votre site est implémenté):
about
, contact
ou login
? En plus d'être déroutant pour les utilisateurs, vous devrez implémenter une sorte de longue liste de noms d'utilisateur interdits afin d'éviter tout conflit de noms (sujet aux erreurs). Et cela réduira naturellement l'espace de noms des noms d'utilisateurs possibles. Avec /user/<username>
tout est un nom d'utilisateur. Quelque chose comme /user/about
peut paraître déroutant, mais cela ne cassera pas votre site.Cela se ferait-il dans mon code (mon fichier de routes) ou via .htaccess ou une autre méthode?
Cela dépend de la manière dont votre site est mis en œuvre. Bien sûr, si vous modifiez l'URL de /user/<username>
en /<username>
, il s'agit de non ce que vous pouvez faire dans .htaccess
. Comme, dans .htaccess
, il n’existe aucun moyen de déterminer si /<something>
est mappé sur un profil utilisateur ou sur une autre page de site, comme /about
, /contact
ou /login
etc. .
Cela devrait aller dans les deux cas.
Tous les deux. Le routage de code est préférable pour l'expérience utilisateur (temps de chargement, etc.). Le routage des serveurs est préférable pour le référencement, car les pages statiques sont le type de pages le plus indexable par recherche.
Avec l'approche de website.com/bob, vous devez vous assurer que l'utilisateur ne peut pas sélectionner un nom d'utilisateur qui soit le nom d'une sous-page (par exemple, empêcher un utilisateur de choisir le nom "home" s'il existe un site website.com/home etc.) Cela devient particulièrement important si vous souhaitez conserver la possibilité d’ajouter de nouvelles pages ultérieurement.
Comme DPS l'a souligné, Facebook utilise une méthode sympa n'incluant pas de préfixe en ajoutant le prénom et le nom avec un. dans l'intervalle qui évite toutes les collisions tant que vous choisissez les noms de vos pages sans points respectivement.