A new plugin vendor has a real choice to make in 2026: submit a plugin to WordPress.org, or skip the directory and sell from your own site. A few years ago the answer was almost always “submit”. Today the directory is busier, the review rules are stricter, and every release now passes an automated security check before it reaches users. So the honest question is worth asking again.

Our team ships free plugins on WordPress.org and sells Pro add-ons from our own store, so we have lived with both sides of this decision. This guide covers the whole picture in plain English: whether to submit at all, where the line between Free and Pro sits under the rules, what usually makes a first review bounce, and what to run before every release tag. Developers get a clearly marked section with the technical detail. If you are a founder or product owner, you can skip that section and still get the full decision.

Should you submit a plugin to WordPress.org? The short answer

Submit to WordPress.org if your plugin needs installs to succeed. That covers most products that serve the general public: a directory, a forum, a form builder, an events tool. The directory gives you search traffic you cannot buy elsewhere, a trust signal customers recognise, automatic updates and translation help from volunteers.

Skip it, or delay it, if your plugin is a niche business tool, a client-specific product, or something where the buyer finds you through a sales conversation rather than a search box. In that case your own store and a licensing system may serve you better, and you avoid the review queue entirely.

The third path is the one we use: put a complete, useful free plugin on WordPress.org and sell Pro as a separate add-on from your own site. It takes the most discipline, because the rules decide where the line between Free and Pro can sit. The rest of this guide explains why.

What the queue looks like now

The Plugins Team publishes its own numbers, so we do not have to guess. In a June 2026 status update, the team reported that new submissions ran at around 500 per week in February 2026 and climbed to a record of around 700 per week in May. They described that May rate as 2.7 times the rate of 2025 and 5 times the rate of 2024.

The same update says the review backlog peaked at roughly 1,050 plugins in mid-April, then fell rapidly and hit zero within a few weeks. The team completed nearly 3,000 initial reviews in May alone, against around 1,100 in the same month a year earlier. In other words, the team got much faster, and the number of people knocking on the door grew even faster.

A weekly report from late September 2026 shows the pace had not slowed: 507 new plugins were submitted in a single week. The same report lists 4,598 plugins in the queue, with 3,860 of them waiting on the author to reply and only 475 waiting on a reviewer.

That last split is the useful part. More than four in five plugins in the queue are waiting on the developer, not on the team. Most submissions come back with a list of fixes, and the clock stops until the author answers. Your wait is mostly your own speed and your own code quality.

For a founder, three lessons follow from these numbers:

  • Expect competition. Roughly 500 to 700 new plugins appear every week. A generic idea will not stand out on listing day.
  • Expect review rounds. The queue is full of plugins waiting for authors. Plan for at least one round of fixes, and budget the time to answer the same day.
  • Do not plan a launch date around approval. Treat approval as an input, not a deadline you control.

The figures above come from the Plugins Team posts on make.wordpress.org (the June 2026 status update and the 28 September 2026 weekly report). They change every week, so check those pages for current numbers before you quote them.

Should you submit at all? The honest trade-offs

What you gain on WordPress.org

  • Discovery. People search the plugin directory from inside their dashboard. That is a buyer-intent audience you do not have to pay to reach.
  • Trust. A plugin that passed human review carries weight. Many agencies will only install plugins from the directory.
  • Free update delivery. WordPress.org serves your updates and your translations. You do not run an update server.
  • A security gate that also protects your users. Every release now goes through an automated security review (more on that below). It is extra work for you, and it is also a safety net for the people who install your code.

What it costs you

  • Time. Review rounds, replies, and the wait between them.
  • Rules about how you monetise. You cannot lock features behind payment inside the free plugin, track users without consent, or serve updates from your own server inside it. We cover each rule in the next section.
  • Crowding. Hundreds of new listings a week means your plugin needs a clear reason to exist.
  • Release friction. A release that scores as high risk is held back from the update system until it is fixed.

The alternatives

You have three other routes, and all of them are legitimate.

Your own store with a licence and update system. You sell and deliver everything yourself. For our Pro add-ons we use Easy Digital Downloads with its Software Licensing extension, so customers get updates from our site once their licence is active. You own the customer relationship and the pricing, and you carry the support and the delivery.

GitHub releases. Good for developer tools and open source projects where the audience is comfortable downloading a zip. Weak for non-technical site owners, who expect one-click updates.

