Alright, I’ve been wanting to blog about this for years now. Some recent posts on twitter inspired me. Finally. If you following , you may be seeing a few tweets that apparently have nothing to do with Sitecore
The main problem with this, besides obvious aesthetics reasons, is that your news article has a very long URL which is pretty bad for SEO.
The instances of such URLs are commonly found in multi-site environments, but not necessarily.
You will have the same problem in single site if your home item was renamed to something else, and configuration was never adjusted.
The important thing is that it does not have to be this way.
Good news is that this is most likely caused by a few configuration issues. Your SEO person should be happy now knowing that your URLs could look something like this, now wouldn’t it be sweet?
It’s 2012 people, great time to clean up your URLs, let’s get it started!
Before we dive into the details, let’s take a quick look at the URL anatomy. The dynamic linking mechanism is described in detail in official documentation here
_hostname – _when the request passes your web server processing and reaches Sitecore, this is how Sitecore understands which ‘site’ needs to respond with the request. This is one of the essential pieces of the multi-site capabilities.
As related reading, check out this blog post by Mark Ursino
languageCode – _the inclusion of the language code depends on how the _LinkProvider is configured in web.config, specifically the “languageEmbedding” settings which could be set to either “asNeeded”, “always” or “never”:
useDisplayName="false" />For the record, I am really not sure why there is “asNeeded” as it seems like this setting will never be needed (pun intended). Either “never” or “always” should be your choice. Anyways, if you are running in single language mode and are not planning going multi-lingual, set this to “never”. _extension – _since we are on the topic of _LinkProvider_, the setting to control the extension is called: addAspxExtension _contentTreePath – _this the part of the content tree where your pages is stored: [![image](http://lh6.ggpht.com/-JJ3qdB9Cn1E/T0P42-obLoI/AAAAAAAAhTA/WcEjXaewQwo/image_thumb%25255B1%25255D.png?imgmax=800 "image")](http://lh5.ggpht.com/-8ZRqZOFgPWU/T0P42PzxotI/AAAAAAAAhS4/4gi6H_DBPlI/s1600-h/image%25255B3%25255D.png) For those of you who is not familiar with inner workings of , the URLs are dynamically handled by what we call “ItemResolver”. That means that there is no static file that web server hosts (_/en/sitecore/content/site1/news/blabla.aspx_), rather there is an item called ‘_blablba_’ that is stored under _/sitecore/content/site1/news_[Sitecore CMS](http://www.sitecore.net/cms) If you would like to understand the linking mechanism in more detail, check out [this doc on SDN](http://sdn.sitecore.net/upload/sitecore6/sc62keywords/dynamic_links_sc62_a4.pdf) Now let’s see how to fix this. Here are the things you need to make sure are configured: - Site1 in this example should have it’s own “site” definition in web.config, add it _before ‘website’_:
<site name="site1" **hostName="site1.local.com"**
**startItem****="/site1**" ... />
startItem="/home" ... />notice how “startItem” points to /site1 instead of /home. Site’s start path = rootPath + startItem. Even if you have only one site, you will need to adjust the “startItem” setting. I’d also recommend creating a dedicated site instead of modifying the “website” in this case. Separate apples and oranges. - For the cross-site linking to work properly, the following settings should be set: > - ensure that Rendering.SiteResolving = true (if I remember correctly, this may have been ‘false’ in earlier versions): >
<setting name="Rendering.SiteResolving" value="true" />
- add _targetHostName _(case sensitive) to your “site1” definition:<site name="site1"hostName="site1.local.com"targetHostName="site1.local.com" />More about both settings in section 2.1.1 of this. As the document explains, having hostName could be sufficient if you don’t have pipes or asterisks in _hostName. _To be on the safe side, I would recommend having _targetHostName _ doc on SDN
As a result, here is how the link from “Home/About” to “/Site1/News/blabla” looks like in such configuration (languageEmbedding="never" && addAspxExtension="false"):
Now everything is fixed, you have a very interesting problem to deal with. Specifically, what to do with old URLs that have /sitecore/content/site1 in them?
Well, you can either handle it with a permanent redirect solution, server based or Sitecore managed.
Another way to consider is to have a “dummy” site mapped to a non-existing item in content tree. This site will intercept all links with /sitecore/content in them and throw Sitecore item not found.
<!-- as always, the order of 'dummy' site placement is important -->
<site name="modules_website" ... />
That’s all, folks! Please leave a comment below.