Severity: HighOwner: DevTime to fix: 1-3 h
Third-party requests before consent
Stop optional vendors from making network calls before a visitor has chosen whether to allow them.
Covers: pre_consent_third_party_request, third_party_data_flow_before_consent
Why this matters
Even when cookies are blocked, third-party network requests can still transmit IP addresses, identifiers, or page metadata before user choice. That can still create compliance risk.
How to verify manually
- Load the page in incognito and inspect third-party requests before any consent action.
- Group requests by provider: analytics, ads, chat, video, fonts, tag manager, consent platform.
- Check whether requests are essential or optional for baseline site functionality.
Typical root causes
- Third-party scripts load from the page template before the CMP decides.
- Optional widgets self-initialize on page load.
- Consent only blocks cookies but not network requests or remote script fetches.
GTM fix
- Move optional vendor tags behind consent conditions instead of firing on all page views.
- Audit custom HTML tags that pull remote scripts directly.
- Separate essential operational tags from analytics and marketing vendors.
WordPress fix
- Review theme, plugin, and page-builder integrations that inject third-party widgets globally.
- Disable auto-embed or auto-load features for optional tools until consent is granted.
- Retest pages after cache purge and plugin optimization layers are cleared.
Generic fix
- Defer optional third-party scripts until consent is granted.
- Lazy-load integrations on user action where possible.
- Replace non-essential always-on embeds with click-to-load placeholders.
How to confirm the fix worked
- Confirm that only essential third-party requests remain before consent.
- Accept optional consent and verify optional vendors load only afterward.
- Run a fresh scan and compare the third-party request inventory.
Next step
Re-scan after deployment to confirm that the runtime behavior changed, not just the banner copy.