Why shouldn't I move finished projects to an archive folder?

Because a page's path is its address. Move the file and every internal link, external bookmark, and published URL that pointed at it breaks. The page's location should describe what it permanently is, not what state it is currently in. Record the lifecycle in frontmatter instead.

How do I mark a page as archived without moving it?

Add a status field to the frontmatter — for example status: archived — and leave the file exactly where it is. Tools, indexes, and dashboards can filter or badge pages by that field, so you get the lifecycle view without ever changing an address.

What determines which folder a page belongs in, then?

Its kind, permanently. A runbook lives under runbooks, a decision under decisions, a topic under its hub — regardless of whether the thing it documents is active, paused, or retired. Kind is stable; status changes, and status belongs in metadata.

Never Move a Note When a Project Ends

On this page

Why moving a page is destructive
Do this instead
The swap-in box
Why this earns its own post

This is a short one, because the rule is short — but skipping it quietly rots a knowledge base over years. It’s one of the ⚠️ mistakes this series flags because it feels like tidying up while it’s actually breaking things.

The rule

A page’s location is its identity — never move it because its status changed. Lifecycle (active, paused, archived) lives in frontmatter. The moment you drag a finished project’s notes into archive/, you break every link and bookmark that pointed at the old path.

First: make these values your own

The title and status in the frontmatter examples are just an illustration — use your own page’s values. The point is the field (status: living in metadata), not the example text.

Why moving a page is destructive

In the previous post we turned the vault into a graph of links. A link is an address. Move a page and every address pointing at it goes stale at once:

The published wiki gives that page a stable URL derived from its path; a search index keys results by path; your browser bookmark is the path. This is exactly the point the W3C’s Cool URIs Don’t Change has made since 1998: the address you publish is a promise, and moving it breaks that promise for everyone who kept it. One “cleanup” move invalidates all three silently — nothing errors, links just quietly rot.

Do this instead

Leave the file where it is and change one frontmatter field:

---
title: "Old Minecraft Server Project"
type: project
status: archived        # was: active
updated: 2026-07-15
---

Now every dashboard, index, and MOC that filters on status can dim, badge, or hide the page — while its address, and every link to it, stays valid forever. Lifecycle became a view, not a move.

Kind is the folder; status is the field

Ask “what is this page?” not “what state is it in?” A runbook is always a runbook. A decision is always a decision. The answer to “what is it” picks the folder once and never changes; the answer to “what state” goes in status and changes freely.

The swap-in box

On other tools

Any static-site or wiki generator (Astro, Hugo, Wiki.js, MkDocs) derives URLs from file paths — so this rule is universal, not specific to my stack. Notion/Confluence: use a Status property and a filtered view; never change a page’s parent to represent lifecycle. If you must reorganize (a genuinely wrong original location, not a status change), add a redirect from the old path so existing links survive the move.

Why this earns its own post

Because it’s the mistake you make while feeling productive. Tidying finished projects into an archive folder looks like good hygiene and is actually link rot in slow motion. Adopt “identity over status” from your first project and the graph you built in the last post stays intact for years.

Next we move from structure to projection — deriving a published Wiki.js site from the one authoritative vault, where these stable paths become stable public URLs: one authority, many views.

Related posts:

Turn a Pile of Notes Into a Connected Brain — the graph of links this rule protects
Never Lose a Homelab Note Again: A Git + Markdown Vault — where the folder taxonomy is set up
Turn Your Git Vault Into a Searchable Wiki.js Site — where stable paths become stable public URLs
Your Homelab Needs a Second Brain — Here’s Why — the single-authority principle behind all of this
Already Made a Mess of Your Notes? Here’s the Fix — undoing the damage when the rules were broken

Comments

Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.