Google’s WordPress Plugin Still Cannot Track a Form Submission as a Conversion

The Gap Google Left Open

Google’s own WordPress plugin has a form-tracking gap that has persisted for years, despite being the most requested feature in its support forums.

WordPress powers 43.4% of all websites on the internet. A significant percentage of those sites are lead-generation businesses, service companies, consultancies, and agencies whose primary conversion is a form submission, not a product purchase. And yet Google’s flagship WordPress integration, Site Kit, still treats form tracking as an afterthought.

Site Kit added what it calls “plugin conversion tracking” in 2024. The feature detects a handful of supported form plugins, including Contact Form 7, WPForms, and Ninja Forms, and fires a browser event when a user submits a form. That event flows to GA4 and, if configured, to Google Ads. On paper, the gap is closed.

In practice, the event still fires from the browser, which means it is subject to every force that is systematically killing client-side tracking: ad blockers, ITP, and consent-banner denial. The 31.5% of internet users who run ad blockers never fire that event. The 75%+ of users in Germany and France who reject tracking cookies never fire that event. The growing share of Safari and Firefox users whose browsers restrict or delete tracking scripts never fire that event.

31.5% of internet users globally use ad blockers, and that percentage rises to nearly 50% among men aged 25 to 34, directly suppressing browser-fired form conversion events.

The result is a structural blind spot. Lead-gen sites are paying for clicks that generate real leads, but those leads vanish from their analytics and their ad-platform attribution before anyone can count them.

You may be interested in: Google Killed Privacy Sandbox. Your WooCommerce Data Is Still Leaking

Why Browser-Side Form Tracking Breaks

Three independent forces are suppressing client-side form events, and they compound rather than overlap.

Understanding why browser-side tracking fails requires looking at the three mechanisms separately, because each one operates independently and they stack on top of each other.

Ad blockers now affect over 900 million users globally. Extensions like uBlock Origin and browsers like Brave block the Google Analytics script, the Google Ads conversion tag, and any third-party tracking pixel before they can load. When those scripts don’t load, no form-submission event can fire, regardless of how the form plugin is configured. This isn’t a niche concern. Among men aged 25 to 34, the most commercially valuable demographic for many B2B and professional-services lead-gen businesses, ad-blocker adoption reaches 36.2%.

Safari’s Intelligent Tracking Prevention and Firefox’s Enhanced Tracking Protection cap or delete first-party cookies set by JavaScript, which breaks the session continuity GA4 depends on. Even when the form event does fire, it may arrive in GA4 without the session context needed to attribute it to a campaign, a source, or an ad click. The conversion technically exists in the data, but it’s orphaned.

Consent banners, operating correctly under GDPR, block all non-essential scripts until the user opts in. In the EU, regulators now require that the reject option be as prominent and accessible as the accept option. The result is predictable: in Germany and France, fewer than 25% of users accept tracking cookies. That means more than 75% of visitors in those markets never load the tracking scripts at all. Poor cookie-consent implementation can lose 40% to 60% of advertising measurement data outright.

These three forces don’t cancel each other out. They compound. A user in Munich running Firefox with an ad blocker who also rejects consent is invisible to client-side tracking three times over. Each layer independently ensures the form-submission event never reaches Google.

The Thank-You Page Hack and Why It Fails

The most common workaround for form tracking on WordPress has a fundamental architectural flaw that grows worse as form design modernizes.

The standard advice in every WordPress form-tracking tutorial is the same: create a thank-you page, redirect the user after submission, and track the pageview on that URL as the conversion. It’s the method Google’s own documentation suggests. It’s what most agencies implement by default.

The problem is that modern forms increasingly don’t redirect. AJAX submissions, inline confirmation messages, and multi-step forms that resolve without a page load are now standard. WPForms, Gravity Forms, and Contact Form 7 all default to AJAX submission. When there’s no page navigation, there’s no thank-you-page URL to match against, and the conversion tracking chain breaks silently.

Even when a redirect does happen, the thank-you page itself is a client-side destination. The GA4 pageview that fires on that page is still subject to every ad blocker, ITP restriction, and consent denial described above. You’ve added a redirect to your user experience and gained nothing in tracking reliability.

The thank-you page is a symptom of a deeper architectural choice: relying on what happens in the browser instead of what happens on the server. The form plugin already knows the submission succeeded. It processed the data, validated the fields, stored the entry, and sent the notification email. All of that happened server-side. The only step that depends on the browser is the tracking event, and the browser is the one component that is increasingly unreliable.

What Server-Side Form Capture Actually Means

Server-side form capture moves the conversion event from the browser to the hosting server, where ad blockers, ITP, and consent denial cannot reach it.

Server-side form capture is not a theoretical concept. It’s a specific architectural pattern: instead of waiting for the browser to fire a JavaScript event after form submission, the conversion event is generated on the server at the moment the form plugin processes the submission.

Here’s the thing: your WordPress server already knows the form was submitted. Gravity Forms fires an action hook when it processes an entry. WPForms fires an action hook. Contact Form 7 fires an action hook. The submission data, including the user’s email, name, and phone number, is already available on the server before the browser even displays the confirmation message.

Server-side capture hooks into that moment and sends the conversion event directly from your server to Google’s endpoints, bypassing the browser entirely. No ad blocker can intercept a server-to-server API call. No ITP restriction applies to a server-originated request. No consent banner can block a process that runs on your own hosting infrastructure.

Server-side form capture fires the conversion event at the moment the form plugin processes the submission on the server, bypassing ad blockers, ITP, and consent suppression entirely.

