URLs are for People, not Computers
not-implemented.com
not-implemented.com
Here is an Amazon URL:
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
Is it completely clean? Nope. It contains a lot of information that feed into the backend, but the core URL is this:
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
This URL will take you to the correct page, every time, and it doesn't take a genius to figure this out. It also doesn't take a genius to figure out what this page is about before you even paste the link into your browser. By putting the human-relevant portion of the URL as far forward as possible it's able to accomplish both priorities: giving the machine as much information as possible, and giving the human as much information as possible.
The trick here is that "Bioshock-Infinite-Premium-Edition-Xbox-360" is entirely superfluous. It is entirely there for SEO and human readability purposes. This URL works just fine and leads to the same place:
http://www.amazon.com/dp/B009PJ9L3Y/
Amazon isn't blind to these issues. So sure, you can take this very last URL and try to make a point about obfuscated URLs, but that's not what's actually in use at Amazon. It seems odd to pick them as an example when they're not even a violator.
[edit] It looks like HN truncates long URLs for display, which only goes further to prove the point.
However, this raises up an important consequence of clean URL design: when you're offering things that may be classified in several categories, it requires good design on the backed/framework to make sure your URL taxonomy isn't overly constricting. For example, example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?
Either one is legit but creating and keeping consistent taxonomy is difficult enough on its own without worrying simultaneously what the URL looks like
Why not both? The URL is just a URL - it does not need to reflect your underlying data model. There would probably be a canonical URL for use when the category context isn't available (say, "consoles"), but why not have multiple URLs lead to the same information?
> "despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs"
But they're really not ugly. In fact, given the complexity of the system they represent, they are remarkably human-friendly.
In an ideal world all ideas, all businesses, and all use cases can be fulfilled by simple URLs like "example.com/shockingly-unique-identifier", but we don't live in that world. Amazon has constructed human and machine-relevant URLs. The author's argument can be applied to many sites, but I don't think Amazon is one of them.
Absolutely! In the REST parlance, resources (which are what URIs point at) do not map 1-1 with entities (which is your internal representation of business objects). If they do, you're quite possibly exposing too many internal details and making your application brittle.
> More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...
This is actually one of the more readable parts of Fielding's dissertation, read the whole section. The examples are great.
The new routes make more sense, and are imho more friendly. The same for listings/view/###/STUB though I put the number/id before the stub, it looks a lot better than it did. Also, I put permanent redirects for any old references to the canonical url. It took a bit of work, now some more updates are going in to make the title/description/h1's more friendly. It's more maintainable now, and some very old URLs are still supported.
Currently working on some other modernization bits, which means a lot of the cruft can finally get cleaned out (if a section at a time, slowly).. having a friendly/consistent url stucture is important imho.
Note: it is a particularly ugly link
http://www.amazon.com/exec/obidos/ASIN/0517149257/o/qid=929505204/sr=2-1/002-9367729-7762218But OMG is amazons html fracking messy or what huge amounts of white space which increases the page size.
Scale challenges a lot of your preconceptions when you actually get there.
I wonder if this really matters with gzip. Or at least whether traffic overhead beats one from implementing and using HTML compression.
I bet they have it measured.
Sure, the URL
http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...
leads to the Bioshock article, but so does
http://www.amazon.com/flux-compensator/dp/B009PJ9L3Y/
or
http://www.amazon.com/hackers-and-painters/dp/B009PJ9L3Y/
In my opinion the only reason for the slug is SEO, everything else is a side effect which I personally find borderline dangerous.
BTW stackoverflow.com URLs work the same way.
It's fun what you can find out given those hostnames. It shows how a unified offering like Office 365 is actually just a few totally separate products, usually hosted in different data centers, that all happen to plug into the same user provisioning system.
We've recently had to configure ~200 users and Microsoft had us login to each user's account to find out on what server they were on.
"Cool URIs don't change"
URLs are fundamentally for web browsers to translate into a domain name lookup, and a HTTP request. They are for computers - the fact that we've managed to convince humans that they should care about them, that they should be decipherable by humans, is, IMHO a failing of the web as is.
On a side note, I note that films are starting to use Facebook URLs by doing [FB Logo]/trancethemovie which the user is intended to translate into https://www.facebook.com/trancethemovie
If URL's are actually intended for computers, than I'd say we've failed rather badly.
The whole point was to interface with people.
If people don't matter and it's for machines, why use URLs? Just type IP's. Skip DNS all together...
That'd be the base URI, but not the full one. If you used IPs, it would still be http://123.456.789.123/search&q=foo
How exactly would you get at a particular resource at that IP? That's what we're all talking about.
But you are not Amazon. Your listings may be competing against Amazon's listings, without the brand recognition, trust and backlinks they have built up.
So you have to do everything better, like building friendly urls, just to have a chance of getting clicks that Amazon can take for granted.
(Amazon does a pretty good job at urls, as others have pointed out, but most larger, established companies are still pretty poor at this, leaving the door open for upstarts to do it better).
URL's are for both, and so you see hints of both concerns represented. Once your routing passes a certain level of complexity, there is no way to make both functional and human-friendly URL's.
The only thing that users should really be concerned with WRT to URL's is the DNS portion; pretty URL's are just that -- pretty -- and a rose by any other name... Ultimately the user should either have trust in your FQDN or not, at which point the actual URL is inconsequential.
EDIT: additionally, a URL is not a UI element, and the user should never even need to see or know about any particular URL (much less its scheme), only that interacting with an anchor tag named "profile" takes them to the profile page, for example. It's up to developers to translate URL's to human-friendly counterparts.
>We found that searchers are particularly interested in the URL when they are assessing the credibility of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user’s question, they are more likely to click.
I wished someone at MS would follow up on that and fix the whole bay0X.cdn url jumping everytime I connect to outlook/hotmail.com
This is also why your parents and grandparents can just type random text into an address bar to execute a search instead of having to go to google.com or type in something cryptic like google.com?q=thing%20i%20want.
Much like with database design, it's easy for programmers to take over the task of URL design and make it easy to use from the write-first, read-never programmer perspective. User considerations come later if at all. I like the reminder to pay attention to these factors. We should all be reminded to question our first impulses; are we making something good for us or good for the user?
URLs are for computers, not people.
To me, a URL is an address to a web site, not the title (or description).
If I want to find somebody's address on a map, I don't go to "Bobby's House". I go to "123 Main Street, New York City, NY". If I search for Bobby's house, I'm not given "Bobby's House" on a map, I'm given a surrogate street address.
If humans are expecting the URL to look pretty and descriptive, then the issue here is that we've conditioned this expectation and we should instead condition users to expect succinct, surrogate URLs that only serve the purpose of identifying the article you're trying to reach.
Additionally, I think the fact that search engines highly weight their optimization on a URL is terrible and counter-intuitive to the purpose of a URL. This is what <title></title> is for, and other <meta></meta> headers.
The URL should not determine a page's rank in search results, at all. At the very most, it may make sense to factor the root domain into SEO, but that's where it should end. This isn't the 1990's when much of the web was static HTML pages that could be given whatever meaningful file names. In today's world where the web is dynamic and mostly made up of user-driven content, URLs are designed to route the user based on one or many identifiers, which are often surrogate identifiers, and not natural or meaningful identifiers.
Edit: I do agree with the point about useless garbage in the URL (like the Google search examples) that are there only in the interests of the site and tracking/analytics. I think URLs should only serve to get the user where they need to go, and contain exactly enough data to get them there.
You left out zip+4 code, GEO coordinates, user spoken language, travel-type preference setting, internal id, and unique user id tracker.
The issue is that URLs are often the only piece of information users receive, and it's why we've conditioned users to expect meaningful URLs.
From our standpoint, it's not too hard to make URLs more meaningful, even with user-generated content. Plenty of sites incorporate the title of submitted content into the URLs, and it's even easier when creating content for oneself.
Would you prefer a link to http://www.example/about or a link to http://www.example.com/?id=123. Which are you able to understand before clicking it? Which are you more likely to click?
Users don't provide URLs unless they type them in the address bar. And if they're doing that, it's likely just the domain name, and very rarely anything more than that.
If they're clicking a URL, then what the URL looks like is meaningless, and often does not even need to be shown to the user. Again, the only reason they care about what a URL looks like is because we've conditioned them to care. It bares no meaning on them being able to access a page.
> The issue is that URLs are often the only piece of information users receive
Why is this? Why do they ever even see the URL?
If it's visible to the user on a page, then replace the URL in the <a></a> tags with a meaningful description of a URL. Showing a user a URL is bad UX (unless you're audience are power users, but that's not what this article is talking about).
> From our standpoint, it's not too hard to make URLs more meaningful, even with user-generated content.
I would argue this is not true. Take Amazon for example. Converting "Panasonic-KX-TG7743S-Bluetooth-Cordless-Answering" to a product in the database is a nightmare I don't want to deal with. Computers work better with surrogate identifiers that are short, and they're easier to generate.
But then add user-generated content. Who is responsible for generating the meaningful unique identifier for the content? "Sorry, that content ID is taken. Try another one." :)
> Would you prefer a link to http://www.example/about or a link to http://www.example.com/?id=123.
An "about" page is a complete different situation, and these static pages are often limited in number on dynamic sites like this article is referring to. Of course they can, and should, have a meaning (there's no reason to give it a surrogate identifier).
But if a computer is responsible for creating the content, and the address to access that content, then why go through the trouble of giving the URL a meaning?
> Which are you able to understand before clicking it? Which are you more likely to click?
Why do I care what the link is? When I see it on a page, I should see "About", not "http://www.example.com/?id=123.
> My thoughts on what I believe is a bad article on HN: “URLs are for people, not computers”. https://news.ycombinator.com/item?id=5499730 http://www.not-implemented.com/urls-are-for-people-not-compu...
URLs are a way of life. Of course the ideal solution is a semantic hyperlink, but people don't share hyperlinks, they share URLs, and they don't always take the time to type out a nice description like the above tweet contains.
> I would argue this is not true. Take Amazon for example. Converting "Panasonic-KX-TG7743S-Bluetooth-Cordless-Answering" to a product in the database is a nightmare I don't want to deal with. Computers work better with surrogate identifiers that are short, and they're easier to generate.
I don't think computers care one way or the other, and it's not hard to generate a key like that at all. In your example, you'd simply have brand + model + short description. In most other cases, you'd simply take the title of content that was submitted. It's a very common solution to this problem [1]. The idea is that a short description is part of the item in the database. It's not some sort of complicated lookup that acts like a keyword search.
[1] https://docs.djangoproject.com/en/dev/ref/models/fields/#slu...
> Why is this? Why do they ever even see the URL?
Because the url often transmits more information than what's in the page title. For better or for worse.
Because the web is about inter-site linking. You can't link if you can't see the full url to a page. You seem to think that only automated software or "power users" would ever want to create links.
> Why do I care what the link is?
You've never wanted to link to anyone else's pages? It's not just power users who do this. Casual internet users share full url links all the time. Requiring more than one click to get at the full URL is burdensome and would change linking on the web.
The web is not the only place urls are used, and http, https, spdy are not the only url protocols in existence. In some cases urls are the only information you have about a resource, and it takes quite a while to get additional information. BTIH, for instance, can take a while to get the torrent depending on the initial connection status to the p2p cloud. In other cases, there may never be any additional information about a resource besides the content of the url. You can't hide urls like those. The URL bar needs to stay. It doesn't have to show full url paths all the time, but it needs to be ready to in a click.
Search engines already understand this, but they go as far wrong in the other direction with SEO signals based on url paths, which encourages pathological descriptive url paths rather than encouraging url paths that are merely adequately identifying.
Urls are important to humans for the same reason we save documents with meaningful names instead of random gibberish.
Urls are the way people use sites, and that's just the way it is.
Most tools and frameworks are designed from the ground up to be document-focused. Some even going as far as to purposely simulate a document when none exists (e.g. Tomcat).
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers.
It is VERY hard to develop applications in them without a document focus because they use documents to direct functionality (e.g. logout.php and login.php might have different underlying functionality).
Now, yes, web-servers do support request redirection, so you can redirect from /logout to /logout.php, but such "magic" is time consuming because there is a disconnect between the underlying framework which "understands" pages and the dumb web-server which just does what it is told to do.
Even if you just automate it so you strip out the extension (e.g. strip ".php") you still wind up /thinking/ about things from a document perspective rather than a functionality perspective (e.g. "this functionality is on THIS page, this functionality is on THAT page").
We just need more modern frameworks where from the ground up the thing is based on a hierarchy rather than documents/files/etc. This should all be dictated by the framework, not the server's filesystem.
I do still think the biggest hurdle PHP faces, at least when new devs come to it, is the lack of any one clear "best" framework. As you even mentioned, there are "main frameworks", but none of them is the clear "best" choice when you are approaching the language. In fact many people start building with PHP without a framework. Almost no one would start using Ruby to build a web app without choosing Rails. Similarly, no one would choose straight Python over using Django (waiting to get flamed by the Flask community here ;) ). With PHP, a lot of people choose it to build a "simple" web app, and end up just hacking together a few .php files. That was even more true 5+ years ago, and now there are a lot of legacy applications out there, that have grown quite large, still built on that principle.
Let's take PHP, ASP.net, and Java. They make up the majority of the internet right now. With RoR and MS MVC being outliers
This sounds very much like you're calling RoR and MS MVC outliers with regard to the fraction of the internet they occupy. You're expecting me to know that your use of "outliers" was with respect to a quality not even mentioned in that particular paragraph, rather than with respect to the sentence right before it? Not to mention the fact that With RoR and MS MVC being outliers. is a sentence fragment, so the most obvious correction to your grammar would be to put it together with the preceding sentence.
So, yes, you don't write very clearly, so I misunderstood you.
It's not winning any writing awards, but it's not at all unintelligible. The organization of a piece of writing doesn't stop at the paragraph level, so to assume that the paragraphs are unrelated is pretty odd.
Please allow me to vent/rant -- I'm finishing up a project where your comment resonates loudly with my frustrations.
I'm a journeyman freelance programmer trying to move from doing WPress marketing sites more interesting programming/development problems, and I just got out of a 2 month Magento project (Magento is an MVC-patterned store software that is based on the Zend PHP framework): extending it to allow users to sign in and create their own product listings.
This was my first time building MVC/OOP modules in the context of a framework, and it took a little bit to connect the OOP principles that I've studied to the actual implementation within the larger framework... but the last month has been like "WOW... I can finally see in a pragmatic way why OOP and MVC are both such a powerful tools!"
Not to mention that, since we were working with extending the system, studying that stuff seemed like an essential learning process if we were going to create the system, even if I was only tasked with the "front-end" side of templates and visualizing the things from the database.
However, the senior guy in charge of creating the functionality to manage products for users thought I was from mars-- his application, which was wholly separate from the Magento install and used a separate database, was patterned around directories, with a set of configuration and include files shoved into the head.
He intend me to integrate his functions by shoving his (single, large) functions file into the head of (each of) my template files, and then calling functions to return arrays of information that I could then push into markup.
Apparently, this is "the right and normal" way to do this stuff in the PHP world, and my process of writing modules, extending existing objects, creating routes to view the data through the framework's template system was all stupidly overcomplex.
I learned a lot out of doing that, and the module that I'm building for another client (aMember/Zend) is both smooth and fun because all of the database interactions and template stuff is already in place and just works... and I can focus on the UI Javacript stuff...
but I feel really badly for the project owner of the Magento project, as I feel the codebase is... well mostly a bunch of functions in a single file and a bunch of single-form .php files that make SOAP calls and depreciated mysqli_ calls...
Now, I dunno-- I'm definitely the less experienced programmer, but if this is the norm in PHP programming (surely it can't be), I will be spending my summer trying to build enough projects in other languages that I can transition out of doing PHP.
Sorry for the rant, but it was cathartic for me :D
You don't need to try other languages, do it only if you want to. If you wanna save time just take my word, Symfony2 has nothing to envy to Django or Rails (I have used them and also digged into their architecture). In fact, it's more modern and better designed.
I'll leave these links here, you might find them useful:
- http://www.phptherightway.com/ (general advice)
- http://getcomposer.org/ (composer, the dependency manager)
- https://packagist.org/ (the main composer repository)
- https://github.com/php-fig/fig-standards/tree/master/accepte... (accepted conventions)
- http://www.slideshare.net/fabpot/dependency-injection-with-p... (if you liked MVC, DI will blow your mind)
- http://fabien.potencier.org/article/50/create-your-own-frame... (an amazing tutorial on how to create a framework, it will let you understand it inside out)
- http://symfony.com/download (what should become your next framework)
- http://silex.sensiolabs.org/ (minimalistic version of Symfony2, it's called Silex, and might be useful for small websites)
If you still want to try something else, try something that has nothing to do with all this, like Clojure. For example, Ruby/Rails is the same as PHP/Symfony2, you won't learn much. I jumped into Rails and just started coding, because I already knew web development, I wasn't impressed, the differences were mostly syntactic sugar, monolithic vs decoupled, and issues like the lack of interfaces and type hinting. But Clojure? Mind blown. I'm gonna spend my next summer learning more Clojure, because I already know it's my perfect language, but it's hard and full of new concepts. Meanwhile, php/Symfony2/nginx is my perfect stack for web development.
I agree that the answer is being more selective about who I work with-- logically, I can probably write terrible code in about any language. For this last contract, it was more a case of having a one of my main clients that I do other projects with hiring a firm.
I didn't apply for it so much as "oh, the project is Magento? I'd really like to work with that", and the getting on as part of the program because I was pretty familiar with the overall project goals and I'm good with javascript/css/html and was hoping to gain a little experience in how Magento templates operate... but I did learn a lot, and I have lot better idea about what kinds of approaches that I am willing to work with.
Symphony2 looks like an entirely reasonable choice for a framework. I spent some time this year working on adding functionality to a cakePHP project, but that felt a little lightweight compared to other things I've been working with... though that is just a general feeling.
I had been trying to get Zend2 and Doctrine working, but I had to run it in a VM-- it wasn't playing well with my normal OSX environment... I eventually had it running and was building a really basic project with it when I got busy last fall.
So, anyhow-- symphony2 is now on my list of "build a really basic project in this framework": thanks :D.
EDIT: Ok the follow up comment doesn't indicate that... but it would be just as valid to do it that way if they are indeed search modifiers.
For Google though I'm not sure you'd want POST requests at all; unless it's to set cookies and do a redirect on POST.
If they are the defaults, why put them in the URL?
You've probably answered your own question there.
Eg: http://www.bing.com/search?q=test&qs=n&form=QBLH&...
Here, sk is "".
You can strip out empty fields with a bit of PHP (creating a new URL without the empty strings), which seems to work okay, but it's probably best not to risk the wrong effect, which is the end program seeing the empty fields wrongly (as NULL and not "").
Even more offensive are the result URLs on the result page. Here's the URL for a logged out search for "hacker news". https://www.google.com/url?sa=t&rct=j&q=&esrc=s&...
sa=t&
rct=j&
q=&
esrc=s&
source=web&
cd=1&
cad=rja&
ved=0CDMQFjAA&
url=https%3A%2F%2Fnews.ycombinator.com%2F&
ei=k99eUcfzOsePiAKjgIG4DA&
usg=AFQjCNGxnV8qCnv_rujodDj6o2ZhqU8Nxg&
bvm=bv.44770516,d.cGE
Note that none of this is necessary for clickthrough tracking; it's easy to do that separately from the href.
Why put extra work into making your RESTful URL structure more semantic, in other words, if Twitter if just going to shorten them to the point that they are no longer fully readable, or Facebook is just going to hide them behind a preview view?
Chair example:
furniture/chairs/desk/chair
inventory/current/reorder/chair
customer/me/bought/chair
customer/me/wishlist/wedding/chair
products/used/modern/office/chair
products/wood/four legs/padded/black/chair
ad nauseum.
Why then do most Microsoft sites not follow this finding? Also, a lot of their products break it as well (I'm looking at you SharePoint and CRM).
Also »Microsoft« isn't one big monolithic entity and it's not uncommon for individual parts of it doing things in quite different ways.
Or for commonly accessed sites I just type a few letters on my browser address bar. reddit.com is actually re+enter. news.ycombinator.com is actually ne+enter to me. After I reach the main site I usually click around or use the site's search bar.
So, I would say that good URL names are a secondary optimisation.
I would prefer to focus on this priority: 1) A good unique domain name; 2) Good SEO; 3) Good site information architecture; 4) Good internal site search.
Case in point: it took a while to those same companies to switch from table layout to CSS based layout [1][2].
[1] http://webmasters.stackexchange.com/questions/20408/if-css-i... [2] https://forums.digitalpoint.com/threads/why-does-google-use-...
Hierarchical URLs betray the underlying model of the internet as a series of interrelated documents. People don't care about understanding the layout of files on a web server; they just want to open Facebook, or their email, or perform a search. Nobody types "http://www.facebook.com into their browser. They either click a bookmark or type "facebook" into the search or URL bar. What happens next is up to the browser.
The best solution would conform to the already existing mental model that people have. They don't think of a website as a bunch of documents on a web server (despite the shared vocabulary with printed media - words like "page" and "bookmark"). Their mental model is probably something like buildings on a city block. You can pick one to go into, and when you're inside you can do things and learn things that are unique to that building. Rooms are connected by hallways and doors. There are windows where you can see outside or into other buildings. You can bring things with you into the building and take things out when you leave. To get back to a room in a building that you've been in previously, you can either go back to the front door and follow the path you took originally to get to the room, or you can "bookmark the page", which is like a shortcut directly that room.
Like somebody else said, I blame the tools, the requirements (but we gotta track the referring url of the referring url!!!), and the programmers.
localnewspaper.example.com/1934342342/mayor-dropping-race-after-scandal -> Mayor Not Dropping Out Of Race After Scandal
The article linked to [1] was also pretty interesting. The line that caught my eye was "The URL will continue to be part of the Web user interface for several more years...". Keep in mind that was published in 1999, therefore Nielsen seems to be implying that he believed the URL will eventually become less relevant as a part of the UI. I don't see this happening anytime soon on the "web", but it's certainly true on "mobile".
Modern Web Application frameworks such as WordPress, Ruby on Rails and many more are forcing good practices on the web moving forward. Most startups today are following all the practices detailed in this article as a result of the frameworks imposed on them.
- Short over long. Consider removing useless words from the url like news.ycombinator.com/tips-for-designing-good-urls
- Concise. To the point, describe the page content from the url
- Use lowercase. Generally the best idea, for sharing links and technical issues (Apache is case-sensitive sometimes)
- Consistent. Stay consistent, make a style guide for URL's if necessary
- Conscious of trailing slashes. Stick with trailing slashes or no trailing slashes. Redirect to preferred form.
- Logical. Follow a logical structure, that follows the structure of the site. A good URL might read like a breadcrumb: site.com/category/product-name, this works for silo'ing your content. Other sites (such as news sites or without a category) might benefit more from the shortest url possible.
- Using dashes for spaces. No underscores, + or %20 spaces.
- Not using special chars. Consider replacing é with e and removing any non-alphabet non-number character like: ' " (
- Canonical. There should be only 1 unique URL in a search engines index with a page content. Use canonical or 301's or smart use of URL's to make sure this is the case.
- Degradable. What happens if a user visits example.com/category/product-name/ and then removes the /product-name/ part? The URL-structure should allow for this and example.com/category/ should return content (preferably the category description)
- Timeless. If you have an event and you set the date inside the URL, then after this date has passed, this URL gets less valuable. Either 301 these aged URL's to the current event URL, or make it so your URL's can be "re-used" for future events. Cool URLs don't change.
- Optimized for search. Use a keyword tool, to find out what users might be searching for and use the relevant keywords inside your URL. Keyword in URL is a (minute) ranking factor. Bolded keywords in URLs help discoverability.
- Not using excessive dynamic variables. These will confuse your users and search engines.
- Flat over deep. Hiding content away in many subdirectories can hamper readability and search engine crawling. Avoid example.com/cat/subcat/subsubcat/widgets/green/second-hand/widget-deluxe/reviews
- Extension agnostic. An URL ending in .php, .py, .xml, .htm etc. can be changed to another extension in the future, requiring an update or inconsistency in the URLs.
- Not spammy. Good URL's don't repeat (slight variations of) keywords or (ab)use extensions like .font or .shoe
- Not disclosing technology. There is little reason to add cgi-bin to your URLs (unless you want to confuse your competition). An extension to really avoid is the .exe extension (mapserv.exe?doc=15)
- Non-traversable. When using document IDs all URL's can easily be scanned/traversed in a loop or manually. Including URL's not yet ready/or never meant for publication.
- Secure. Not susceptible to injection, XSS etc.
I'd say URLs are both for humans and machines.
Where does the user go to find the 2008 event, if his post from 2008 has a URL that now points to the 2013 event?
A link to https://us.pycon.org from a post dating back to 2008 now redirects to https://us.pycon.org/2013. But that is on a domain basis. Hypothetical: python.org/pycon could always show the most current event, with a link to an archive, if you'd want to read the announcement page of the 2008 event, for whatever reason.
If you use python.org/pycon-2012/ and it gets 1000s of links, then you lose all that if you create a new URL python.org/pycon-2013/.
This does depend on the event of course and how bad it is reduced in relevance after its date has passed.
Compare: /search-engine-ranking-factors-2010 /search-engine-ranking-factors-2011 /search-engine-ranking-factors-2012
or a catchall:
/search-engine-ranking-factors
Showing the most current one. An URL like above will collect links from all the years, instead of spreading it out over multiple years.
P.S.: If you register pycon2013.org then domain squatters might register pycon2014.org pycon2015.org etc.
I disagree with this. Maybe this works in English where some spell naïve with two dots to appear fancy, but in some languages letters with diacritical marks are completely different.
Now, with IDNs, people should be moving towards more internationalization, not less. Sorry for the bitterness, but the English alphabet is like IE6.
Why? It's prettier (imho), guaranteed to work everywhere and most people don't expect é, ü, å or ł to appear in urls.
I got my start with internet business by "SEO." What did I do? I made sure all of my URLs were very simple and shallow. Google liked this and I got a lot of users for free when my competitors had better sites.
Conscious of trailing slashes... Redirect to preferred form.
The interleaved explanation, however, is problematic:
Stick with trailing slashes or no trailing slashes.
A trailing slash indicates a resource that is in some sense a container. (Historically one would have called this a directory.) The browser knows that '.' refers to the current resource with a trailing slash, while it refers to the parent resource path when the current resource doesn't have a trailing slash. You want to leave off the slash when you know a particular resource is a leaf node.
I actually wouldn't have a problem with advice to "stick with trailing slashes", but I don't think "no trailing slash" would be a sustainable policy. It would be too difficult to keep URLs straight between the server and the browser side.
GitHub: https://github.com/danielnr/prettify-url
UserScripts: http://userscripts.org/scripts/show/164318
Note that this is absolutely not meant to be an end-all solution to the problem, but instead a ray of sun in a thunderstorm of ugly URLs. The core responsibility still lies on the developer, this just tries to make things a bit more bearable.
I also list a number of positive and negative examples from the wild.
this is fantastic for SEO: Main-Category/Sub-Category/Specific-Item - is practically screaming look at my site heirarchy and look how much data I have about furniture -> chairs -> chair manufacture -> chair model
* That pesky analytics stuff (rel= on YouTube for instance) which you don't want to re-send on refresh or when someone passes on the URL to someone else (because now your data is inaccurate)
* Error messages specified by URL parameters (we only want to show them once)
* URL parameters containing secrets allowing someone to access a page (we don't want to accidentally pass them on)
etc.
This is the worst offender, in my opinion. It makes any link really ugly to share.
I'm not so sure of this. URLs that are over-optimised seem link-baity to me and I'm more inclined to not click it.
At some point, searching for terms like "best hdtv 2013" would return a page full of sites with perfect urls like http://www.best-hdtv-2013.com/, and all of them would be extremely spammy and lacking in actual content. Seems less prevalent these days.
"http://example.org/furniture/desk-chairs/herman-millers-mirr... makes me think crappy search landing page website that is probably malware infested I don't want to click, ever
However, I believe that is mostly due to the domain. If it was amazon.com I'd click it likewise if it was http://www.example.com/gp/product/B0002K11BK/ref=sr_1_5?ie=U... I would also think I'm going to get spammed :)
I think it should be done, but I think it would have to be header data explaining the "layout" of the URL, not a standard URL scheme.
If a URL becomes a popular for human usage, it is a safe bet to keep it as it is, that doesn't mean you cannot have all sorts of gobbledygook URLs which also get you to that same resource.
There is no need to have this be an either-or proposition.
I like a clean semantic URL, but if I'm being honest with myself, I know that is just my opinion. I don't know of any real-life correlation between URLs and business outcomes.
The argument is being made that clean URLs are important to success of websites. That the most successful sites on the internet are sites that don't use clean URLs is counterevidence to the claim made. That's not an appeal to authority
The goal in designing a good URL is in a scheme that allows the site to grow without "abandoning" URLs.
And yes, for hacker types this intention of Google's seems overbearing...but for the other 99.9% of the population, google is likely more interested in making search uniformly accessible than making clean URLs
But I remember the days when you could craft a Google search url by hand and tweak the results. It was part of an advanced user's toolkit. All of that has been taken away. Searching is now opaque.
1. Search has always been opaque. We've never known the complete details of PageRank, and we know even less about the hundreds of other flags and signals used by Google search to parse a query as vague as the famous "mike siwek lawyer mi" into something useful.
2. It is largely a good thing that we don't need to hack the search parameters anymore...because, in one sense, it means that search has gotten amazingly accurate. It's so good that I hardly ever go to the second page of results...instead, if I don't find what I want in the first 10, I just slightly alter my text query and Google will eventually get what I need (or at least what I think I need, but that's a philosophical question). I think that is a better UX experience for even hackers, as you can refine using natural language rather than tinkering with vague params.
For example:
https://www.google.com/search?q=pillow&start=100
But you may have tweaks in mind that no longer work, and so forth.
https://asherwolf.net/the-tragedy-of-jailing-weev-the-intern...
(waits for further downvotes)