1. Automatic rewriting -- I would like to see this feature removed. It makes it way too easy for a merchant to mess up their search engine rankings by simply renaming a product or category. Rather, I think the Custom URL field for a product or category should be a required field. You could add a button next to the box that says "Generate URL" which would derive the URL from the name of the product or category (alternately you could use JS to generate the URL as the merchant enter the product or category name). However, now there is a fixed URL so a merchant can freely change the name of a product or category without fear of messing of their rankings.

2. Semi-automated 301 redirects -- when a user changes the URL in the Custom URL field, a pre-checked checkbox should appear that says "create 301 redirect". This makes it idiot proof and saves time when a change to a URL must be made.

3. Extension-less URL's would be nice...I realize that this will require IIS 7 and probably ASP.NET 3.5

4. Breadcrumbing URL -- the way this is currently implemented isn't done so in a true hierarchical way, though I think this is due to the inability to do extension-less URL's. See example below:

Currently:
/Departments/Parent-Category.aspx
/Departments/Parent-Category/Child-Category.aspx

Should be:
/Departments/Parent-Category/
/Departments/Parent-Category/Child-Category/

This way the parent/child relationship is communicated via the directory structure.

One concept I've been working with is a product URL that looks like this:


/products/1234/some-text-slug-for-product/

In this instance the "1234" part is the id of the product and will never change. Any text you put after the id will be accepted and direct to product 1234. This guarantees that all old urls for the product will work after you change the name.

Thoughts?

Matt,

In your example you would need to manually add a rewrite rule:

domain.com/some-text-slug-for-product.aspx = domain.com/products/1234/some-slug-text-for-product

Would that meet your needs? Assume that we could auto-import any custom URL rules you have in BV5

Marcus,
I'm not really a fan of that for two reasons:

1. The 1234 is not "friendly", at least to users, and is excess noise in the URL.
2. The URL prefix is potentially excess noise in the URL and can be a detriment to SEO. I hate being constrained by it.

I've done both types of rewriting/manual URL setup for websites. I haven't seen a difference in peformance between the Extension/No Extension concept coupled with directory structure setup. In my experiences so far, the performance has been about the same with both having their pros and cons. Frankly, I don't care for the argument that could result from me saying this.

We know there's a difference between linking to www.domain.com vs. www.domain.com/ vs www.domain.com/default/ vs. www.domain.com/default.aspx

add .php, .htm, what have you for an extension.

I asked way back in the beginning of a BV5 build if I could get rid of Departments/ & Products/ but still maintain the use of the auto-rewrite. Couldn't happen, so resorted to manual rewrites.

This request was based on the previous store having Aram's rewriter in place for 2 years with an attempt at easing the transition to new version.

Preference: Manual Rewrites - Results: A ridiculous sales & engine performance comparison. So changing to a whole new naming structure simply isn't going to happen for another few years. We've nailed it, until there's a problem, we keep it the same.

Why do I like manual rewrites? Because I get to control all of it. My client's like to fiddle, knock yourself out I say, please don't touch the URL. Let me know when you break something and I'll fix it. :)

So my preference:

1. Do not remove the ability to manually rewrite URL's for products and categories

2. Allow for it to not need Departments/ & Products/ or any derivative of for auto-rewrites. I know this is a tough one, you've explained it to me several times as I can be persistant in my annoyance...LOL..

3. If I went with auto rewrites, I would love to see it as (Noting option between extension/no extension. Even the ability to choose extension.):

Category-Name/Sub-Category-Name/Sub-Sub-Category-Name/auto-rewritten-product-name-url/

or

Category-Name/Sub-Category-Name/Sub-Sub-Category-Name/auto-rewritten-product-name-url.aspx (or .htm/.html)

But that opens up a can, what if the product is assigned to multiple categories? You'd end up having 10 rewrites for one product if it's assigned to 10 categories? What if the product is temporarily assigned to a higher category because it's a featured item at the parent category level, how does the system pick the URL name? if it's then moved out of that category, does the URL get rewritten? (There's that 301 table size issue).

So that's why I am going to continue to pound a dead horse about manually rewritten URLs and keep mentioning it until I get a clear cut answer as to whether or not it's going to be included or deprecated from future versions!!!!!

LMAO.. c'mon Marcus... is it going to be deprecated or what?

I know I'm being a redudant record... Automation is fantastic, but it has it's limitations like we're pointing out. I try to automate as much as I can in my routine but I'll never sacrifice the importance of being exact just for convenience purposes.


Now if it were 10,000 rewrites...

Matt,
When I said:



I mean that it is a limitation of URL's in general. In other words, a URL does not have the ability to relate to multiple directories in the same way that a product can relate to multiple categories. Now, if a URL had meta data, then we might be able to address this problem.

Aaron: Good points all around. A hash on the URL might speed lookups

Matt: I'm curious about why specifically you don't want "/products" and "/categories" at the beginning of your url?

While I am looking at improving the auto-rewrite of URLs for the next version of BV I have no plans to remove the manual rewrite option. There will always be someone who wants to explicitly map one URL to another and I think we should continue to support that.

I'm not a URL rewrite expert, so this going to be more of a functional request...

Realizing that different stores are going to have different URL requirements,perhaps a rule based hierarchy would be the most flexible. Set the store default as you have it now, and the override at the category/product level, and create rules between the two.

You could have a rules page that is defined by a matching criteria (similar or the same as selecting products in the category page), so that you could apply different rules to different groups of products/categories. Those that meet the criteria follow the URL rule, if no matching rule use the store default, and obviously if there is an
override for the product, use that.

In each rule, you have the option to choose url scheme, as well as the extension. It would be nice if the url scheme could assign the rules in a label-replacement type format,
like you have in the email/print templates.

That way you can have (or whatever labels you make available):

/Products/Product-Type/rewritten-url-name

/Products/Manufacturer-Name/sku/rewritten-url-name

/Parent-Category-Name/sku/rewritten-url-name


If there are technical/performance hurdles that won't allow the matching criteria, perhaps a simliar rule structure could be defined at the store level, and allow overrides
at the product/category level as they currently are.

If you allow matching criteria, you would likely need an audit/report available to show which rules had possible duplicates, or invalid rules.

Perhaps you could add it to the workflow engine, so custom re-write plugins can bypass it, or allow you to develop feature enhancements without impacting existing stores.

Another thought..create an option to use ISAPI_Rewrite, in addition to a standard set of rewrite rules. If selected, a process is run to create the ISAPI rewrite rules based on custom rules defined within the store. The custom rules page could only be accessed if ISAPI_Rewrite is selected. This would offload the lookup from BV.

Just some thoughts.