Search Engine Optimization Technical Tips

This page contains technical how-to information, tips and advice on how to adjust for server and design issues that may be negatively impacting your search engine optimization efforts. It has long been known (we admit that it may only be based upon coincidence at times) that certain server issues seem to impact search engine ranking and that when "repaired" the ranking significantly improves. This page discusses ways to address those that we feel are going to have a negative impact upon your ranking.

You have multiple domain names pointing to the same content.

Usually your first consideration for purchasing multiple domain names may be to cover your product category with similar names and possibly the purchase of commonly misspelled variations. Or you may just want to deprive your competition of some other nice domain names. But you own a bunch of them, and you have had each of them pointed to your main web site.

This is usually considered spam because you're trying to index multiple website domain names that point to the same physical content on the server. This is common where DNS services are used to "map" multiple sites to the same server files. Most search engines have the ability to save and check file size and the ability to save and check long text strings. They will notice duplicate content and only index one site while throwing the rest out.

How to correct this problem.

By using what we refer to as an IP-funnel you can have the domains go to your production site, but without the problems associated with duplicate data for each domain. Below are directions to correct the domain spam problem so that a search engine does not view your multiple sites as deceptive or misleading.

	Most domain services web sites (domain.com and most others) provide the ability to "point" or "forward" to another site.		The multiple domains will point to a feeder site that is hosted
The feeder index will include a "meta refresh" and a "no index" statement.	The feeder index file should have an "optimized" title, description, and keyword tag.		The Feeder Site is hosted and only contains an index file and a robots.txt file	Next, add a 301 Permanently Moved action to the Feeder Site that will redirect to the Main Site so that any links and status is passed. The feeder site will correctly redirect to your "real" site.

How to move a site to a new host

If you are moving your site to a new IP address or ISP this procedure will help minimize the downtime and confusion during DNS propagation.

Set up the DNS on your new host to point to your existing (old host) site first. This is an important first step. Now change the TLD (top level domain) information at your domain registrar to point to this new site DNS. Your old site should still show by either by IP or domain name. This step results in "propagation" which commonly takes 72 hours to update servers world-wide, so do not proceed with step 3 for about four days. Copy your existing site to your new site and validate that all files have transferred and the links work. After allowing 4 days for the DNS to be fully propagated, point your new DNS to your new site. Make sure that your old site mailboxes have been emptied before you change any DNS info at this time. Once this DNS change occurs you cannot get to your old mail. *If everything has been validated you should now also point the old DNS to your new site. This is a safety issue in case there is a lingering propagation error. Search Engine listings or bookmarked pages should transfer to your new site with a 301 redirect. After everything has been checked you should be able to delete your old site after a sufficient amount of time has passed (not more than 3 months). Note that Google does cache the old DNS address information and until they verify that the site has moved and store the new DNS information they may not visit your new site. The 301 will assist in this area. If you are moving from an IIS server to Linux (Apache) you should validate your formmail scripts, and any items that may not be cross platform compatible. If you are moving from Linux to IIS then your .htaccess file will not be compatible as well as the ability to CHMOD permissions. Validate all functions with your ISP Administrator (some of the following steps may need to be redone on your new server).

How to configure a 301 Permanently Moved action

In the above example the IP Funnel page should transfer to the production site via a 301 Permanently Moved action. A 301 is also useful in resolving typographical errors in links from other sites, as well as creating shortcuts. In UNIX you may also choose to use it to handle improper case specifications in URL's.

How to correct this problem.

In a UNIX/Linux (Apache) environment you would modify the .htaccess file to include the command:

RedirectPermanent /techtips.htm http://www.bruceclay.com/SEO-tech-tips/techtips.htm
RedirectPermanent / http://www.bruceclay.com/

In a Microsoft IIS environment you would normally open the control panel, select "Home Directory", and select "Redirection to a URL".

In both cases you would be well advised to include a custom 404 page. The 301 Moved action (where you do not specify a from page name as in the "/" example above) causes http://www.old-domain.com/xyz.htm to be sent to http://www.new-domain.com/xyz.htm -- specifically requiring that the page names match or a 404 will result. It is possible to intercept and alter the 404 to be a 301 thru programming in IIS or Apache.

