Developer forum

>> So the pattern would be:  /Product-Number/Product-Name(.aspx) and /Product-Number/Variant-ID/Product-Name/variant-name(.aspx).

That woud also cause SEO duplicatte content and allow your competitors to link to you with a ink like:

/123/SomeReallyyStinkingProject,aspx

and the site would respond with the product as it doesn't know if that name existed previously or not.

Imar

What it can do is perform a 301 redirect if the Name in the URL doesn't match the name in the database. So that will always have a primary URL that is current, but old URLs will still be able to find their way back home.

Scott

Hi Guys,

I think there are 2 sides to this situation.

1. Avoid 404 response

2. Keep link juice

Let's assume you have a nice popular product that was online for quite a while. The link was index by Search Engines and you get some nice relevance for it. The moment you change the name, and the friendly URL is changed as well, you loose all that juice. If you manage to get a redirect to homepage, you manage to assign that juice to the homepage or category page but it's still not the same thing. That's why you would need a 301 redirect old-url-to-new-url.

One alternative method would be to alway index unfriendly URL's by submitting them in the sitemap xml but that's arguable as some of the juice on the links will be gathered via friendly URL's. And I can imagine SEo purists will have something against this method anyway.

The ideal way would be to have DW handle this register of old/new URL's and create automatic Direct Path entries everytime there is a change that affects the friendly URL. The challenge is to monitor all methods of making changes: Data Integration, Integration Framework, Backend as they might use different notifications.

Adrian 

Hi Adrian,

Exactly! To achieve what you mention as the ideal way, I can envision one of three ways to handle that:

1. As you mentioned, every place that could change a product name would monitor the changes and write a direct path for the old URL when it changes
2. Keep the URLs in a static table rather than dynamically building them on app load. Then on app load, if the URL changes, save the old to direct paths, and the start using the new. This would also give more control and address other issues with duplicate names with products that are named the same.
3. What I mentioned above to include the product number in the URL and use that for the mapping, and the rest for the sake of SEO.

Any of those three could work. Probably #1 and #2 are better since the issue with #3 is that neither ProductID or ProductNumber are guaranteed to be unique by themselves.

Scott

I wanted to send a nudge on this thread. It's pretty important for us.

I created a temporary solution that is working now to address active issues on two different sites. The solution is using the #2 option using a scheduled SQL script. Of course, I had to mimic some of the regex logic in TSQL and such. Essentially it runs every 6 hours and looks for any URL pattern that isn't already stored to a UrlHistory table. It creates a mapping from the URL to the product ID. 

The 404 page handler checks to see if a URL matches in the UrlHistory table and if it does, it redirects to the new location. This way it will keep a history of the URLs as far back as they want.

I used this for a website that had already made a few hundred product name updates. I used a backup of their database from before the change, and generated the URL patterns. The second site planned in advance, so I didn't have to use a backup. 

But this should really be done in the platform rather than in SQL so that it benefits from the same platform logic. Otherwise it's just a mirror of the code.

A 4th option is to write the URL pattern to EcomProduct.ProductMetaUrl so that it remains static, even if the product name changes. But that should also be handled in the platform as an option rather than in the integration or after the fact.  

Thoughts?

Scott