The free plan wasn’t actually “no registration required” — fixing a landing page claim that contradicted itself

Background

An external marketing review flagged what looked like a contradiction in our landing page’s FAQ. Checking it against the actual code confirmed the claim was accurate.

Two statements coexisted on the same page:

• Quick Start, step 2: “Register with your email to start for free”
• The FAQ answer: “The Free plan requires no registration and allows up to 1 site, 3 runs per month — completely free.”

One says “please register.” The other says “no registration needed.” Checking the implementation confirmed that the Free plan requires an email address to be registered and verified on first launch — without that step, the app cannot be used. The FAQ’s “no registration required” simply wasn’t true.

Conflating “free” with “no registration”

Tracing the contradiction back to its root, it came from folding two independent axes into a single phrase.

• Cost axis: no credit card, no charge at any point
• Procedural axis: one step — registering an email address — is required

Both are true characteristics of the Free plan here, but the phrase “no registration required” denies the procedural axis outright. Most likely, an accurate statement like “no credit card required” was shortened over time into “no registration of any kind required,” and that shorter version stuck. It’s a reminder that landing page copy is never really “done” — it needs to be re-verified against the implementation every time the underlying feature changes.

Fixing what’s actually true, not just deleting the claim

There were two ways to resolve this:

1. Keep the FAQ’s “no registration required” claim as-is, and remove the email registration requirement from the product instead
2. Leave the implementation untouched, and rewrite the FAQ to match reality

Email registration underpins verification-email deliverability and license management, so removing it wasn’t a realistic option. We went with option 2 — matching the copy to what’s actually true.

- The Free plan requires no registration and allows up to 1 site,
- 3 runs per month — completely free.
+ The Free plan only asks for your email address and allows up to
+ 1 site, 3 runs per month — completely free. No credit card, no
+ time limit.

The key detail: rather than just deleting the “no registration” claim, we explicitly kept the cost axis (no credit card, no time limit) in the rewritten sentence. What users usually want to know is whether they’ll be asked for a credit card and how long the free tier lasts. Affirming both of those clearly, while precisely correcting only the procedural claim (email registration is required), landed on wording that neither overstates nor understates what’s true.

The same phrasing also appeared in the Quick Start description.

- No credit card required. Just install it and start right away.
- The Free plan stays free forever.
+ No credit card required. Just register your email and start
+ right away. The Free plan stays free forever.

Across the Japanese and English versions and duplicate FAQ entries on two pages, three files and four separate spots were brought in line with the same corrected wording.

What we deliberately left alone

During the same review, we noticed a second inconsistency: the product name appeared on the landing page in two forms, “WP Maintenance Manager” and “WP Maintenance Pro.” The binary actually being distributed carries the “Pro” name. Standardizing the landing page alone to “Manager” would have created the opposite kind of mismatch — the landing page and the distributed product disagreeing with each other.

We left that alone here and set it aside as a separate naming decision to make later. Trying to fix every inconsistency uncovered during a single review, in a single commit, risks mixing problems with very different blast radii into one change and leaving one of them half-fixed. Correcting the “no registration” claim was a wording-only fix that could be completed cleanly on its own; the product-naming mismatch touches the binary name, the installer, and past distributed builds — a decision of an entirely different order. Keeping the scopes separate was deliberate.

Wrap-up

Landing page copy can be correct the day it’s written and quietly drift out of sync as the implementation changes underneath it — in this case, once email verification was added to the registration flow. This particular gap surfaced through an outside review, but the real fix is the underlying habit: periodically checking landing page claims against what the code actually does. Just as important as fixing what you find is resisting the urge to fix everything discovered in the same pass — problems with different scopes deserve to be handled on their own timelines.