I'm building a site that has items, with each item having a page, for example:
website.com/book/123
website.com/film/456
website.com/game/789
Each item can have multiple sub (and sub-sub, sub-sub-sub) pages, for example a book could have a blurb, a film could have a gallery and a game could also have a gallery.
My question is, does any sort of standard or best practice exist around structuring the URLs for pages associated with an item? For example:
website.com/film/456/gallery
Where the sub page comes after the item, or:
website.com/film/gallery/456/
where the item is the very last part of the URL.
Does anyone have any information on why which approach is best or if any web standard exists? It seems an obvious thing but I'm struggling to decide, I can think of pros and cons for each approach -- although I'm leaning towards the former option because it means the following user path would match the URL:
load website.com -> click "films" (website.com/films)-> click "a film" (website.com/film/123) -> click gallery (website.com/film/123/gallery)
but something about it seems... off, inconsistent maybe.
You are correct that the former URL is "better" and is more widely deployed. I don't think you would find this documented in any standard; it is rather more of a convention. Most articles and books covering REST do it that way.
The reason for this is, as you say, that the path components in the URL match the structure of resources and sub-resources. In particular, all of the following should be valid URLs:
website.com/
website.com/books
website.com/books/123
In particular, note that it is books/123, not book/123 like you have. I have seen the singular but IMHO the plural is better.
For the URL /books
a GET gets all books, but you can restrict the books with query parameters, e.g. /books?author=alice
a POST adds a new book (with a server-generated id).
For the URL /books/123
a GET gets that particular book
a PUT replaces the book with that id (or adds a book with that client-generated id)
Now if a book has blurbs and the blurbs are unique only to a particular book then you will add the following URLs:
website.com/books/123/blurbs
website.com/books/123/blurbs/72
You can do the same for films and galleries, provided each gallery belonged to a single film. But if galleries existed for multiple films, then you would make /galleries a top-level URL. Navigating from a film to a gallery would still be fine. You wouldn't have a structured URL. You would instead get all galleries containing pictures from film 456 via a GET to
website.com/galleries?film=456
The general rule is that if you have an ownership relation for the subresources you can use structured urls, but if there is a looser relationship among top-level items, query parameters are fine. Don't fall into the common misconception that RESTful URLs don't have query parameters; they do. :)
Now finally, to directly answer your question: website.com/films/galleries/456 is not a good URL IMHO because `website.com/films/galleries/ is not very useful. In fact I think it is rather ugly. What would it mean? All galleries? If so, it should be website.com/galleries.
Again I don't think this is standardized anywhere, but it feels very common and conventional.
Related
I'm running a simple site based on Joomla. The SEF URLs are defined by SH404SEF and look like https://[domain]/[category]/[sub category]/[article title alias].html. In some cases there is a 1-to-1 relationship between category and article but in some cases one category has several articles.
Suddenly I have URLs requested following https://[domain]/table/[category]/[sub category]/. Not only does these new URLs in some cases create 404s, they also view my articles in the wrong way and when there is not a 1-to-1 relationship between category and article the link adds several articles on one page.
The correct non-SEF URL ends with &view=article and the new, uncorrect non-SEF URL ends with &view=category. I have no table/ in my correct URLs, neither in any internal link, in the articles' html code, in menu items nor in my sitemap.xml. I've discussed this with the few extension providers I am using and none of them see their extension as doing this request new.
Is there any way to find out what is making these requests?
I cannot make a redirect for these URLs since all of them do not
correspond to one article, but several. Can you see any risk with
making a rewrite rule that puts a 410 on all URLs that starts with
table/?
This is actually a misconfiugration in sh404SEF. Here's what to do:
Login to the backend of your Joomla site
Go to the sh404SEF configuration
Set the field "Insert Content Table Name" to "No"
Flush all URLs and clear your Joomla cache
This should do it.
I want to ask how to SEO-wise properly structure URLs for e-commerce store (eshop) with multiple categories being nested in different ways.
Let's use example of cars. Customer can filter products using several features, by brand, car and fuel. And I want to use selected filter options in URL like this:
www.foo.com/mercedes
www.foo.com/blue-cars
www.foo.com/diesel-cars/blue-cars/mercedes
But I also want to maintain the navigation path user used to get to his filtered products. So the problem is, that I will have different URLs having exactly same content, e.g.:
www.foo.com/diesel-cars/blue-cars/mercedes
www.foo.com/mercedes/diesel-cars/blue-cars
www.foo.com/blue-cars/mercedes/diesel-cars
And so I will have duplicate content as well. I could/should do a rel="canonical" in those pages to one MAIN url, however, it stil will be a little mess. Any suggestion or best practice how to deal with this problem ?
If you have the same item (car) on multiple categories very often, you definitely risk a duplicate content issue.
Solutions:
Have a main category only, ex: http://example.com/cars and add a query string for filtering ex: http://example.com/cars?color=blue
Stackoverflow use a similar approach look here:
Use canonical link to improve link and ranking signals for content available through multiple URL. More info from Google here:
https://support.google.com/webmasters/answer/139066?hl=en
Say I have a list of orders I want to display. I want to give the user the ability to show all orders, all orders from a certain state, and all orders from a certain category. Each of these can be filtered by a date range.
Without worrying about routing, I might just add each on the query string:
/orders?State=TX&Category=Books&DateRange=Yesterday
While I could easily make this work, it doesn't "feel" like this is the correct MVC-way of doing things.
I could have routes that look something like this:
/orders/
/orders/state/{state}
/orders/category/{category}
/orders/state/{state}/category/{category}/
/orders/state/{state}/category/{category}/Date/{date-range}
But I'd still want to support each of those filters not being there. Is there a better way of handling this or am I just over thinking the whole thing?
If I go the URL only path, it isn't clear how I would create these routes without just repeating them for all the combinations I would want (state, no category, date, state, no category, no date, no state, category, date, etc.)
I think the query parameter version is fine for MVC. What's probably confusing you is that, when you want to give the user a page for a specific order, you do put the order_id in the page. So where in a traditional website, you'd just make that URL
/order.html?order_id=1234
(or whatever), with MVC you want to use
/orders/1234
instead. The difference is, you only want to put mandatory parameters --- those that the page would break without --- in the URL; not every parameter. You can't return an order page without an order id, so that goes in the URL.
You can have both on a page; for a silly example, if you had a shipping tracking page for an order, you could have a URL like
/orders/1234/tracking?since=9%3a00
to only show tracking events (arrived at, departed at) since 9:00am.
It's actually a common practice to leave search/filter options in query parameters, look on google for instance.
From my point of view, unless you care about seo on filter results or want to have human friendly urls for this page, the is no point in supporting routes for any possible filter.
I'm working on a new advert website and want to implement some good SEO URLs.
I got category URLs like:
/category
/category/sub-category
This seems ok. What about detail pages?
Option 1:
/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Option 2:
/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
In reality my website has a pretty long URLs due to multiple areas you can shop. So it would become:
/en/area-name/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
/en/area-name/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Which detail page would be a better URL? The first option seems to be better if the product has no long/good title. The second seems better as its the most relevant one and shortest especially with long category names.
I would like to hear your thoughts!
EDIT:
I found this two google docs:
http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDYQFjAA&url=http%3A%2F%2Fwww.google.com%2Fwebmasters%2Fdocs%2Fsearch-engine-optimization-starter-guide.pdf&ei=lXyaT6T_L8zR4QSM4c2qDw&usg=AFQjCNEMj8KHxhxQz9cMLoMxMDiLdrAbJw
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329
I think I will be going for /adverts. Anyone disagree?
i have seen many of SEO analysts miss something about optimizing their webpage and that is your page will be optimized for only some keywords not all keywords. it is not important how length is your URL. you should first analyze whether the contents in your webpage is rich enough to have such URL with these keywords or not. if the answer for every keyword is yes then the more length will give you the more rank.
I think you can even set your pages up in a way to use only the slug and skip the id, such as:
/adverts/suscipit-dis-molestie-malesuada-vestibulum-ut
or even just:
/suscipit-dis-molestie-malesuada-vestibulum-ut
like this and refer straight to the adverts controller and the advert itself, which has this slug assigned to it (the one with id 15880).
This way you'll have nice and clean URLs. Just assign and keep an unique slug for each advert and handle it using .htaccess, or dynamically inside the code of your site, if the system allows it.
Cheers.
I am in the process of building a super simple CMS to handle smaller "static" page type projects (e.g. - small sites for friends). I have different "page types" that I would like to add. I built something similar in Coldfusion previously. Looked something like this:
table content_type:
content_type_code varchar(10)
content_type_name
table content:
content_id
content_type_code varchar(10)
content_name
content_desc
content_url
I would create a content type called "blog" or "photo" and each time a content was added, it'd get assigned the content_type_code. Then in /blog/ I'd query for all content that had a content_type_code of "blog".
Now that I'm using Ruby/RoR I am trying to think about things differently. I was thinking a better way might be to use nested pages with awesome_nested_set (https://github.com/collectiveidea/awesome_nested_set). But I'm not sure if that's the best solution.
Then I could create a page called "blog" and add to that many pages. So essentially the top level would take place of the "content_type" from my previous example.
Can someone steer me in the right direction on what the best method would be? I'm a newb looking for a kick in the right direction.
EDIT
I should add that the only real thing that I would change between the different "types" of content would be the layout and where they are displayed ("photo" content at /photos/, "blog" content at /blog/).
I try to recap:
You want to build a CMS
Your CMS manages a single web site
A web site is made of content
There are differenti type of contents, and I am assuming every type of content has its own behaviour
Contents are organized in a tree
Here is the plan I suggest you:
Create the Content resource; use the scaffold to have something already working, adding few field (title and body in example)
Add validations to your new model
Write a couple of unit tests against your validation (quite useless, just to see how it works)
Install awesome_nested_set and manage to make it working with your model
Work on the UI to make it quite easy to create new content, move content around, edit a single content
Now its time to implement the content types; STI is the Rails way, but I have to warn you it can be really hard. I suggest you to reiterate 1, 2, 3, 5 to create new models for Photo and BlogPost
Once you will be there, you will have hundreds of ideas to implement. Have fun :)
Instead of using content_type I would rather let the user choose a model on a selection page, like "photo" or "blog" and load an editing page based on that selection. So the user wants a new 'blog'-entry they get redirected to blog/new or 'photo' for photo/new. It's the easiest way to go in terms of usability and your controlling backend and you don't have redundant data (for example an empty photo url which is not necessary in a blog-type) in your database.