Slash breaks relative URLs in 404 page

I’m not sure if it’s Netlify or Hugo related, but the 404 page can’t seem to resolve links correctly when a / is in the url: = ok = /test/ is prepended to all links inside the page, breaking the navigation and styles.

Any idea how to fix that?
Here is my repo with the 404.html layout and _redirects.

I opened an issue at Hugo two months ago but haven’t get a fix.

It seems I cannot edit the original post to update the links, so here they are: = ok = “/test/” is prepended to all links inside the page, breaking the navigation and styles.

Here is my repo/branch

Hi, Victor. This is happening because the links to the resources are relative links. For example:

<link rel="stylesheet" href="./main.css">

For the first URL ( the path is /test and this is in / so the relative path is /main.css. That is a valid path to an existing asset.

For the second URL ( the path is /test/. Because this is in /test/ the same relative URL now points to /test/main.css. This is not a valid path to an existing asset so a 404 occurs for that URL (which is

The solution for this is to make those paths absolute, instead of relative. For example:

<link rel="stylesheet" href="/main.css">

This change above (removing the “.” before “/main.css”) would cause both URLs to use a path of /main.css for this asset.

Regarding what to change in your Hugo configuration to make that happen, that a Hugo specific question and that I don’t know the answer to.

I suspect the solution (for that CCS file) is to change this here:

From this:

<link rel="stylesheet" href="{{ $mainCSS.RelPermalink }}">

to this:

<link rel="stylesheet" href="{{ $mainCSS.Permalink }}">

But I’m not a Hugo expert (I do like it though) so don’t quote me on that. :wink:

If it does work (or if you find a different solution) we’d love to know about it though.

If there are other questions about this, please let us know.

Thanks @luke for your answer.

Setting relativeURLs to false in the site configuration (while keeping .RelPermalink) solved the problem, but now I’ll have to check the URLs in content files.

glad it’s working :tada: