Alright, let’s get our hands dirty. You’ve hit that point, haven’t you? The point where running hugo server feels less like a build step and more like you’ve just asked your laptop to calculate every prime number. A site with thousands of pages will do that. It’s not Hugo’s fault; it’s just math. But we’re not here to complain about math, we’re here to cheat at it.

The core strategy is brutally simple: build less stuff. Hugo is wonderfully, blissfully literal. It will happily build every single page it can find, regardless of whether you need it right now. Your job is to tell it what to ignore.

Pruning the Content Tree with _build

The most surgical tool in our arsenal is the _build front matter parameter. This little gem tells Hugo’s renderer to just… skip things. It’s like a “Do Not Disturb” sign for your content. The two most useful values are list and never.

Use list for pages you need to exist in a section listing (like a blog roll) but don’t need their own dedicated, rendered page. Think of category or tag pages. Do you really need a standalone page at /categories/technology/ that just lists posts? Probably not. You just need that list to be available for a sidebar. list is your answer.

Use never for content that should be completely ignored by the build process. This is perfect for legacy content, outdated versions, or experimental pages you’re not ready to delete from your repo but absolutely don’t want published.

# content/old-site-migration/obsolete-page.md
---
title: "Our Old PHP Site (Circa 2005)"
_build:
  list: false
  render: never
publishDate: 2005-06-15
---
This page is for archival purposes only. Hugo, please ignore this.

Why this works: Hugo’s build process checks this parameter very early, saving the cycles it would have spent on templating and writing the file to disk. It’s a direct off-switch.

Leveraging Sections for Strategic Builds

Hugo’s sections (the top-level directories in your content folder) aren’t just for organization; they’re leverage. You can target commands to specific sections, which is a godsend for large sites.

The classic move is to work on a specific section without building the entire, multi-thousand-page site every time. Combine this with the --disableFastRender flag to get a clean, full build of just that part of the tree.

# Build and serve only the content in the 'blog' section
hugo server --contentDir content --disableFastRender --navigateToChanged

# The --navigateToChanged flag is pure genius, by the way.
# It automatically opens the edited page in your browser. Someone at Hugo HQ was having a good day.

This is a game-changer for content creation. You can write and preview a new blog post instantly, even if your main site has 10,000 product pages.

Exposing Drafts: A Necessary Evil (And How to Contain It)

We all use draft: true in our front matter. But during active development, you need to see them. The problem? Running hugo server -D builds every single draft across your entire site. On a large site, this can be catastrophic for build times, especially if you have a lot of old, forgotten drafts lying around.

The solution is to be brutally minimalist. Only put drafts in the specific section you’re currently working on. For everything else, use _build: never. This turns the nuclear option of -D into a precise tool.

Better yet, use the --contentDir flag to isolate your active work. I have a separate content-dev directory I use only for things I’m actively writing. My main content dir stays clean.

# Work on a new section in isolation
hugo server --contentDir content-dev -D

This way, -D only ever builds the few drafts I’m actually working on, not every half-baked idea I’ve had since 2018.

The Golden Rule: The Build Timer is Your Friend

Never fly blind. Always run Hugo with the --printMemUsage and --printTime flags. The data doesn’t lie.

hugo --printMemUsage --printTime

This will tell you exactly how long each build takes and how much memory it scarfed down. Watch these numbers like a hawk. If a new section you add causes a 200% spike in build time, you’ll know immediately, and you can investigate why (probably too many list templates or a recursive shortcode). This is the single most important habit for managing a large Hugo site. It turns abstract “slowness” into a concrete, measurable problem you can actually fix.