Hugo deployment generates URLs to

I’m trying to deploy a Hugo site via Github. Some links to static resources work fine, while others keep pointing to… whereas the local build of my site is working perfectly fine.

The deployment as such works super smoothly. I just can’t figure out where these links are created, when my whole repository doesn’t contain a single instance of “”. My guess is somewhere in the Hugo engine? This would mean I’m probably missing some additional setting?

Here’s the relevant section of my config.toml:

################################# Default configuration ###################
baseURL = “
title = “WENGLEIN. Coaching & Capital”
theme = “meghna-hugo”

My netlify.toml:

publish = "public/"
command = "hugo --gc --minify"

HUGO_ENV = "production"

command = "hugo --gc --minify --enableGitInfo"

HUGO_ENV = "production"

command = "hugo --gc --minify --buildFuture -b $DEPLOY_PRIME_URL"


command = "hugo --gc --minify -b $DEPLOY_PRIME_URL"



Hi Mike!

At the first glance, this setting in your config looks wrong:

baseURL = “”

This will likely have the effect that all the permalinks in your site will point to this specific deploy.

About this URL

This url points to one of the many atomic deploys your site has. This url is useful to show people a specific state your site was in at one point in time. But it will never update. New deploys will get a url with a new id.

Why is this a wrong Hugo setting?

Hugo uses the baseURL setting to base all the permalinks on it. Those are generated whenever a layout calls .Permalink on something.
Most likely you don’t want all the links and asset urls in your site to point to a specific deploy, right?

How can you fix it?

Hugo accepts the following value:

baseURL = "/"

This means it should not put a domain into permalinks, but make sure to make all urls absolute. The browser will then use whatever domain you’re accessing the site with.

By the way, we just had a very similar case in another topic: Redirects in page not updating URL correctly when deploying from github

Hi Marcus,

thanks for your hint. I saw the post you mentioned and also some others suggesting different baseURL settings in similar contexts. I’ve tried several variations like “/” (as in your mention), but also “/public”, for example, which was often mentioned by people struggling with path issues, probably in confusion with netlify.toml publish = “public/” setting.

Fact is, whatever setting I use, the netlify build stubbornly reverts to, when the local build is working perfectly fine. In fact there isn’t a single mention of the term “” inside the complete local build directory. The term isn’t even mentioned anywhere in my whole git repository, so I suppose it must be dynamically injected during netlify build, probably due to some other setting missing or wrong.

Btw, I’ve found interesting that when switching between absURL and relURL in the Hugo template:

{{ range .Site.Params.plugins.css }}
	<link rel="stylesheet" href="{{ .link | absURL }}">
{{ end }}

the resulting difference is only honored in the local Hugo build:

Local Hugo build

<link rel="stylesheet" href="//localhost:1313/plugins/bootstrap/bootstrap.min.css">

<link rel="stylesheet" href="/plugins/bootstrap/bootstrap.min.css">

…which I think is the expected behavior.

Netlify Hugo build

absURL and relURL both result in:
<link rel=stylesheet href=>

I’m a little confused here as well.

I can see that the theme you’re using has this as part of its examplesite:
Might that be the issue?

There is very little I can do without looking in to your Repository honestly. Netlify does not inject any environment variable that could be related to this. Our docs list all of them

Have you tried executing just hugo locally and looking at the resulting files? What happens on Netlify is not far from that.

Solved. I completely missed your hint at the atomic URLs pointing to specific deployments. The problem has been solved by removing the ExampleSite from the theme folder (and thereby any redundant configuration files). I was simply looking at an outdated version…

Thanks again and sorry for my confusion!

1 Like