Blog index page management in Sanity CMS: separate document vs page builder component?

You've actually walked yourself through to a really solid solution! Your final approach is absolutely valid and pretty common in the Sanity community. Let me validate your thinking and share some patterns I've seen work well.

Your Solution is Sound

The "Blog Index" component in your page builder is not silly at all – it's actually a smart compromise that balances structured content with editor flexibility. You're right that keeping "Blog Article" as a separate document type maintains proper content structure, which is the key thing. The blog index component is just a presentation layer decision, not a content modeling compromise.

Alternative Patterns to Consider

That said, here are a few other approaches I've seen work well:

1. Singleton Document for Index Pages

Create a blogIndexPage singleton document (using document.newDocumentOptions to limit it to one instance) that contains:

• Page metadata (title, SEO, etc.)
• Introduction text/content
• Display settings (posts per page, filtering options)
• Navigation settings

Then in your frontend, you hard-code the /blog route but pull content from this singleton. This keeps the content editable without making it a "page builder page."

2. Conditional Page Types

Some folks create a pageType field on their Page document with options like standard, blogIndex, shopIndex, etc. When blogIndex is selected, the page builder shows different available components or automatically includes the blog list. The Studio's structure builder can then group these by type in the sidebar for better organization.

3. The Route + Page Split (What You Mentioned)

The pattern from the Next.js starter where routes and pages are separate is actually quite powerful for larger sites. Routes handle navigation/hierarchy, Pages handle content. It's more complex upfront but scales really well when you have multiple content types that need to appear in navigation.

The Real Answer: It Depends on Your Clients

Your instinct is spot-on here:

"For web agencies building websites for clients who need flexibility and don't want to hire the services of a developer for small changes... For companies with in-house developers, we can have more content 'hardcoded'."

Exactly. The page builder approach with a "Blog Index" component gives maximum flexibility with minimal developer intervention. If a client decides they want the blog index on a different URL or want multiple filtered blog views, they can just create new pages and drop the component in.

Best Practice: Model for Meaning

The Sanity philosophy on page builders emphasizes "model for meaning, not presentation." Your Blog Article documents represent meaningful content entities. The fact that you're using a page builder component to display them doesn't compromise that structure at all – it's just a view layer decision.

One Tip: Make It Obvious

If you go with the blog index component approach, consider:

• Limiting it to one instance per page (or showing a warning if multiple exist)
• Giving it a clear icon and description in the schema
• Maybe adding a preview that shows "This will display your blog articles list"
• Using validation to prevent confusion

This way editors understand it's a special component, not just another content block.

Your evolution toward this pattern makes total sense. It's a pragmatic solution that prioritizes editor autonomy while maintaining content integrity. Don't second-guess it!