Choosing How to Manage Your Website Content

The Decoupling Trap: From Monolithic CMS to API Sprawl

Over the past decade, a great many businesses concluded that monolithic runtime CMS platforms (WordPress, Drupal) were unsuited for modern web work:

• They carried chronic security problems (SQL injection, malicious PHP plugins).
• They were slow, generating dynamic HTML from unindexed database queries on every request.
• They went down during traffic spikes, usually on the day a local newspaper wrote about you.

In response, the market embraced Headless CMS. Businesses moved their content to hosted API vendors—predominantly Contentful, Sanity, Strapi, and Prismic—and paired them with modern frontend frameworks.

While headless CMS solved the runtime security flaws of WordPress, it introduced a new class of hidden architectural and financial liabilities.

│                                                                               │
│                  THE THREE CONTENT ARCHITECTURE PARADIGMS                     │
│                                                                               │
│ 1. RUNTIME CMS          │ 2. HOSTED HEADLESS CMS  │ 3. GIT-BASED CMS          │
│ (WordPress, Drupal)     │ (Contentful, Sanity)    │ (Astro Collections)       │
│ Runtime MySQL database  │ Proprietary SaaS cloud  │ Flat MDX files in Git     │
│ Vulnerable PHP plugins  │ GraphQL / REST JSON     │ Version history           │
│                         │                         │ included                  │
│ Uncached DB queries     │ Rate limits on builds   │  Schema checked at build  │
│ Downtime under spikes   │ Seats and API overages  │ $0 per month              │
└─────────────────────────┴─────────────────────────┴───────────────────────────┘

At Aura Logic, we do this comparison for founders who own their own sites and are deciding how much of their content future they want to rent. Below is our comparative breakdown of the leading content paradigms.

1. Auditing the Market Leaders: Contentful vs. Sanity

To understand the tradeoffs, we examine the two dominant commercial hosted headless platforms:

A. Contentful: The Structured Suite Model

• Strengths: Role-based access control, multi-locale localization workflows, and a long track record of running large content libraries.
• Architectural Liabilities:
  • API Rate Limiting: Contentful enforces strict API rate limits on its Content Delivery API. During a static site build, where thousands of pages query the API at once, builds can fail with 429 Too Many Requests errors unless batching and queueing scripts are engineered.
  • Pricing Tiers: The free plan is limited in seats, locales and monthly API calls. The first paid step is a monthly subscription with per-seat surcharges and API overages billed on top. For a business publishing a handful of pages a month, that is a lot of subscription for a handful of pages a month.
  • Proprietary Rich Text Format: Contentful stores rich text in its proprietary AST (Abstract Syntax Tree) JSON format. Moving away from Contentful later means writing custom parsers to convert nested JSON trees back into Markdown or HTML.

B. Sanity: The Real-Time Structured Content Engine

• Strengths: Excellent developer ergonomics, real-time collaborative editing, and the expressive GROQ query language.
• Architectural Liabilities:
  • GROQ Query Latency: While GROQ is powerful, complex deeply nested queries add latency during build time or server-side rendering passes, and that cost grows with the depth of the query and the size of the content set.
  • Egress & API Quotas: Sanity’s published prices start at a free plan of $0 forever with up to 20 user seats, then a Growth plan at $15 per seat per month, with a paid quota add-on at $299 per month that raises the included allowances to 50k documents, 5M API CDN requests, 1M API requests, 500GB bandwidth and 500GB assets. Editor roles, seat count and overage bills all scale upward as more people publish.

2. The File-Based Alternative: Git Content Collections

For a business that publishes steadily and wants to own what it owns, the practical alternative is Git-Based Content Collections.

Under this paradigm, every article, case study, service page and about page lives directly within the repository as an MDX, Markdown, or YAML file.

┌─────────────────────────────────────────────────────────────────────────────┐
│                           WHERE THE CONTENT LIVES                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   src/                                                                      │
│     content/                                                                │
│       insights/                                                             │
│         headless-cms-evaluation.mdx                                         │
│         web-font-engineering.mdx                                            │
│       case-studies/                                                         │
│         modernisation-notes.mdx                                             │
│     content.config.ts   <-- strict Zod schema, checked at build             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

