The problem: could not load this blog without the www. prefix

This blog is hosted on site44. This is a very convenient way of running a static website – simply update your static content in Dropbox and Site44 will serve it up as a site for you. It’s reasonably priced and I’ve been using it for various things for years.

One long-standing quirk has been that you have to specify the URL when setting up the site. I chose www.matthewstrawbridge.com, which meant that while you could browse to http://www.matthewstrawbridge.com or https://www.matthewstrawbridge.com and everything would work, omitting the www. prefix would just load Site44’s 404 error page:

Screenshot of 404

Note that part of the complication is that Site44 requires a CNAME record in your DNS to do the redirection, rather than simply having an A record pointing at your site.

See this snippet from their custom domain help page:

CNAME aliases do not apply to “naked” domains like example.com—they only apply to subdomains like www.example.com or blog.example.com. Site44 only supports subdomains; use “forwarding” (see below) to handle naked domains.

This is a record of how I solved this problem.

The solution: adding a CloudFlare redirect rule

CloudFlare is renowned for providing the infrastructure and know-how to keep large sites up and available online, with a good reputation for preventing denial-of-service (DOS) attacks. But alongside this commercial clout, they also offer a free plan which includes a DNS service.

There are three things necessary to get everything working.

1. A `CNAME` link from the custom domain to Site44

This was already present on my previous DNS host, and CloudFlare imported it and set it up automatically. This is a CNAME entry from www to site44. Once this is in place (and propagated) you can navigate to the site when using the www. prefix.

Note that this has the proxying option OFF, which seems to be necessary for Site44.

The CNAME entry is shown on the bottom line in this screenshot:

Screenshot of DNS settings

2. An `A` record entry for the top-level host

In theory this shouldn’t be necessary, but CloudFlare’s redirection rules for the top-level site (see next step) don’t seem to work without it.

This is the other record shown in the screenshot above; an A DNS record to the top-level site (you can just enter @ into the relevant box, and Cloudflare will fill in the host – in this case matthewstrawbridge.com – automatically.

The content that it’s redirecting to shouldn’t really matter, because the redirection rule we create will kick in before anything ends up at that IP address. I chose to use 192.0.2.1, which is a dummy address used in lots of examples.

Note that this record can have CloudFlare’s automatic proxying turned on (shown by the orange icon).

3. Create the redirection rule

Now we want any attempts to access the top-level host to be automatically redirected to the equivalent URLs with the www. prefix.

This was a bit more complex.

From the Cloudflare menu, select Rules > Redirect Rules. This is preferable to using page rules, which I understand to be deprecated.

Then you can create a redirection rule that looks like this:

Custom redirect rule

It uses a custom filter expression as follows:

when the hostname in the incoming request is matthewstrawbridge.com (rather than, say, www.matthewstrawbridge.com) then
respond with a permanent redirect (301 HTTP status code) to the alternative URL that you get by concatenating www.matthewstrawbridge.com with the rest of the path from the original URL (e.g. /some-article/) and preserving the query string (e.g. ?search=wibble) if there is one.

Conclusion

All this is a little bit more long-winded than I’d like, but at least it’s a one-off cost.

As always with DNS things, it can take a long time for the settings to propagate.

I guess the popular alternative these days for a technical blog such as this would be to host it on GitHub pages, but I’ve been happy with Site44 and this fixes the main niggle that I’ve had with it.