I went ahead and implemented nice URLs in uCommerce and I'm pretty happy with how they turned out. If you have some feedback on the format now is the time to let me know about it:
Basically we have three different types of URLs: One for catalogs, one for categories, and one products. The thinking is to enable stuffing the URL with as much information as possible without having to reimplement the entire thing from scratch so I came up with the concept of a payload tacked on the end of the URL.
For a catalog url the payload at the end of the url would look like this: c-<catalogName>.
So Our is not very happy to display URLs without formatting them so I guess I better explain what the idea is.
Basically I'm outputting DisplayName for catalogs, categories, and products for the first part of the URL. Secondly I'm adding a paymnet to the end of the URL for uCommerce to use to figure out what should be displayed.
So the URL will look like this DisplayName + DisplayName + DisplayName + c-catalogName,p-SKU
Not 100% sure what you mean with your explanation, so let me instead try and explain how I solved it on Filabel.dk:
There is only one catalog on Filabel.dk, so this part is hardcoded into all macro's. No need to specify it in URL's if it's always the same.
But all URL's in the product catalog part of the page starts with
/shop/, so it is easier for the URL-Rewriter to pick up and transform.
It's sort of a "trigger" for the rewritter.
The format for category pages is /shop/<CategoryName>/<SubCategoryName>.aspx
<SubCategoryName> is optional.
The format for product pages is /shop/<CategoryName>/<SubCategoryName>/pr-<ProductSKU>.aspx
Again, <SubCategoryName> is optional. The "pr-" prefix on the
pagename itself functions as a "trigger" for the rewriter to look for a
product SKU.
I would have loved to have the ProductDisplayName in there somewhere too
for SEO purposes, but that was cut due to time constraints.
All this is rewritten to
/shop/category.aspx?maincat=<CategoryName>&subcat=<SubCategoryName>
for category pages, and
/shop/product.aspx?maincat=<CategoryName>&subcat=<SubCategoryName>&sku=<ProductSKU>
for product pages.
One problem with this method is, that it opens
up for duplicate content issues. Especially since you can write
anything before "/pr-" and it'll still load up the product page. But the
problem with having flat product page URL's is, you can't identify how
the user navigated to the product. And show this both in an expanding
product category tree, nor in fx. a breadcrumb trail. And this is
absolutely essential for the usability experience.
Besides, as
long as your navigation macro's don't mess things up and always uses the
same url format for linking, there's no problem. As long as none/no
site links this a given page, Google won't find it and index it.
You
WILL have duplicate content issues in a webshop, where one product can
be in multiple product categories. But it's not "illegal" to have
duplicate content. Unless 80% of your site is marked as duplicate, then
Google will look badly on you. But then you probably have bigger issues.
The consequence of this strategy is (if Google is even able to
identify which of your product pages are "duped") that one of your
product pages won't be admitted into Google's index. But the other one
is, so no biggie. Though external links into the dupe page isn't
counted, but product pages rarely gets that much link love anyways.
If
you want the propper solution, then you need to identify which should
be your "primary" product page, ie. the one you want Google to have in
its index. And then use the meta canonical tag on all other versions of
the product page to point to the primary one.
But if you ask me,
that's a lot of work and a lot of server overhead, for a theoretical
problem. A problem you'll only rarely run into out in the real world,
and which won't have that much of a consequence if you never discover
it.
This is great update! We went through headaches while ago implementing nice url's on uCommerce and we end up in format:
/DisplayName/DisplayName/SKU-ProductName
Since display names can be swapped and same product can apper on many categories we added meta canonical url for each product so we are not getting killed in SEO.
We had also problems with special characters in DisplayNames. Do you have a out-of-the-box solution if someone puts #%&/(Ø*Å in DisplayName?
@Jukka: On Filabel.dk we always use Name, and not DisplayName. Exactly for the reason you specify: DisplayName often contains chharacters that can't be used in URL's. So we would have to create some UrlEncode engine like the one used in Umbraco (or if possible, reuse the one in Umbraco). But there wasn't time for that, although that would have been pretty sweet.
The way we solved the problem with special characters in Names was to tell the customer not to use any :-) The same with SKU's.
Personally I really dislike that form of url and have been through the pain of setting them up, we've got around it in the past by storing a separate field for the url value which has to be unique for that path, doesn't fit too well into the current uCommerce structure mind you.
In regards how we've done it with other installations, we've leveraged the Umbraco pages and have added a category selector to the page type.
@JP/Soren: For special chars I plan to run the generated URL through char replacement to strip out chars like æøå and replace them with ae, oe, aa. Of course, it will only support Danish special chars, so I'm relying on UrlEncode for the rest.
@Tim: I'm trying to hit a happy medium as I'm aware that one solution won't be right for everybody. The UrlService can be replaced to support a completely different URL scheme like the one you describe.
A separate field will be very easy to implement, but I don't want to impose the extra management overhead unless it's an explicit choice.
I see that nobody has done that here, could anybody advise as to if/why this is a bad idea? (ps in this instance there won't be any products across multiple categories)
@Zac, why botther with the /category/ and /product/? I guess it makes it easier to identify in some respects but you can drop them completely quite easily...
Interesting, I've not seen that one before are you sure they weren't saying structure it as /category/product? That way if you remove "product" you get it's parent category etc.
uCommerce will use a similar technique to what Zac describes. The reason for this is indeed to serve as a marker so we know which URLs to rewrite and which to leave alone. Basically the final part of the URL serves as the payload uCommerce needs. Everything else can be customized if need be and still use the same url generation engine.
BTW I'm url encoding each of the url parts to ensure that we won't have any illegal chars in the url.
Good to know! What I've got so far doesn't deal with encoding the urls, so I need to be careful (or more importantly the client does!). I also wanted to do:
The StackOverflow example is pretty close to my thinking with the only difference being that the first part of the default uCommerce URLs will be interchangable, so the following will take you to the same page:
c- acts as my marker for a catalog url, while c-c- does the same for a category url, and c-p- for product urls. I've thrown in to optionally have .aspx on there as well to support older IIS installs.
By the way you won't have to mess around with XSLT to get those URLs. There's an XSLT extension in there which will generate urls for you if you give it catalogs, categories, products, or some combination of the three.
Feedback wanted: Nice URLs in uCommerce 1.4
I went ahead and implemented nice URLs in uCommerce and I'm pretty happy with how they turned out. If you have some feedback on the format now is the time to let me know about it:
Basically we have three different types of URLs: One for catalogs, one for categories, and one products. The thinking is to enable stuffing the URL with as much information as possible without having to reimplement the entire thing from scratch so I came up with the concept of a payload tacked on the end of the URL.
For a catalog url the payload at the end of the url would look like this: c-<catalogName>.
Catalog URL: www.yoursite.com/<CatalogDisplayName>/c-<catalogName>
Example: www.yoursite.com/Lovely-Spring-Offers/c-spring-offers
Following the same pattern a category url will be:
www.yoursite.com/Lovely-Spring-Offers/Flowers/c-spring-offers,c-flowerpower
Category URLs will be able to have the full path as part of the URL:
www.yoursite.com/Lovely-Spring-Offers/Flowers/Flower-Arrangements/Special-Offers/c-spring-offers,c-flowerpower
And a product:
www.yoursite.com/Lovely-Spring-Offers/Beautiful-Flower-Arragement/c-spring,p-100-200-300
So Our is not very happy to display URLs without formatting them so I guess I better explain what the idea is.
Basically I'm outputting DisplayName for catalogs, categories, and products for the first part of the URL. Secondly I'm adding a paymnet to the end of the URL for uCommerce to use to figure out what should be displayed.
So the URL will look like this DisplayName + DisplayName + DisplayName + c-catalogName,p-SKU
Not 100% sure what you mean with your explanation, so let me instead try and explain how I solved it on Filabel.dk:
But all URL's in the product catalog part of the page starts with /shop/, so it is easier for the URL-Rewriter to pick up and transform. It's sort of a "trigger" for the rewritter.
<SubCategoryName> is optional.
Again, <SubCategoryName> is optional. The "pr-" prefix on the pagename itself functions as a "trigger" for the rewriter to look for a product SKU.
I would have loved to have the ProductDisplayName in there somewhere too for SEO purposes, but that was cut due to time constraints.
All this is rewritten to /shop/category.aspx?maincat=<CategoryName>&subcat=<SubCategoryName> for category pages, and /shop/product.aspx?maincat=<CategoryName>&subcat=<SubCategoryName>&sku=<ProductSKU> for product pages.
One problem with this method is, that it opens up for duplicate content issues. Especially since you can write anything before "/pr-" and it'll still load up the product page. But the problem with having flat product page URL's is, you can't identify how the user navigated to the product. And show this both in an expanding product category tree, nor in fx. a breadcrumb trail. And this is absolutely essential for the usability experience.
Besides, as long as your navigation macro's don't mess things up and always uses the same url format for linking, there's no problem. As long as none/no site links this a given page, Google won't find it and index it.
You WILL have duplicate content issues in a webshop, where one product can be in multiple product categories. But it's not "illegal" to have duplicate content. Unless 80% of your site is marked as duplicate, then Google will look badly on you. But then you probably have bigger issues.
The consequence of this strategy is (if Google is even able to identify which of your product pages are "duped") that one of your product pages won't be admitted into Google's index. But the other one is, so no biggie. Though external links into the dupe page isn't counted, but product pages rarely gets that much link love anyways.
If you want the propper solution, then you need to identify which should be your "primary" product page, ie. the one you want Google to have in its index. And then use the meta canonical tag on all other versions of the product page to point to the primary one.
But if you ask me, that's a lot of work and a lot of server overhead, for a theoretical problem. A problem you'll only rarely run into out in the real world, and which won't have that much of a consequence if you never discover it.
Hope this helps you, otherwise do let me know!
Best regards,
Soeren Sprogoe
This is great update! We went through headaches while ago implementing nice url's on uCommerce and we end up in format:
/DisplayName/DisplayName/SKU-ProductName
Since display names can be swapped and same product can apper on many categories we added meta canonical url for each product so we are not getting killed in SEO.
We had also problems with special characters in DisplayNames. Do you have a out-of-the-box solution if someone puts #%&/(Ø*Å in DisplayName?
@Jukka: On Filabel.dk we always use Name, and not DisplayName. Exactly for the reason you specify: DisplayName often contains chharacters that can't be used in URL's. So we would have to create some UrlEncode engine like the one used in Umbraco (or if possible, reuse the one in Umbraco). But there wasn't time for that, although that would have been pretty sweet.
The way we solved the problem with special characters in Names was to tell the customer not to use any :-) The same with SKU's.
/SoerenS
Personally I really dislike that form of url and have been through the pain of setting them up, we've got around it in the past by storing a separate field for the url value which has to be unique for that path, doesn't fit too well into the current uCommerce structure mind you.
In regards how we've done it with other installations, we've leveraged the Umbraco pages and have added a category selector to the page type.
Thanks for the feedback, guys.
@JP/Soren: For special chars I plan to run the generated URL through char replacement to strip out chars like æøå and replace them with ae, oe, aa. Of course, it will only support Danish special chars, so I'm relying on UrlEncode for the rest.
@Tim: I'm trying to hit a happy medium as I'm aware that one solution won't be right for everybody. The UrlService can be replaced to support a completely different URL scheme like the one you describe.
A separate field will be very easy to implement, but I don't want to impose the extra management overhead unless it's an explicit choice.
I've been having a go at getting nice URLs. I've been going for:
/shop/category/<categoryname>/product/<product-sku>
I see that nobody has done that here, could anybody advise as to if/why this is a bad idea? (ps in this instance there won't be any products across multiple categories)
@Zac, why botther with the /category/ and /product/? I guess it makes it easier to identify in some respects but you can drop them completely quite easily...
@Tim Originally, yeah that's what I had. But then I figured... it serves as an identifer for the following parameter.
I can't for the life of me remember where, but I remember someone suggesting this as good practice.
I figured it would also make the rewrite rules much more robust (i.e. less likely that I will make a mistake in ordering them)
Interesting, I've not seen that one before are you sure they weren't saying structure it as /category/product? That way if you remove "product" you get it's parent category etc.
uCommerce will use a similar technique to what Zac describes. The reason for this is indeed to serve as a marker so we know which URLs to rewrite and which to leave alone. Basically the final part of the URL serves as the payload uCommerce needs. Everything else can be customized if need be and still use the same url generation engine.
BTW I'm url encoding each of the url parts to ensure that we won't have any illegal chars in the url.
Good to know! What I've got so far doesn't deal with encoding the urls, so I need to be careful (or more importantly the client does!). I also wanted to do:
where this would be compeltely interchangeable with
That way the seo friendly url part would be essentially just there for show (you could replace it with whatever and it would still use the SKU).
Unfortunately, I've not had much luck hacking at the XSLT to get it to make my urls safe and friendly.
As a comparison, these three StackOverflow urls go to the same page:
The StackOverflow example is pretty close to my thinking with the only difference being that the first part of the default uCommerce URLs will be interchangable, so the following will take you to the same page:
c- acts as my marker for a catalog url, while c-c- does the same for a category url, and c-p- for product urls. I've thrown in to optionally have .aspx on there as well to support older IIS installs.
By the way you won't have to mess around with XSLT to get those URLs. There's an XSLT extension in there which will generate urls for you if you give it catalogs, categories, products, or some combination of the three.
is working on a reply...