Both. Free on WordPress.org, Pro self-hosted. This is our model, and it fits products that serve a broad public and have a clear paid layer for businesses.

A quick way to decide

Your pluginOur advice
Serves the general public and wins by being foundSubmit. The directory is your best distribution channel.
Niche B2B tool sold through conversationsOwn store first. Submit later only if you want a free entry point.
Built for one client or one agencySkip the directory. Private distribution is simpler.
Free core plus a paid business layerFree on WordPress.org, Pro self-hosted, as separate code.

If you are weighing the cost side of running a plugin business, our breakdown of what it actually costs to run a WordPress plugin business covers hosting, support, AI tooling and the hidden costs that decide whether a plugin survives.

The Free and Pro line, under the actual rules

Every founder who sells a Pro version asks the same question: how much do I put in the free plugin? Too generous and nobody upgrades. Too thin and nobody installs. The guidelines do not tell you how to price, but they do set hard limits on where the line can sit. These are the rules that matter, quoted from the Detailed Plugin Guidelines on developer.wordpress.org.

Guideline 5: trialware is not permitted

“Plugins may not contain functionality that is restricted or locked, only to be made available by payment or upgrade.”

The guideline goes on to say that functionality may not be disabled after a trial period or quota is met, and that plugins offering only sandbox access to an API or service count as trial plugins too. It then points to the approved route: paid functionality in services is permitted, provided all the code inside the plugin is fully available, and the team recommends add-on plugins, hosted outside WordPress.org, to keep the premium code out.

In practice this means the free plugin cannot contain Pro code that sits switched off until a licence key arrives. Pro must be separate code, shipped as a separate plugin, that adds to the free one.

Guideline 6: services are allowed

“Plugins that act as an interface to some external third party service are allowed, even for paid services.”

If your product is a service, such as email delivery, backups or an AI feature that runs on your servers, the plugin can be a thin front end for it. The service can charge. The plugin cannot hold back its own code to force a sale.

“Plugins may not contact external servers without explicit and authorized consent.”

The guideline describes an opt-in method, such as registering with a service or ticking a checkbox in settings. It also asks you to document what data you collect and how it is used in the readme. Anonymous “usage tracking” switched on by default is a common reason for a bounce.

Guideline 8: no outside code, no updates from other servers

The guideline says executing outside code within a plugin, when not acting as a service, is not allowed. Its examples include serving updates or otherwise installing plugins, themes or add-ons from servers other than WordPress.org, and installing premium versions of the same plugin. So the free plugin cannot download your Pro add-on, and it cannot carry its own updater that talks to your store.

Your Pro add-on is a different plugin. It can ship its own licensing and update code, because it is not hosted on WordPress.org.

Guideline 11: upgrade prompts, used sparingly

The text asks that upgrade prompts, notices and alerts be limited in scope and used sparingly, whether contextually or only on the plugin’s settings page. Site-wide notices and dashboard widgets must be dismissible. Guideline 5 also confirms that upselling users on ad-hoc products and features is acceptable, as long as it stays within the bounds of guideline 11.

The practical reading: one clear “Upgrade” link on your own settings page is fine. A red banner on every admin screen is not.

The design rule that keeps you safe

Put it in one sentence for your team: free must be complete and useful on its own, and Pro adds, never unlocks.

That rule solves the generosity dilemma too. When the free plugin does a whole job well, people install it, recommend it and leave reviews. Pro then sells a different layer: scale, team features, integrations, priority support. We wrote about our own approach in why our free WordPress plugins aren’t crippled on purpose.

A useful test before you submit: if a reviewer installed only your free plugin and read your code, would they find a feature that exists but is switched off? If yes, move it out, or make it work.

Getting through review the first time

You will probably get at least one set of review comments, but you can shorten the process by removing the usual causes before you submit. Here are the ones we see most.

The name and the slug

Guideline 17 says that using a trademark as the sole or initial term of a plugin slug is prohibited unless you can prove ownership. If your plugin is called “Facebook Feed Pro” or “Elementor Widgets Plus”, expect to be asked to rename it. Lead with your own brand name and describe the function after it. A rename after approval is possible, but a clean name on day one saves a full review round.

Readme spam

