You’re starting a Payload build that needs SEO fields, a contact form, site search and redirects, and you want to know how much of that already exists. As of 10 November 2026, Payload 3.93.0 has 11 official plugins, and every one of them is released at the same version as the core (v3.93.0 release).
This guide covers what a plugin is, the official set and how often each one is installed, the plugins a website needs, community plugins, and how to choose. Our project template, the codebase our client projects start from, registers nine of the official plugins.
- What is a Payload plugin?
- Plugin, adapter or core feature?
- Which official plugins does Payload have?
- Which plugins does a Payload website need?
- Community plugins: where to find them and how to judge one
- How we run Payload plugins in production
- When should you write your own plugin?
- How to choose plugins for your Payload project
- Payload plugins: common questions
- What to do next
What is a Payload plugin?
A Payload plugin is a function that takes your Payload config and returns a changed copy of it (Payload plugins overview). You list plugins in the plugins array of payload.config.ts, and each one can add collections, fields, hooks, endpoints or admin views. For example, the SEO plugin gives every collection you name a set of fields for its page title, description and sharing image.
Plugins run once, when Payload starts. They run after Payload validates your config and before it fills in its defaults, so each plugin sees the config as you wrote it. The hooks a plugin adds run later, on every create, update or delete, which is where most of its work happens.
Order matters when one plugin needs something another one adds. By default, plugins run in the order of the array. Since version 3.83.0, released on 15 April 2026, the definePlugin helper lets a plugin declare an order, where lower numbers run first, and find other plugins by their slug (release notes). Payload marks that API as experimental.
We’ll use one illustration through this guide, a website for a group of dental clinics in the UAE. It has treatments nested under specialties, dentist profiles, an appointment request form, search, and redirects from the old site. Its config starts like this:
import { buildConfig } from 'payload'
import { seoPlugin } from '@payloadcms/plugin-seo'
import { redirectsPlugin } from '@payloadcms/plugin-redirects'
export default buildConfig({
// collections, db, editor and the rest of your config
plugins: [
seoPlugin({ collections: ['treatments', 'dentists'] }),
redirectsPlugin({ collections: ['treatments'] }),
],
})Plugin, adapter or core feature?
Payload connects outside services in three places in its config, and only one of them is the plugins array. Some features people search for as plugins are built into the core, and a few are sold under Payload’s Enterprise licence.
| What it is | Where it goes | Examples | Where to read more |
|---|---|---|---|
| Plugin | the plugins array | SEO, Redirects, Search, Form Builder | this guide |
| Storage adapter | the plugins array, built on plugin-cloud-storage | S3, Vercel Blob, Azure, Google Cloud Storage, R2 | where Payload stores uploaded files |
| Email adapter | the email property | Nodemailer, Resend | this guide, “Is email a Payload plugin?” |
| Database adapter | the db property | Postgres, MongoDB, SQLite | which database fits a Payload project |
| Core feature | built in | versions and drafts, localisation, authentication, the jobs queue | Payload’s docs |
| Enterprise feature | Payload’s Enterprise licence | SSO, publishing workflows, static A/B testing | Payload’s Enterprise page |
For example, the clinic’s dentist photos go to cloud storage through a storage adapter, and its confirmation emails go out through an email adapter. Neither appears in Payload’s list of official plugins. Payload’s Enterprise page also lists a Visual Editor, which is still to come as of 10 November 2026.
Which official plugins does Payload have?
Payload lists 11 official plugins, all MIT-licensed and all versioned with the core. The table shows what each one adds and how often each was downloaded from npm in the week of 2 to 8 November 2026 (fetched on 10 November 2026), next to the 1,551,720 downloads of the payload package in the same week (npm downloads API).
| Plugin | What it adds to your config | Weekly downloads | Share of core downloads |
|---|---|---|---|
| SEO | A meta group (title, description, image), generate functions and a search-result preview | 347,215 | 22.4% |
| MCP | An MCP server that lets AI clients work with your collections through API keys (setting up the MCP plugin) | 265,072 | 17.1% |
| Redirects | A redirects collection with from, to and type | 219,840 | 14.2% |
| Form Builder | forms and form-submissions collections, confirmation emails and an optional payment field | 166,088 | 10.7% |
| Nested Docs | parent and breadcrumbs fields | 165,741 | 10.7% |
| Multi-Tenant | A tenant field, a tenant selector and tenant-scoped lists (multi-tenancy in Payload) | 159,944 | 10.3% |
| Search | A search collection kept in sync, with priorities | 139,916 | 9.0% |
| Import Export | CSV and JSON import and export in the admin (moving content into Payload) | 59,434 | 3.8% |
| Sentry | Error and performance tracking through Sentry | 42,029 | 2.7% |
| Stripe | Data synced both ways with Stripe, and its webhooks proxied to your app | 18,604 | 1.2% |
| Ecommerce (Beta) | Products, variants, carts, orders and payments through adapters (building a store on Payload) | 16,680 | 1.1% |
Keep in mind that downloads aren’t projects. Every CI build and every new project made from a template counts, and Payload’s website template installs SEO, Redirects, Search, Form Builder and Nested Docs together, which is why four of those five sit between 9 and 15 per cent. Ecommerce is still in Beta, with breaking changes possible.
Payload’s repository holds a twelfth plugin package, plugin-cloud-storage, which the storage adapters are built on. Every storage adapter pulls it in, so it was downloaded 1,087,039 times that week.
Which plugins does a Payload website need?
Five of the official plugins cover most of a website, and three common needs have no plugin at all.
Is there a Payload SEO plugin?
Yes. The SEO plugin adds a meta group with a title, description and image to the collections and globals you choose. It adds buttons that fill those fields from functions you write, and a preview of how the page might look in search results. Your front end still renders the tags, and structured data such as JSON-LD goes into fields you add through the plugin’s fields option. Dynamic variables in the generated text are still to come.
For example, the clinic’s treatment pages can take their title from the treatment name and the clinic’s name, and their description from the treatment’s summary. Our template does the same, with titles in the form “page title | site name” and descriptions taken from the excerpt.
How do redirects work in Payload?
The Redirects plugin stores redirects as content, and your front end carries them out. It adds a redirects collection where each entry has a from URL and a to that’s either a URL or a document, with an optional type such as 301 or 302. Your site reads the collection and issues the redirect, so an editor can fix a broken link without a deploy.
For example, the clinic’s old /services/braces page can point at the new Clear aligners document. Payload’s website template looks up the document’s current slug when the redirect runs, so the redirect still lands on the right page if that treatment’s slug changes later. Our template offers 301 and 302 redirects on pages.
Does Payload have a sitemap plugin?
No, there’s no official sitemap plugin. Payload’s own website template builds its sitemaps with the next-sitemap package and two route handlers, one for pages and one for posts. Community sitemap plugins exist if you’d rather install one.
Our template uses a Next.js sitemap route that lists the home page and every public path. It’s prerendered and cached for seven days, and publishing a page clears the cache. Crawlers fetch sitemaps often, and rendering one on every request would cost a database query each time. For the clinic, the same route lists every specialty, treatment and dentist page.
Does Payload have an analytics plugin?
No official one. Page analytics belong in your front end, as a script in the layout that wraps every page, and that’s how our template does it.
If you want numbers inside the admin, a dashboard widget in the admin panel can show them, and community plugins add Google Analytics 4 or Plausible charts. The official Sentry plugin tracks errors and performance, so it doesn’t count visitors. Payload also sells static A/B testing under its Enterprise licence.
Is the Payload search plugin full-text search?
No. The Search plugin keeps a search collection in sync with the collections you choose. Each record holds a title, a link to the source document and any fields you add, plus a priority for sorting. You query it like any collection, and the like operator matches when every word is present, in any order. There’s no full-text index behind it and no relevance ranking beyond the priority you set.
That’s enough for a search box over titles and short excerpts, such as the clinic’s treatments and dentists. For full-text search across long pages, you add your database’s own text search or a hosted engine such as Algolia or Meilisearch, fed from hooks. Our template indexes pages at priority 10 and the site’s other collections at 5, leaves drafts out, and removes a record when its page is unpublished. With localisation on, each record’s title is localised too.
How do you build forms in Payload?
With the Form Builder plugin. Editors build forms in the admin from field types such as text, email, select and checkbox. Submissions save to your own database, and confirmation emails go out through your email adapter.
For example, the clinic’s appointment form lives in the admin, so the front desk can add a field without a developer. Keep in mind that, by default, anyone can create a submission and any user who can sign in to the admin can read every submission (plugin source). Our template tightens that access and leaves the payment field off.
Is email a Payload plugin?
No. Email is an adapter that goes in the email property of your config, and Payload has two official ones. The Nodemailer adapter sends through any SMTP server or Nodemailer transport. The Resend adapter sends through Resend’s API, and it’s the lighter choice on serverless hosts. Form Builder’s confirmation emails and Payload’s own verification and password reset emails all go through whichever adapter you set. Our template sends through Nodemailer over SMTP.
How do you do nested pages and breadcrumbs in Payload?
With the Nested Docs plugin. It adds a parent field and a breadcrumbs field to the collections you name, and fills the breadcrumbs with each ancestor’s label and URL. When a parent changes, every page below it updates. For example, moving Orthodontics under a new specialty rewrites the breadcrumbs of Clear aligners and every other page under Orthodontics.
Your front end renders the trail from the breadcrumbs field. The plugin works with localised fields, and our template runs it on pages only, building each URL from the chain of parent slugs.
Community plugins: where to find them and how to judge one
Payload points to the payload-plugin topic on GitHub for community plugins. On 10 November 2026 the topic held 346 repositories, and community directories such as payload.market and payloaddirectory.dev listed between 299 and 568 plugins, depending on what each one counts. No list is complete, so search npm for the job as well.
Before a community plugin touches your schema, run five checks:
- Version range. Run
npm view <package> peerDependenciesand check that itspayloadrange includes the version you run. A plugin written for Payload 2 won’t load on Payload 3. - Release pace. Compare its last release with Payload’s. Payload released four minor versions between 18 September and 4 November 2026, 3.90 to 3.93 (releases).
- What it adds to your schema. Read its config function. Every collection and field it adds becomes tables and a migration on Postgres or SQLite, and data you’d have to move if you take the plugin out.
- Its hooks. A plugin’s hooks run inside your saves, so a hook that throws can fail a save that has nothing to do with the plugin’s feature.
- Who answers issues. Open issues with replies from the maintainer tell you more than the star count.
For example, a community sitemap plugin passes for the clinic if its peer range covers 3.93, it adds no collection you’d have to migrate away from, and its releases have kept pace with Payload’s. Our template runs no community plugins. Everything it needs comes from the official set or from plugins we wrote.
How we run Payload plugins in production
Our project template registers nine official plugins: SEO, Nested Docs, Form Builder, Search, Redirects, Import Export, MCP, Multi-Tenant and Ecommerce. The notes below describe its 4 November 2026 release, which runs Payload 3.90.1.
Every Payload package on one version. All 18 payload and @payloadcms packages are pinned to the same exact version, so a fresh install can’t pull a plugin that’s ahead of or behind the core.
Plugins that add collections before Multi-Tenant. Form Builder, Search, Redirects and every plugin of ours that adds a collection register before Multi-Tenant. Otherwise their collections aren’t tenant-scoped. The template doesn’t use definePlugin, because the array order does the job.
Files on Vercel Blob. Uploaded files go to Vercel Blob through its storage adapter.
If you’d rather a team set up and maintain these plugins for you, that’s part of our Payload CMS development work.
When should you write your own plugin?
Write your own when the feature is yours to maintain across projects and no official or maintained community plugin covers it. A one-off hook on one collection is simpler left where it’s used. Payload’s plugin template gives you a package with a development project and tests to start from.
Our template carries five plugins we wrote, and the workflows and Intercom plugins already run this site:
| Our plugin | What it adds | Payload pieces it uses |
|---|---|---|
| Intercom | A settings global so non-engineers can tune the messenger without a redeploy, contact and event sync to Intercom, and an optional sync of users as contacts | a global, background jobs, a hook |
| WhatsApp Business through Meta’s Cloud API, with every message tracked, sending in the background, and incoming messages and delivery status received | a collection, a background job, an endpoint, fields added to the tenant record | |
| Workflows | An automation engine with rules, stored credentials, approvals that wait for a person, execution logs as an audit trail, and eight step types | collections, hooks that start a workflow when content changes |
| Dynamic data | Custom fields, record types and data-driven page blocks that tenant admins define in the admin, validated and access-controlled per role, plus roles per tenant | collections, fields, blocks, access functions |
| Ecommerce wrapper | The official Ecommerce plugin, off until a project sells, with our Razorpay and cash-on-delivery payment adapters | another plugin, payment adapters |
Each of the five bundles pieces that only work together, such as the WhatsApp plugin’s collection, job and endpoint, and each one arrives in every new project with the template. The WhatsApp plugin also adds its settings fields to the tenant record, a collection it doesn’t own. Dynamic data ships as its own package shared across projects, so a tenant admin adds a field without a developer, a migration or a deploy. What the Ecommerce plugin covers explains where payment adapters fit.
For example, if the clinic’s appointment requests have to reach its practice management system, a plugin can add a sync status field to submissions, a hook that sends each request, and an endpoint that retries failures. Packaged that way, the same plugin moves to the clinic group’s next site unchanged.
How to choose plugins for your Payload project
Work through the build’s needs in this order:
- List what the site or app needs, feature by feature.
- Check the core first. Versions, drafts, localisation, authentication and scheduled jobs need no plugin.
- Take the official plugin where one exists.
- Treat files, email and the database as adapters, chosen for where you host.
- Judge a community plugin with the five checks for community plugins.
- Write your own when nothing official or maintained covers it and you’ll reuse it across projects.
- Pin every Payload package to the core’s version, and update them together.
For the clinic, that adds up to SEO, Redirects, Nested Docs, Search and Form Builder from the official set, an email adapter for confirmations, a sitemap route, an analytics script in the front end, and one plugin of its own for the booking sync.