The word redirect has almost become synonymous with a 301 redirect or URL redirect. Redirect obviously could mean anything, but when we talk about redirect in the internet world, we typically mean a page redirect or URL redirect.
If you are already familiar with 301 redirects and know why we use 301 redirects and just want to know how we handle 301 redirects in PrimeAgile, you may want to click here go directly to PrimeAgile's 301-redirect handling page.
A 301 redirect is a permanent redirect. The 301 status code means the page had been permanently moved to a new location. There are many different status codes that a server can return that informs a browser and a user what is going on with the page. A 301 redirect is special because it informs the browser, but it also informs search engines so they can index the correct page, so users and search engines are redirected.
301 redirects are a necessary part of any content management system or any website management system really. It is an often overlooked feature of a CMS because it is built into most web servers and it is easy to think 'why reinvent the wheel'. However as we explain later it is necessary to have a better system than what is built into a web server.
Without 301 permanent redirects, browsing the web would be inconvenient. Many pages would no longer exist. As pages are renamed or moved the page URL changes resulting in dead links. The reason we don't run into dead links all the time is thanks to the 301 redirect. The fact that we run into any at all is because not all systems have an integrated easy to manage process for handling 301 redirects.
Any time a page url changes in any way, a 301 redirect is necessary to prevent the following problems:
There are several cases when somoene might need to use a 301 redirect.
Any time someone renames a page, not as in changing the page title but changing its url, all links pointing to that URL break. For example, this page was originally called redirects. Then later I realized that 301-redirect was a more appropriate url, it gives a better description of the page. The page url affects search engine placement which affects the ability of this page to serve people looking for information about 301 redirects. So I appropriately changed the url from /redirects to /301-redirect to better server my potential audience. I then later renamed it to /CMS/301-redirect to even better organize the content. This was a good choice in both cases, however it causes the problems listed above every time I make a change and as the content for a site evolves and gets better, changes will happen regularly.
Moving a site to a new domain requires 301 redirects for every page on the old site. It is possible to do this simply using an alias. For example if the domain ibcs.com was available the www.ibcscorp.com website could maybe be moved to that new domain. However, doing so would break all traffic to www.ibcscorp.com that has been built up over the years, again causing the problems listed above. Simply aliasing www.ibcscorp.com to www.ibcs.com would fix all of the links, but providing a proper permanent 301 redirect would also inform search engines and sophisticated content management systems that this was a permanent change and that their indexes and links should be fixed.
A website should have only one URL and that same URL should be used all the time. www.PrimeAgile.com is the canononical url for this site. All traffic and links point to www.PrimeAgile.com. Any traffic to PrimeAgile.com is automatically redirected to www.PrimeAgile.com. This is built into PrimeAgile for all websites running on PrimeAgile. If we ever changed that canonical URL, then we would want to put 301 redirects in to fix all of the links and indexes pointing to the old URL.
Similarly if we purchased two domains and their content and wanted to merge them into one website, www.PrimeAgile.com for example, to prevent losing the value of those two sites we purchased, we would use 301 redirects to point those old urls to the new urls on the www.PrimeAgile.com.
There is more than one angle on 301 Redirect Handling. First when we change the URL of a page, we want to redirect traffic to the new URL. Secondly, we also want to be 301 aware so that we update any links that are being redirected. Third we want to be aware of any 301 redirects that we have so that we aren't confused when we create a new page url that already has a redirect.
In many content management systems (CMS) 301 redirects are handled by a .htaccess file. This is fine except that general authors don't usually have access to the .htaccess file. This means they may or may not know that a 301 redirect exists. Even worse is that they can't create 301 redirects themselves and ultimately it does not get done.
In PrimeAgile CMS, redirect handling however is not tucked away in a .htaccess file where it is hard to get to and where only priveleged users can access it. We believe that managing 301 redirects is an important feature of any CMS system and that it needs to be part of the every day process of managing a website. Click here to learn more about how PrimeAgile CMS handles 301 Redirects.
When building a front end there are several ways of doing a 301 redirect.
externalContext.setResponseStatus(HttpServletResponse.SC_MOVED_PERMANENTLY); externalContext.setResponseHeader("Location", destination); facesContext.responseComplete();
Powered by PrimeAgile ™