Google site map issues when URL contains %3A

Google is not properly following site map URLs containing a %3A

[KenB]

I've discovered that Google's bots seem to be unable to properly follow URLs that encode colons (':') as %3A. It seems that Google insists on replacing the '%3A' with a ':' before following the link. This creates concatenation problems as I'm found other cases where links could not be properly followed by others if they use a ':' instead of '%3A'.

For example if the urlencoded URL http://example.com/foo/widgets%3A%20blue.html was in a site map, Google would follow it as http://example.com/foo/widgets:%20blue.html.

In order to prevent duplicate content penalties and in an effort to try and concatenate all pages to a single page I had coded a 301 redirect from URI requests containing ':' to URIs using '%3A'. This threw Google into a circular redirect as Google's bot would still make its request using ':'.

My method for dealing with this issue has been to stop redirecting requests with URIs containing ':' to URIs using '%3A' and instead using the following in my HTML header:

<link rel="canonical" href="http://example.com/foo/widgets%3A%20blue.html">

Where the URL above is replaced with a properly urlencoded reference for the page in question.

[goodroi]

nice tip and a good brainteaser for the next pubcon :)

[KenB]

Good brain teaser for Pubcon maybe, but right now Webmaster tools (WMT) is throwing 350 not followed followed errors due to googlebot's inability to follow my redirects. :(

Now I have to wait a week or two for those errors to clear themselves out of my WMT crawl error log. grrrr....

[jdMorgan]

The take-home lesson here is to avoid "special characters" in the URL-path-part of a URL. You can use these special characters more freely in the query string part (always-encoded if need be), but the URL-path-part has many more restrictions [tools.ietf.org].

Like it or not we are *not* free to use 'just any' characters anywhere we want in URIs.

Jim

[KenB]

This is a really old part of my site. Basically it is using some rewrite rules to convert the URL into a query string. For instance behind the scenes, http://example.com/foo/widgets%3A%20blue.html is handled as http://example.com/index.html?foo=widgets%3A%20blue

It is actually a chemical database, with each chemical name being the "filename". This lead to some really messed up file names, but like I said this section of my website is almost ten years old so there is a limit to what I can do to fix things without taking some serious SERP hits.

Remember way back when I added this section of my site, query strings weren't treated as nicely by search engines as were "real" web pages so it was important to rewrite queries into the main URI. Even today there is debate whether one should rewrite queries into the main URI.

[eeek]

Basically it is using some rewrite rules to convert the URL into a query string

Have you considered using pathinfo instead of a query string?

[KenB]

Pathinfo wouldn't resolve my stupid encoded character issue and the query strings work just fine. They are hidden from users since I'm using RewriteRule and any changes to the design of the site in this matter would be drastic beyond measure.

As they say, don't fix what ain't broke. The stupid %3A issue was a break that had to be fixed, but that wasn't a RewriteRule problem.

[speedshopping]

Hi,

We had 110,000 keywords that looked like this:

www.domain.com/keyword A/

You will notice it has a space within the keyword part of the URL.

After noticing recently in WMT that Google had started to have problems with the spaces (although it had managed to index 70,000) we changed the format to:

www.domain.com/keyword%20A/

i.e. replacing a space with a %20

Since doing this we have noticed in WMT that in just over 72 hours the indexed URLs has gone from 79,000 to 30,000!

Is Google treating the URLs as being different?

Can anyone help us?

Regards,
Wesiwyg

[dstiles]

Spaces in URLs is just asking for trouble. Ditto certain symbols. Use hyphens or underlines.