Why We Built Our Own Anti-Spam Plugin (When So Many Exist)

For a long time, we faced a persistent challenge with our clients’ WordPress sites. Even on forms that only receive a modest number of daily submissions, automated spam was becoming a serious issue.

“Half of our inquiries this week were just spam,” a client would report. “It’s getting annoying to sift through them.”

The problem wasn’t just the time spent deleting junk; it was the slow erosion of trust. When real leads are buried under a daily pile of garbage submissions about crypto or SEO services, the contact form—the primary bridge between a business and its customers—starts to feel like a liability. This is the dev story behind Samurai Honeypot for Forms: why we decided to build our own solution after exhausting the standard options, and the technical decisions that shaped it.

The Reality of Modern Spam

We build and maintain dozens of WordPress sites. Most run Contact Form 7 because it is lightweight and flexible. However, its lean design means it relies on the ecosystem for spam protection. For years, we bolted on various solutions, but the landscape has changed significantly in 2024 and 2025.

The evolution of bots

We are no longer dealing with simple scripts. Modern bots often run headless browsers that execute JavaScript and render CSS, mimicking human behavior with realistic timing. With the integration of large language models, some messages even read like genuine business inquiries, making traditional content filters less effective.

The operational impact

When a business owner has to sift through dozens of junk messages just to find a couple of real leads, the signal-to-noise ratio collapses. We noticed a worrying trend: some clients stopped checking their form submissions promptly, relying instead on phone calls. The website’s most critical conversion point was losing its value. We realized we needed a more durable way to handle this without compromising the user experience.

What We Evaluated

Before writing a single line of code, we spent months testing existing solutions. We didn’t want to reinvent the wheel—we just needed something that worked for our specific requirements.

Custom Challenges (The “Japan Quiz”)

For several projects, we tried adding simple, culture-specific questions (e.g., “What is the color of a Japanese post box?”). While this dropped spam to nearly zero overnight, it had two drawbacks: it disrupted the form’s professional design, and we knew it was only a matter of time before LLM-powered bots could easily bypass such “cultural” hurdles.

Content-Based Filters (Akismet)

Akismet is a robust industry standard, but it primarily analyzes content. Against unique, AI-generated spam, content analysis alone is becoming less reliable. Furthermore, we wanted a solution that processed data entirely on our own servers to maintain a high standard of data privacy without relying on third-party APIs for every submission.

Behavioral Analysis (reCAPTCHA)

Google reCAPTCHA v2 and v3 are powerful, but they come with trade-offs. v2 can hurt conversion rates (especially on mobile), while v3, though invisible, can impact page load times and occasionally flag legitimate users on privacy-focused browsers or VPNs as “suspicious.”

Standard Honeypot Plugins

The concept of a hidden field is sound, but most plugins use static implementations. Once a bot script identifies that the field hp_field is hidden via display: none, it simply skips it. We found that the effectiveness of these tools would often degrade within weeks as bots updated their patterns.

Our Approach: Layered, Local, and Lean

We sat down and defined what an ideal solution would look like for our workflow: no visible UI, no external dependencies, and resistant to bot evolution.

But if we are being completely honest, there was another reason: we just really wanted to build it. As developers, we were tired of patching together third-party tools and constantly managing updates and API limits. The challenge of creating a standalone, polymorphic defense mechanism sounded like a fun engineering problem to solve. We wanted to see if we could build something elegant from scratch.

Our very first prototype—internally codenamed “Honey Potter”, a single, simple honeypot—actually succeeded in drastically reducing the absolute volume of spam. However, on day 11 of its deployment, we checked the logs and realized an uncomfortable truth: while the low-level scripts were blocked, advanced headless browser bots were walking right past our hidden fields without breaking a sweat.

“If we reduced the volume this much, we can catch these smart ones too.” This technical obsession ignited our engineer egos. It drove us to shift our mindset from building a passive trap to forging an active, multi-layered defense system that ruthlessly cuts down malicious intent.

Polymorphic Defense

To counter predictable bot scripts, we implemented polymorphic honeypots. Instead of static names, our hidden fields rotate their names and CSS hiding methods on every page load. To a bot scanning the DOM, the form looks different every time, making it much harder to build a consistent “skip” rule.

Layered Validation

We believe no single method is a silver bullet. Instead of waiting for bots to fall into a trap, our plugin actively uses five independent layers:

1. Polymorphic Honeypots: Catches standard automated scripts.
2. Submission Timing Validation: Embeds a signed timestamp when the form renders to block submissions that happen faster than humanly possible (e.g., under 3 seconds).
3. Client-Side Proof of Work: Forces the browser to solve a tiny, invisible computational puzzle, making mass submissions too expensive for bots.
4. Stateless HMAC Tokens: Validates submissions server-side without relying on WordPress nonces, ensuring compatibility with aggressive page caching and CDNs.
5. Silent Rejection: When a bot is detected, we return a success message. This avoids giving bot operators the feedback they need to debug and improve their scripts.

Technical Restraint

We made a conscious effort to keep the plugin “boring” on the inside. It uses vanilla JavaScript to avoid dependencies and hooks directly into the existing Contact Form 7 pipeline. We also prioritized accessibility, using aria-hidden attributes to ensure the honeypot fields don’t confuse screen reader users.

Lessons Learned

Building this tool taught us that you don’t need to be unbreakable; you just need to be more expensive to attack than the alternative. By adding multiple layers—even simple ones—we raise the “cost per successful submission” for bot operators until they move on to easier targets.

We also reaffirmed that privacy and performance are linked. By processing everything locally, we eliminated external API latency and ensured that user data never leaves the client’s own environment.

Current Status

Samurai Honeypot for Forms is now live on the WordPress repository. We use it across our client portfolio, and the feedback has been consistent: the “junk” has subsided, and the legitimate leads are coming through clearly again.

We built this because we needed a tool that balanced invisible security with zero external dependencies—and because sometimes, building the tool yourself is just the most satisfying way to solve a problem. If you’re a developer or site owner looking for a similar “install and forget” approach, we hope you find it useful.

Samurai Honeypot for Forms is free and open source on the WordPress Plugin Repository. If you want to know how we arrived at this multi-layered defense and read about our messy behind-the-scenes development, check out our deep dive: From “Honey Potter” to Samurai: Why We Forged a Katana to Fight Spam.