Serve Multiple Payload CMS Collections from One Route
Disambiguate slugs in Next.js with Payload CMS using route detection, direct verification, and handler orchestration…
📚 Comprehensive Payload CMS Guides
Detailed Payload guides with field configuration examples, custom components, and workflow optimization tips to speed up your CMS development process.
Related Posts:
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.
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
