gohugoio/hugo · error
%v failed to render pages: %w
Error message
%v failed to render pages: %w
What it means
This wraps the first error returned by any of Hugo's concurrent page-render workers for one site dimension (language/version). `s.resolveDimensionNames()` prefixes which site variant failed, and `%w` carries the underlying template-execution or output-writing error. It means the render phase for that site aborted after a worker reported a failure.
Source
Thrown at hugolib/site_render.go:118
}
}
return radix.WalkContinue, nil
},
}
if err := w.Walk(context.Background()); err != nil {
return err
}
close(pages)
wg.Wait()
close(results)
err := <-errs
if err != nil {
return fmt.Errorf("%v failed to render pages: %w", s.resolveDimensionNames(), err)
}
return nil
}
func pageRenderer(
ctx *siteRenderContext,
s *Site,
pages <-chan *pageState,
results chan<- error,
wg *sync.WaitGroup,
) {
defer wg.Done()
sendErr := func(err error) bool {
select {
case results <- err:
return true
case <-s.h.Done():View on GitHub ↗ (pinned to 8a468df065)
Solutions
- Read the wrapped error after the dimension name — it names the template file and line; fix that template or the page's front matter.
- Run `hugo -v` or `hugo --panicOnWarning` locally to reproduce and get the full error chain for the failing page.
- If it appeared after upgrading Hugo, check the release notes for removed template functions or layout-resolution changes and update the theme.
- Check the failing language/version prefix — if only one language fails, inspect that language's content and i18n files.
Example fix
<!-- before: layouts/page.html -->
{{ .Params.author.name }}
<!-- after -->
{{ with .Params.author }}{{ .name }}{{ end }} Defensive patterns
Strategy: try-catch
Try / catch
err := h.Build(hugolib.BuildCfg{})
if err != nil {
// wraps the underlying template/page error — unwrap for the root cause
log.Fatalf("site build failed: %v", err)
} Prevention
- Treat this as a wrapper: inspect the wrapped error (errors.Unwrap / %+v) for the failing template and page
- Run hugo with --printPathWarnings and verbose logging to localize the failing page
- Test template changes on a minimal site before full builds
- Keep templates free of nil-unsafe accesses (use `with`/`default`) so per-page rendering can't fail
When it happens
Trigger: During `hugo` / `hugo server` builds, in `Site.renderPages`: a `pageRenderer` goroutine fails executing a layout template (undefined function, nil pointer in template, bad partial), fails an output-format render, or fails writing to the destination filesystem; the first error from the `errs` channel is wrapped here.
Common situations: Template errors in `layouts/` (calling methods on nil `.Params` values, deprecated template funcs after a Hugo upgrade), themes incompatible with the current Hugo version, front matter missing fields a template dereferences, or disk-full/permission errors on the `public/` directory.
Related errors
- error building site: %w
- failed to transform template %q: %w
- failed to render shortcode: %w
- error copying static files: %w
- failed to compile cache buster %q: %w
AI-assisted analysis of gohugoio/hugo@8a468df065 (2026-07-31).
Data as JSON: /data/errors/13674bc60b6f1227.json.
Report an issue: GitHub ↗.