WPForms Prefill by URL reads the query available when the form renders. An HTTP redirect, WordPress canonical rule, Cloudflare Redirect Rule, Worker, page-rule replacement, marketing short link, consent tool, or client-side navigation can drop, decode, duplicate, or rename the key before that point. A cache can then serve HTML or JavaScript generated for a different query state. The failure looks like a form bug even though the original URL was correct.
Use this when WPForms prefilling works on a direct uncached URL but fails through ads, short links, HTTP-to-HTTPS redirects, www redirects, language paths, Cloudflare, or a production page cache.
Quick answer
Start with one simple documented WPForms key and use curl without and with redirect following to capture every Location header. Confirm the final browser URL still contains the exact encoded key. Review Cloudflare Redirect Rules, Transform Rules, Workers, cache rules, query-string normalization, origin redirects, WordPress canonical behavior, consent scripts, and client-side routers. Compare cache miss, hit, bypass, mobile, and private-window fixtures. Preserve required query keys through redirects and avoid caching query-dependent rendered variants together unless the form fills entirely client-side from the final URL.
What to check first
- Record the starting URL, expected final URL, exact prefill key, encoded value, redirect chain, cache status, Cloudflare rule IDs, Worker version, and origin response.
- Capture headers without following redirects, then follow the chain and compare every Location value for missing, decoded, reordered, duplicated, or renamed parameters.
- Inspect Cloudflare cache-key and query-string policies, Redirect and Transform Rules, Workers, page cache, canonical redirects, localization, and consent scripts.
- Test cache miss, hit, bypass, private window, mobile, logged-out, AJAX, and non-AJAX form paths with the same fixture.
- Compare final URL, rendered field, conditional logic, entry, notification, webhook, CRM, and analytics before changing more than one rule.
Why this usually happens
- A redirect target is configured as a fixed URL and does not preserve the original query string.
- A Worker or Transform Rule normalizes parameters before WordPress receives the request.
- Cache policy ignores query strings even though server-rendered form state depends on them.
- The browser displays an encoded value differently from the stored choice or composite subfield contract.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -I --max-time 20 'https://example.com/go?wpf20_4=sales'
curl -sS -L -I --max-time 20 'https://example.com/go?wpf20_4=sales'
# Record Location, cf-cache-status, age, cache-control, and the final URL.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Trace the complete redirect chain | Record the starting URL, expected final URL, exact prefill key, encoded value, redirect chain, cache status, Cloudflare rule IDs, Worker version, and origin response. | Every redirect preserves or intentionally maps the documented WPForms key. |
| Audit Cloudflare and origin query behavior | Capture headers without following redirects, then follow the chain and compare every Location value for missing, decoded, reordered, duplicated, or renamed parameters. | Cloudflare cache policy does not mix incompatible query-dependent form states. |
| Preserve only required keys | Inspect Cloudflare cache-key and query-string policies, Redirect and Transform Rules, Workers, page cache, canonical redirects, localization, and consent scripts. | Direct, redirected, cache-hit, mobile, and private-window fixtures agree. |
| Separate query-dependent cache variants | Test cache miss, hit, bypass, private window, mobile, logged-out, AJAX, and non-AJAX form paths with the same fixture. | Entry, notification, webhook, CRM, and analytics retain the expected value. |
Decision rule
The fix is complete only when the required key survives every redirect, the final URL is correct, cache hits and misses render the same approved form state, and the stored entry matches.
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 |
|---|
| Direct origin | Documented key on final URL | Field populates |
| Redirect chain | Key survives every Location | Field populates |
| Cloudflare hit | Approved cache variant | Same value as miss |
| Unknown query | No approved prefill key | Safe empty default |
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.
- Trace the complete redirect chain
- Audit Cloudflare and origin query behavior
- Preserve only required keys
- Separate query-dependent cache variants
- Verify form and downstream records
Production verification checklist
- Every redirect preserves or intentionally maps the documented WPForms key.
- Cloudflare cache policy does not mix incompatible query-dependent form states.
- Direct, redirected, cache-hit, mobile, and private-window fixtures agree.
- Entry, notification, webhook, CRM, and analytics retain the expected value.
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.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
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.
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 trace the WPForms redirect and cache path.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references