The Payload CMS Plugins We Actually Install (and Those We Scrap for 20 Lines of Code)

When you search for payload cms plugins, every list will tell you the same top‑10 with no mention of what actually breaks when you upgrade Payload 3 inside a Next.js app. We evaluate every plugin by three hard metrics: admin bundle growth (how much JavaScript it forces onto every content editor), migration burden (whether it silently creates collections or fields that you’ll have to baby across Payload 3.x releases), and upgrade risk (how often the plugin caused a white‑screen admin on a minor version bump). We learned these the hard way — once, a mid‑launch schema migration failed because a plugin’s field definition didn’t survive payload migrate:create, leaving the site down while we hand‑edited JSON. Never again.

On a project like the Work Well Mats quoting site, where buyers either check out in two minutes or need a guided mat‑finder and a whole‑site quote, every kilobyte of admin JS and every extra database collection directly slowed down the content team. That real‑world pressure is what drives this list. Here are the payload cms plugins we actually install, the ones we yank after a one‑time job, and the features we now replace with less code than a plugin’s README.

¹ Measured on a fresh Payload 3.0.3 + Next.js install with ANALYZE=true next build.

SEO Plugin: Always Install, But Don’t Blindly Trust the Defaults

Best for: Every public‑facing Payload site — blogs, e‑commerce, lead‑gen pages.

We install the official SEO plugin before the first commit. Its admin bundle footprint is negligible (~18 KB gzipped), and because it’s nothing more than a meta field group plus a tabbedUI helper, it survives Payload upgrades without drama. The only con: the default uploadsCollection setting is undefined, so you’ll manually point it to your media slug. Missing that makes the social‑image field invisible, which cost us a launch checklist panic.

Tradeoff: You lose fine‑grained control over structured data if you need JSON‑LD beyond Open Graph. For most projects that’s fine; if you need rich snippets, a small custom hook still beats dragging in a second plugin.

Search Plugin: Use for Simple Blogs, Skip for Anything Custom (Here’s Why)

Best for: Traditional content sites where the search query is a single text box hitting a single content collection.

The payload‑search plugin is beautifully engineered, but it’s the biggest admin‑bundle liability we’ve shipped. On a fresh instance it added over 200 KB gzipped to the admin — unacceptable for clients accessing the panel from a factory floor on a mobile hotspot. It also creates its own search collection, which tripped our migrations when Payload 3.1 changed the index strategy: we had to drop and recreate the collection manually.

What broke in production: After the 3.1 upgrade, the admin search UI still rendered but returned zero results until we ran a custom reindex script. That script wasn’t documented; we found it by reading the plugin’s source.

For the Work Well Mats mat‑finder — a three‑question tool that recommends floor material based on wetness, oil, and shape — the search plugin couldn’t filter on computed relationships. Instead we wrote a custom endpoint that joins questions → answers → products in three lines of Payload’s local API, served as a Next.js React Server Component. Lighter, faster, and we control the schema.

Import/Export Plugin: Great for One‑Off Migrations, Dangerous in Production

Best for: Migrating legacy data into Payload, or a one‑time CSV dump for a stakeholder.

We used the Import/Export plugin to pull 1,200 SKUs out of a legacy WooCommerce store and into the Payload backend that would later power Work Well Mats. It handles mapping well and generated clean migration scripts. But we never leave it in production. It adds a bulk‑export button to every collection list view — an open data‑leak vector if someone with read access forgets it’s there.

Tradeoff: For ongoing client‑facing reporting we now build a bespoke CSV export endpoint in Next.js, which takes 12 lines of code and gives us server‑side filtering that the plugin can’t match.

What We Replaced with Twenty Lines of Custom Code: The Quote Builder and Mat Finder

Best for: Everything that feels “plugin‑shaped” but whose constraints you’d discover only after launch.

Both the quote builder and the guided mat‑finder on the Work Well Mats project started as “let’s find a plugin”. We evaluated a popular community form builder and a PDF exporter; each added north of 100 KB to the admin, migrated three new collections that we’d have to maintain across Payload versions, and — when Payload 3.0 shipped — broke because custom field components weren’t compatible with the new React‑18 concurrent renderer.

Instead we built:

• A quote builder as a custom Admin view with Payload’s CustomProvider, backed by a quotes collection with block‑based line items. The PDF is generated on‑demand with @react-pdf/renderer inside a Next.js API route — the entire generator is under 40 lines. No plugin migration surface, no bundle growth.
• A mat finder with a React state machine in a client‑side admin component that calls Payload’s local API, filters products by floorMaterial, oilResistance, and shape, then creates a quote request. Twenty lines of logic that would have been spread across 3 plugin config files and a buggy conditional‑logic UI.

If you’re building a Next.js + Payload app with similarly custom workflows, a Next.js development partner that understands Payload’s extensibility can save you the weeks of bending plugins to do what twenty‑line components do natively.

The Payload CMS Plugins That Make the Grade

We didn’t even touch the other 16 in the usual roundup. Authentication, media transforms, and i18n are often better handled by Payload’s built‑in hooks and custom fields unless you’re dealing with multi‑tenant auth or direct Cloudflare R2 uploads — those two niche cases are the only time we’d reach for a third‑party plugin today. For everything else, the admin panel is so rich that a Custom Component gives you the same UI with zero production surprises.

So next time you’re evaluating a payload cms plugin, ask not “does it do what I need?” but “what will I have to fix when Payload 3.4 drops?” — and check the bundle inspector before you merge.

FAQ

Which Payload CMS plugins should I install first?

Start with the official SEO plugin. It’s lightweight, pays off in organic traffic, and its migration surface is tiny. For an ecommerce or content site, that alone covers your most critical need. Skip the search plugin unless you have a pure blog with simple full‑text needs. Everything else — quotes, complex filtering, PDF generation — is usually faster, safer, and cheaper to build with Payload’s own hooks and custom components.

How do I evaluate a Payload plugin’s impact on admin performance?

Use Next.js built‑in bundle analysis (ANALYZE=true with @next/bundle-analyzer). A healthy plugin adds <30 KB gzipped to the admin JavaScript bundle. The official SEO plugin sits around 18 KB; the search plugin pushes past 200 KB due to its embedded index viewer. Also watch the migrations folder after payload migrate:create — if a plugin creates new collections or fields you didn’t expect, you’ll feel it during the next Payload version jump.

Can I build custom functionality without plugins in Payload?

Yes, and that’s the core superpower of Payload 3 inside Next.js. Custom admin views, server‑side logic, and on‑demand PDF generation can all live directly in your app directory as React Server Components or API routes. On the Work Well Mats project, the entire quote builder and mat‑finder recommendation engine were custom code — no plugin needed, no bundle bloat, and no schema‑migration risk.