A developer picks a solid name for a new WordPress plugin, registers the slug early to lock it in before the plugin is actually finished, and assumes that reserves the name the way registering a domain does. It does not work that way. WordPress's own Plugin Handbook states directly that plugin slugs cannot be reserved for future use, and directory names belonging to approved plugins that go unused can be given to other developers instead. The slug you spent an afternoon picking can quietly become someone else's if you never actually publish under it. Most plugin developers never read this rule until it already applies to them, usually while staring at a slug they thought was locked in.
What the WordPress Plugin Handbook actually says about naming
WordPress states this precisely in its own detailed plugin guidelines, and two rules matter most. First, slug names cannot be “reserved” for future use or to protect a brand — and the same guidelines add that a directory name belonging to an approved plugin can still be given to another developer if it goes unused. In practice, the plugin repository does not function like a domain registrar, where holding a name costs nothing while you decide whether to actually use it. Publishing a real, approved plugin under a slug is what puts the name to active use — not just typing it into a submission form, and even an approved slug is not guaranteed to stay yours if it never gets used.
Second, the guidelines prohibit using a trademark or another project's name as the sole or first term of a plugin slug, unless you can show proof of legal ownership or representation. WordPress itself is the guidelines' own example: the WordPress Foundation holds the trademark on the term “WordPress,” and that protection extends to plugin slugs too. These are stated as review policies, not stylistic suggestions, and a submission that violates either one can be rejected during the required review process every plugin goes through before approval, the same kind of strict, enforced naming check that happens at publish time on other developer platforms, not just a style guideline offered in passing, similar to the same uniqueness enforcement at publish time that GitHub applies to its own Marketplace listings.
Figma draws this same boundary with unusual clarity, publishing a named approved example and a named rejected example side by side in its own guidelines, which is more concrete than WordPress's own wording gives you here. The underlying test rarely changes from platform to platform. A name can point at the platform it works with, but it cannot be built as though the platform made it, and reviewers on both platforms are checking for that exact distinction, not just scanning for a banned word.
The slug is not the only field that has to match
The WordPress.org listing gets most of the attention, but a plugin actually carries several names at once, and they can quietly drift apart without anyone noticing until a reviewer, or a confused contributor, flags it later.
The Text Domain has to match the slug exactly
This is a specific, technical requirement most naming guides skip entirely. WordPress's own internationalization documentation states plainly that “the text domain must match the slug of the plugin,” formatted with “dashes and not underscores, lower case, and no spaces.” A developer who names their plugin task tracker pro but sets the Text Domain to something else entirely, perhaps an earlier working name that never got cleaned up, creates a real mismatch with a documented technical requirement, not just a cosmetic one. Fixing it after the fact means editing header comments across the whole codebase, not just renaming one field in a settings page.
The Plugin Name field is separate from the slug, but not fully free
The plugin header's Plugin Name field is the human readable name shown in the WordPress dashboard, and it has more formatting freedom than the slug, similar to the display name and technical identifier split covered on other developer platforms. Spaces, capitalization, and punctuation are all fair game here in a way they are not for the slug itself. But it is still bound by the same trademark restriction, since the guidelines explicitly warn against starting a plugin name with WordPress, WP, or another company's brand, regardless of which field it appears in. Extra formatting freedom does not create an exemption from that rule.
Your main plugin file is often named after your own slug
The main PHP file housing your plugin's header comment is conventionally named to match the plugin's own slug — WordPress does not enforce this technically, but the naming decision still extends beyond the WordPress.org listing itself into the actual file structure a developer maintains day to day. Getting this consistent from the start avoids a confusing mismatch between what the repository shows and what the codebase actually contains months later. A contributor opening the repository for the first time should be able to match the file name to the listing without asking anyone, and without digging through the header comment to confirm it, which matters more than it sounds like once a plugin has more than one person committing to it.
A pre-submission naming check for a WordPress plugin
Run through this before you submit anything to the review queue, since each check maps to a rule the Plugin Handbook already enforces, and catching a problem here is faster than waiting for a rejection to surface it.
- 01Confirm your candidate slug does not begin with WordPress, WP, or any other trademarked product or company name, since the Plugin Handbook explicitly prohibits this without proof of legal ownership.
- 02Do not attempt to reserve a slug early without an actual plugin ready for review, since unused directory names from approved plugins can be reassigned to other developers.
- 03Set your Text Domain header field to match your slug exactly, using dashes, lower case, and no spaces, as WordPress's internationalization documentation requires.
- 04As a convention rather than a strict technical requirement, name your main plugin PHP file to match your slug, keeping your repository listing and your actual codebase aligned.
- 05Search the WordPress.org plugin directory directly for your candidate slug and close variants as an initial check — final slug eligibility is only confirmed when WordPress.org reviews your submission.
Running through all five before you submit takes a few minutes and catches the kind of naming problem that otherwise surfaces during review, right when you are hoping to hear back with an approval instead of a request for changes.
Name it once, submit it clean
A WordPress plugin slug is not something you can reserve in advance the way a domain works, and the naming decision extends into the Text Domain header and the main plugin file, not just the public listing. Getting all three aligned before submission reduces friction during review and avoids a rename after the plugin already has real users attached to whatever name shipped first. Draft candidates with NameKit's Project Name Generator, then check each one against the Plugin Handbook's rules above and search the directory for it directly, before you write the Text Domain header into a single file.
Frequently asked questions
Can I reserve a WordPress plugin slug before my plugin is finished?
No. The WordPress Plugin Handbook states directly that slugs cannot be reserved for future use or to protect a brand. Directory names belonging to approved plugins that go unused can be reassigned to other developers, so holding a slug without an active, submitted plugin gives you no real protection at all, no matter how early you registered it.
Can my plugin name include the word WordPress?
Only with proof of legal ownership or representation, which most independent developers simply do not have. The Plugin Handbook names WordPress directly as an example of a trademarked term that cannot begin a plugin slug, since the WordPress Foundation holds that trademark itself, and the restriction applies whether the reference feels obvious or incidental to you.
Does the Text Domain need to match the plugin slug?
Yes. WordPress's internationalization documentation states plainly that the text domain must match the plugin's slug, formatted with dashes, lower case, and no spaces. It's documented as a technical requirement rather than a stylistic preference, so keeping them aligned from the start saves you from editing header comments across your codebase later.
What happens if my chosen plugin slug is already taken?
You will need to choose a different slug — the plugin directory does not support two different plugins publishing under the same slug. Searching the directory directly for your candidate slug and close variants before submission is a useful initial check, but WordPress.org makes the final call on slug eligibility when it reviews your submission.
Can I use a company name in my WordPress plugin name?
The Plugin Handbook advises against it, partly because companies change over time and renaming a plugin later is disruptive for existing users, and partly because using another company's name as the sole or initial term of your slug without legal ownership violates the same trademark restriction that applies to WordPress itself, the exact rule covered earlier in this guide.