Forum Moderators: buckworks & skibum

Message Too Old, No Replies

Parameters in landing URLs causing errors

Sometimes the URLs requested have been urlencoded

         

camden

11:10 am on May 29, 2008 (gmt 0)

10+ Year Member



Hello - and apologies for the length of the post!

We have adverts where the destination URL contains parameters, e.g.
http://www.example.com/products/page.php?bar=foo

This is what is entered and shown in the AdWords interface (aside from the anonymisation for this forum). I have seen our ads live and they work fine for me clicking through.

However, we have a number of 'URL encoded' versions of these URLs appearing in our site error logs. For the above URL, we sometimes see:

/products/page.php%3Fbar%3Dfoo

These URLs result in 404 not found errors. These requests also come from a large number of different hosts e.g.

eir234.internetdsl.tpnet.pl
ARennes-359-1-105-76.w90-49.abo.wanadoo.fr
CPE-60-231-203-156.sa.bigpond.net.au

and only occur when these adverts are active.

We are getting a number of clickthroughs that work correctly, but I'd estimate that about 30-40% result in these errors.

I am fully aware of Google's auto-tagging feature and can confirm that our website is fully capable of handling correctly formatted URL parameters.

The issue I have is that for a number of our visits, the initial URL requested is wrong. It appears to have been URL-encoded somewhere.

Some real examples from our logs may be helpful:

131.114.48.2 - - [28/May/2008:09:24:05 +0100] "GET /products/page.php?bar=foo&gclid=CN_kuZXiyJMCFRqH1QodVicWkg HTTP/1.1" 200 193854 "http://www.google.it/search?hl=it&q=foo&btnG=Cerca+con+Google&meta=" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Sgrunt¦V109¦301¦S1420136176¦dial; snprtz¦S27830700000656¦2600#Service Pack 2#2#5#1; .NET CLR 1.1.4322; InfoPath.2)"

80.232.176.130 - - [28/May/2008:10:39:17 +0100] "GET /products/page.php?bar=foo&gclid=CL6elv3yyJMCFQ2L1QodMFa5jw HTTP/1.1" 200 6681 "http://www.google.lv/search?hl=lv&q=foo&btnG=Google+mekl%C4%93%C5%A1ana&meta=" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

These are working requests - see the dynamic URL and that Google has correctly appended the autotagging parameters. Our website responds with a 200 OK response and the page is served perfectly.

Now look at these:

213.140.19.119 - - [28/May/2008:10:07:40 +0100] "GET /products/page.php%3Fbar%3Dfoo HTTP/1.1" 404 14180 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;1813)"

85.72.37.151 - - [28/May/2008:12:18:38 +0100] "GET /products/page.php%3Fbar%3Dfoo HTTP/1.1" 404 14138 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;1813)"

These are erroneous requests where the '?' has been converted to '%3F' and '=' to '%3D', i.e. they have been URL-encoded. Both of these result in a 404 error. This has nothing to do with our server as the requests are malformed in the first place - these are the first occurrences of these IP addresses in our log files. To prove my point that it's not a misconfigured webserver, even [google.co.uk...] doesn't work.

I note that for these, none of the auto-tagging parameters have been appended, nor is the referrer set. They are however, coming from a variety of different hosts (as mentioned above) and have only started occurring since I placed AdWords adverts with these destination URLs.

From this evidence, I therefore believe that there is a bug somewhere in the AdWords system. I am also concerned that we are paying for clicks that are sent to the wrong URLs and that potential customers are left disappointed.

I have contacted Google. Their initial response just told me to turn auto-tagging off - this clearly isn't the cause and is very useful to our analytics. Since I've gone back with the raw log data above, I'm yet to hear anything further.

Has anyone else experienced this?

Rehan

1:28 pm on May 29, 2008 (gmt 0)

10+ Year Member



It's caused by the AVG LinkScanner module. There was some discussion at [webmasterworld.com...]

camden

1:52 pm on May 29, 2008 (gmt 0)

10+ Year Member



Yes - that explains it. Thanks for pointing this out :)