From a content/ Folder to the Page: One Source of Truth on a Static Site
When posts are plain files, publishing feels calmer; the app always knows where the canonical text lives.
I like sites that know where the truth lives for every article: one Markdown file, explicit front matter, and the app reads plus renders. That cuts surprises at deploy time—no hidden database, no dueling copies of the same paragraph. A content/ folder is not just storage; it is a contract with your project that says every change starts here.
Why files sometimes beat a dashboard
Dashboards shine when teammates or clients collaborate, but they add friction for a personal site. Files in Git give you history, review before merge, and backups without a separate ritual. You also read the content almost the same way the site does, which shrinks the “what actually shipped?” confusion.
Filenames and dates
Use clear English slugs for URLs and localized titles inside YAML when you need them. A front-matter date helps ordering without relying solely on filesystem timestamps. Consistency beats clever naming; your future self will thank you.
What never belongs in Markdown
Skip API secrets, other people’s personal data, or sensitive logic that must stay on the server. Markdown is for prose and structure; behavior stays in code. With those boundaries, content/ stays safe and legible for any future contributor.
Parting question: If your content directory vanished for a day, what would you miss first on the live site?