--- title: "Best Payload CMS Plugins in 2026: Official & Community Picks" slug: "best-payload-cms-plugins" published: "2026-03-25" updated: "2026-10-05" categories: - "Payload" tags: - "payload cms plugins" - "best payload cms plugins" - "payload plugins" - "payload cms plugin" - "payload 3 plugins" - "payloadcms plugins" - "payload mcp plugin" - "payload ecommerce plugin" - "payload multi-tenant plugin" - "payload redirects plugin" - "payload auth plugins" - "payload admin feedback plugin" llm-intent: "reference" audience-level: "intermediate" framework-versions: - "payload cms" - "@payloadcms/plugin-seo" - "payload-auth-plugin" - "auth.js (nextauth)" - "payload-ai" status: "stable" llm-purpose: "Payload CMS plugins: Discover top official and community plugins for authentication, AI, search, SEO and developer experience. Compare compatibility and…" llm-prereqs: - "Access to Payload CMS" - "Access to @payloadcms/plugin-seo" - "Access to payload-auth-plugin" - "Access to Auth.js (NextAuth)" - "Access to payload-ai" llm-outputs: - "Completed outcome: Payload CMS plugins: Discover top official and community plugins for authentication, AI, search, SEO and developer experience. Compare compatibility and…" --- **Summary Triples** - (@payloadcms/plugin-seo, provides, meta management (meta titles, descriptions, OG images), auto-generation hooks and a search-result preview inside the admin) - (@payloadcms/plugin-search, solves, search performance and indexing needs by integrating Payload with external search engines and optimizing queries) - (payload-auth-plugin, integratesWith, Auth.js/NextAuth-style workflows to provide authentication flows for Payload projects) - (payload-ai, integratesWith, OpenAI (and similar providers) to enable AI-assisted content generation and editor tooling in the Payload admin) - (Algolia / Meilisearch, usedFor, scalable, low-latency full-text search when paired with Payload via search plugins or connectors) - (Lexical, usedFor, modern rich-text editing in the admin (a recommended alternative to heavier WYSIWYG editors)) - (import-export plugin, enables, content migration, backups and bulk data transfers between Payload instances) - (multi-tenant plugins, provide, tenant scoping and data isolation patterns necessary for SaaS/multi-site Payload projects) - (official Payload plugins, are, maintained by the core team and kept in sync with Payload releases for higher stability) - (OpenAPI plugin / spec, usefulFor, documenting Payload APIs and generating typed clients for integrations) ### {GOAL} Payload CMS plugins: Discover top official and community plugins for authentication, AI, search, SEO and developer experience. Compare compatibility and… ### {PREREQS} - Access to Payload CMS - Access to @payloadcms/plugin-seo - Access to payload-auth-plugin - Access to Auth.js (NextAuth) - Access to payload-ai ### {STEPS} 1. Review official Payload plugins 2. Evaluate authentication plugin options 3. Add AI-assisted content tools 4. Improve developer experience with plugins 5. Discover and vet community plugins # Best Payload CMS Plugins in 2026: Official & Community Picks > Best Payload CMS plugins in 2026, refreshed for Payload 3.90: official picks like SEO, Redirects, Multi-Tenant and MCP, community auth and AI plugins… Matija Žiberna · 2026-03-25 I refreshed this guide in October 2026 because the Payload plugin ecosystem has changed materially since the first version. Payload now ships a substantial official plugin set covering SEO, redirects, search, multi-tenancy, MCP, ecommerce, Stripe and Sentry, which removes a lot of custom work that used to be unavoidable. The first place I look on any project is that official set, because maintenance and compatibility matter more than the length of a feature list. Community plugins become valuable around authentication, AI workflows, editorial experience and specialist functionality. What follows is my current shortlist of plugins I would consider for production Payload projects, with the limitations that matter before adopting each one. Versions referenced were checked against Payload 3.90.2. ## What counts as a plugin Plugin does not mean every optional Payload package. Four different things get lumped together under that word, and separating them makes the rest of the decisions easier. | Category | Meaning | Examples | |---|---|---| | Official plugins | First-party extensions maintained with Payload | SEO, Search, Multi-Tenant, MCP, Ecommerce | | Community plugins | Third-party extensions to Payload capabilities | Auth integrations, AI tooling, admin enhancements | | Adapters | Infrastructure integrations that connect Payload to a service | S3, Azure, GCS, Vercel Blob storage | | Custom extensions | Functionality you implement through hooks, components, collections or endpoints | Approvals, governance, specialised workflows | Storage adapters such as `@payloadcms/storage-s3`, `@payloadcms/storage-vercel-blob`, `@payloadcms/storage-gcs` and `@payloadcms/storage-azure` are infrastructure choices that follow from where you host. They are not ranked below, because they do not compete with application plugins for a place in your architecture. ## Decision table This table is the short version. Each row is expanded in the sections below. "My take" is a judgement about trust, and the maintenance column shows the date of the latest release or commit I could verify, because star counts say little about whether a package will keep up with Payload. | Plugin | Category | Use it for | My take | Maintenance | |---|---|---|---|---| | `@payloadcms/plugin-seo` | Official | Meta fields, auto-generation, search preview | Default choice | Released with Payload | | `@payloadcms/plugin-redirects` | Official | CMS-managed redirect records | Default choice | Released with Payload | | `@payloadcms/plugin-search` | Official | Synced search collection | Strong option | Released with Payload | | `@payloadcms/plugin-multi-tenant` | Official | Tenant field, scoping, admin filtering | Strong option, needs architecture around it | Released with Payload | | `@payloadcms/plugin-import-export` | Official | Editor-driven CSV and JSON operations | Project-dependent | Released with Payload | | `@payloadcms/plugin-form-builder` | Official | Admin-built forms and submissions | Project-dependent | Released with Payload | | `@payloadcms/plugin-mcp` | Official | MCP endpoint for AI clients | Strong option | Released with Payload | | `@payloadcms/plugin-ecommerce` | Official | Commerce primitives, currently Beta | Evaluate carefully | Released with Payload | | `@payloadcms/plugin-stripe` | Official | Stripe sync, webhooks, REST proxy | Project-dependent | Released with Payload | | `@payloadcms/plugin-sentry` | Official | Error and performance monitoring | Strong option | Released with Payload | | `payload-auth` | Community | Better Auth for admin and app | Strong option | v3.0.0, Aug 2026 | | `payload-authjs` | Community | Auth.js sessions | Evaluate carefully | May 2026 | | `payload-auth-plugin` | Community | OAuth and SSO provider logins | Project-dependent | May 2026 | | `payload-oauth2` | Community | Generic OAuth2 login | Specialist | May 2026 | | `payload-totp` | Community | TOTP two-factor for admins | Specialist | Oct 2026 | | `@ai-stack/payloadcms` | Community | AI generation in the admin | Project-dependent | Sep 2026 | | `payload-oapi` | Community | OpenAPI spec generation | Specialist | Oct 2026 | | `payload-lexical-typography` | Community | Typography controls in Lexical | Specialist | Nov 2025 | | `@matija2209/payload-plugin-admin-feedback` | Community (mine) | In-context client feedback | Specialist | v1.0.4, May 2026 | ## Official Payload plugins I would start with The official plugins live in the Payload monorepo and are versioned with Payload itself. For the packages in this section, the `payload` peer dependency is pinned to the exact release, which removes the compatibility lag that causes most plugin upgrade problems. That is why I treat them as the baseline and look for gaps in them before reaching for anything else. ### SEO `@payloadcms/plugin-seo` adds a `meta` field group with title, description and image to the collections you choose. Editors can auto-generate those values through `generateTitle` and `generateDescription` functions you write, and a search result preview renders under the fields and updates as they type. ```typescript // File: payload.config.ts seoPlugin({ collections: ['pages', 'posts'], uploadsCollection: 'media', generateTitle: ({ doc }) => `${doc.title} | Build with Matija`, generateDescription: ({ doc }) => doc.excerpt, }) ``` I would use it on any content-driven website. It handles the CMS metadata layer only. The frontend still owns rendering that metadata correctly, which means wiring `generateMetadata` in Next.js, canonical URLs, Open Graph tags and structured data. If you run several sites from one install, [multi-tenant SEO with Payload and Next.js](/blog/multi-tenant-seo-payload-nextjs-guide) covers where per-site metadata logic goes. I trust this plugin as infrastructure. ### Redirects `@payloadcms/plugin-redirects` adds a `redirects` collection with `from` and `to` fields, where `to` can point at a document reference. The plugin manages redirect records in the admin panel and the database. It does not perform the redirect. Your frontend queries the collection and issues the HTTP redirect, which is the part teams forget when they install it. This deserves its own place in a plugin stack because redirects carry real SEO weight during migrations and slug changes, and editors should be able to fix a broken URL without a deploy. Redirect coverage belongs in every migration plan, and the [Payload CMS migration service](/payload-cms-migration) page describes how it fits the wider process. The multi-tenant case needs extra thought, since the same path can mean different pages on different sites, which I cover in [Payload redirects across tenants and locales](/blog/payload-redirects-plugin-multi-tenant-multi-locale-301s). I would use this plugin by default and trust it as infrastructure. The sibling package `@payloadcms/plugin-nested-docs` handles parent and child page hierarchies with generated breadcrumbs. It is a good fit for page trees, and the [nested docs breadcrumbs guide](/blog/payload-nested-docs-multi-tenant-breadcrumbs) covers the tenant-aware version. ### Search `@payloadcms/plugin-search` creates a separate `search` collection and keeps a static copy of selected fields from your other collections in sync through hooks. You query it with the normal Payload APIs and sort by a `priority` value you control per collection or per document. I would use it for ordinary CMS search over controlled, indexed content: a site search bar, a docs search, a blog index. It stops where search becomes its own product. Large catalogues, complex ranking, typo tolerance and faceting are the cases where Algolia, Meilisearch or similar infrastructure earns its cost. For shared indexes across sites, see [the Payload multi-tenant search guide](/blog/payload-cms-multi-tenant-search-shared-index). It is a strong option with a clear boundary. ### Multi-Tenant `@payloadcms/plugin-multi-tenant` is the official tenant foundation. It adds a `tenant` field to the collections you list, a tenant selector in the admin panel, filtering of list views and relationship fields by the selected tenant, automatic tenant assignment for new documents, and rejection of writes that assign a tenant the user does not belong to. It can also treat a collection as a per-tenant global, with one document per tenant. That is the foundation. A production multi-site system needs a lot more around it, and I have built that surrounding layer for a single Payload installation serving several brands. A tenant field does not decide who can edit which brand, how departments split access within a brand, who may publish and who may only draft, how content on one site references content on another, how the frontend learns which site a request belongs to, or where brand-specific configuration lives. Roles, site memberships, departmental permissions, publishing gates and frontend site context are all your design work. The plugin also deletes related documents by default when a tenant is deleted (`cleanupAfterTenantDelete`), so access control on the tenants collection deserves careful thought. Multi-tenancy is an architecture problem, and the plugin is one component of the solution. I wrote down the access model decisions in [Payload multi-tenant versus access control: a decision framework](/blog/payload-cms-multi-tenant-vs-access-control-decision-framework), and the boundary question in [how to choose the right tenant boundary](/blog/payload-cms-tenant-durability-boundary). Localization has its own traps, covered in [multi-tenant localization setup and gotchas](/blog/payload-multi-tenant-localization). I would use this plugin as the starting point for any multi-site build and plan the rest deliberately. If a build like this is on your roadmap, the [Payload CMS audit](/payload-cms-audit) is where I review the tenant model before it hardens. ### Import/Export `@payloadcms/plugin-import-export` adds CSV and JSON export through the admin UI, with import back into a collection, a preview step before either operation, and jobs-queue processing for large runs. The queue needs a configured runner (`jobs.autoRun`), otherwise imports and exports sit in a pending state. I would use it for editor-controlled operations: bulk field updates, structured exports for a client, recurring data fixes. Application migration is a separate problem. On a project with hundreds of normalised products carrying relationships, localized fields and media, an editor-driven CSV import is the wrong tool, and a deliberate ETL pipeline with validation, ordering and idempotent re-runs is the right one. I describe that route in [building a CSV product import system with Payload queues](/blog/bulk-data-import-with-payload-queues). Project-dependent, and trusted for what it is designed to do. ### Form Builder `@payloadcms/plugin-form-builder` lets editors build forms in the admin panel, store submissions in the database, send emails on submission and show a confirmation message or redirect. You render the form on the frontend with your own components. It replaces external form tooling for contact forms, lead forms, surveys and editable landing page forms. It does not cover custom workflows such as routing a lead into a CRM, multi-step logic tied to your data model, or automation after submission. Those need custom collections, hooks or an external system, and the [Payload and n8n integration patterns](/blog/payload-cms-n8n-integration-operational-workflows) show one way to connect them. Project-dependent. ### MCP `@payloadcms/plugin-mcp` turns a Payload instance into an MCP server. After `mcpPlugin({})` is added to the plugins array, `POST /api/mcp` accepts MCP requests, and every collection and global is reachable through generic tools such as `getConfigInfo`, `getCollectionSchema` and `findDocuments`. This is more than an AI plugin. It makes Payload an interface that agents can interact with programmatically while the CMS stays the controlled content and permissions layer. The pieces that matter for production: | Capability | What it gives you | |---|---| | Tools | Built-in discovery and CRUD tools, plus custom tools defined with `defineTool` | | Resources and prompts | Custom resources and prompts you expose to clients | | Operation restrictions | Per-collection control over which operations are enabled | | Access control | API keys with per-key capabilities, code-level `access` callbacks, and normal Payload access rules still protecting documents | | Response shaping | `overrideResponse` to sanitise what a model receives | I would use it where an organisation wants structured content to be reachable by agents, which ties into the wider work of making content infrastructure AI-ready. The plugin handles the protocol and the permission hooks. You still design which operations an agent should have, how sensitive fields are filtered, and how to authenticate remote clients. My [security-first Payload MCP integration guide](/blog/secure-payload-mcp-integration) documents a production setup, including a slug case-sensitivity failure I hit along the way. Strong option, and trusted as infrastructure as long as you restrict operations deliberately. ### Ecommerce `@payloadcms/plugin-ecommerce` provides commerce primitives: products with variants, carts tracked in Payload, orders, transactions, addresses linked to customers, multiple currencies, React utilities for frontend logic and a payments adapter pattern with Stripe supported today. It is currently marked Beta in the Payload documentation, so breaking changes are possible between releases. The plugin does not handle shipping, taxes or subscriptions natively, and it is not a Shopify replacement. Production commerce needs decisions on shipping rules, tax calculation, fulfilment, subscriptions, inventory and integrations with the systems around the shop. My [walkthrough of the ecommerce plugin with Stripe, carts and orders](/blog/payloadcms-plugin-ecommerce-stripe-cart-orders-guide) covers the build, and [the ecommerce plugin compared with Medusa](/blog/payload-cms-ecommerce-plugin-vs-medusa) covers when each fits. For budgeting a shop on Payload, the [Payload CMS pricing guide](/payload-cms-pricing) breaks down the variables. Evaluate carefully, and pin versions while it is Beta. ### Stripe `@payloadcms/plugin-stripe` solves Stripe-specific integration problems. It syncs Payload collections with Stripe resources such as customers and products, stores a read-only `stripeID` for cross-reference, handles webhooks for events like `customer.subscription.updated`, and proxies the Stripe REST API through Payload access control at `/api/stripe/rest` with an explicit method allowlist. The ecommerce plugin supplies commerce-domain primitives. The Stripe plugin supplies Stripe synchronisation. They complement each other: the ecommerce plugin's Stripe adapter covers taking payments, and the Stripe plugin is useful when you also need customers or subscriptions mirrored between systems. Because the ecommerce plugin does not do subscriptions natively, that mirroring is often where subscription logic starts. Project-dependent. ### Sentry `@payloadcms/plugin-sentry` connects Payload to Sentry for exception visibility, performance monitoring and stack traces with context. It requires Sentry's Next.js setup first, and by default it captures errors with a 500 or higher status, with `captureErrors` for adding more codes. I would install it on every production project. It is infrastructure for debugging and reliability, and its presence in the official list shows how far the ecosystem extends beyond editorial features. ## Community plugins I would actually shortlist This is a curated shortlist organised by problem. It is not a catalogue. I checked each package's Payload peer dependency and latest activity on npm and GitHub in October 2026. ### Authentication Authentication architecture depends on who owns authentication. Payload may own it for the admin and a small set of users. The wider Next.js application may share it with Payload. An external identity provider may sit in front of both. No single plugin wins across those cases, and the [comparison of Payload auth plugins](/blog/which-payload-cms-auth-plugin-to-use) works through the decision in detail. | Approach | Plugin | When I would consider it | |---|---|---| | Better Auth shared by admin and app | `payload-auth` | Greenfield projects wanting one auth system across the admin and the application | | Auth.js sessions | `payload-authjs` | Existing Auth.js applications, with the caveat below | | OAuth and SSO provider logins | `payload-auth-plugin` | Provider-based login and enterprise-style SSO, with protocol coverage documented at authsmith.com | | Generic OAuth2 | `payload-oauth2` | Google, GitHub or another standard provider without a larger auth layer | | Stronger admin authentication | `payload-totp` | TOTP second factor for admin-heavy applications | On `payload-authjs`, its own README warns that Auth.js v5 is still in beta and that Auth.js is now part of Better Auth, so its long-term path is uncertain. That is the reason I mark it "evaluate carefully" and lean toward `payload-auth` for new builds. Payload's native auth is often enough, and the [cookie auth with Next.js guide](/blog/payload-cms-cookie-auth-nextjs) shows the architecture without a third-party layer. ### AI and localization I only shortlist AI plugins where the workflow is concrete and measurable in editor time saved. `@ai-stack/payloadcms` (the `payload-ai` repository) adds text, image and voice generation, and translation inside the admin panel, supporting several providers. It fits teams that publish a lot of content or work across languages and want drafting help without leaving Payload. Budget for provider costs and keep a human review step before publishing. For translation of localized fields at scale, a plugin button runs into the same limits as any synchronous request. Long translation runs belong in background jobs, which I describe in [automating Payload translations with OpenAI and job queues](/blog/automating-payload-cms-translations-openai-job-queues). ### Admin and editorial experience These are workflow improvements and not core architecture dependencies, so I add them last and remove them without much pain. Payload already has a native capability for in-context editing. Before adding any visual editing package, check whether Live Preview covers the need. The [Live Preview implementation guide](/blog/live-preview-payload-cms-nextjs-implementation-guide) shows the setup with no extra dependency, and the [Payload CMS demos](/payload-cms-demos) show it running. The `payload-visual-editor` package still appears in searches, but its peer dependency targets Payload 2 (`^2.0.13`) and its last release was in March 2024, so I do not recommend it for a Payload 3 project. `payload-lexical-typography` adds font, size, line height and colour controls to the Lexical editor. It is useful when editors need more inline styling than the default editor offers. It declares peer dependencies on the Lexical and UI packages (`^3.43.0`) and none on `payload` itself, so test it against the exact Payload version you run. Its latest release is from November 2025, so I treat it as a specialist option. The `payload-bites` repository is a collection of small packages such as soft delete, activity log, audit fields, content freeze and a broken link checker. It is worth scanning before you write a utility by hand, and each package deserves the same vetting as any other dependency. For custom admin work that no plugin covers, the [guide to custom admin fields and views](/blog/payload-cms-custom-admin-ui-components-guide) shows the native route. ### Developer tooling `payload-oapi` generates OpenAPI 3.0 and 3.1 specifications from a Payload instance and includes Swagger UI and Rapidoc. I would use it when a Payload project is an integration surface for other teams or third parties, and a generated contract replaces hand-written endpoint documentation. It was updated in October 2026 and supports Payload `^3.0.0`. ## My own plugin: admin feedback I built `@matija2209/payload-plugin-admin-feedback` because of a recurring problem on client projects. Client QA and feedback arrives as screenshots in Slack, vague descriptions and messages with no route context, and someone has to reconstruct which page and which element the comment meant. The plugin keeps the feedback inside the application. A floating widget captures the message, the current page path, an optional CSS selector, and a screenshot that can be annotated with pen, rectangle, arrow and text tools. Each submission creates a record in an `admin-feedback` collection and sends an email notification through the Payload email adapter you already use, with a direct admin link. It works in the Payload admin and on selected Next.js frontend routes. I do not position it as an ecosystem standard. It is at v1.0.4, it requires Payload `^3.84.1`, and it is a specialist tool. I include it as a firsthand example of when writing a plugin makes sense: a repeated problem, a clear boundary, and behaviour that several projects can share. It also uses `definePlugin`, so it doubles as a real example of the API described later in this guide. ![payload-plugin-admin-feedback header](https://github.com/matija2209/payload-plugin-admin-feedback/blob/master/public/payload-admin-plugin-header.png?raw=true) ## When I would not install a plugin A plugin is a dependency, and it also adds extension points and config changes that your project inherits. I usually avoid a plugin when: - the required behaviour is only a small hook you could write in a few lines - the plugin alters important collection behaviour in ways the team does not understand - maintenance activity is weak - its peer dependencies lag behind Payload releases - the project needs substantially different behaviour anyway - the feature is part of the project's core business logic Complex approvals and publishing governance are the clearest example. They tend to become business-specific quickly: who reviews what, which content types need two approvers, what happens when a reviewer is on holiday, how a publish gate differs between brands. Explicit collections, hooks and access rules are easier to reason about than a generic workflow plugin bent to fit. A [Payload CMS audit](/payload-cms-audit) is a good point to check whether a plugin has ended up carrying business logic it should not. ## How I evaluate a community Payload plugin I run the same checklist on every community package before it enters a project. GitHub stars are a useful discovery signal and carry no weight in the decision. | Check | What I look for | |---|---| | Payload peer dependency | A range that includes the Payload version I run, and a history of following Payload releases | | Latest release and commits | Activity in the last few months, and releases that match the commit history | | Open issues | Whether the maintainer responds, and whether reported breakages get fixed | | Test coverage | Tests that exercise the plugin against a real Payload instance | | Documentation | Setup, options, and known limitations written down | | TypeScript quality | Typed options and exported types without casts | | Config mutation | How many collections, fields, endpoints and admin components the plugin changes | | Introduced collections and fields | Which ones appear in my schema and database | | Registered hooks | Which hooks run on my collections, and when | | Migration implications | What database migrations installation and upgrades require | | Removal | How hard it is to take the plugin out later, including the data it created | The last three often decide the outcome. A plugin that registers hooks on collections you rely on, adds tables, and cannot be removed without losing data is a much larger commitment than its install command suggests. ## How Payload plugins work in 2026 The mental model is unchanged: a plugin is a function that receives the incoming config and returns a modified config. Payload's documentation describes that contract as stable, and it can add collections, fields, hooks, endpoints and admin components. This is the plain form: ```typescript // File: my-plugin/src/index.ts import type { Config } from 'payload' export const myPlugin = (options: MyOptions) => (config: Config): Config => ({ ...config, collections: [...(config.collections || []), myCollection], }) ``` Plugins run in array order by default, and they transform the config before Payload sanitises and initialises it. Hooks a plugin registers run later, during operations, which is a separate phase. ```mermaid flowchart TD A["Base config"] --> B["Plugins sorted by order"] B --> C["Plugin receives config, options and plugins map"] C --> D["Returns modified config"] D --> E["Next plugin"] E --> F["Sanitize config and initialize Payload"] ``` *Config transformation happens once at startup. The hooks a plugin adds execute later at runtime.* Payload also documents an advanced API, currently marked experimental, built around `definePlugin`. It adds a `slug`, an execution `order` (lower values run first, default `0`), typed `options`, and a `plugins` map that lets one plugin find another and adjust its options before it runs. ```typescript // File: my-plugin/src/index.ts import { definePlugin } from 'payload' type SEOPluginOptions = { collections: string[] } export const seoPlugin = definePlugin({ slug: 'plugin-seo', order: 10, plugin: ({ config, options }) => ({ ...config, collections: [...(config.collections || [])], }), }) ``` Plugin packages can augment the `RegisteredPlugins` interface so the `plugins` map is typed for consumers. Because the API is experimental, I use it for published plugins and accept that its surface may shift. The full workflow, including packaging and publishing, is in [building publishable Payload plugins with definePlugin](/blog/build-payload-plugins-defineplugin). For admin UI, the server and client split matters. Components are referenced from the config by path and resolved through the import map, so client components belong in their own exported entry point with `'use client'` at the top, while server components and config logic stay on the server side of the package. Mixing them is a common source of build errors in plugin packages. ## How to discover more plugins Payload does not run a marketplace. The official plugin list lives in the [Payload plugin documentation](https://payloadcms.com/docs/plugins/overview), and community plugins are discoverable through the [`payload-plugin` GitHub topic](https://github.com/topics/payload-plugin) and npm. The documentation itself says plugins change quickly, so check back often. Discovery is the first step only. A plugin appearing in a topic list or a package search does not make it production-ready. For anything that will sit deep in your architecture, read the source: look at what it adds to the config, which hooks it registers and what it writes to the database. ## The hierarchy I follow Start with the official plugins. Use community packages where they solve a defined problem and show credible maintenance signals. Keep core business workflows in code you control when their behaviour is specific to the business. The ecosystem is increasingly useful because you no longer need to rebuild every common capability yourself. Payload's underlying extension model still gives you an escape hatch when the plugin abstraction stops fitting. If you are evaluating Payload for a production CMS, a multi-site platform or a migration, I help teams design and build the architecture around it. See how I work as a [Payload CMS developer](/payload-cms-developer). If you are still deciding on the CMS itself, the [CMS picker tool](/tools/cms-picker) gives a quick recommendation, and the [Payload CMS cost estimator](/tools/payload-cms-cost-estimator) helps size the budget. Thanks, Matija ## LLM Response Snippet ```json { "goal": "Payload CMS plugins: Discover top official and community plugins for authentication, AI, search, SEO and developer experience. Compare compatibility and…", "responses": [ { "question": "What does the article \"12 Best Payload CMS Plugins to Boost Your Project Now\" cover?", "answer": "Payload CMS plugins: Discover top official and community plugins for authentication, AI, search, SEO and developer experience. Compare compatibility and…" } ] } ```