Quick and Dirty Redirect of a Jekyll Blog to Its New Domain
Having recently moved this blog from its previous domain to the current1 location, I was on the lookout for a way of easily redirecting all pages of the old instance to their equivalents of the new one, thus avoiding breaking any links.
To achieve this, I didn’t want to install a plugin, futz with the web server configuration, or change the DNS settings of the old domain – partially because I’m lazy and my blog isn’t nearly popular enough to warrant a truly robust solution (see the caveats at the bottom of this post). There’s also my preference for solutions that work universally – for Jekyll sites that one might want to move off of, say, GitHub Pages, where you’d only have access to the DNS settings if using a custom domain, and zero control of the web server configuration or Jekyll plugins no matter what.
At least for my purposes – a low-traffic blog that’s only updated a couple of times each year – the approach outlined below successfully walks the ride line between simplicity and elegance.
Here’s how!
Create a snippet _includes_/domain_redirect.html
with the following code which, if a site-wide configuration option has a non-empty value, redirects visitors via <meta http-equiv="refresh" …>
and robots with <link rel="canonical" …>
:
{% if site.domain_redirect %}
<meta http-equiv="refresh" content="0; url={{ site.domain_redirect }}{{ page.url }}">
<link rel="canonical" href="{{ site.domain_redirect }}{{ page.url }}" />
{% endif %}
In the template2 that generates your site’s <head>
– depending on your theme, it might be resident at _includes/head.html
, _layouts/default.html
, or something similar – add the following line somewhere between <head>
and </head>
, ideally close to the top:
{% include domain_redirect.html %}
Finally, in your old site’s _config.yml
, specify the new root URL without a trailing slash:
domain_redirect: https://excessivelyadequate.com
If you ever want to disable the redirect in the future, just remove that line from your configuration again.
Caveats
Of course, a basic approach like this has a number of downsides:
- Performance will suffer a bit compared with lower-level redirects as the user’s browser needs to load at least a few packets worth of data before it encounters the relevant
<meta>
tag. Keeping your pages light, which is a good idea anyway, minimizes this problem. - It only works if the page structure remains unchanged between the old and new Jekyll sites, but that’s usually not an issue if you simply want to move an existing site.
- Static files aren’t redirected. Accomplishing this requires a webserver-level redirect or a DNS reconfiguration – besides, you’re probably referring to images and other media with relative paths anyway, so this likely won’t cause any issues for you.
- The all-important RSS feed isn’t redirected, either. In my view, that’s the main limitation of my approach – but the only reliable way to provide uninterrupted service to feed readers is the kind of DNS change mentioned previously. Web server redirects may or may not be followed depending on how well the feed reader is implemented. To remedy this problem, I recommend publishing a final post on the old Jekyll instance that points subscribers to the new site.
Despite these caveats, most search engines will follow this kind of redirect without any problems, and others might defer to the <link rel="canonical" …>
tag.