Guideline 12 covers the public pages on WordPress.org, including your readme. The text lists unnecessary affiliate links as spammy behaviour. Keep the readme honest: what the plugin does, how to install it, a clear changelog. Skip keyword stuffing and competitor names in the tag list.

Bundled libraries

Guideline 13 requires plugins to use the default libraries that ship with WordPress rather than including their own copies. If you bundle your own jQuery or a second copy of a library WordPress already ships, a reviewer will ask you to remove it.

Anything that sends data to an outside server needs an opt-in, a readme disclosure, and ideally a privacy policy link. That includes fonts and scripts loaded from a CDN when they are not part of a service.

The developer checklist (skip if you are not technical)

These are the code-level items that most often cause a bounce. Hand this list to your developer.

  • Unique prefixes. Every function, class, constant, option name, post type slug, script handle and meta box ID needs a prefix unique to your plugin. A generic meta box ID such as settings or details can collide with another plugin and is a classic review comment.
  • Activation hook order. If you call flush_rewrite_rules() on activation, register your custom post types and taxonomies first, in the same request, before the flush. Flushing before registration does nothing useful and gets flagged.
  • Escape on output, sanitise on input. Use the esc_html, esc_attr and esc_url family at the point of output. Sanitise every value read from $_POST, $_GET and $_REQUEST.
  • Nonces and capability checks. Every form or AJAX action that changes data needs both a nonce and a current_user_can() check for the right capability. A nonce alone proves intent, not permission.
  • Prepared queries. Use $wpdb->prepare() for any query that includes variable data.
  • Direct file access. Guard PHP files that run code on load with the standard ABSPATH check.
  • Uninstall behaviour. Give site owners a clear choice about whether data is removed when the plugin is deleted, and implement it in uninstall.php.
  • Readme and headers. A valid readme.txt, a licence compatible with the GPL, a matching version in the header and the readme, and a stable tag that points to a real tag.

Run the official Plugin Check tool on your code before you submit. It catches many of these problems in minutes and it is the same family of checks the review team uses.

Security before every tag, not just the first submission

This is the biggest change in the last year. Review used to be a gate at the door: pass once and you were in. Now every release is checked.

How the automated review works

According to the Plugins Team announcement on make.wordpress.org, each new plugin release goes through a cooldown window of about six hours, introduced in June 2026. During that window, multiple AI models and Jetpack Scan analyse the release. Their findings are cross-checked and combined into a security score, where a higher score means greater potential risk. Releases with a high-risk score are blocked from distribution through the WordPress.org update system until the issues are resolved.

The announcement is careful on one point: a high score does not mean malicious intent. The system measures risk, not motive. A plugin with a sloppy unescaped output can score high for the same reason a backdoor does.

Why it exists

The team shared one example. On 28 July 2026, a backdoor was committed to a plugin with roughly 20,000 active installs. The automated review flagged it, and the compromised version was never distributed to users. The plugin was closed 26 minutes after the Plugins Team was notified by Wordfence about the update.

If you are a small vendor, read that as protection for you as well. Account takeovers and purchased plugins have turned into a real attack route, and a safety net that stops a poisoned release from reaching 20,000 sites is worth having, even when it adds a step to your own release day.

What to do if your release is held

The team’s advice is plain: fix the issue and publish a new release, rather than appealing. They note that publishing a fixed release is almost always faster than waiting for a manual review. Read the findings, correct the flagged code, bump the version, tag again.

That advice also tells you how to plan. Do not schedule a release for the last hour of a Friday. Leave a buffer for the cooldown window and, if needed, one fix-and-retag cycle.

The tools the team recommends

The announcement lists the checks that make the biggest difference before you tag, in order of impact:

  1. PHP_CodeSniffer with the WordPress Coding Standards, which catches unescaped output and missing nonce checks.
  2. Plugin Check, which covers security, readme, internationalisation and performance.
  3. Static analysis tools such as PHPStan or Semgrep.
  4. QIT, for WooCommerce extensions.

Treat these as a pre-flight list. The scan on WordPress.org should not be the first time anyone looks at your security.

How we run it: free on WordPress.org, Pro on our own store

We do not want to dress our process up as more than it is, so here is what we actually do.

Separate code, separate delivery

