Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

With Microsoft providing zero support when doing URL rewriting, what is my best approach for providing URL redirects? I'm not too familiar with the topic.

The approach I've seen (a solution from a previous colleague) was something to the tune of the following: Create a custom error page, and when that error page is hit, check a SPList to see if a list item exists for the URL you are trying to get. If so, it will redirect you on to the full URL. This approach makes management of the URLs easy and doesn't involve IIS.

Are there any implications related to SEO with this approach?

The provided solution would best be one that is easily deployed, and wouldn't involve IIS directly.

share|improve this question
add comment

4 Answers

up vote 3 down vote accepted

That is an option, however, search would not show those same urls. If you wanted to actually do host header site collections, this would ensure that you have the URLs that are friendly in the search results, and would allow the end user to search using that part of the URL as well. However, there are some disadvantages to the host header URLs as well. You have to add them to IIS, you cannot use Alternate Access Mapping with it, and you have to manually add the start address to the content source to be crawled in teh default SharePoint Sites. You also have to be concerned if you are using Vanity urls with external sites as you can have either www.sitename.com or sitename.com and not both. Then you will have to create a redirect to the other one if you choose to do that.

Another option is to use IIS and create the redirects to the internal site or site collection manually. However, if there are potentially hundreds of these, then you will want to minimize this as well, because it can become very painful to manage, and when you have multiple web front ends, you end up with even more pain! And once again, search will only show the actual internal URLs.

My personal recommendation is to try to talk people out of vanity URLs as much as possible. If there is a need for a separate URL, then you should really explore why and see if it really should be another web application alltogether. I've worked with Vanity URL's and have several blog posts about configuring them, creating search with them, and also dealing with public facing ones. You can see those at http://pointgowin.com/seethepoint if you like.

share|improve this answer
1  
Agreed. Either you can use the Alternate Access Mapping, or you can try the URL Rewriter Module for IIS (not your preference), I am using this to map some older URL's from IIS to our new SharePoint site once we migrate the site to the new environment. I had to do a lot of investigation into this in order to see what would work, and wouldn't and one thing I found with the URL Rewriter was changing URL's means supporting underlying SharePoint calls and that could be a mess. Or means lots of checking. Avoid Vanity if at all possible. –  MichaelF May 23 '11 at 15:33
    
It's not always possibly just to 'talk them out of it' :). In some cases, they may be trying to link to commonly used views that have a lot of ribbon context appended to the url, etc. Your approach seems feasible, but you seem to run in to issues when the amount of re-directs increase. Maintainability seems to be unmanageable. –  Tim Gabrhel May 24 '11 at 12:43
add comment

If you have TMG in place, you can probably setup a redirect of a vanity URL, but again these are not formally supported in SharePoint.

As for the question of SEO... a search engine isn't typically going to follow your redirect rules when they're indexing, so I'd expect to see a fairly large impact on SEO.

As Lori said, I'd try to talk people out of this as much as possible. Use managed paths to structure your sites/webs in a more user intuitive way (don't just dump every site collection under the "sites" managed path), and URLs will be far easier to work with.

share|improve this answer
add comment

There should be no problem with redirects - the supportability issue relates to URL rewriting.

Both redirects and rewrites can be achieved at the IIS level using the Microsoft add-on for IIS7 called URL Rewrite and a third-party module called urlrewriter.net. There is also a SharePoint redirect publishing page or you can write something custom or find something on Codeplex.

But the URL redirect doesn't really solve the vanity URL problem, because the re-written URL is what users will see in the browser address bar, not the vanity URL. That's one big advantage of the URL re-write (the other is that it doesn't involve an additional round trip to the server). You are also telling the search engine that the vanity URL has been "moved" to the actual URL.

So the SEO implications of URL redirects is that it doesn't really solve the problem, assuming that the problem is a real one in the first place. That's another debate ;-)

Similar question was asked here.

share|improve this answer
    
But aren't you breaking inherit functionality, by re-writing, of the object model, specifically SPContext? –  Tim Gabrhel May 24 '11 at 12:41
    
Yes; that is why it is not supported, as I said in my answer. –  SPDoctor Nov 18 '11 at 22:32
add comment

As an alternative you can also use a commercial URL Shortener product such as this one. It allows vanity urls to be created either manually, via a web service call or via a workflow. Alternatively you can let it generate the shortest most posible URL.

Disclaimer, I worked on this product so I am obviously biased. Having said that, it works great.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.