Will Google's crawler refuse to follow redirects when the difference between the redirected-from and redirected-to URLs is solely whether specific characters are percent-encoded or not? For example:
- www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+%28install+on+Linux+only%29
- www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux+only)
Both of these are, per the HTTP specs, valid and equivalent URIs, but our site's code always redirects to a "canonical" URL for each content page-- which in this case is the first URL listed.
Google clearly isn't indexing this page (in either URL variant). Neither of the URLs above show up when I search for "PDF Report Server (install on Linux only)".
Google webmaster tools reports a "redirect error" for the "decoded" variant of the URL: www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux+only)
Another problem is that we're currently using a 302 instead of a 301 redirect to handle canonicalization-- we're switching to 301s soon for canonicalizing redirects.
But I'm wondering if the 302 vs. 301 issue may be a red herring-- that the actual underlying issue may be that, in Google's eyes, we're redirecting a URL to itself since, per the HTTP specs, a perecent-encoded and non-percent-encoded URL should be treated the same by clients and servers.
I found a related thread here. It's not the same issue-- in their case the only difference between redirected URLs was the upper/lower case of the percent-encoded hex values. But it's suspiciously similar to our issue.
Finally, my question: Has anyone run into this percent-encoding-plus-redirect issue, and if so can you discuss how you worked around it? Did switching to a 301 fix it, or was more needed?
For workarounds beyond 301-ing, we're looking at a variety of options from using REL=CANONICAL and turning off redirection in this case, to modifying our escaping to turn off escaping of apostrophes, parentheses, and other not-usually-percent-escaped characters.
For long-term fixes, we're looking at:
- like this site does, using a numeric ID as a key, adding REL=CANONICAL to handle changes in SEO text after the title, and not doing any redirection
- like many blogs do, continuing to use the title as the canonical URL, continue redirecting, but switching all problematic characters with dashes so we don't have to worry about encoding/decoding
%28
and%29
in the address bar will just turn into(
and)
. In Opera, it's just the opposite. And had you needed a redirect, you would not need a canonical link. Canonical links are a last-resort. Google prefers you simple use a permanent redirect. You wouldn't ever need to use both.Has anyone run into...
yes, and my answer below did the trick. Loss of PR was a moot point, since the whole site was a re-write and the CMS swapped out. (and really after it was done it gained PR right back and then some because the CMS used SEO better.)