TL;DR
- Markdown files in Astro content collections suit a developer's personal blog: they are versioned, reviewed and kept apart from the layout.
- A post goes live on its publication date, once the daily rebuild has run. A draft flag keeps a post hidden whatever its date.
- A CMS is the better choice when non-technical editors need previews, media handling, approval roles or frequent updates.
For my own blog, writing in files works well. The content lives beside the site code, changes can be reviewed in version control, and the page layout doesn’t need rebuilding for each article.
That suits a developer maintaining a personal website. It isn’t automatically the right choice for a marketing team with several authors and an approval process. Those are different jobs, and the second one usually needs a different tool.
The article is content, not a new page design
Each post lives in src/content/blog/ as Markdown. Its frontmatter supplies the title, description, publication date, tags and optional settings. The template handles everything around the text.
That separation keeps writing away from layout decisions. A new article shouldn’t need the author block, share controls or navigation copied in from an old one.
The content loader also removes a leading filename date when it generates the article ID. A file called 2026-10-08-webflow-vs-wordpress.md therefore keeps a URL based on webflow-vs-wordpress, rather than including the date.
Changing the date prefix doesn’t by itself require a new public slug. That’s a deliberate choice in this repository, not a rule every Astro blog has to follow.
A schema catches avoidable mistakes
Astro content collections let the project define the fields it expects. On this site, the schema checks strings, dates, tags, the draft state and the allowed cover and service values.
That matters because an article file is easy to edit and easy to mistype. A missing description should fail validation during the build, not appear as an empty card after publishing.
The schema doesn’t judge whether an article is accurate or readable. Those checks still need an editor. Valid frontmatter is where the review starts, not where it ends.
Drafts and scheduling are separate features
The repository’s post query includes drafts in development and excludes them in production. It then sorts articles by publication date.
A draft flag hides a post in production, whatever its date. A post without that flag appears once its pubDate has passed, as long as the site has been rebuilt since then.
A scheduled workflow rebuilds the site every day, so a post goes live on the morning of its date. Dates are read as midnight UTC, and the workflow can start a few minutes late. The schedule lives in the frontmatter, and the build enforces it. A calendar file on its own wouldn’t do that.
Reading time and RSS should follow the same content
This site estimates reading time from the article body, leaving fenced code blocks out of the word count. It’s a rough aid, not a promise about how long a technical article takes to read.
An RSS feed is useful for people who want updates without returning to the index. It should follow the same publication rules as the article list. Drafts shouldn’t leak into the feed because a second query forgot to filter them.
Sitemaps and related-article navigation need the same consistency. Every part of the site should agree on what counts as published.
Keep the editing workflow realistic
Markdown works for me because I can edit files, preview changes and deal with a failed build. If a client can’t comfortably do those things, telling them to “just update the repo” creates a dependency instead of removing one.
A CMS can be the better investment when people need visual previews, media management, reviewer roles, localisation or frequent editing by non-technical staff. For a comparison of how those trade-offs play out on a marketing site, see Webflow vs WordPress for a marketing website. Astro can also work with a CMS, so choosing the framework doesn’t force repository-based writing.
My requirement for this blog is modest: content I can maintain, URLs I can keep and a publishing process I understand. Extra features should solve a real problem before they become another system to manage.