I realize I'm a bit late jumping into this conversation, but for what it's worth I love the manual URL definition. I don't care if we have 10,000 products, I'd rather put it in Excel and create my own formula for the URL and bulk import that puppy. Automatic URLs is nice but if you're serious about it then manual is definitely the way to go. I've seen other platforms insert the category name into the URL but when you have one product in 10 categories you have potentially 10 URLs and if you're not properly defining the canonical version of that page you have potential concerns with dupe content.

Another consideration Marcus, and one reason I actually prefer the way you have it now is that you don't want product URLs that look to be 5 or 6 "directories" deep - closer to the root is better and popping in ID #s in the URL is not very user friendly IMO

If you want to change the automatic setting (please please please not the manual as it is one competitive advantage I see with BV vs. the others is I have total control over the entire URL - it doesn't have to be automatic and not just the slug) then I'd suggest letting people define their own format where you have it right now with /departments and /products allow them to use variables like {{productid}}, {{category}}, etc.

Otherwise I tend to agree with Aaron. We've gotten extensionless to work via some ASP.NET / IIS configuration already but otherwise the auto 301-creation if you ever change that value could come in handy. Like he said, clients have a tendency to fudge that up sometimes.

Corneliu,

Some stores have 10 products, some have 500,000+. If I assumed a best case scenario of using only ASCII characters (1 byte per character) with 255 characters of space to hold a URL * 500,000 products = About 120MB of data just for the urls. That doesn't include 301 data. If each product had 2 old 301's you're adding another 240MB of memory just for this.

Yes, for a small store that might be efficient but it won't scale.

That is the problem with domain.com/random-text-for-each-product

Everytime you have to do a SQL table scan for a text match on 500,000 records that's a heavy operation plus the overhead of going across the lan to the DB in the first place. I'm not worried about this for a small store but once you start to put a significant number of products in place things could get slow quickly.

That's an interesting idea, but think how brittle that will make the URL. If the user changes any one of those fields you'll need to 301 the old URL to the new one. Granted, if BV implements my suggestion of explicitly defining a URL for every product and category, then by default the old URL would be retained.




Again, this is very brittle unless the URL for a category is explicitly defined. Otherwise if you change a category name you've broken the URL of every child category and product. Also, since a product can belong to multiple categories, you would need to use the new canonical link tag to prevent duplicate content. This also means that there needs to be a way to specify what the canonical link is in the admin (i.e. which category is the master).

Honestly, why is URL rewriting so darn complicated? Sometimes I wonder if we should all go back to query strings. It was so much easier then. :)