How to configure a 404 File Not Found action

In any case, you might have a case where the page name is invalid and instead of having a basic page displayed you would like to see a custom page (usually with some navigation). This is easily accomplished in all systems.

How to correct this problem.

In a UNIX/Linux (Apache) environment you would modify the .htaccess file to include the command(s):

ErrorDocument 404 /404.htm
ErrorDocument 403 /404.htm
ErrorDocument 401 /buynowpage.htm
----- Error codes appear below

In a Microsoft IIS environment you would normally right-click on the appropriate Web service icon in the IIS Management Console and select Properties. Select Custom Errors then select the 404 error, and then select Edit Properties. In the Message Type list select Edit URL being careful (!) to specify the error recovery page URL.

Tables are causing long navigation lists to be seen as the first content

Your site is developed in "tables" and by the time the search engines encounter your "main content" it is too far down the page for the spider to consider it important. Generally, the text at the top of the page is the more important text, and sometimes site design pushes the main body content hundreds of lines from the top of the page source file.

A normal web page usually has a header, a nav bar that is usually on the left side of the page, and the main content is on the right. The search engines usually look at many page attributes, i.e., title, description, and at least the first 200 words of your content after your opening <body> tag.  The engines do spider your whole page but if your nav bar lists many products, the search engine may not encounter your main body within the first 200 words.

How to correct this problem.

This technique is also known as the "table trick". We include our description as an example for our clients.

Most of the search engines will read a table a certain way.  They will find the opening <table> tag and look for the first "table row" <tr>.  They will begin to read each "data set" <td>"data"</td> inside the "table row" from left to right until they find the closing </tr> tag.  They will try to keep going until they find the closing </table> tag. They will continue until they have crawled the entire page. Your "main body content" is usually where you would have most of your keyword phrases and the "relevant" body copy that you would want the search engine to index.  Knowing that the spider will often try to figure out your "theme" within the first 200 words of your site you would want them to see the relevant text as soon as possible.  The table technique will "push" your left-side navigation (etcetera) bar down below your body content and "pull" up your body content so it will usually be within the first 200 words.

		Normal site without "table technique"	Normal site with "table technique"
View the page Before implementation When you "view source" the page is heavily commented.	In our example we used "includes" to show where most of your body content would normally be located			The most important part of the technique is to insert an "empty data set" right before your body content "include"	View the page After implementation When you "view source" the page is heavily commented.
The left nav may have many product links listed that would easily be over 200 words. Especially if all of the links are fully qualified.	When you look at the source you will notice that the body is below the nav bar	There are many variables to contend with.  We are assuming that your site header could be mostly pictures, <alt> tags and some navigation.  The first area that is usually content intensive is a text based nav bar. If your nav bar is javascript or flash based, you have a whole new set of concerns.	If your site header is mostly pictures and the table technique "data set" is empty. The second item that is read is really your "main content". Depending on your page architecture, this could take some thinking and major redesign work.	You will notice that the nav bar is down at the bottom of the page and the only visible difference is that your nav bar is slightly lower. A small price to pay for better ranking.

The site is frames-based -- What do I do?

Search engines are having increased problems with trying to spider a "frames based" site. We believe there will be continued problems and we STRONGLY recommend a redesign to a non-frames environment. Note that the URL included in the frames pages are being indexed instead of your invoking frames page, so if you include content from another site in your frames page you are not getting ANY credit for that content... you are simply causing the other site to get spidered. It does not help you in the least in this case. If the content is from your own site and you need to use frames then there is a solution that will help by re-establishing the frames environment for the site.

How to correct this problem.

In the interim, adding this to the top of each page included in a frame will result in having that page detect that it is being loaded outside of the frame and it will re-establish the frame around this page:

Server Side Include Tips

Your pages are .htm or .html and your server does not recognize your files when you're using SSI (server side includes). OR you are using SSI commands but you are afraid that the .shtml commands are harmful to your search engine optimization efforts. OR your site is entirely .html extensions, but you suddenly want to add SSI commands for tracking or promotional purposes.