# Best practice for preserving archive pages?
**URL:** https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468
**Category:** support
**Created:** [August 11, 2026, 8:46pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468 "2026-08-11T20:46:45Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@toddfoster](https://discourse.gohugo.io/u/toddfoster)
#### Post date: [August 11, 2026, 8:46pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/1 "2026-08-11T20:46:45Z")
I have a simple site is keyed to the calendar and grows by 200-400 pages per year. Presently I’m at 2200 pages and it takes ten seconds to build.
I would prefer NOT to modify or update pages from previous years, though that often happens as I heavily leverage shortcodes and json data sources for content. Those shortcodes, some of which have significant decision trees, continue to evolve. Many of the pages look similar from year to year, but the finer details are always changing.
I would like to archive pages so that I can have:
- the freedom to evolve shortcodes without worrying about distorting older pages
- faster builds
Is there a preferred way to archive pages within my site so that they will not be rebuilt any more?
Could I, for example, copy sub-directories of the deployed (html) site into the static folder and link them from the relevant content page? Or perhaps I should keep separate repo’s for older years and somehow mount them into the current one?
The site in question can be found at [GitHub - toddfoster/sharedprayers · GitHub](https://github.com/toddfoster/sharedprayers)
Thank you for any suggestions/observations!
Todd
---
### Author:  [@irkode](https://discourse.gohugo.io/u/irkode)
#### Post date: [August 12, 2026, 6:24am UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/2 "2026-08-12T06:24:05Z")
Thats two topics:
- build performance and segmentation
- versioning your layouts
* * *
tried to do a bare build after clone on wndows.
**duplicate pagenames** Capitalization
```auto
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'content/archive/2023/Proper-19.md'
'content/archive/2023/proper-19.md'
'content/archive/2023/Proper-28.md'
'content/archive/2023/proper-28.md'
'content/archive/2024/Proper-14.md'
'content/archive/2024/proper-14.md'
'docs/images/qr/archive/2023/Proper-19.png'
'docs/images/qr/archive/2023/proper-19.png'
'docs/images/qr/archive/2023/Proper-28.png'
'docs/images/qr/archive/2023/proper-28.png'
'docs/images/qr/archive/2024/Proper-14.png'
'docs/images/qr/archive/2024/proper-14.png'
'static/images/qr/archive/2023/Proper-19.png'
'static/images/qr/archive/2023/proper-19.png'
'static/images/qr/archive/2023/Proper-28.png'
'static/images/qr/archive/2023/proper-28.png'
'static/images/qr/archive/2024/Proper-14.png'
'static/images/qr/archive/2024/proper-14.png'
```
build errors with hugo 164.0
```auto
hugo
WARN deprecated: project config key languageCode was deprecated in Hugo v0.158.0 and will be removed in a future release. Use locale instead.
Start building sites …
hugo v0.164.0-ce2470e7012b5ab5fc4e10ebe4027e9f8d9e00dc windows/amd64 BuildDate=2026-07-06T16:39:30Z VendorInfo=gohugoio
Total in 36151 ms
ERROR error building site: assemble: failed to create page from pageMetaSource /archive/2021/he-covid-augustinearchbishop: "C:\_repos\github\clone\topic-57468-archive\content\archive\2021\he-covid-augustinearchbishop.md:5:1": [4:1] mapping key "title" already defined at [1:1]
1 | title: Holy Eucharist, Rite II (Augustine, First Archbishop of Canterbury)
2 | date: 2021-05-26
3 | lectionaryyear: b
> 4 | title: "Holy Eucharist for Augustine, First Archbishop of Canterbury, 605"
^
5 | bcppage: 355ff.
```
> [@Archive pages with shortcodes?](https://discourse.gohugo.io/t/archive-pages-with-shortcodes/43315/3):
>
> Thanks for the quick response! I was thinking along those lines, too – I even do some of it on a small scale. One simple way to version (and contain) shortcut names could be to have years in the root of the shortcodes directory and copy them forward each year to make changes. But multiplying code in the shortcode (to provide different functionality depending on what version the page expects) or multiplying files in the shortcode directories (already a bit hairy) are both bad habits making my …
---
### Author:  [@toddfoster](https://discourse.gohugo.io/u/toddfoster)
#### Post date: [August 12, 2026, 1:21pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/3 "2026-08-12T13:21:45Z")
Thanks for the reply – and for digging up the fact I’ve asked this before! Three years later the question is shaped differently because I have twice as many pages to generate. Performance is a concern, but I’m pretty convinced that “segmenting the build” would render the performance issue negligible.
Thanks, too, for trying to build and discovering the filename conflicts. I wonder if those are only in 2023-2024. That looks like technical debt that ought to be paid down someday.
Versioning the short-codes: you offer several excellent options. Thank you. Some of them were offered to me three years ago, and some partially implemented. I keep weighing complexity against the fact that I only dive into the code about once every other year (and therefore desire a clean, simple, readable system).
Segments look like a promising direction, though they would require a more complicated call to hugo to build and not lose my old versions. Is this how makefiles came to be? 🤪 As you say, my git history will be my friend in this.
It seems the answer is [still] not going to be as simple as I hoped for my idiosyncratic use-case. @irkode Thank you for engaging the conversation with me. I’m going to look into segments.
---
### Author:  [@jmooring](https://discourse.gohugo.io/u/jmooring)
#### Post date: [August 12, 2026, 10:52pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/4 "2026-08-12T22:52:21Z")
If it were my site I would, as suggested before, version your shortcodes, and I wouldn’t complicate things by somehow taking older content out of the workflow to reduce build times.
At the rate you’re adding pages it will take another 5-10 years to double the page count. And in a [CI/CD](https://gohugo.io/quick-reference/glossary/#cicd) workflow, a 10-20 second build is noise.
---
### Author:  [@toddfoster](https://discourse.gohugo.io/u/toddfoster)
#### Post date: [August 13, 2026, 3:18pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/5 "2026-08-13T15:18:40Z")
@jmooring Joe,
Thank you again for helpful input – and your continued generosity to the hugo community.
It’s all about context, isn’t it? In a CI/CD workflow, you’re right: speed (on this scale) wouldn’t be a relevant thought. For my little manually-built hobby site, I can put up with longer build-times (though memories of optimizing builds as a software dev makes me want a faster turnaround when there’s no reason to re-render 95% of the pages during most builds). But yes, I am certainly weighing the complexity of segments (and the startup cost of figuring them out!) against my 10 second waits.
I think you’re right that versioning my shortcodes is probably something I need to do. Though that adds its own complexity.
So really this is an exercise in weighing out my own values and hopes against the ways that hugo is meant to be used. Thank you (again) for giving me some clarity on what makes sense on the hugo side!
---
### Author:  [@irkode](https://discourse.gohugo.io/u/irkode)
#### Post date: [August 13, 2026, 4:31pm UTC](https://discourse.gohugo.io/t/best-practice-for-preserving-archive-pages/57468/6 "2026-08-13T16:31:01Z")
a really simple versioning approach is:
use sc.html - your current one
when you start a change
copy sc to sc-1.html and use that from now on
continue with sc-2.html
you get diffable shortcodes
if you use archetypes you could add an attribute needsSC: sc-2 after the first change and add a guard if you use sc.html in such a file