Site Built With Previous Version Won't Build Properly

I’ve just hit this weird problem when trying to update one of my sites, which I haven’t made any changes to for about 6 months [so presumably it was built with an older version of Hugo].

If I run the old stylee hugo server --watch --renderToDisk command, the site seems to build OK, but certain elements like embedded fonts don’t render [I get a CORS error in the browser console:

Access to Font at 'https://madra.net/fonts/opensans.ttf' from origin 'http://localhost:1313' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:1313' is therefore not allowed access.

which is odd, as surely Hugo shouldn’t be looking for site elements such as fonts at the ‘production’ URL when building locally? I don’t get this error and embedded fonts display properly in another site with a very similar setup but which has been updated more recently.

Additionally, no changes I make to the page I’m working on are reflected when the site is rebuilt. Hugo detects the page has been updated and claims to have rebuilt the page, but the content doesn’t change

Change detected, rebuilding site
2018-02-07 19:01:10.792 +0000
Source changed "/Users/madra/Sites/madra.net/content/shop.md": CREATE
Total in 16 ms

If I use the newer stylee hugo server --disableFastRender then every page on the site apart from the index returns a 404 page not found error.

As with running hugo server --watch --renderToDisk above, making changes to the page triggers a rebuild and Hugo shows no error but the pages don’t get built - 404 for anything which isn’t the index page.

Change detected, rebuilding site
2018-02-07 19:13:20.793 +0000
Source changed "/Users/madra/Sites/madra.net/content/shop.md": CREATE
Total in 17 ms

This sounds very similar to a problem mentioned by @rickymetz in another thread and @billthefarmer also seems to have been afflicted with build errors using a newer version of Hugo

In the past, I’ve had the odd error and needed to make the odd code tweak, after an update to Hugo. But these were usually flagged up by the output from hugo server. In this case I’m getting no error from hugo server but the pages are either; not being updated or not being built at all --depending on which flag I use with the server command.

So, is there a breaking change in a recent update, affecting static pages, which I should be aware of? And, if so, how do I fix it?

Sorry. Forgot to mention. I’m on Hugo Static Site Generator v0.34 darwin/amd64 BuildDate:

…and updating to 0.36 gives me the same errors

That looks as if it could be related to my problem which was that I had a site index page called index.md. You mention an index page, possibly you need to rename it to _index.md, or if it is a site index to something else.

Cheers! --I should have read your thread all the way through.

That seems to have fixed the rendering problems [although not the font errors, but they should sort themselves out on upload to the live site].

I see the explanation given in your thread was:

I can’t say as that makes it any clearer, as I’ve not kept abreast of Hugo’s latest Page Bundle features but it would have been nice to have the server throw up some kind of error message --and nicer still for a new feature not to break [what must have been many people’s] existing site structure!

Thanks for your help.


REPLY to @bep’s post below, since he locked the thread [not very free-speech-friendly!]

OK. I accept that sometimes changes break stuff. I alluded to that in my previous post. But this was quite a nasty one.

It is hard to give error messages for this situation, as it is nearly impossible to separate from “correct behaviour”

Surely it’s not that difficult to check for the presence of an index.md file at the root of the site content folder and show a "You might want to rename that..." error? After updates, Hugo regularly warns me that certain functions have been renamed or are deprecated, why not a similar warning in this case?

The use of “index.md” pre Hugo 0.32 was not in widespread use

Really? Have you any figures to back that up?

It’s in use on all my Hugo sites -about half a dozen at last count [including a few I’ve built for clients, which I will likely be getting “My site is broken…” emails about, next time they try to update them.

And I’m sure I’m not the only one. Anyone who’s using Hugo to build a site which goes beyond a straightforward blog is likely have been using a static index page.

it was discussed for 6 months before release (I have checked) and clearly noted in the release notes

Well, having ‘been round the block’ a few times with Hugo, I don’t tend to visit the forum that often, as I can usually fix anything that breaks myself, so I missed that discussion.

I do however look at the release notes with every new version but [again, I presume I’m not alone in not in this] that tends to consist of reading the ‘headline items’, not every single word. And even, looking at them again today, I’m hard pushed to see any kind of warning that we will need to rename our index.md pages or our sites will break

Right down the bottom of the release notes page, in the ‘Notes’ section, I find

  • Images and other static resources in folders with “_index.md” will have its RelPermalink relative to its page.
  • Images and other static resources in or below “index.md” folders will have its RelPermalink relative to its page (respecting permalink settings etc.)
  • Content pages in or below “index.md” will not get their own URL, but will be part of the .Resources collection of its page.

I reckon you’d need to do a lot of reading between the lines and have advance knowledge of the new feature to take away from that anything which suggests breaking changes are afoot.


Site breakage is unfortunate but is sometime needed to get where we want.

It is hard to give error messages for this situation, as it is nearly impossible to separate from “correct behaviour”.

I have had this discussion before, but I will repeat:

  • The use of “index.md” pre Hugo 0.32 was not in widespread use
  • It was a workaround that had weird side-effects (naming conflicts)
  • Using it to identify bundles in Hugo 0.32 was an obvious choice. Having us make up some other keyword to avoid breaking some sites would have been an ugly hack. And it was discussed for 6 months before release (I have checked) and clearly noted in the release notes