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).