If you’re running Google Ads, Meta Ads, or any paid campaign that sends traffic to a WordPress site, there’s a good chance you’re losing attribution data on a significant number of your leads. Your CRM says “direct traffic.” Your analytics show unattributed conversions. And you’re left making budget decisions based on incomplete data.
The culprit? UTM parameters disappearing in WordPress before your visitor ever submits a form.
This guide explains exactly why it happens, how to diagnose which cause affects your site, and three proven methods to persist UTM parameters across every page — so every lead gets properly attributed to the campaign that generated it.
Your UTM Parameters Vanish After One Click
Here’s the scenario. A potential customer clicks your Google Ad. The URL looks like this:
https://yoursite.com/landing-page/?utm_source=google&utm_medium=cpc&utm_campaign=spring-sale&gclid=abc123They land on your page. The UTM parameters are right there in the URL. So far, so good.
But then they click your navigation menu to check your pricing. The URL changes to:
https://yoursite.com/pricing/The UTM parameters are gone. When they finally fill out your contact form on a third page, there’s no trace of where they came from. Your form plugin records the submission, but the traffic source is blank. Your CRM logs it as “direct” or “unknown.”
This isn’t a rare edge case. It happens on every WordPress site that doesn’t explicitly handle UTM persistence. And it means you’re flying blind on which campaigns actually generate revenue.
7 Reasons WordPress Loses Your UTM Parameters
UTM parameters can vanish at several points between ad click and form submission. Understanding which cause affects your site is the first step to fixing it.
Client-Side: The Browser Drops Them
1. Standard page navigation. This is the most common cause and it affects every website, not just WordPress. UTM parameters exist only in the URL of the page the visitor landed on. The moment they click any internal link — your menu, a button, a text link — the browser navigates to a new URL that doesn’t include those parameters. They’re not stripped or deleted; they simply aren’t carried forward. This is normal browser behaviour, and it’s why every site needs a persistence mechanism.
Server-Side: WordPress or Your Hosting Strips Them
2. Caching plugins. Server-side caching plugins like WP Super Cache, W3 Total Cache, and WP Fastest Cache can interfere with UTM tracking. When caching is aggressive, the server may serve a pre-built page that never processes the query string at all. Some configurations strip query parameters entirely to improve cache hit rates. If your form plugin relies on server-side access to UTM parameters (rather than client-side JavaScript), caching can make them invisible.
3. Managed hosting platforms. Hosts like WP Engine, Kinsta, and Cloudways apply their own server-level caching and URL normalisation. WP Engine has historically been known to strip UTM parameters in certain caching configurations, serving cached page versions that don’t reflect the query string in the original request. The specific behaviour depends on your plan and cache rules — check with your host’s support team if you suspect this is happening.
4. Misconfigured redirect rules. When your site redirects a URL — for example, adding a trailing slash or forcing HTTPS — query parameters can be dropped if the redirect rule doesn’t explicitly pass them through. On Apache servers, this means the .htaccess rewrite rule is missing the QSA (Query String Append) flag. On Nginx, the config needs to include $args or $query_string. This is a server configuration issue, not a WordPress core problem, but it catches many site owners off guard.
5. SEO plugin redirects. Custom redirect rules created in Yoast Premium or Rank Math can drop query strings if the destination URL is hardcoded without a passthrough rule. This applies to manually created redirects within these plugins — their automatic canonical redirect behaviour typically preserves query parameters. If you’ve set up 301 redirects through your SEO plugin, test them with UTM parameters attached to confirm they pass through.
Third-Party: External Platforms Strip Them
6. CDN and edge caching. If you use Cloudflare (especially with APO enabled) or another CDN, edge caching may serve cached page versions that were built from requests without UTM parameters. The CDN doesn’t strip the parameters from the URL per se — but the cached response your visitor receives may not reflect them, making UTM data inaccessible to server-side WordPress code. Adding cache bypass rules for URLs containing utm_ parameters is the standard fix.
7. Social platforms and in-app browsers. LinkedIn’s link-tracking redirects can drop UTM parameters depending on how the link was shared and whether it’s opened in the app or browser. Facebook and Instagram’s in-app browsers can strip parameters during handoff to Safari on iOS. These are largely outside your control at the platform level, which makes client-side cookie persistence (covered below) even more important — it captures UTMs before any platform can interfere.
Quick Diagnostic Checklist
Not sure which cause is affecting your site? Walk through this checklist:
- Test basic navigation. Visit your site with UTM parameters in the URL. Click to another page. Check the URL — are the parameters gone? (They will be. This is cause #1 and affects everyone.)
- Check for redirect chains. Paste your UTM-tagged URL into httpstatus.io or a similar redirect checker. If you see 301/302 redirects, check whether the final URL still has the query string.
- Disable caching temporarily. Turn off your caching plugin, then test a UTM-tagged URL. If tracking starts working, your cache configuration is the problem.
- Test with and without Cloudflare. If you use Cloudflare, enable Development Mode (which bypasses the cache) and test UTM tracking. If it works in Development Mode, add a cache bypass rule for UTM parameters.
- Check your SEO plugin redirects. If you have redirects configured in Yoast or Rank Math, test each one with UTM parameters appended. Confirm the destination URL retains the query string.
- Test from different traffic sources. Click a link shared on LinkedIn, Facebook, and Twitter. Compare which platforms preserve your UTM parameters and which strip them.
- Check your hosting provider’s documentation. Search your host’s knowledge base for “query string caching” or “UTM parameters.” Many managed hosts have specific guidance.
In most cases, cause #1 (basic page navigation) is your primary issue. Even if you fix every server-side and third-party cause, you still need a persistence mechanism to carry UTM data across pages.
3 Proven Ways to Persist UTM Parameters Across Pages
Since UTM parameters live in the URL and URLs change on every page load, you need a way to capture the data once and make it available on every subsequent page. Here are the three main approaches.
Method 1: Store UTMs in Browser Cookies (Recommended)
This is the most reliable and widely-used method. A small JavaScript snippet runs when the page loads, checks the URL for UTM parameters, and writes them to a first-party cookie. On any subsequent page — whether it’s the next click or three pages later — the cookie is available and can be read into hidden form fields when the visitor submits a form.
The basic logic works like this:
- On page load, JavaScript reads
window.location.searchfor UTM parameters and click IDs - If found, it stores them as a JSON object in a first-party cookie using
document.cookie - On subsequent pages, the cookie persists across navigation because it’s tied to your domain
- When a form is submitted, the cookie data is read and included with the submission — either via hidden fields or server-side processing
Cookie duration matters. You need to decide how long the UTM data should persist:
- Session cookie (recommended) — expires when the browser closes. Best for same-session attribution and the safest option under Safari’s Intelligent Tracking Prevention (ITP), which caps JavaScript-set persistent cookies at 7 days.
- 1-day cookie — covers visitors who leave and return within 24 hours.
- 7-day cookie — accommodates longer consideration cycles, but note that Safari ITP will delete JavaScript-set cookies after 7 days regardless.
Pros: Reliable across all pages, works with any form plugin, survives internal navigation, no impact on URLs or SEO.
Cons: Requires JavaScript (won’t work if JS is disabled, which is extremely rare). Safari ITP limits persistent cookie duration to 7 days for JavaScript-set cookies.
Method 2: Append UTMs to Every Internal Link
This approach (sometimes called “link decoration”) uses JavaScript to find every internal link on the page and append the current UTM parameters to each one. When the visitor clicks any link, the UTM parameters stay in the URL because they’ve been explicitly added to the destination.
Pros: UTMs stay visible in the URL throughout the session. No cookies required.
Cons: This method has significant downsides. Every internal page gets indexed with UTM parameters in the URL, creating duplicate content issues that can hurt SEO. Your analytics will show inflated page views with query string variations. Dynamically-loaded content (AJAX navigation, single-page app sections) may not get decorated. And it makes your URLs look messy to visitors.
For most WordPress sites, the SEO and analytics risks make this method a poor choice compared to cookie-based persistence.
Method 3: Google Tag Manager Persistence
Best for: sites already using GTM with a developer or analytics specialist on hand.
If your site already runs Google Tag Manager, you can use a community-contributed tag template called “Persist Campaign Data” (available in the GTM Community Template Gallery) to capture UTM parameters and store them in a first-party cookie. You configure which parameters to store, set the cookie duration, and the tag handles the rest.
You’ll then need a second step: a Custom HTML tag or JavaScript variable that reads the cookie and writes the values into your form’s hidden fields at submission time.
Pros: Leverages your existing GTM setup. No code changes to your WordPress theme.
Cons: Requires GTM knowledge. The persistence template is community-maintained, not an official Google product — verify it’s still available before relying on it. You still need to configure hidden fields in your form plugin, which varies by plugin.
How to Choose the Right Method
Here’s how the three methods compare across the criteria that matter most:
| Cookies (Method 1) | Link Decoration (Method 2) | GTM (Method 3) | |
|---|---|---|---|
| Setup difficulty | Moderate (JS required) | Moderate (JS required) | High (GTM + form config) |
| Reliability | High | Medium (breaks with AJAX) | High |
| SEO safe | Yes | No (duplicate content risk) | Yes |
| Works without developer | With a plugin, yes | No | No |
| Form plugin compatibility | All (via hidden fields or server-side) | Limited | Requires per-plugin config |
| Safari ITP impact | Session cookies unaffected; persistent capped at 7 days | No cookie impact | Same as cookies |
For most WordPress sites, cookie-based persistence is the clear winner. It’s reliable, SEO-safe, and works with every form plugin. The question is whether to implement it yourself or let a plugin handle it.
If you have a developer on staff and a simple setup (one form plugin, no complex tracking needs), a custom JavaScript snippet can work. But if you run multiple form plugins, want click ID tracking (gclid, fbclid, msclkid), or simply don’t want to maintain custom code through WordPress and theme updates, a dedicated plugin is the more practical path.
The Plugin Approach: Automatic UTM Persistence for WordPress
LeadSourcePro was built specifically to solve this problem. It handles the entire UTM persistence workflow automatically — no hidden fields to configure, no JavaScript to write, no GTM setup required.
Here’s how it works:
- Capture. A lightweight vanilla JavaScript file (no jQuery) runs on every page load. It reads UTM parameters and ad platform click IDs — including gclid (Google), fbclid (Meta), msclkid (Microsoft), li_fat_id (LinkedIn), and ttclid (TikTok) — from the URL.
- Persist. The captured data is stored in a first-party cookie with a configurable conversion window: same session, 1 day, or 7 days.
- Attach. When the visitor submits a form, LeadSourcePro hooks directly into your form plugin and attaches the stored traffic source data to the submission. No hidden fields, no shortcodes, no form template edits.
- Report. Every submission appears in a WordPress dashboard with the full attribution trail: traffic source, UTM parameters, click IDs, landing page, and referrer.
It works automatically with 9 form plugins — Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Formidable Forms, Fluent Forms, Elementor Pro Forms, Forminator, and Jetpack Forms — plus a [utm_tracker_fields] shortcode fallback for custom or unsupported forms (which does require manual placement).
Because the UTM capture runs entirely in the visitor’s browser via JavaScript, server-side caching doesn’t interfere. The plugin also auto-detects the traffic source even without UTM parameters — so visitors from organic search, direct traffic, and referral links are categorised too.
The free version includes all tracking features, all form integrations, a sortable dashboard, and CSV export — limited to the 10 most recent entries on a rolling basis. Pro plans unlock unlimited entries, per-submission email notifications, and summary reports.
All data stays in your WordPress database. No external servers, no third-party analytics dependencies. IP addresses are automatically anonymised.
Frequently Asked Questions
Does Google Analytics still track UTMs if they disappear from the URL?
Yes — but only for the landing page session. Google Analytics captures UTM parameters when the visitor first arrives and stores them in its own cookie. So your GA reports will show campaign data for that session. The problem is on the lead capture side: if your form plugin doesn’t have access to the UTM data when the form is submitted (which may be several pages later), you can’t connect a specific lead to a specific campaign in your CRM or email system.
How long should UTM cookies persist?
It depends on your sales cycle. For most B2B and lead-gen sites, a session cookie is the safest and most accurate choice — it attributes the lead to the campaign that brought them in during that visit. A 7-day window accommodates visitors who return before converting, but introduces the risk of misattribution if they click a different campaign in the meantime. Longer windows also run into Safari ITP limits, which cap JavaScript-set cookies at 7 days.
Does cookie-based UTM tracking work with WooCommerce?
Yes. Cookie-based tracking works with WooCommerce because the cookie is set and read entirely in the browser, independent of WooCommerce’s cart and checkout flow. If you’re using a form plugin on your WooCommerce site for lead capture (contact forms, quote requests, etc.), the UTM data persists through the browsing session just like on any other WordPress page.
Will this work with Safari’s Intelligent Tracking Prevention (ITP)?
Session cookies are not affected by Safari ITP — they expire when the browser closes, which is before ITP’s enforcement kicks in. If you use a persistent cookie (1-day or 7-day), Safari ITP caps JavaScript-set first-party cookies at 7 days. For most lead generation workflows where the visitor converts in the same session, this isn’t a practical concern. If your conversion cycle is longer than 7 days and you have significant Safari traffic, consider a server-side cookie approach as a more durable alternative.
What about click IDs like gclid and fbclid — do they disappear too?
Yes, click IDs are query parameters just like UTMs, so they’re subject to the exact same issues. A gclid from Google Ads or an fbclid from Meta Ads will vanish the moment the visitor navigates to another page. Any persistence method that handles UTM parameters should also capture these click IDs. LeadSourcePro captures gclid, fbclid, msclkid (Microsoft), li_fat_id (LinkedIn), and ttclid (TikTok) alongside UTM parameters automatically.
Stop Losing Attribution Data
Every form submission without a traffic source is a data gap that compounds over time. You end up undervaluing the campaigns that actually drive leads and overvaluing the ones that just happen to be running when someone converts from an earlier touchpoint.
The fix is straightforward: capture UTM parameters on arrival, persist them in a cookie, and attach them to every form submission. Whether you build it yourself or use a plugin like LeadSourcePro, the important thing is that every lead carries its source data from click to conversion.
See how LeadSourcePro works or install the free version and start tracking in under two minutes.
Leave a Reply