Holy Crap, Google Just Blocked My Site!

Last Updated on Thursday, 24 January 2013 11:53 Written by Brent Riggs Thursday, 24 January 2013 11:53

So I’m kicked back one day enjoying a relaxing and peaceful afternoon when all of a sudden I get an email that one of the primary pages has been blocked by Google. And it’s on the website that funds my entire business .

Panic would be an understatement.

The site has thousands of users and the emails start flooding in from irate users. I have no clue why my page had been blocked or “suspected of malware”. I dove into the page code only to be more puzzled because it was a simple page:

• A blog reader clicks on a link
• That link goes to an intermediate page
• A “click counter” is ticked off in the database
• The reader is redirected to the destination URL

About 10 lines of code and I’m getting an ulcer trying to figure out how this could be hacked or malicious. The code uses an “id” from the querystring. No problem… the code checks to make sure the “id” has not been tampered with. It also checks for any additional variables that have been added.  If the “id” doesn’t exist in the database, nothing happens.  Fool proof… which makes the whole thing maddening.

I just cannot figure out why Google is blocking me. Yep, that’s my site in the graphic below (www.linkytools.com)… talk about the kiss of death. Bloggers will spread that kind of information like wildfire:

After couple of valium, some logic set in: it must be the target site being redirected to because I know the “malware” is not on mine. So why is “www.linkytools.com” getting the bad wrap by Google?

Using the “id” in the offending link from my click-counting page, I got in my database and found the destination URL.  Imagine my relief when I visited that URL and found out I was right. THEY were problem, not Linky Tools:

I could rest easy that is was not my site but I was still left with how to fix things where 1) the click is tracked, 2) the redirect occurs and 3) if a bad site is encountered, Linky Tools is not listed as the culprit.  I had several options for redirecting in my .NET environment:

• Response.redirect – would not fix the “blame Linky Tools” issue and it’s not a permanent redirect so the end users don’t get any link love
• Response.PermanentRedirect – users get credit for the link in search engines and ranking but does not solve the “blame Linky Tools for the malware” problem
• HTML Meta-refresh – solves the bad site message but gives no link love (not a permanent redirect)

The solution was using the response headers.  The following code is not .NET or VB peculiar. All the webdev platforms can use some version of this; it is the process of sending page headers to the final HTML output:

• Response.Status = “301 Moved Permanently”
• Response.AddHeader(“Location”, “http://” & whateveryoururlis)
• Response.End()

Send these headers to your page when it loads. The “Status” takes care of making the redirection permanent so your end users get the linking credit they crave from search engines. “AddHeader” allows you to add the redirection (“Location”) and the URL to send the page to.  ”End” stops any additional processing.

Works perfect.  Using this method, I don’ t have to worry about anything on the hundreds of thousands of destination URLs in my database causing me another Google-banned-me-coronary-arrest.  I can’t risk having any more episodes of Judge Judy interrupted like that.