How not to specify URL site?

Good afternoon. Can I as baseURL specify the value “/”? I it is important to make sure that the site was not attached to a domain. How to do it?

In your site’s config.toml and config.yml, respectively:

baseurl = "/"


baseurl: "/"

I believe that the default value when running hugo server is actually the full localhost:1313/ with the closing /, so this might (not sure of your end goal) help keep consistency between your dev and prod environments. That said, make sure you look into the relURL and absURL functions, since I’m starting to think this is a better practice overall for your templating, especially if you’re creating themes :smile:

“/” is not a valid baseURL. It may work, but may have undefined behavior in some scenarios (the relativeURL may not be happy, relURL / absURL may not be happy).

If you want relative URLs then use relative URLs in your templates.


Then I want to make this clearer in the docs.

Here’s why, for anyone interested:

In a template for a site with a configured baseurl = "", running locally the following will work…

<link rel="stylesheet" href="{{.Site.BaseURL}}css/style.css">

Because, at least from what I remember a couple versions ago, the local server includes the trailing slash, as follows:

<link rel="stylesheet" href="http://localhost:1313/css/style.css">

However, using the example (or even leaving the baseurl field empty [baseurl = ""]) in the config would create the following at build:

<link rel="stylesheet" href="http://mysite.comcss/style.css">

Which breaks for obvious reasons. As I mentioned already, using relURL and absURL functions are a best practice, especially in the context of themes, but I’d like to make this clearer in the docs.

I don’t feel like I’ve seen this a lot lately, but there was certainly confusion about it in the past and in my own experience starting Hugo…if my memory serves.

For the docs, never use that manual concatenation, because it can never handle the subtle differences in baseURL properly.

And we

  • Cannot add any more magic to “fix” baseURL because of the above example
  • We cannot add any validation of baseURL because of the many variants in the wild.



  • relURL or relLangURL for relative URLs
  • absURL or absLangURL for absolute URLS

If you use the relativeURLs setting, you basically have to use all relative URLs in the templates.

You may try to use “/” or some other non-URL value in baseURL, but you are basically on your own, so do not file any issue on the issue tracker if “something doesn1’t work”.


[EDIT]: Forgot about the warning in the console re: menus and BaseURL…hmmm…disregard.

I think that’s all I needed…this should be clarified for users, so I’m thinking that really the only purpose, at least moving forward, for the baseurl field in the config is to define the full base URL of your website for deployment purposes…and that referring to it specifically in templates (or doing something similar to {{$base := .Site.BaseURL}} is more or less a bad idea…?

1 Like
  1. I think an URL, if not having some kind of relative context, is always absolute, see
  2. There could be use cases for handling the BaseURL directly, but not for creating references to `CSS´ and other resources that need an absolute URL.

The only thing that’s springing to mind for me is

<link rel="dns-prefetch" href="{{ .Site.BaseURL }}">
 <link rel="preconnect" href="{{ .Site.BaseURL }}">

But then maybe not if the end user isn’t putting the Hugo site at the root. I’m sure there are others, but it is almost 4am here in Chicago, so I’m not at 100% :smile:

<link rel="dns-prefetch" href="{{ "/" | absURL }}">
<link rel="dns-prefetch" href="{{ "/" | relURL }}">

I don’t have a Wikipedia article on this, so I hope you regard the WC3 as an equally scholarly resource:

The dns-prefetch link relation type is used to indicate an origin that will be used to fetch required resources, and that the user agent should resolve as early as possible.

What am I missing if I’m thinking that your relURL example doesn’t fit here?

You are right … I didn’t know what dns-prefetch was …