================================================
 access|control|action|   target file
------------------------------------------------
  spider            gets    <-- cloaked page
         \        /
           SWITCH
         /        \
   human            forwards to --> normal page
================================================

As you can see, search engine spiders and human visitors are treated differently when accessing a cloaked web site: while the search engine will be fed an optimized cloaked (or “phantom”) page, the human visitor will be redirected to a normal, human readable page.

This is effected by the SWITCH — a cgi program whose primary task it is to determine which type of visitor is accessing the site and to treat them accordingly. Note that the Switch will masquerade as an ordinary .html or .htm file, i.e. it will sport that extension, whereas in truth it is a cgi or Perl script hiding behind this file format. The reason for this is that search engines will not commonly accept submissions for files bearing a .cgi or .pl extension.

While the file name of the Switch (termed “keyword switch” for reasons to be outlined now) may well be “index.htm” or “index.html”, you will attain to greater flexibility by creating several files named “keyword1.htm”, “keyword2.htm”, “keyword3.htm” etc. respectively.

These would then be submitted to the search engines as URL “http://yourdomain.com/keyword1.htm”, etc. This is what one might term the “one switch per keyword” (1SPK) approach as used.

To understand the precise mechanics of this procedure, please bear in mind that keyword switches and cloaked or phantom pages will normally come in tandem: i.e. the switch file “keyword1.htm” will read the optimized phantom page “keyword1.html” (note the different file extensions!) to the spider, whereas the human visitor will be redirected to, say, “section1.html” which itself may or may not be related to the keyword in question. (Obviously, if it is not, this qualifies for spamming and may easily get you banned from search engine submission, which is why we can only advise against it.)

To illustrate this process, here's another diagram:

===================================================
target     |control|action|      served file
---------------------------------------------------
                     spider is fed <-- keyword.html
                    /
keyword.htm - SWITCH
                    \
                     human gets
                     redirected to  --> section.html
====================================================

There are another, fundamentally different approaches in which the Switch will, for example, redirect both the search engine spider and the human visitor to different pages each. Alternatively, both spiders and humans might be fed with relevant pages without being redirected. Finally, some cloaking programs will differentiate between different spiders and feed them individually optimized pages, e.g. one phantom page to the AltaVista spider, another phantom page to the Excite spider, etc. This can be termed the “one switch for all” (1S4A) approach.

All these different cloaking philosophies have their advantages and their drawbacks. Whereas the 1SPK approach outlined above is extremely flexible as it allows for unlimited fine-tuning, it does tend to blow up the number of files on your server considerably. As keyword switches and cloaked pages always come in tandem, optimizing your web site for, say, 50 keywords will imply generating a minimum of 100 pages (50 keyword switches + 50 phantom pages), possibly even 150, if you redirect human visitors to a different page for every keyword, though this will usually not be the case. E.g. you might optimize your site for keywords “widget”, “prime widgets” and “cheap widgets” search engine wise, whereas it might suffice to redirect all human visitors to one single “widget.html” page.

While storage space isn't such a serious problem anymore these days, the more so as a good switch file shouldn't be longer than appr. 2K. However, the administrative overhead can obviously be daunting.

The 1S4A approach reduces the number of keyword switches to just one, which may seem a lot more attractive because the administrative overhead induced should be less. However, there are some trade offs to be considered as well: a keyword switch catering to all site visitors will usually be significantly more voluminous and, hence, slower to load than the lean and mean 1SPK scripts. Moreover, if you want to retain high flexibility, you will have to use a program which allows for assignment of different phantom pages to various search engines — thereby hardly reducing administrative tasks at all.