There seems to be some debate as to whether there is an actual SEO penalty to using spaces or the encoded %20 in urls. I’ve spent some time researching the matter and I wasn’t able to come away with any conclusive evidence one way or the other. However, when a client wants a site with no spaces or %20 in the urls that is in itself a deciding factor.
Apparently my client and I aren’t the only ones that ran into this problem, and perhaps I wasn’t the only one to come up with this solution, but I didn’t find it posted anywhere else on the internet, so I am going to post it here.
Ok, so views has an option under the argument section that says “Transform spaces to dashes in URL”. At first this sounds like the right direction, but in fact it isn’t, and as of the date of this posting it is acknowledged on the views issue queue that this option doesn’t work. The reason is simple: by the time the argument gets to views the url is already created. Views could technically do a redirect on the page load, but it’s doubtful that this would be a clean solution, and it wouldn’t really help the SEO side of things if Google does in fact prefer dashes to spaces (again this is a debatable question).
Really what is needed is exactly the opposite, that is views needs an option to convert dashes into spaces. This way you can have links that have dashes or underscores and views will convert the dashes or underscores to spaces.
As it turns out there is a way to do this and it only takes two lines of code. Under the “Validator Options” for the argument in question choose “PHP code” from the drop down. Then in the text area provided enter the following code:
$handler->argument = str_replace(‘_’, ‘ ‘, $argument);
Now what this does is it takes the incoming argument, which in my site was a multi-word taxonomy term for some views and a node title for other views and it switches out the underscore for a space before handing it to views for processing.
IMPORTANT: Don’t use hyphens in the argument replacement (-) unless you are absolutely sure that your terms will not have any natural hyphens. Underscores are never used in normal words, so they make a safe space replacement.
Now the only trick is to switch out underscores for all the links that are headed to that page. This is fairly easy if you have control of the code. In my particular case the menu items were created with custom views, so I just used this basic pattern for the links:
$path = str_replace(‘ ‘, ‘_’, $path);
And Voila. A simple workaround for the issue. Hopefully at some point views will fix the bug, but don’t hold your breath, it’s been on the issue queue since 2008.