Page Cloaking - To Cloak or Not to Cloak
Page cloaking can broadly be defined as a technique used to deliver different web pages under different circumstances. There are two primary reasons that people use page cloaking:
i) It allows them to create a separate optimized page for each search engine and another page which is aesthetically pleasing and designed for their human visitors. When a search engine spider visits a site, the page which has been optimized for that search engine is delivered to it. When a human visits a site, the page which was designed for the human visitors is shown. The primary benefit of doing this is that the human visitors don't need to be shown the pages which have been optimized for the search engines, because the pages which are meant for the search engines may not be aesthetically pleasing, and may contain an over-repetition of keywords.
ii) It allows them to hide the source code of the optimized pages that they have created, and hence prevents their competitors from being able to copy the source code.
Page cloaking is implemented by using some specialized cloaking scripts. A cloaking script is installed on the server, which detects whether it is a search engine or a human being that is requesting a page. If a search engine is requesting a page, the cloaking script delivers the page which has been optimized for that search engine. If a human being is requesting the page, the cloaking script delivers the page which has been designed for humans.
There are two primary ways by which the cloaking script can detect whether a search engine or a human being is visiting a site:
i) The first and simplest way is by checking the User-Agent variable. Each time anyone (be it a search engine spider or a browser being operated by a human) requests a page from a site, it reports an User-Agent name to the site. Generally, if a search engine spider requests a page, the User-Agent variable contains the name of the search engine. Hence, if the cloaking script detects that the User-Agent variable contains a name of a search engine, it delivers the page which has been optimized for that search engine. If the cloaking script does not detect the name of a search engine in the User-Agent variable, it assumes that the request has been made by a human being and delivers the page which was designed for human beings.
However, while this is the simplest way to implement a cloaking script, it is also the least safe. It is pretty easy to fake the User-Agent variable, and hence, someone who wants to see the optimized pages that are being delivered to different search engines can easily do so.
ii) The second and more complicated way is to use I.P. (Internet Protocol) based cloaking. This involves the use of an I.P. database which contains a list of the I.P. addresses of all known search engine spiders. When a visitor (a search engine or a human) requests a page, the cloaking script checks the I.P. address of the visitor. If the I.P. address is present in the I.P. database, the cloaking script knows that the visitor is a search engine and delivers the page optimized for that search engine. If the I.P. address is not present in the I.P. database, the cloaking script assumes that a human has requested the page, and delivers the page which is meant for human visitors.
Although more complicated than User-Agent based cloaking, I.P. based cloaking is more reliable and safe because it is very difficult to fake I.P. addresses.
Now that you have an idea of what cloaking is all about and how it is implemented, the question arises as to whether you should use page cloaking. The one word answer is "NO". The reason is simple: the search engines don't like it, and will probably ban your site from their index if they find out that your site uses cloaking. The reason that the search engines don't like page cloaking is that it prevents them from being able to spider the same page that their visitors are going to see. And if the search engines are prevented from doing so, they cannot be confident of delivering relevant results to their users. In the past, many people have created optimized pages for some highly popular keywords and then used page cloaking to take people to their real sites which had nothing to do with those keywords. If the search engines allowed this to happen, they would suffer because their users would abandon them and go to another search engine which produced more relevant results.
Of course, a question arises as to how a search engine can detect whether or not a site uses page cloaking. There are three ways by which it can do so:
i) If the site uses User-Agent cloaking, the search engines can simply send a spider to a site which does not report the name of the search engine in the User-Agent variable. If the search engine sees that the page delivered to this spider is different from the page which is delivered to a spider which reports the name of the search engine in the User-Agent variable, it knows that the site has used page cloaking.
ii) If the site uses I.P. based cloaking, the search engines can send a spider from a different I.P. address than any I.P. address which it has used previously. Since this is a new I.P. address, the I.P. database that is used for cloaking will not contain this address. If the search engine detects that the page delivered to the spider with the new I.P. address is different from the page that is delivered to a spider with a known I.P. address, it knows that the site has used page cloaking.
iii) A human representative from a search engine may visit a site to see whether it uses cloaking. If she sees that the page which is delivered to her is different from the one being delivered to the search engine spider, she knows that the site uses cloaking.
Hence, when it comes to page cloaking, my advice is simple: don't even think about using it
Article by Sumantra Roy. Sumantra is one of the most respected and recognized search engine positioning specialists on the Internet. For more articles on search engine placement, subscribe to his 1st Search Ranking Newsletter by sending a blank email to 1stSearchRanking.999.99@optinpro.com or by going to www.1stSearchRanking.net
More than 350 million English language Web searches are conducted every day. Is your site well-ranked in the results? In Chapter 1 of The Search Engine Marketing Kit, Dan explains the essential background you'll need to know before you can efficiently and intelligently undertake search engine marketing.
The decision to use an open source license can plunge Web professionals into a mire of patent, trademark and copyright law. In this expose, Blane speaks with Eric Raymond, cofounder of the Open Source Initiative, in an effort to untangle the complexities of open source licensing.
2004 was a big year for the open source movement. In his detailed round-up, Blane considers key developments, from the rebirth of Novell to the new GNU... and everything in between!
The Apple Xserve launched in 2002 without much fanfare in the server marketplace. Two years later, the platform has gained more steam than even avid Apple watchers had anticipated. Blane explains what the fuss is all about in this detailed expose.
Are you having relationship problems? Some of your clients are time-drains, don't pay, require constant communication... and these guys distract you from the profitable clients! Andrew provides a practical strategy to identify and enhance relationships with your best clients - and resolve your issues with the others!
Isolate objects. Extract objects. Cut out an image. Remove a background. Whatever you call it, the separation of objects from the background of an image is an essential skill for Web designers. Here, Corrie explains 5 masking techniques, highlights their pros and cons, and identifies the applications to which each is suited.
Countless freelancers want to build their businesses into bigger organizations, but don't know where to start. Andrew's step-by-step guide to taking the leap towards sustainable business provides the answers.
The lack of decent Apache security titles prompted Tony Mobily to pen Hardening Apache, the new, definitive reference on the subject. Here, Blane talks with Tony about the technology, the book, and the future...
Amazon Web Services can push fresh content to your site, and help you make some cash in the process. Use ASP.NET with the Amazon Web Service to query the company's catalogue and return results to your site -- Philip's practical tutorial shows how.
Cool XP-style icons are within your capabilities! Corrie creates vector graphics to replicate XP icons - and design her own - in the last of her 3-part series on vector graphics.
Products overcome the fundamental flaw of services: they aren't limited by time. Augment your service offering with resalable products and watch your profits grow. Andrew explains why - and how - to do it!
Create your very own Flash Panel to control the rotation of Movie Clips on the stage using standard Flash MX 2004 components, a hefty sprinkling of ActionScript and some tips and tricks -- Steve shows how it's done!
SQL Server 2005 goes beyond T-SQL to provide the full power and breadth of functionality available in the .NET Framework. In this hands-on tutorial, Philip shows how to build stored procedures that host CLR-code using SQL Server 2005 Express.
eZ publish fans and newbies alike will benefit from 'Learning eZ publish 3: Building Content Management Solutions'. Penned by a selection of experienced, high-profile members of the eZ publish community, this well-organised, practical book fills the holes left by the online documentation.
What's it really like to migrate your site from MySQL 3 to MySQL 4? Why would you do it, and what are the pitfalls? Tyson Lowery of SimDynasty.com answers these questions and more in this candid interview.
hi mom
|
