How to host a Hugo site on the Netlify CDN for free

Hosting a Hugo site on Netlify is free if it’s a personal website.

Ron Erdos • Updated July 26, 2022
Tested with Hugo version 0.101.0

In this tutorial, I’ll show you how to get your Hugo site hosted on Netlify.

Hosting is free for personal websites.

Let’s get started.

How to set up a Hugo site on Netlify hosting

If you haven’t already, you can sign up for Netlify here.

I don’t make any money from this; I just recommend the tools and services I think are the best.

Step 2: Add your domain name to Netlify

2a) Log in to your Netlify account if you haven’t already.

2b) Head to the “Domains” tab.

2c) Click the “Add or register domain” button:

2d) Add your domain name (or intended domain name—you can have Netlify purchase it for you).

2e) Hit the green “Verify” button:

If you already own your domain, you’ll see the screen below. (If you don’t own your domain, and want Netlify to purchase it for you, this tutorial doesn’t cover that yet. I may add it in the future.)

2f) Hit the green “Yes, add domain” button:

Next, you’ll see the screen below.

There’s no need at this stage to add DNS records.

You can always do this later, for example, if you want to set up MX records for email.

However, for now:

2g) Hit “Continue”

Finally, you’ll see the screen below. Keep it open in your browser as you’ll need it in a second.

Step 3: Log in to your domain provider and update the nameservers

Every domain name provider’s interface is generally a bit different, so I won’t provide a screenshot here.

However, it should be relatively straightforward to find out how to change the nameservers for your domains at your provider (e.g. NameCheap, GoDaddy, Zuver etc).

You’ll need to update the nameservers to the ones you got in the previous step of this tutorial (which may be different to the above screenshot).

Once you have made these changes, it may take several hours to propagate through the DNS network.

Step 4: Deploy your site to Netlify

While you’re waiting for the nameserver changes you made in Step 3 to propagate, you may want to deploy your site to Netlify from your GitHub, GitLab or Bitbucket account. Here’s how to do that:

a) Head to the “Sites” tab

b) Hit “New site from Git”

You’ll see the screen below.

c) Choose your Git provider (GitHub, GitLab or Bitbucket)

d) You’ll then be asked to sign in to your Git provider via a pop up window (not shown here).

I use GitHub so the rest of this tutorial will focus on that. It should be pretty similar for GitLab or Bitbucket, though.

e) You can then choose the repository containing your Hugo site.

f) If you don’t see the repo in the list, you’ll need to configure the Netlify app in your Git provider (e.g. GitHub). You can click the green text link named “Configure the Netlify app on GitHub” to do so.

g) Choose your branch (if not master).

h) Specify the Hugo build command (I use hugo without any flags).

i) Reference the location of the Hugo rendered HTML files (this will generally be public).

j) Hit “Deploy” and you’re done! Once your DNS changes have propagated, your site will be live on Netlify.

Compression is automatic with Netlify

You don’t need to do anything to enable asset compression with Netlify. In Netlify’s own words:

It just works.

That phrase has become immortal, it seems.

Depending on the asset type (HTML, CSS, JS, SVG etc), Netlify uses either gzip or Brotli compression.

For HTML, CSS and JavaScript, Netlify uses Brotli compression rather than gzip.

Here’s why.

Quoting an Akamai study (which appears to have since been removed), Netlify states:

JavaScript files compressed with Brotli are 14% smaller than gzip.
HTML files are 21% smaller than gzip.
CSS files are 17% smaller than gzip.

That’s good enough for me! Brotli compression is accepted by pretty much all browsers.

For SVG files, Netlify uses gzip compression.

I confirmed this by testing my own site.

When I used Developer Tools to inspect the MoonBooth homepage in Microsoft Edge—using an InPrivate window to avoid the effect of browser extensions—I noticed that:

The HTML document was compressed with Brotli
The CSS stylesheet was also compressed with Brotli
The logo.svg and planets.svg files were compressed with gzip
The favicon.svg was not compressed at all (at 462 bytes, perhaps it would have been made larger by doing so due to the presence of the content-encoding header).

Pingdom fails to recognise Brotli

An interesting fact I discovered recently is that one of the most well-known speed tests—Pingdom—does not recognise Brotli compression and thus marks you down. This is not an issue for SEO—as touched on above, Chrome and Chromium browsers such as Microsoft Edge, Opera and Brave do accept Brotli compression, and in fact, it was developed at Google! If anyone at Pingdom is reading this, I’d encourage you to add Brotli compression to your speed check.

How to 301 redirect your default Netlify subdomain to your primary domain

When you first host a site on Netlify, your site will automatically be published on a Netlify subdomain of the form example.netlify.app.

You can’t eliminate this Netlify subdomain (although you can rename it in the UI). What you can do—and what I recommend you do from an SEO perspective—is 301 redirect it to your primary domain.

The only way to do this is in your /static/_redirects file. When I tried to put this redirect in my /netlify.toml file, it didn’t work. Note: I do keep all my other redirects—for example, if I combine two blog posts—in netlify.toml, and they work just fine.

So, in /static/_redirects, add this:

# Redirect default Netlify subdomain to primary domain
https://example.netlify.app/* https://example.com/:splat 301!

Some points on the above:

Obviously you would change example.netlify.app to match your Netlify subdomain; similarly, you would change https://example.com to match your primary domain.
The /* and /:splat you see above work together to create a wildcard redirect. So example.netlify.app/my-awesome-blog-post/ will 301 redirect to example.com/my-awesome-blog-post/, and so forth for every piece of content (including the home page).
Make sure you use the exclamation mark on the end of the 301, as that is how Netlify forces redirects even when the original file (at example.netlify.app/*) exists.
I recommend a 301 redirect, as per the code sample above, unless you have a very good reason to use a 302 redirect.
You don’t need to handle the non-https version of the .app Netlify subdomain (or the old .com format if you’re a longstanding Netlify user), as Netlify 301 redirects those to the https version of the .app subdomain automatically.