A Static MDX Publishing Pipeline

The durable version of a personal site is not the one with the most runtime capability. It is the one whose publishing path remains obvious after months away from the repository.

Astro and MDX are a good fit because the content model stays close to the filesystem while the rendering model stays static.

Content As Source Code

Blog posts should behave like code: reviewed, typed, linted, and built. A content collection schema gives frontmatter the same treatment as any other contract in the system.

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    description: z.string(),
    publishDate: z.coerce.date(),
    tags: z.array(z.string()),
  }),
});

Search Without Runtime Weight

Pagefind works well for static publications because it moves indexing to build time. The client only downloads the search UI and index fragments when someone visits the search page.

That keeps the article reading path clean:

1. render content at build time
2. emit HTML
3. index the output
4. load search only on demand

Syntax Highlighting Belongs In The Build

Code blocks should not require hydration. Shiki gives deterministic highlighting during the Astro build, which keeps pages fast and avoids client-side parsing work.

The result is less dynamic, but more reliable.

Keep The System Legible

Every abstraction in a publishing system should make a future edit easier. Layouts, components, and utilities are useful when they clarify repeated behavior. They become weight when they hide simple content flow.