GA4’s Measurement Protocol accepts server-originated events. Google Ads Enhanced Conversions for leads accepts hashed first-party data sent from your server. Both of these are documented, supported Google APIs. The only missing piece has been a WordPress-native tool that connects the form plugin’s server-side hook to these APIs without requiring a developer to write custom code or maintain a server-side GTM container.

Method	Survives Ad Blockers	Survives ITP	Survives Consent Denial	Works Without Thank-You Page
Site Kit Plugin Conversion Tracking	No	Partial	No	Yes (limited plugins)
GTM DataLayer Push	No	Partial	No	Yes
Thank-You Page Pageview	No	Partial	No	No
Server-Side Form Capture	Yes	Yes	Yes	Yes

Consent Banners: The Silent Conversion Killer

Consent compliance doesn’t just affect EU businesses. Any site with EU visitors loses form conversions under GDPR’s opt-in requirement.

Consent banners deserve a separate discussion because their impact is frequently underestimated, and it is growing. GDPR enforcement has intensified: European regulators now mandate that cookie-rejection options must be equally prominent as acceptance options, and fines for non-compliant banners have exceeded 100 million euros in aggregate across CNIL actions alone.

The practical result is that EU cookie-acceptance rates have collapsed. In Germany and France, the two largest EU economies, fewer than 25% of users accept tracking cookies. In the United States, acceptance rates exceed 80%, but any WordPress site serving international traffic, which is most of them, faces a blended consent rate that drags overall tracking completeness down significantly.

When a user rejects consent, Google’s Consent Mode v2 enters “denied” state. In this state, GA4 can model some aggregate data using cookieless pings, but it cannot record individual conversion events tied to specific users or sessions. A form submission that occurs during a denied-consent session is effectively invisible to your conversion reporting. It happened. The lead is real. Your Google Ads campaign generated it. But it will never appear as an attributed conversion.

Server-side form capture does not bypass consent requirements. However, it operates on first-party data that the user explicitly provided by submitting the form. When a visitor fills in their email, name, and phone number and clicks submit, they have provided that data to your business directly. The conversion event is sent using that first-party data, hashed, to Google’s server-side endpoints. This is architecturally distinct from dropping a tracking cookie onto a browser, and it’s the pattern Google’s own Enhanced Conversions for leads documentation recommends.

You may be interested in: Manifest V3 Killed Real-Time Ad Blockers on Chrome and Pushed Users to Brave

Where the Data Goes After Capture

Once the form event fires server-side, it can feed GA4, Google Ads, Meta CAPI, and BigQuery simultaneously through a single pipeline.

The value of server-side form capture extends beyond fixing a single tracking gap. Once the conversion event exists on the server, it becomes a structured data record that can be routed to multiple destinations in parallel.

GA4 Measurement Protocol receives the event as a server-originated hit, complete with client_id for session stitching. Google Ads Enhanced Conversions for leads receives the hashed email and phone number, improving match rates and enabling offline conversion import. Meta’s Conversions API receives the same event, closing the attribution loop for Facebook and Instagram campaigns. And the raw event data flows to BigQuery for long-term analysis, cross-platform attribution, and custom reporting.

This is the infrastructure pattern that enterprise advertisers have been running for years through custom-built pipelines and server-side GTM containers. The difference is cost and complexity. A WordPress lead-gen site running Gravity Forms shouldn’t need a server-side GTM container, a cloud function, and a DevOps team to track a form submission.

In Seresa’s architecture, inPIPE hooks the form plugin’s server-side submission event, and Transmute Engine routes the hashed, structured conversion data to every configured destination. The site owner installs a WordPress plugin. The pipeline handles the rest. No GTM. No thank-you page. No developer writing custom dataLayer code. And critically, no dependency on whether the visitor’s browser cooperates.

Key Takeaways

• Google’s Site Kit still fires form events from the browser: Its plugin conversion tracking feature detects select form plugins, but the event is client-side and subject to ad blockers, ITP, and consent denial.
• 31.5% of users globally run ad blockers: Over 900 million people suppress the tracking scripts that form conversion events depend on, with the highest rates among the most commercially valuable demographics.
• EU consent rejection exceeds 75% in key markets: In Germany and France, fewer than one in four users accepts tracking cookies, silently killing any browser-dependent conversion event.
• Thank-you pages and GTM dataLayer pushes face the same exposure: Both are browser-side methods and both fail under the same conditions that suppress Site Kit’s events.
• Server-side form capture is the durable architecture: It hooks the form plugin’s server-side submission event and sends conversion data directly to GA4, Google Ads, and Meta without touching the browser.

References

• GWI via Backlinko. “Ad Blocker Usage and Demographic Statistics in 2026.” Backlinko, updated March 2026.
• W3Techs via ThemeHunk. “WordPress Market Share Statistics and Trends in April 2026.” ThemeHunk, 2026.
• Advance Metrics via CookieYes. “Cookie Consent Trends by Country: 2026 Global Compliance Guide.” CookieYes, January 2026.
• Google. “Plugin Conversion Tracking.” Site Kit by Google Documentation, 2024.
• SecurePrivacy. “Global Cookie Consent Trends 2026.” SecurePrivacy, November 2025.
• Statista via DataFeature. “Ad Blocker Usage Statistics.” DataFeature, updated 2026.
• Google. “Enhanced Conversions for Leads.” Google Ads Developer Documentation, 2026.

If your WordPress site generates leads through forms and you’re paying for the clicks that produce them, the tracking gap isn’t academic. Talk to Seresa about closing it.