Relative Links

The WordPress Relative Link Conundrum

As a blog that runs on WordPress, this site is bound to the glorious options that are presented by this tool; but also many of the limitations. I’ve worked with WordPress in a number of ways, but one that seems to be most tricky is its internal linking. Out of the box, WordPress won’t offer you the ability to show internal elements (such as images) with a relative URL.

And, this seems to run counter to what Google suggests. In a recent post, Google sets forth a suggestion to “Use relative URLs for resources that reside on the same secure domain” and “Use protocol relative URLs for all other domains” Given these suggestions, not having relative links in WordPress had me thinking.

What are relative and protocol-relative URLs? These are links that are absent direct, specific location information. One example we could use is that of a simple image on our site.

The full, specific URL for this would be:

If we’re in the root domain and want to reference it in a relative manner, we might use (and sometimes without the leading forward slash):

If we were to link to this image from outside but use a protocol-relative URL, we might use (trying it in a browser just defaults to the file:// protocol):

There are a number of schools of thought about how useful relative URLs are, how fast they can be, and some take a hard line saying the practice is too unruly and should never, ever happen. On a growing site covered in relative URLs snaked through many directory levels, this could really be a mess. Coming back to WordPress, they’re pretty specific about not supporting this practice. All elements in WordPress use the full absolute URL (yes, there are plug-ins to circumvent this). You can just manually edit the text of a post, set relative URLs, and update – but this would be a real pain in the ass.

This makes Google’s suggestions about using relative URLs interesting. They are promoting the use of SSL on sites but must know that virtually every single WordPress-based site cannot comply with what they’re suggesting. Google generally penalizes sites that contain multiple copies of content anyway, so why would anyone want to run two copies (HTTP and HTTPS) of a site at the same time?

Beyond, a site’s transition period, I don’t see the use myself. Are there really any reasons to serve up non-encrypted versions of a page (or the same, encrypted content)? That makes Google suggestions more unusual.