Should users be directed to a 404 page or a landing page?

Question

We have two pages. One is a landing page, given by the route /region. The other is a detail page for a particular region, given by the route /region/summary/{id}. The landing page is the normal way by which a user would navigate to a detail page.

Suppose a user visits the intermediate route region/summary. Should he be redirected to a 404 page, since technically it's not a valid route, or redirected to the region page, since the main problem is that he didn't provide an id in the route, and he'd find valid links everywhere on the landing page?

Answer 1

This was originally a comment, because I had assumed it was considered and not used prior to this question being posted..

At the moment, these are your URLs (with "summary" being a type of action, presumably):

/region
/region/{action}/{id}

Your question is, what should you do if someone tries to access it without an ID, like this:

/region/{action}

I say: Don't allow it in the first place, and shape your URLs conceptually like this:

/region
/region/{action}
/{region}
/{region}/{action}

So with this mapping: {region} -> region/{id}, you get the URLs:

/region
/region/{action}
/region/{id}
/region/{id}/{action}

• /region would still go to the same place you intend; a landing page.
• /region/{id}/summary does the same thing as your /region/summary/{id}
• /region/{id} basically would mean "Get me information about Region {ID}", which could either 302 to /region/{id}/summary, or just return that page.
• Likewise for /region/summary - the user is asking for information about the landing page. It should return the same thing as /region (or 302 to it, or /region should 302 to here).

RESTful URLs like this are used in web APIs, and they're pretty intuitive, making it a good model for sites that can use them.

Two more sets of examples from the StackExchange API (which, granted, doesn't include /tags/{tags}):

/badges                   Get all badges on the site, in alphabetical order.
/badges/{ids}             Get the badges identified by ids.
/badges/recipients        Get badges recently awarded on the site.
/badges/{ids}/recipients  Get the recent recipients of the given badges. 

/tags                   Get the tags on the site.
/tags/{tags}/info       Get tags on the site by their names.
/tags/synonyms          Get all the tag synonyms on the site.
/tags/{tags}/synonyms   Get the synonyms for a specific set of tags.

And one from this Edit Answer page (which, unfortunately, doesn't work without /edit...):

http://ux.stackexchange.com/posts/39273/edit

Answer 2

I think it's ok to make guesses about where your users were trying to go, but always provide the correct HTTP response code to indicate that the item was not found or was "Permanently Moved" and consider showing a simple message on the page in case the user really was trying to go somewhere they thought was legitimate and are confused why you redirected them.

Answer 3

I would argue that if you have the ability to fall back to a page that may be useful, you should do that rather than give a 404 error.

In your example, falling back to /region when someone enters /region/summary gives the user the opportunity to select what they may have been looking for. This interrupts their flow much less than it would have if you have given them a 404 error page, and presents them with a better UX.

When you are working with people, you should consider the intent of the user and be as flexible as you can. With machines, it's more about being precise, and that is where you should give an error instead of falling back to the closest information that you have.

---

On the other hand if they gave a wrong {id}, you should revert to a 404 error page with the most useful information that you can offer.

Answer 4

404 Errors can be really helpful.

Everyone wants their sites to be intuitive and every user strives to do less work. With that being said the 404 errors in your statistics and logs can help you to determine where the shortcomings of your user interface reside. If the user interface is so bad from a user experience standpoint that the users are trying to "skip" using the interface, then there is a need for revision. Google and search engines should not typically reach a 404 error on your site, since they only follow hard links. In the backend of Google's webmaster tools they do provide feedback as to whether or not they found a bad or dead link on your website and you can search Google to determine where it came from.

If you blindly give someone a 301 [permanent] redirect that presents them with the wrong information, there is the risk that you will drive site visitors away. If you redirect all traffic to the landing page in the event they tried to access a page that did not exist they have no way of knowing if it was their own mistake, if the page no longer exists, or worse if the site is broken.

I have found it useful to parse the request to show likely links that the visitor was intending. The these are presented in a list as a 300 redirect indicating some other action is necessary since multiple actions could potentially be taken. If there are no records even remotely on topic for the request then I provide a 404 error because I do not want the search engines or visitors to relate my site with the failed query, keywords, or context. This can help to keep traffic on the site as well as inform search engines that there are related items in your site.