If you sell a WordPress plugin, a theme, or any downloadable software product, you will eventually find a copy of it on a "nulled" site, offered for free with the license check stripped out. This is not a hypothetical risk to plan around — it is close to a certainty for anything that reaches a meaningful number of users. The question worth spending engineering time on isn't "how do we stop this from ever happening," because that goal is not achievable for software that runs on hardware you don't control. The question worth answering is: what should we actually spend effort protecting, and what should we accept as a cost of doing business?
Piracy Is a Cost of Doing Business, Not a Solved Problem
PHP is interpreted, not compiled to an opaque binary. A WordPress plugin ships as readable source code on the customer's own server, which they have full file system access to by definition — that's how WordPress hosting works. Any license check, no matter how it's written, exists as code the site owner can read and, if determined enough, remove or patch out. Desktop and mobile software has more room for obfuscation, but the same underlying truth applies: code that runs on a device you don't control can eventually be reverse-engineered by someone with enough time and motivation.
Once you accept that, the framing shifts from "prevent piracy" to "make piracy inconvenient enough, and legitimate ownership valuable enough, that it doesn't meaningfully cut into revenue from customers who would otherwise pay." Teams that don't make this shift tend to sink disproportionate engineering time into increasingly aggressive protection schemes, chasing a small number of people who were never going to pay in the first place, while the actual paying customers deal with the friction those schemes introduce.
A Layered Defense That Actually Holds Up
None of the following individually stops a skilled and motivated attacker. Together, they raise the effort required enough that casual sharing drops significantly and the people who do strip your license checks are, almost by definition, people who were never going to buy a license anyway.
License Validation on Activation
Every install should call your licensing API on activation, as described in our guide to how software licensing actually works. This isn't primarily an anti-piracy measure on its own — it's the foundation everything else builds on, because it's what lets your server know which sites are legitimately activated in the first place.
License Checks on Update Requests
This is the single most effective lever available to plugin and theme sellers, and it's underused. WordPress's built-in update mechanism checks a URL you control for new version information. If that endpoint requires a valid, active license before it returns update data, then a nulled copy simply stops receiving updates the moment its license check was removed — because removing the check also removes the plugin's ability to authenticate against your update server. The pirated copy is frozen at whatever version it was cracked at, accumulating unpatched bugs and, eventually, security vulnerabilities and compatibility breaks with newer WordPress and PHP versions.
Site or Domain Locking
Tying an activation to a specific domain, with a reasonable self-service allowance for legitimate domain changes, stops the simplest form of casual sharing: someone handing their license key to a friend to activate on an unrelated site. It won't stop someone editing the plugin's source to bypass the check entirely, but it stops the much more common case of a valid key circulating informally.
Gating Updates and Support Behind a Valid License
This deserves its own emphasis because it's the part most sellers underinvest in relative to how effective it is. Support and updates are the two things that genuinely cannot be pirated, because they require an ongoing relationship with you, not just a copy of a file. A pirated plugin has no path to ask a question, report a bug, or get help with a conflict — and for a business relying on that plugin for anything important, that gap is usually worth more than the price of the license itself.
Rate-Limited Activation Attempts
A license key can be brute-forced or guessed the same way a password can, especially if your key format is short or predictable. Treat the activation endpoint like the sensitive authentication surface it is: rate-limit attempts per IP and per key, and flag keys that see repeated failed activation attempts from many different domains in a short window, since that pattern is far more consistent with a leaked key circulating than with a legitimate customer fumbling their input. This overlaps directly with the general API hardening we cover in securing a SaaS API — a licensing endpoint is still a public API endpoint, and it deserves the same throttling discipline as a login form.
Why Heavy Obfuscation and DRM Usually Backfire
It's tempting to reach for aggressive code obfuscation, encoding tools, or hard machine-locking as a first line of defense. In practice these tend to cost more than they return:
- They break for legitimate customers first. Obfuscated PHP has a track record of causing conflicts with caching plugins, security scanners, and PHP version upgrades — problems your paying customers hit and your support team has to untangle, while a cracked copy with the check removed doesn't have the obfuscation-related bug at all.
- They generate false positives. Aggressive machine or domain locking flags legitimate server migrations, staging-to-production moves, and multisite setups as violations, turning normal customer behavior into support tickets and refund requests.
- They rarely stop the people they're aimed at. Anyone capable of stripping a simple license check is generally also capable of working around an obfuscated one — it just takes a bit longer, and the resulting cracked copy circulates just as widely afterward.
- They erode trust. Heavy-handed DRM sends a signal to prospective customers that you expect to be robbed, which is not the tone you want on a purchase page.
This isn't an argument for shipping completely unprotected code — a basic license check is still worth having, since it stops the least sophisticated sharing and is what your update-gating and support-gating logic hook into. It's an argument against escalating that check into something elaborate enough to become a liability of its own.
The Hidden Cost of Nulled Copies: It Isn't Just Lost Revenue
It's worth being clear-eyed about what "nulled" actually means in practice, because the risk isn't limited to lost sales. Sites distributing cracked plugins and themes are rarely doing it as a public service — bundling malware, backdoors, or SEO spam injectors into the modified files is common, because the download traffic itself is the monetization model. When that happens, the compromised site is running code that still carries your plugin's name and, often, your branding inside its admin screens. A site owner who gets hacked through a nulled copy of your plugin frequently has no way of knowing the vulnerability was introduced by the third-party site they downloaded from, not by your actual product — and if they do trace it back, the association with your brand is exactly as damaging as if the vulnerability had been yours. This is a real, practical reason to gate updates behind a valid license beyond the direct revenue argument: it keeps the population of sites running old, unpatched, and potentially tampered-with versions of your code as small as you can reasonably make it, and it gives you a legitimate basis to publicly clarify that a compromised nulled copy isn't the product you shipped.
The Friction vs. Security Trade-off
Every protection mechanism you add has a cost measured in legitimate customer friction, and that cost needs to be weighed deliberately, not assumed away. A five-site activation limit with easy self-service domain swaps is barely noticeable to a real customer. A three-strikes-and-you're-locked machine fingerprint with no manual override is the kind of thing that generates a one-star review from someone who just replaced a hard drive. The right amount of friction is the minimum needed to make casual, low-effort sharing inconvenient — not the maximum your license server is technically capable of enforcing. The same reasoning applies to the ongoing relationship a license represents more broadly — the ecosystem of update checks, support access, and version compatibility we cover in what WordPress maintenance services actually include, and if the plugin itself needs functionality beyond what off-the-shelf tools support, see our overview of custom WordPress plugin development.
Protect the Update Channel and the Support Relationship
If there's one framing worth carrying away from all of this, it's that a pirated copy of your plugin, sitting frozen on someone's server with no updates and no path to support, is not actually competing with you for the customers who matter. It's competing for the users who were never going to pay in the first place. The customers you're building a business around — the ones running the plugin on a site that matters to them — are the ones who value knowing it will keep working after the next WordPress core update, and who value being able to ask a real person for help when something breaks.
Building your protection strategy around that distinction — rather than around trying to make every byte of shipped code unreadable — is both more defensible from an engineering standpoint and considerably less expensive to maintain. It's the same principle we apply when we build licensing and update infrastructure for our own products and for client plugin and SaaS work: reach out if you're weighing how much of this to build versus what to accept as a reasonable cost of running a software business.
