Gravity Forms 3.1 adds link and URL detection for supported fields, including fields with the No Links/URLs setting and several structured fields. Spam rarely arrives as one obvious https URL. It may use full-width characters, Unicode dots, zero-width marks, Markdown, HTML anchors, punctuation, internationalized domains, or encoded text. A rule that blocks too little still admits campaigns, while a rule that normalizes too aggressively can reject names, addresses, order references, and legitimate support messages.
Use this when enabling Gravity Forms 3.1 link detection, investigating spam that bypasses a plain URL rule, or checking whether international customers receive confusing validation or false spam classification.
Quick answer
Clone the live form to staging and build a fixture matrix with plain URLs, www forms, Markdown links, HTML anchors, Unicode dots, full-width letters, zero-width marks, internationalized domains, email addresses, postal addresses, and ordinary punctuation. Run each fixture with No Links/URLs alone and with Advanced Honeypot configured to flag spam. Record visible validation, entry creation, spam status, notifications, feeds, retries, and logs. Keep the built-in rule where it matches the field's business purpose and add narrow validation only for a proven gap.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Plain URL | https://example.test | Reject or flag by policy |
| Unicode dot | example[dot]test variant | Document actual normalization |
| Legitimate address | 1 Example St. | Submit normally |
| Markdown link | label plus target | Reject or flag by policy |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Map fields and policy outcomes | Inventory every field type, No Links/URLs state, Advanced Honeypot action, conditional branch, add-on feed, and user-facing error message. | Known link fixtures follow the documented block or spam policy. |
| Run the Unicode fixture matrix | Create a redacted fixture set for ASCII, Markdown, HTML, encoded, Unicode, internationalized, email, address, and ordinary prose cases. | Legitimate names, addresses, emails, product text, and international input submit correctly. |
| Separate validation from spam handling | Compare blocked validation with spam classification because they create different entries, notifications, retry, and CRM outcomes. | Stored entries, notifications, feeds, webhooks, and spam queues match the visible outcome. |
| Narrow any custom normalization | Test pasted and typed values on mobile and desktop so browser normalization and hidden characters are represented. | Custom validation is removed or limited where Gravity Forms 3.1 already owns the rule. |
What to check first
- Inventory every field type, No Links/URLs state, Advanced Honeypot action, conditional branch, add-on feed, and user-facing error message.
- Create a redacted fixture set for ASCII, Markdown, HTML, encoded, Unicode, internationalized, email, address, and ordinary prose cases.
- Compare blocked validation with spam classification because they create different entries, notifications, retry, and CRM outcomes.
- Test pasted and typed values on mobile and desktop so browser normalization and hidden characters are represented.
- Review stored entry, spam queue, notification, feed, and webhook evidence before declaring a value accepted or blocked.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,field_type,representation,expected
plain_url,text,https://example.test,block
unicode_dot,text,example。test,record_result
postal_address,address,1 Example St.,allow
markdown,paragraph,[label](https://example.test),block
Why this usually happens
- Different Unicode characters look alike but do not share the same byte sequence.
- A honeypot policy can save an entry as spam while field validation blocks without creating one.
- Structured fields may be checked automatically even when a nearby free-text field uses another rule.
- Custom validation snippets duplicate or conflict with the Gravity Forms 3.1 built-in detector.
Decision rule
Do not expand the detector from one bypass example. A production rule must catch the proven spam pattern while the international, address, email, accessibility, and integration fixtures still pass.
Production verification checklist
- Known link fixtures follow the documented block or spam policy.
- Legitimate names, addresses, emails, product text, and international input submit correctly.
- Stored entries, notifications, feeds, webhooks, and spam queues match the visible outcome.
- Custom validation is removed or limited where Gravity Forms 3.1 already owns the rule.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Map fields and policy outcomes
- Run the Unicode fixture matrix
- Separate validation from spam handling
- Narrow any custom normalization
- Verify entries, feeds, and messages
Mistakes to avoid
- Changing production before recording the exact version, URL, role, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, caches, and downstream systems remain unchecked.
- Testing a different role, locale, cache state, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, helper code, or relaxed firewall rules active after verification.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test Gravity Forms spam detection.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references