Why I Use Next.js + Sanity for Content Sites

If you’re building a marketing site or content platform, you want three things:

• pages that load fast,
• content that’s easy to edit,
• and an SEO setup you can trust.

For most projects I ship, Next.js + Sanity is the sweet spot.

What Next.js gives you

• Great performance defaults: route-based code splitting, image optimisation, and server rendering when needed.
• Metadata control: canonicals, Open Graph, Twitter cards, and structured data can be treated as first-class code.
• Deployment simplicity: ship to Vercel (or any Node host) and keep it boring.

When Next.js is the right tool (and when it’s not)

Next.js is ideal when you care about speed + SEO + developer velocity together:

• Marketing sites with landing pages that must load instantly and share well.
• Content sites where posts need to be crawlable, linkable, and structured.
• Hybrid apps where some pages are static (blog) and others are dynamic (pricing, dashboards, gated content).

When I don’t reach for Next.js:

• If the site is purely static and will never need dynamic data, a simpler static generator can be enough.
• If you’re building an internal tool with no SEO needs, you may prioritise different trade-offs.

The SEO primitives you get “as code”

The big win is that SEO becomes part of your engineering surface area:

• Canonical URLs: avoid duplicate indexing.
• OpenGraph/Twitter: previews that look consistent across platforms.
• Structured data (JSON-LD): help Google understand the page type and relationships (author, breadcrumbs, collections).
• Sitemaps + robots: generated + validated like any other build artifact.

If you’re building a blog, that means every post can ship with:

• a canonical,
• a BlogPosting schema,
• and a stable OG image route (like /api/og/blog/[slug]).

What Sanity gives you

• Flexible content modelling: you can represent real business concepts instead of forcing everything into a “blog post” shape.
• Editorial velocity: drafts, previews, and publishing without developer tickets.
• Structured SEO fields: titles, descriptions, canonicals, and share images can be part of the schema.

Sanity is not “just a CMS” — it’s a content database

Most teams hit limits when their CMS only supports “Page” and “Post”.
Sanity lets you model the real world:

• Authors (with bios, socials, headshots)
• Categories (and content verticals)
• Reusable blocks (CTAs, testimonials, FAQs)
• Relationships (related posts, featured projects, “learn more” links)

That structure is what makes a site scale without becoming chaos.

A blog model that scales (simple but future-proof)

If I’m setting up a blog, I start with a schema that supports:

• slug (stable URL)
• title + description (SERP + social)
• publishedAt (ordering)
• tags/categories (internal navigation + topical authority)
• body (portable rich text)
• optional featured image (sharing + in-article media)

You can keep it lightweight at first, and expand only when you need it.

The trade-offs

• Sanity is another system to manage (datasets, roles, previews).
• If you only need a handful of posts, MDX in the repo can be enough.

What it costs (so you can plan properly)

• More moving parts: environment variables, datasets, permissions, preview URLs.
• More decisions up front: your schema design affects how editors work every day.
• Preview complexity: “draft vs published” needs a clean workflow (it’s worth it, but it’s work).

None of these are deal-breakers — they’re just real.

How to decide: MDX vs Sanity (quick framework)

Use MDX in the repo when:

• you’ll publish infrequently (or you’re the only editor),
• you want “blog as code” and don’t need editorial workflows,
• you care about shipping fast and keeping infra minimal.

Use Sanity when:

• multiple people need to publish,
• content types will grow beyond “blog post”,
• you want drafts, approvals, and previews,
• you want a long-term content pipeline (case studies, landing pages, docs).

A practical implementation plan (what I ship for clients)

Here’s the sequence I follow for a high-performing content site:

1. Define content types: start minimal (post, author, category).
2. Build listing + detail pages: /blog and /blog/[slug].
3. Add technical SEO: canonicals, JSON-LD, sitemap, RSS, OG images.
4. Add internal linking: “related posts” + links from services/projects pages.
5. Measure + iterate: Search Console, Core Web Vitals, and content refresh cycles.

Common mistakes I see (and how to avoid them)

• Thin posts: short posts without a unique angle won’t build authority. Prefer fewer, deeper articles.
• No internal links: link your posts to relevant pages (and between posts) so crawlers understand structure.
• Unstable slugs: never change slugs once indexed unless you have redirects.
• Missing OG images: social previews matter for distribution (and distribution matters for links).

What the stack actually costs to run

Founders assume headless means expensive infrastructure. The honest numbers for a typical marketing site on this stack:

• Sanity: free tier covers two editors and 500k API requests/month — most marketing sites never leave it. The Growth plan is $15/user/month when you need more seats or roles.
• Vercel: free for hobby, $20/user/month Pro for a commercial team. A mostly-static Next.js site serves the vast majority of traffic from CDN cache, so function invocation costs stay negligible.
• Everything else: $0. No plugin licences, no managed WordPress hosting, no security-patching retainer.

Realistic total: $0–50/month for most sites, versus the $100–400/month a comparable managed WordPress setup accumulates once you count plugins, hosting tiers, and the maintenance that isn't optional. The build cost is where the money goes; the run cost rounds toward zero.

When I don't recommend this stack

Credibility requires saying where the answer is no:

• A five-page site that changes twice a year. A CMS is overhead here — MDX in the repo, or even a static site builder, ships faster and there's nothing to maintain.
• Content teams wedded to visual page building. Sanity models structured content; it is not a drag-and-drop page builder. If marketing's mental model is Webflow, either budget for the workflow change or pick the tool that matches it.
• Heavy e-commerce. Product catalogues, carts, and checkout belong in Shopify or a commerce engine. Sanity works well as the content layer alongside — but not as the commerce backbone.
• No engineering capacity at all. This stack assumes someone can run git push. A team with zero technical staff will resent every part of it, and a fully-hosted platform serves them better.

The pattern in every exception: match the tool to the team's actual workflow, not to the architecture diagram. The stack wins when structured content, performance, and editor autonomy all matter at once — which happens to describe most funded startups and agencies I work with, but not everyone.