Our free plugins live on WordPress.org and work on their own. Our Pro add-ons are separate plugins, sold from our own site, and they use Easy Digital Downloads Software Licensing for licence checks and updates. The free plugin never downloads or unlocks Pro code. When a customer installs Pro, it extends the free plugin through its hooks and filters.

This split is also why we can say with a straight face that the free plugins are not crippled: there is nothing in them that waits for a key.

Checks we run before a release

These are the checks that exist in our repositories today, not an aspirational list:

  • PHP_CodeSniffer with the WordPress Coding Standards, run as part of a single check script that also runs linting and PHPStan.
  • PHPStan static analysis, at a fixed level across the codebase.
  • The Plugin Check tool against the release build, including the “tested up to” header and readme fields.
  • A security review per release that covers injection sinks, authorisation on every REST route, data exposure in API responses, and secrets handling, with the results written down for that release.
  • A release build that packages only the files the plugin needs to run, so development folders, screenshots and notes never end up in the zip.
  • A smoke test on a clean install and on an upgrade from the previous version.

We cover the release process in more detail in a separate piece on how our release gates work with a small team and AI agents. The point for this guide is simple: the checks that WordPress.org now runs on your release are checks you should already be running yourself.

One file name that cost us a rename

A small example of why the zip itself deserves a check. Two of our plugins had an admin template file named shell.php. Several hosting firewalls block zip uploads that contain a file with that name, because it matches a common web shell filename. The file was harmless, but the install failed on those hosts. We renamed it to layout.php. If a customer ever tells you your plugin “will not upload”, look at your file names before you look at your code.

What we will not claim

We are not going to give you a pass rate or a count of review rounds for our own listings, because the honest version of those numbers belongs to the Plugins Team, not to us. What we can say is that the rules above shaped how we split Free from Pro, and the pre-release checks shaped how we ship.

How to submit a plugin to WordPress.org: a launch plan

If you decide to submit a plugin to WordPress.org, this is the order we would follow.

  1. Pick a name that is yours. Check it against the trademark rule before you write a line of code.
  2. Define the free scope first. Write down what the free plugin does on its own. Make sure that scope is complete, not a demo.
  3. Put Pro in a separate plugin from day one. Do not start with one codebase and plan to split it later. Retrofitting is where locked features sneak in.
  4. Add consent for anything that leaves the site. Document it in the readme.
  5. Run the pre-flight checks. WPCS, PHPStan, Plugin Check, and a manual pass over every form and AJAX handler.
  6. Write a readme a stranger can follow. No affiliate links, no keyword stuffing.
  7. Submit, then watch your email. Because most of the queue is waiting on authors, replying the same day is the single biggest lever on your timeline.
  8. Treat every later release as a mini-submission. Same checks, with a buffer for the security cooldown.

Common questions

Can I sell Pro from the plugin settings page?

You can show an upgrade link or a short description of the Pro add-on on your own settings page. You cannot let the free plugin download or install the paid version, and you cannot gate features in the free plugin behind a key. Keep upgrade messages sparing and dismissible.

Can the free plugin check my licence server?

Only if the plugin is acting as an interface to a service the user has opted into. A licence ping from the free plugin that the user never agreed to is the kind of external call guideline 7 targets.

Is SaaS allowed?

Yes. Guideline 6 allows plugins that act as an interface to an external service, even a paid one. The plugin itself must still be fully functional code, with no locked features and clear consent for any data sent out.

What if my release is blocked after submission?

Read the findings, fix them, and tag a new release. The team says this is almost always faster than an appeal.

Does being on WordPress.org mean I cannot sell anything?

No. Many successful businesses give away a good free plugin and sell add-ons, services or support. The restriction is on locking functionality inside the free code, not on having a business.

The bottom line

WordPress.org in 2026 is still the best place in the ecosystem to be found, and it is more demanding than it was. The queue is busy, the rules on trialware and tracking are firm, and every release now meets an automated security gate. None of that is a reason to stay away if your plugin needs installs. It is a reason to arrive prepared: a clean name, a free plugin that stands on its own, Pro as separate code, and the same checks the directory will run on you.

If you are planning a plugin launch or a Free and Pro split and want a second pair of eyes on the architecture, our team builds and ships this way every week. Tell us what you are building and we will tell you honestly which route fits.

For more on how we keep a plugin catalogue healthy over years, read why written rules do not reliably govern AI agents, where we explain why we turned our rules into enforced gates.

Sources