Partials

Right, let’s talk about the workhorses of your template directory. These are the files you’ll include on nearly every page, the ones that handle the repetitive, soul-crushing boilerplate so you don’t have to. We’re going to make them smart, then stitch them together into something that doesn’t suck. The head.html Partial: Your Page’s First Impression This little guy is arguably the most important. It’s not seen by your users, but it’s read very carefully by browsers and search engines. A messy head is like showing up to a job interview with your shirt on inside-out. Let’s get it right.

Alright, let’s talk about organizing these partials. You’ve got a few of them now, and your templates directory is starting to look like my desk on a bad day: a chaotic mess where finding anything requires archaeological skills. We need a system. The moment you have more than a handful of partials, you’ll feel the pain. Is header.html for the blog or the store? Is that card.html for a product, a user profile, or a cat photo? Throwing them all into a single flat directory is a rookie move that scales horribly. The solution, like in any good codebase, is to use directories to create namespaces. We’re going to nest them.

Right, so you’ve been building up your partials, making them nice and reusable, and then you hit a wall. You need a snippet of logic to not just output some HTML, but to actually give you back a value—a string, a slice, a boolean, something you can use in the parent template’s logic. You’ve probably tried the old trick of using .Scratch.Set and felt a little dirty about it. I don’t blame you. It worked, but it was clunky and indirect, like passing a note through three friends to ask someone out.

Right, so you’ve met {{ partial }} and you’re probably thinking, “These are great! I can break my site into logical, reusable chunks.” And you’d be right. But you’re about to hit a wall. A big, slow, frustrating wall. Every time you change a single line of CSS, Hugo has to rebuild your entire site’s structure because it can’t be sure that change didn’t affect the header partial used on every single page. It’s maddening.

Right, so you’ve broken your UI into partials. Good for you. Now you’re staring at a template that looks like this, wondering how the heck you get data into that isolated little island. {{ template "user-card" }} It renders, but it’s a ghost town. Your brilliant user-card partial is starving for data. This is where you stop just including a partial and start calling it with arguments. Welcome to the main event. The Dot: Passing the Entire Context The simplest way to feed your partial is to just hand it your entire current context (a.k.a., “the dot”). You do this by piping the dot into the template call.

Alright, let’s talk about getting these partial templates onto your page. You’ve defined these reusable fragments, these beautiful little components of HTML, and now you need to actually, you know, use them. Hugo gives you two main ways to do this: partial and partialCached. One is your reliable workhorse, the other is a performance-obsessed specialist. Choosing the right one is the difference between a swift, elegant site and one that’s constantly doing unnecessary heavy lifting.

Right, let’s talk about the layouts/partials/ directory. This isn’t just another folder Hugo tells you to use; this is your new best friend, your toolbox, your secret weapon against the soul-crushing dread of repeated code. Think of partials as the reusable fragments of your site’s UI. That header you copy-paste into every single layout? That’s a partial. The footer that’s identical on every page? Partial. That complex “related articles” component you spent three days building? For the love of all that is holy, make it a partial.