The WordPress 7.1 roadmap proposes more eager speculative loading when both object and page caching are detected. A prefetched or prerendered destination must not count as a pageview, lead, checkout, or purchase until the browser activates the page and the real business event occurs.
Use this for sites with Speculation Rules, Google Tag Manager, Meta Pixel, affiliate scripts, call tracking, or route-based conversions that may execute during prerender.
Quick answer
WordPress 7.1 Speculative Loading False Conversion Audit should be handled with a narrow evidence-first workflow: inventory speculation, read lifecycle signals, test without click, then verify the result before making broader changes.
What to check first
- Record current speculative loading settings, cache detection, eligible links, and browser support.
- Inspect Sec-Purpose, Purpose, document.prerendering, visibility state, and page lifecycle events.
- Hover or approach an eligible link without opening it and watch analytics and advertising requests.
- Activate the prerendered page, then complete the actual conversion and compare event IDs and timestamps.
- Repeat with consent denied and with speculative loading disabled as a control.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory speculation | Record current speculative loading settings, cache detection, eligible links, and browser support. | Hovering or prerendering alone creates no lead, checkout, purchase, or paid-media conversion. |
| Read lifecycle signals | Inspect Sec-Purpose, Purpose, document.prerendering, visibility state, and page lifecycle events. | The activated page records the intended page lifecycle event once. |
| Test without click | Hover or approach an eligible link without opening it and watch analytics and advertising requests. | The real business action sends one conversion with a stable event ID. |
| Activate and convert | Activate the prerendered page, then complete the actual conversion and compare event IDs and timestamps. | Denied consent and disabled-speculation controls match the documented policy. |
Why this usually happens
- A tag can initialize during prerender before the page becomes visible.
- A route-based conversion may rely on URL alone instead of the business action.
- Consent and page lifecycle listeners can fire in an unexpected order.
- A cached destination can hide that two document lifecycles produced related events.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
if ( document.prerendering ) {
document.addEventListener( 'prerenderingchange', () => {
window.dataLayer?.push( { event: 'page_activated' } );
}, { once: true } );
}
// Keep business conversions tied to accepted actions, not URL activation alone.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory speculation
- Read lifecycle signals
- Test without click
- Activate and convert
- Compare disabled control
What to tell the client or owner
Report core build, cache state, rule eagerness, destination, request-purpose headers, prerender state, activation time, consent state, event IDs, and conversion count.
Production verification checklist
- Hovering or prerendering alone creates no lead, checkout, purchase, or paid-media conversion.
- The activated page records the intended page lifecycle event once.
- The real business action sends one conversion with a stable event ID.
- Denied consent and disabled-speculation controls match the documented policy.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, 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, audit WordPress conversion tracking.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Filter by request-purpose evidence
Implement the WordPress speculative-request analytics purpose filter to keep nonactivated prefetch and prerender traffic out of sessions, leads, purchases, and ordinary security events.
Helpful references