royans

A few weeks ago I wrote a small hack to use google to handle 404 errors. You can find that artcle here Using Google to handle website 404 errors Unfortunately even though it works, its not optimal. Here are the few drawbacks I noticed I was using Meta Redirects. Some bots didn't understand that very well Meta redirect generates a 302 (temporary move) instead of 301 (permanent) Some bots, browsers were refreshing the same page in an endless loop for some reason. So in frusteration I wrote another piece of code. This time I'm using google web-api to get my results internally, instead of forcing the user to go to the google website for the first best hit. Here is the code I'm using. Please remember to put in your google key in the right place before you try it out yourself. #!/usr/bin/perl use strict; use SOAP::Lite; my $request=$ENV{REQUEST_URI}; my $httphost=$ENV{HTTP_HOST}; my @found=(); my $foundtext=""; my $lookfor=&fix;($request); my $site="www.roya

Introduction: I heard about this only today, but seems like this is one of the most secret bugs which google is being hit with right now. Whats interesting is that this has been going on for a while. I saw references to similar problems made in posts made in 2003. Problem: If site A points to site B using meta-refresh/redirects in a certain way, google interprets it in such a way that site A has the same content as site B. Based on what I saw in different posts across the internet, site A doesn't need to have any replicated content hosted on it. It just needs a meta-refresh pointing to site B. This by itself is not the problem however, since the most popular site will still show up first on the google search pages. This becomes a problem if the redirect is initiated by a page which has a higher PR (Page Ranking) within google. So if site A somehow has higher PR, it could effectively hijack site B by abusing its PR ranking using this kind redirect to site B. Analysis: So there are