What Git Collections Give You:

1. Compile-Time Type Safety via Zod: With a hosted CMS, an editor can publish an article without an author or with a broken image link, breaking production pages at runtime. With Astro Content Collections, whose documentation describes a collection schema as the way to define the expected shape of each entry for type safety, autocomplete and validation, every file is validated against a strict Zod schema at compile time. If an editor omits a mandatory field, the build fails before bad data ever reaches production:

   // src/content.config.ts
   const insightsCollection = defineCollection({
     loader: glob({ pattern: "**/*.{md,mdx}", base: "./src/content/insights" }),
     schema: z.object({
       title: z.string().min(10).max(120),
       publishDate: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),
       category: z.enum(['Architecture', 'Performance', 'AI Systems', 'Design Engineering']),
       tags: z.array(z.string()).min(1),
       faqs: z.array(z.object({ question: z.string(), answer: z.string() }))
     })
   });

2. True Atomic Releases: In a hosted CMS, publishing a content change happens asynchronously from code deployments. If a marketer publishes content that relies on a new component that hasn’t finished deploying, the website crashes. With Git, content and code are deployed together in a single atomic commit.
3. No Subscription, No Ceiling: There are zero API servers, zero rate limits, and zero monthly content bills. A repository of MDX files compiles locally or on GitHub Actions, whether it holds ten articles or ten thousand.

3. Financial Audit: 3-Year Cost of Ownership

Below is an illustrative comparison, not a client result, for a small business publishing about a dozen pages a month with a few hundred visitors.

┌───────────────────────────┬────────────────────────┬──────────────────────────┐
│               ILLUSTRATIVE 3-YEAR COST: ONE SMALL BUSINESS SITE               │
├───────────────────────────┼────────────────────────┼──────────────────────────┤
│ COST LINE                 │ HOSTED HEADLESS        │ GIT-BASED CMS            │
│ Free tier for a 3-page    │ $0 / month             │ $0 / month               │
│ site                      │                        │                          │
│ Two people who need to    │ $15 to $30 / month     │ $0                       │
│ publish                   │                        │                          │
│ Hosted CMS, past          │ a paid monthly tier    │ $0                       │
│ free tier                 │                        │                          │
│ Extra API quota, if       │ $299 / month           │ $0                       │
│ needed                    │                        │                          │
│ 3-year total              │ $1,080 to $11,844      │ $0                       │
└───────────────────────────┴────────────────────────┴──────────────────────────┘

Read the right-hand column carefully: it is not that a git-based site is free to run. Hosting still costs something. It is that the content layer adds nothing on top, and the number does not move when you publish more.

The hosted column is built from Sanity’s published prices, not from a quote: the Growth plan at $15 per seat per month for the two people who publish is $30 a month, and the paid quota add-on at $299 a month takes it to $329. Over three years that is between $1,080 and $11,844. It is a model of the shape of the cost, not a price for your project.

4. Solving the Editorial Experience

The primary objection to git-based content is: “My marketing person does not know how to use Git or write Markdown.”

This problem has been solved with modern Git-backed visual editing layers:

• Keystatic / TinaCMS / Decap CMS: Lightweight open-source visual editors that install into the Astro project. An editor logs into a clean visual UI, edits content in a rich text view, uploads images, and clicks “Publish”.
• Behind the scenes, the tool writes clean Markdown directly to the repository and triggers a deployment via GitHub Actions.
• Non-technical editors get the friendly ergonomics of WordPress, while the person who owns the business keeps the code, the version history, and the absence of a monthly bill, and can manage every page in files that belong to them.

Conclusion: The Practical Recommendation

For a small business or a founder who owns their own site:

• Choose a hosted headless CMS (Sanity, Contentful) if several people need to publish at the same time, from different devices, with real-time previews, and you are comfortable paying a monthly subscription for that convenience. Both have generous free tiers, so start there.
• Choose Git content collections (Astro) for a business that publishes steadily, wants no ongoing content subscription, and wants the site to be a file on its own server that it can hand to any developer, any host, or any future buyer.

The real question is not which platform is more advanced. It is whether you want to rent your content from a vendor who can change the terms, or own it as files that travel with the business.