: User profile URL design I've noticed that some sites are moving away from root-directory user profiles. For example, YouTube channel URLs are now /channel/<id> and /c/<username> instead

@Ann8826881

When having the username at the beginning of the path, you would have to make sure to avoid name clashes with non-user pages (and, for sites that allow custom templates and forms, phishing potentials), and you lose some usability.

Examples:


Reserved filenames: A user could choose the username robots.txt, favicon.png, .well-known, etc.
Internal pages: Your contact/about/etc. page vs. a user named contact/about/etc.
Usability: users can’t no longer be sure what the URL will be about without visiting it:
www.facebook.com/loogin is a user profile www.facebook.com/login is not a user profile, but Facebook’s login page
twitter.com/StackOverflow/media is the "media" page of a user named "StackOverflow" twitter.com/hashtag/media is the "media" hashtag, not the "media" page of a user named "hashtag"
Phishing (if you allow custom templates and forms): when /login is your login page, a user named "signin" could bring people to login on their user page /signin.


When having a path prefix for usernames (e.g., /users/<username>), you don’t have these problems, and you get a nice (because browsable) URL for showing the user list: /users.

Additional benefits of such a path prefix:


It allows you to easily block the crawling of user profiles in robots.txt:

Disallow: /users


If you don’t have such a "namespace", you would have to list each username.
Users can use an external search engine to search all user profile pages, e.g. with site:example.com/users.

Vote Up Vote Down

@Welton855

For the most part, Google doesn't really care how you structure your URLs (as long as they're reasonably stable & crawlable; with the exception of country-targeting). Think about what you'd want out of your URL structure instead:


need to do country-targeting? Use subdomains or high-level folders, e.g., uk.domain.com/... , domain.com/uk/... (this is the main place where Google's guidelines come into play)
need to track or control access by type of content? Folders are useful for that, e.g., /users/... , /blog/... , /private/... , /shop/shoes/... (site:-queries give you some insight & many tools allow separating out directories, they're also easy to find in log files)
need to remove content by user quickly? Put their user-id in the path too, e.g., /users/user1234/content123 (the removal tools let you do directory removals)
need temporary identifiers, like referral-Ids? Put them in the query-string so they can be easily recognized & stripped, e.g., /bluesuedeshoes.htm?ref=123 (using the standard key=value format makes it easy for most tools to recognize).


At any rate, I would not blindly follow some big site's structure, in the hope that they must have planned everything in detail. All sites are different, and you'd be surprised at how often big sites manage to get things wrong :).

Using "detail" identifiers (user-name, channel-name, product-name, etc) at the root level makes recognizing (for serving, tracking, blocking, etc) specific types of content impossible, and can result in clashes between different types of content. For example, is /chicken the user "chicken", the channel "chicken", or the product category & what if multiple of these exist? No need to make running a site harder than it already is.

Vote Up Vote Down