| 4:57 pm on Aug 6, 2006 (gmt 0)|
I just did two google searches: allinurl:& and allinurl:&
The first search returns zero results. The second search returns 672 million results, and every one of them has & in the uri, despite the fact that an explicit search generates zero results. So it looks to me that Google is right on top of this, and the two versions of the uri are clearly not seen as duplicates. Rather, everything seems to be mapped to the & version.
| 5:53 pm on Aug 6, 2006 (gmt 0)|
Thanks Tedster. This gives me the confidence to amend the URLs and go and get properly validated.
| 6:53 pm on Aug 6, 2006 (gmt 0)|
That might be an artifact of the allinurl: function. I agree that "&" and "&l:" are normally interchangeable, but they are distinct URLs that could theoretically produce different results. Like "www" and non-"www" domain addressing, for example.
| 8:50 pm on Aug 6, 2006 (gmt 0)|
I must admit I haven't experienced any problems with the XML sitemap, which forces you to use & even though the website in question (until today) used '&' in the querystring.
Naturally I was nervous when going ahead and changing all the links to & today.
I can only cross my fingers and hope.
Does anyone else have any experience or thoughts about this?
| 10:25 pm on Aug 6, 2006 (gmt 0)|
Links with & are fine on a browser for sure. The browser knows to request a URL with just an & in it from the webserver, and not to try to find a character to draw on the screen called &productid; or &pagenumber; or something.
Look in your raw log files and see that even though the link has & in it, that the browser requests a URL as if it just has a & when the request hits the server.
| 7:24 am on Aug 7, 2006 (gmt 0)|
Good thinking. I'll go and have a look at my logs to confirm this.
| 7:27 am on Aug 7, 2006 (gmt 0)|
You're absolutely right. My log files confirm this. I can now rest easy.
Thanks to everyone for your help.