Technical Solution
Permanently Redirecting URLs using 301 Headers in Static and Dynamic Sites
Permanently redirecting traffic using a 301 header is the proper and fail-safe way to ensure that your web-visitors continue to find content that has permanently moved to a new locations. Search engine ranking is crucial for any business. Web infrastructure changes and changes in best-practices can lead to a change in the URI of content items. Being that Search Engine indexes take time to update (10 days to 3 months), it is important to continue to maintain the old URLs until all the external referrers are updated.
Why there may be a need to use new paths
It is probable you have gained some knowledge and technologies have changed since you last overhauled your website and you may have a new naming system for your paths that's uniform and that hopefully embeds keywords in your document paths to maximize your ranking advantage. This situation makes it necessary for a web producer to create new URL paths for existing documents while keeping the old URLs active until everyone is updated.
How to implement
You cannot reliably depend on client technology to handle any tasks beyond the display of simple standards-compliant markup. Therefor you can employ a number of methods on the server to implement 301 Header redirects as follows:
Server-side ImplementationWindows IIS with Active Server Pages (ASP)
<%@ Language=VBScript %>
<%
Response.Status = "301 Moved Permanently"
Response.AddHeader "Location", "http://newpagelocation.com/path"
Response.End
%>
PHP
<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: /my-new-path");
exit();
?>
ColdFusion
<CFHEADER statuscode="301" statustext="Moved Permanently">
<CFHEADER name="Location" value="http://newpagelocation.com/path">
mod_rewrite (Apache Web Server)
rewriteEngine on
rewriteRule ^contact\.php$ http://newpagelocation.com/path [R=permanent,L]
Placing this code in the template and testing for the requested URL to see if the page has been redirect can add a heavy overhead that could slow or even cause errors in your system. It is better to create placeholder pages with the URL of the removed pages and place the 301 redirect code for each case.
NB: If your CMS can schedule publishing and archival of pages, you can determine when to retire the redirect for a given page (estimate 6 months for all Search Engines to update their indexes)
For example, to implement this in Drupal:
- Create regular node of any node type
- Select the the PHP content type
- Place the following code in it and modify the destination URL to the new path alias (for engines to index the new name as opposed to the node ID)
Create a path alias for this document bearing the URl of the OLD path Save and publish the document
_________________________
How it works
Since you create a document with the same path as the old location, when the old URL is called, the redirecting node will 301 redirect it to the new location thereby enabling you to maintain your old URLs while promoting your new paths and indicating to Search Engines that your page has moved.
NB: Sending a 301 header redirect is the best and proper way to redirect permanently moved pages.
- Client-side Redirection
- As explained at the beginning of this document, the only reliable and proper way to redirect traffic from a non-existent page and properly signal the new location is to use the 301 Header redirect. In the absence of access to server technologies, the next best thing is to use client-side scripting and META REFRESH headers to redirect traffic. These methods do not indicate a permanent change or URI and bookmark and index driven agents such as search engines and link referrers will not know that your content has moved unless a human-being manually modified the path.
-
- Javascript
<script type="text/javascript">
window.location.href='http://newpagelocation.com/path';
</script>
META REFRESH
<html>
<head>
<meta http-equiv="refresh" content="0;url=http://newpagelocation.com/path">
</head>
<body>
This page has moved to <a xhref="http://newpagelocation.com/path"> The content has moved to http://newpagelocation.com/path</a>
</body>
</html>
Drupal: Sending email without an SMTP Server configured in PHP
Based on the assumption that most Drupal installations are done on Unix or Linux/LAMP plateforms, there is not enough information on how to implement the email function when installation on Windows or any other Operating System that does not have the Send-mail engine that is classic of Linux and other Unix-like operating systems.
Error 1067 while installing Apache 1.3.34 and PHP 4.4.2 on Windows Server 2003/XP
This is a report ofthe challenges, error message 1067 in Apache 1.3.34 and solution that I found to this problem while typing to get PHP 4.4.2 to run an Apache module.
Having installed WAMP using version 2.0.55 of Apache, and now recognising the fact that Apache 2.0.55 does not come with inbuilt SSL support (due to export restrictions of some governments and the pervasiveness of Open Source applications such as WAMP/LAMP), I decided to install the stable version of 1.3.x which has better SSL support. Also, I have experienced some problems and apparent instability running PHP and mySQL on Apache 2.0.55
In this procedure, I decided to replicate the version combinations of Site5 (a popular web host) with regard to the fact that there would be a slight version number difference being that Site5 is running LAMP and the same exact versions of AMP are not compiled for Windows.
Error 1067
I was able to install and test apache with no problems at all. Since I knew that PHP 4.4.2 worked well in my other WAMP installation, I made the lazy mistake of trying to borrow too much from that installation. I carried some of the files and php.ini file from that instllation and in hindsight, it seems that php4ts.dll file that I was trying to run was not wholly compatible with the rest of the files. As usual, I ran the binary installation and then attempted to bring-in the extensions and includes from my other installation to this setup.
After struggling and failing, I decided to read some online documents that I have previously relied upon to help me find my oversights and mistakes:
- http://httpd.apache.org/docs/1.3/windows.html
- http://www.thesitewizard.com/archive/php4install.shtml
- http://www.neothermic.com/tutorials/ApacheTutorial.php (clear and concise)
Solution
The steps seemed very clear and direct on all of them but I kept getting the same error message 1067 for which there was not clear diagnostics from Apache or anyone else. The details of the Windows error message (Yes, Windows reported that Apache had failed and asked me if I wanted to report the error), ther was a reference to php4ts.dll. At least I knew that Apache was looking for PHP, and based on my experience with error 1251 in which having the wrong file at the wrong place caused me argony, I decided to refresh the folders by downloading a fresh copy of the PHP application.
I renamed the existing folder and named the new folder as c:\php , save the old php.ini file in the right place and made changes to the folder references (I decided to keep the /sapi folder intact). I relaunched Apache and it worked like a charm.
I intend to downgrade my other WAMP installation to 1.3.34 to support SSL as well as implement virtual hosts so that I can generate multiple LOG files (something that multi-site hosting of Drupal cannot provide in Apache logs since it is running on a layer above the host - Apache 1.3.34)
