What happens between Submit and your inbox

A customer types a question into your contact form and presses Send. What happens in the next moment decides two things: whether the spam in your inbox stops, and whether that customer ever notices anything happened at all. Spambuster is built so the answer is yes to the first and no to the second.

This is the whole route a submission takes, written out stage by stage. It is worth reading before you install anything in this category, because the differences between products in this market are almost entirely in the parts that listings do not show: which forms an app can see, what it loads onto your pages, what it does when something upstream breaks, and whether it can tell you afterwards what it did and why.

Two minutes, and no Google console

Using Google reCAPTCHA normally means a trip to the Google Cloud console: create a project, generate a site key and a secret, choose the right protection type, register your domains, then paste two long strings into an app. It is the step at which most merchants give up on doing it themselves, and several apps in this category still ask you to do it before their product will work at all.

Spambuster does all of it for you through Google's API. During setup the app provisions a dedicated reCAPTCHA Enterprise key for your store, of the correct type for the protection mode you chose, and registers your domains against it. There is no console to visit, nothing to generate and nothing to paste. Install, switch on the app embed, and you are protected.

Two details in that arrangement save merchants trouble months later, and both are worth knowing about.

Your key keeps up with your store. A reCAPTCHA key does not learn about new domains by itself, so a merchant who adds a custom domain six months after setup would normally find verification failing on the new domain only, which is a genuinely baffling fault to diagnose. Spambuster reconciles your key's domain list against your store on an ongoing schedule, so the problem never arrives.

Your own Enterprise keys stay yours. If you supply a key from your own Google Cloud project, the app uses it and reports any faults on it rather than modifying it. Your project may hold keys used by other software, and we leave those alone.

Eleven stages, and how few of them your customers pay for

Here is every stage a submission passes through, in order. Note how much of the work never happens: on a page with no form, the app does nothing at all, and two of the four ways a submission can be resolved are settled in the browser before a single network request is made.

Three decisions that protect your page speed

Three of those stages could have been built the easy way. Each was not, and each choice shows up in what your storefront costs a visitor.

Google's library could be fetched on every page. That is the simple way to build it, and it means every visitor to every page downloads a third-party library that most of them will never need. Spambuster fetches it only once form discovery has found a form that uses it, so the cost lands on the pages that have something to protect and nowhere else. On a catalogue-heavy store that is a small minority of page views.

The honeypot could be checked on our server. Checking it in the browser instead removes a network round trip for the submissions least worth scoring, which during an attack is a large share of the volume. It also means the trap keeps working even if our backend is unreachable, which is precisely when you would least like to be undefended.

The environment checks could run immediately. They wait for idle time instead, because a spam filter that costs you your Largest Contentful Paint has made a bad trade on your behalf. The checks are valuable. They are not more valuable than your page rendering.

The night shift: a filter that repairs itself

This is the feature no other listing in the category claims, and it exists because reCAPTCHA configuration decays quietly. An installation that worked in March can be silently failing by September with nothing in the dashboard to say so.

Keys get deleted from Google projects. A protection mode is switched and the key type no longer matches. A custom domain is added and never registered. A theme is republished and the metafields carrying the key go stale. In every one of those cases the app still appears installed, the dashboard still looks healthy, and the spam quietly starts coming back.

Every night, Spambuster reads the last 48 hours of verification errors across the fleet, works out which shops have a real configuration fault, and fixes them. You do not have to notice, diagnose or report anything.

Two safeguards make that safe to run against live stores.

Every change is audited, so there is a record of what was altered and why. And changes are capped per run: if a change at Google's end ever caused the classifier to conclude that hundreds of stores needed new keys, it would repair a handful and stop rather than rewriting the fleet overnight. Careful beats clever when the thing being edited is somebody's live storefront.

Every decision, on the record

The most common complaint about spam apps is not that they block too much or too little. It is that merchants cannot tell what they did. A blocked count is a number you have to take on faith. Spambuster records every submission individually, so when you want to know what happened to a specific message you can simply look.

What it is built for

Spambuster protects the seven forms on your storefront: contact, newsletter, blog comments and reviews, login, account registration, password reset, and the order form on Premium. Those are the doors a stranger can push text through, and they are where the overwhelming majority of Shopify form spam arrives.

It is built to do that job invisibly. Your customers never see a puzzle, never tick a box, and never wait. Google's engine does the scoring, you set the strictness, and the app handles everything in between including the parts that normally require a Google Cloud account.

Two things worth knowing about the scope, because they save you time rather than because they are caveats.

Checkout is Shopify's own infrastructure. Requests that go straight to the checkout endpoint never load any storefront app, ours or anyone else's, which is why we wrote a whole dispatch on it. If your problem is a flood of fake abandoned checkouts, start there rather than with any app.

Automation is what gets filtered. Everything above tests whether a submission came from a machine, which is what the overwhelming bulk of form spam is. The residue that arrives from a human typing a sales pitch is a mail-rule problem, and our first dispatch shows how to write those in about fifteen minutes.

Within that scope, this is a narrow thing done carefully. Every submission on seven forms scored by Google's engine. No console, no keys, no puzzles. Nothing loaded on pages that do not need it. Every decision written down with the score behind it. And a job that checks, every night, that the whole arrangement still works.

Fourteen days free is enough to see all of it on your own store.