slug: payload-cms-multiple-collections-one-route publishedAt: '2025-12-14T06:00:00.000Z' title: Serve Multiple Payload CMS Collections from One Route subtitle: >- Disambiguate slugs in Next.js with Payload CMS using route detection, direct verification, and handler orchestration… excerpt: >- Learn how to serve multiple Payload CMS collections from a single /events/[slug] route — use route detection, direct slug verification, and sequential… metaDescription: >- Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct… authorId: 80987f45-fee1-450a-afb1-930edc3d08e0 categories:

• 05b0679c-38aa-4aa4-9434-7368fb567e00 keywords:
• Payload CMS multiple collections
• Payload CMS routing
• Next.js dynamic routes
• route disambiguation
• collection verification
• slug verification
• handler orchestration
• checkEventExistsDirect
• checkWorkshopExistsDirect
• unstable_cache
• SEO unified URLs
• server-side routing

Note: While this guide uses tenant context (common in multi-tenant apps), the pattern applies to any scenario where multiple content types share a URL path. If you're building a multi-tenant app and need this pattern, ensure you have the basic multi-tenant setup working first.

Serving Multiple Payload CMS Collections from a Single Route

Introduction

I was building a client's event management site when I hit an interesting architectural challenge. They had two distinct content types—public events and interactive workshops—with completely different data structures and admin interfaces. The business requirement was straightforward: both should be accessible from /events/[slug] for SEO and user experience reasons. Technically, putting them on separate routes like /events and /workshops would've been cleaner, but business needs don't always align with technical elegance.

After implementing a working solution, I realized this pattern solves a broader problem that many developers face when building Payload CMS sites with complex content hierarchies. This guide walks you through the exact implementation I developed, covering route detection, collection verification, and handler orchestration. By the end, you'll understand how to let business requirements drive your architecture while keeping the technical implementation clean.

... (rest of the content) ...

Step 1: Create Collection Verification Functions

... (rest of the content from local backup) ...

Step 4: Orchestrate Handlers in the Main Page Component

... (rest of the content from local backup) ...

Conclusion

This pattern solves a real problem that many CMS projects face: business requirements often dictate unified URLs for better SEO and user experience, but data structure differences demand separate collections. Rather than forcing content into unnatural structures or creating awkward URLs, you can embrace both requirements by building smart disambiguation logic.

The key takeaway is this: let route detection be permissive (accept multiple possibilities), let database verification be authoritative (the true arbiter of which collection owns a slug), and let handler orchestration be sequential (first match wins). Together, these three layers create a clean, maintainable system that handles complex real-world scenarios.

You now have a reusable pattern that works for any number of collections on the same path. Whether you're dealing with events and workshops, products and content products, or blog posts and news articles, the approach remains the same: detect permissively, verify authoritatively, orchestrate sequentially.

Let me know in the comments if you have questions about adapting this pattern to your specific needs, and subscribe for more practical development guides.

Thanks, Matija