Scheduling Future Posts in Hugo Without Dead Links

The Problem With Linking to the Future When I published my post on monorepos, I wanted to link to the follow-up article about syncing private repos to public GitHub subtrees. The problem was that the follow-up did not exist yet. A dead link on a freshly published post is not a great look, and “I will add the link later” is the kind of promise that usually gets forgotten. Building on my automated blog pipeline, I wanted a better, hands-off workflow: I wanted to write future posts, push them to my repository, and have them resolve to a clean “Coming Soon” teaser page if a reader clicked the link early. Once the publication date arrives, the same URL should automatically render the full article and show up in my site lists with zero manual cleanup. Here is how I built that, and the things that broke along the way. The Approach Hugo has a buildFuture option that compiles future-dated posts into the site. Normally you would not want this, since it would expose unfinished drafts. But combined with a template check on the post date, it becomes exactly what I needed: the page exists and resolves, but renders a teaser instead of content until the date arrives. The front matter convention is minimal. A future post looks like any other post, just with a date that has not happened yet: --- title: "Monorepo Sync: From Private Repo to Public Subtrees" date: 2026-07-05 draft: false slug: "monorepo-subtree-sync-justfile-onedev" description: "How to maintain a private monorepo while selectively pushing directories to public GitHub repositories using git subtrees, Justfile, and OneDev automation." --- No special flags. The date drives everything. First, enable buildFuture in hugo.toml: buildFuture = true Then the template checks whether the post date is still in the future and swaps the content accordingly. Attempt One: Wrong Directory My first instinct was to put the overrides in layouts/_default/single.html and layouts/_default/list.html. That is where you would logically expect default templates to live, and it is what the Hugo documentation points you toward for overrides. It did nothing. The site built fine, the templates were ignored entirely, and future posts rendered their full content as if the check was not there. The cause took a while to track down. PaperMod places its single.html and list.html directly in the theme’s layouts/ root, not in layouts/_default/. Hugo’s template lookup order gives root-level files higher priority than _default/ files. So my overrides in _default/ were never reached because the theme’s root-level files matched first. The fix was to move my overrides to the root of the local layouts/ folder, which takes priority over anything in the theme: layouts/ list.html single.html rss.xml partials/ coming-soon.html extend_head.html Attempt Two: Syntax Error on now Once the files were in the right place, I wrote the date check like this: {{- if gt now.Unix .Date.Unix }} Hugo threw a runtime template error. The problem is that now in Hugo is a function, not a variable. Go’s template engine does not let you access methods directly on a function call without wrapping it in parentheses. The cleaner fix was to avoid the issue entirely and use Hugo’s built-in time comparison method: {{- if .Date.After now }} {{- partial "coming-soon.html" . }} {{- else }} {{- end }} .Date.After now works because Hugo executes now as an argument automatically. Clean and readable. Attempt Three: The where Clause Does Not Work on Time Hiding future posts from the homepage list and RSS feed was the next step. My first attempt used Hugo’s where function: {{ $pages := where .Site.RegularPages "Date" "le" now }} This silently returned all pages, including future ones. No error, just wrong output. The workaround is a manual loop that builds a filtered slice using the .Date.After time comparison method, which works correctly: {{- $filteredPages := slice }} {{- range $pages }} {{- if not (.Date.After now) }} {{- $filteredPages = $filteredPages | append . }} {{- end }} {{- end }} {{- $pages = $filteredPages }} We use not (.Date.After now) because it behaves correctly and is native to Go’s time package. This loop filters the pages cleanly without causing paginator offsets or blank entries. The same filter applies in rss.xml to keep future posts out of the feed. The Coming Soon Partial With the routing and filtering sorted, the teaser itself is straightforward. In layouts/partials/coming-soon.html: {{ .Title }} {{- if .Description }} {{ .Description }}

{{- end }} This post is not live yet. Expected {{ .Date.Format "January 2, 2006" }}.

Subscribe via RSS to be notified when it publishes.

And in extend_head.html, the noindex tag so search engines do not index the teaser: {{- if .Date.After now }} {{- end }} Search Index Exclusions (index.json) Because buildFuture compiles future posts to disk, your JSON search index (layouts/index.json in PaperMod) will include them in search results by default. To prevent this, override layouts/index.json. We declare an explicit $now := now variable at the top of the file, and filter using our negated date check: (Note: We declare $now outside the loop defensively. Inside range loops or custom output format templates like JSON/RSS, Go templates reset the dot context (.), and calling the global now function directly inside complex condition blocks can occasionally result in template evaluation scope lookup failures depending on your Hugo version. Pre-declaring it at the top avoids this completely.) {{- $now := now -}} {{- $.Scratch.Add "index" slice -}} {{- range site.RegularPages -}} {{- if and (not .Params.searchHidden) (ne .Layout `archives`) (ne .Layout `search`) (not (.Date.After $now)) }} {{- $.Scratch.Add "index" (dict "title" .Title "content" .Plain "permalink" .Permalink "summary" .Summary) -}} {{- end }} {{- end -}} {{- $.Scratch.Get "index" | jsonify -}} Note: Browsers cache the search index JSON file aggressively. In development, open an Incognito tab or disable cache in DevTools to see the changes. Tag and Category List Exclusions (taxonomy.html) My next realization came when visiting the tag list page (e.g., /tags/). Although future posts were hidden from the homepage listing, the tags themselves were still being listed, and their post counts included the future articles. A reader clicking a tag could end up on an empty list page if the only post with that tag was scheduled for the future. Hugo’s default taxonomy template calculates counts across all compiled pages in the site. To fix this and dynamically filter out scheduled entries from the counts (and hide tags with a count of zero), I had to override layouts/taxonomy.html. We loop through each term, manually verify that its pages are published, and only render the tag if the count is greater than zero: {{- define "main" }} {{- if .Title }} {{ .Title }} {{- end }} {{- $type := .Type }} {{- range $key, $value := .Data.Terms.Alphabetical }} {{- $name := .Name }} {{- $count := 0 }} {{- range .Pages }} {{- if not (.Date.After now) }} {{- $count = add $count 1 }} {{- end }} {{- end }} {{- if gt $count 0 }} {{- with site.GetPage (printf "/%s/%s" $type $name) }} {{ .LinkTitle }} {{ $count }} {{- end }} {{- end }} {{- end }} {{- end }} One Thing to Keep in Mind Because Hugo is a static site, the transition from “coming soon” to “live” only happens on the next build. If you push nothing on publish day, the post stays hidden until something triggers a deploy. I handle this with a scheduled nightly build in OneDev. A lightweight job that just runs hugo and deploys the output, no code change required. That way posts go live within 24 hours of their date automatically. The Result Future posts now resolve immediately when linked. Readers see the title, description, expected date, and an RSS link. The post graduates to full content on the next build after the date passes, with no front matter to clean up and nothing to remember. The four lessons that actually cost time: put overrides in the layout root not _default/, use negated time methods like not (.Date.After now) in loops, never trust where with time.Time values, and manually calculate taxonomy tag counts to hide scheduled posts. None of these are obvious from the documentation, which is the main reason this post exists.