Why Your GCLID Disappears Between Pages (WordPress Fix)

The Problem: Your GCLID Vanishes the Moment Visitors Click Away

You spend $2,000 a month on Google Ads for your law firm. A prospect searches “personal injury lawyer Austin,” clicks your ad, and lands on your homepage. The URL in their browser reads yoursite.com/?gclid=EAIaIQob... — proof that Google tracked the click.

Then they do what any reasonable person does. They browse your About page. They read a case study. They click “Contact Us” and fill out your intake form. Your form captures their name, email, and phone number — but zero information about which ad brought them to your site. The GCLID was in the homepage URL, not the contact page URL. It’s gone.

A GCLID (Google Click ID) is a unique identifier Google attaches to your URL when someone clicks your ad. It’s the thread that connects a click in Google Ads to whatever happens on your website. Without it, you can’t tell Google which clicks turned into clients. Your Smart Bidding algorithm keeps optimizing in the dark.

This article explains the three reasons this happens and two ways to fix it — one takes two minutes, the other takes a developer.

Why This Happens (And It’s Not a Bug)

The URL Changes When They Navigate

The GCLID is a URL parameter — the ?gclid=xxx portion tacked onto your landing page address. It only exists in that specific URL. The moment a visitor clicks any internal link on your site, the browser loads a new page with a completely different URL. No GCLID attached.

If your form reads the GCLID from the current page’s URL at the time of submission, it’ll find nothing on any page except the original landing page. This isn’t a WordPress bug or a theme conflict. It’s how URLs have always worked. The parameter belongs to the page it arrived on, and it doesn’t follow the visitor around.

This is the single most common reason GCLID data goes missing, and it affects every WordPress site regardless of theme, hosting, or form plugin. If you’re using UTM parameters to track form submissions, those vanish in the same way.

Caching Plugins Strip the Query String

Even on the landing page itself, you can lose the GCLID before anything captures it. WordPress caching plugins — WP Rocket, LiteSpeed Cache, W3 Total Cache — and managed hosting platforms like WP Engine cache pages to improve load speed. When they serve a cached version, they sometimes strip query parameters like ?gclid from the URL before the page’s JavaScript has a chance to run.

The visitor sees the GCLID in their browser’s address bar. But the cached page your server delivered never processed it. Your tracking script fires, reads the URL, and finds nothing.

The fix is to exclude URLs containing ?gclid from your cache. But this needs to happen at two levels: your caching plugin’s settings and your server or CDN layer. If you’re using Cloudflare, you need a Cache Rule that bypasses cache when the query string contains gclid. If you’re behind Nginx, you need a configuration rule there too. Missing either layer means cached pages can still swallow the parameter.

Redirects Drop the Parameter

If your site redirects http:// to https://, or non-www to www, or adds a trailing slash to URLs, each redirect is a chance for query parameters to get stripped. The visitor clicks your ad and hits http://yoursite.com/?gclid=abc. Your server redirects to https://www.yoursite.com/. The GCLID didn’t survive the hop.

Google’s own support documentation warns that website redirects can cause click data to be lost. The fix is straightforward: make sure your Google Ads destination URLs use the final, canonical URL format. That means https://, the correct www or non-www prefix, and trailing slashes that match your WordPress permalink settings. No redirects means no opportunity to lose parameters.

Use a redirect checker tool (search “redirect checker” — there are several free ones) to test your ad’s destination URL. If you see more than one hop, update the URL in your Google Ads campaign.

iOS and Privacy: No GCLID at All

On iPhones and iPads, Safari’s Intelligent Tracking Prevention (ITP) limits JavaScript-set cookies to 7 days. In some scenarios — like when the user arrives via a cross-site redirect — the cap drops to 24 hours. That means even if you store the GCLID in a cookie, it may expire before the visitor returns to convert.

But there’s a bigger issue. For some clicks on iOS, Google doesn’t attach a GCLID at all. Instead, it uses two privacy-preserving alternatives:

• wbraid — used for web-to-web measurement when third-party cookies are blocked. Google generates this when it can’t rely on traditional cookie-based tracking.
• gbraid — used for app-to-web measurement. If someone clicks your ad inside an app and lands on your website, you’ll get a gbraid instead of a GCLID.

If your tracking setup only captures gclid and ignores wbraid and gbraid, you’re blind to a growing chunk of your iOS traffic. Any solution you implement needs to capture all three parameters.

The Fix: Store the GCLID in a Cookie

The solution is simple in concept. Capture the GCLID (and wbraid/gbraid) the instant the visitor arrives on your site. Store those values in a first-party browser cookie — a small piece of data your website saves in the visitor’s browser. Then, when they submit a form on any page, read the values from the cookie instead of the URL.

The cookie persists across page navigations. It doesn’t care whether the visitor is on your homepage, your About page, or your contact form. As long as the cookie hasn’t expired, the GCLID is there waiting to be read.

One critical implementation detail: the cookie must be set with path=/ so it’s accessible on every page of your site, not just the landing page. It also needs SameSite=Lax (so modern browsers include it on same-site navigations) and the Secure flag (so it only transmits over HTTPS). Skip either of these and you’ll hit silent failures in Chrome, Firefox, and Safari.

This is exactly what every GCLID tracking plugin does under the hood. The difference is whether you build it yourself or install a plugin that handles it automatically — along with the nine different form plugin integrations, the edge cases, and the iOS cookie limitations.

How to Set It Up

Option 1: Install a Plugin (2 Minutes, No Code)

Download TrueConversion from trueconversion.net. In your WordPress admin, go to Plugins > Add New > Upload Plugin, select the zip file, and click Install Now. Activate the plugin and follow the setup wizard.

Here’s what it does automatically, with no configuration beyond the wizard:

• Reads GCLID, wbraid, gbraid, MSCLKID (Microsoft Ads), FBCLID (Meta Ads), and all UTM parameters from the visitor’s URL on arrival.
• Stores them in a first-party cookie on your domain, scoped to the root path.
• When a visitor submits any supported form, the tracking data is appended to the submission and stored in your WordPress database.
• Provides a dashboard where you can see every submission’s traffic source, export to CSV, and receive email notifications.

TrueConversion works with Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Formidable Forms, Fluent Forms, Elementor Pro Forms, Forminator, and Jetpack Forms. If you use a different form plugin, a shortcode fallback ([utm_tracker_fields]) lets you add hidden tracking fields to any form.

The free version captures all tracking parameters, integrates with all nine form plugins, and gives you the dashboard and CSV export. TrueConversion Pro adds AI lead classification, conversion marking, Google Ads offline conversion upload, and Enhanced Conversions support — the features you’ll need once you’re ready to send GCLID data back to Google. There’s a 14-day free trial if you want to test the Pro features.

Download TrueConversion (Free)

---

Option 2: Custom JavaScript + PHP (Developer Route)

The JavaScript below runs on every page load. It checks the URL for a GCLID, wbraid, or gbraid parameter. If it finds one, it saves the value in a cookie that lasts 90 days.

// Read GCLID, wbraid, or gbraid from the URL and store in a cookie
(function() {
  // The three Google click parameters we need to capture
  var params = ['gclid', 'wbraid', 'gbraid'];

  // Parse the current page's query string
  var search = new URLSearchParams(window.location.search);

  params.forEach(function(param) {
    var value = search.get(param);
    if (value) {
      // Cookie expires 90 days from now
      var expires = new Date(Date.now() + 90 * 24 * 60 * 60 * 1000).toUTCString();

      // Set cookie at root path so it's readable on every page
      // SameSite=Lax: sent on same-site navigations
      // Secure: only transmitted over HTTPS
      document.cookie = param + '=' + encodeURIComponent(value)
        + '; path=/; expires=' + expires
        + '; SameSite=Lax; Secure';
    }
  });
})();

Add this script to your site by enqueueing it in your theme’s functions.php or placing it in a custom plugin. Don’t paste it into a “header scripts” box in your theme settings — those often load after the page renders, which creates a race condition where the visitor might navigate away before the script fires.

Here’s what the script does, line by line. It wraps everything in an IIFE (Immediately Invoked Function Expression) to avoid polluting the global scope. It defines the three parameter names to look for. It uses the browser’s built-in URLSearchParams API to parse the query string. For each parameter found, it calculates an expiration date 90 days in the future, then writes a cookie with path=/ (readable on every page), SameSite=Lax (compatible with same-site navigations), and Secure (HTTPS only).

That handles the capture side. Now you need to read the cookie when a form is submitted and attach the GCLID to the form data. This requires server-side PHP, and the implementation depends entirely on which form plugin you use.

Each form plugin exposes a different hook with a different signature. Contact Form 7 uses the wpcf7_before_send_mail hook, which gives you access to the submission object. WPForms uses wpforms_process_complete, which passes the entry data and form fields as separate arrays. Gravity Forms uses gform_after_submission with an entry array and a form object. Each requires different code to read the cookie, sanitize the value, and attach it to the form entry.

This is where a plugin saves you significant development work. Instead of writing and maintaining per-form-plugin integration code, you get a single installation that handles all nine form plugins plus a shortcode fallback.

One more consideration: on iOS Safari, cookies set via JavaScript (using document.cookie) are limited to 7 days by Intelligent Tracking Prevention. If your sales cycle is longer than a week, the GCLID cookie will expire before the visitor returns to convert. The workaround is server-side cookie setting using PHP’s setcookie() function on the first page load. This produces a first-party cookie that Safari treats with a longer lifespan. A plugin approach has a technical advantage here — it can set the cookie server-side automatically.

Testing That It Actually Works

You’ve installed a plugin or deployed the code. Now verify it’s working before you spend another dollar on ads. A broken tracking setup is worse than no tracking at all — it gives you false confidence that your data is complete when it isn’t.

1. Open an incognito or private browser window. This avoids cached cookies from previous tests that could give you a false positive.
2. Navigate to your landing page with a test GCLID appended: yoursite.com/?gclid=test_click_123
3. Click through to your contact page, or wherever your form lives. Don’t submit the form from the landing page — the whole point is to test cross-page persistence.
4. Fill out and submit a test form entry with a recognizable name like “GCLID Test.”
5. Check the entry in your TrueConversion dashboard (under Lead Source in the WordPress admin sidebar) or in your database if you used custom code. The GCLID field should show test_click_123.
6. If you’re using TrueConversion, run two additional tests with ?wbraid=test_wbraid_456 and ?gbraid=test_gbraid_789 to confirm all three Google parameters are captured.

Run this test after every major site change — theme updates, new caching configurations, CDN migrations, SSL certificate renewals. Any of these can introduce redirects or caching behavior that silently breaks parameter persistence.

What to Do With the GCLID After You’ve Captured It

Now that you’re capturing the GCLID with every form submission, you have the data you need to import offline conversions back to Google Ads. When a lead becomes a paying customer — weeks or months after the initial click — you can send that GCLID back to Google so Smart Bidding learns which clicks produce real revenue, not just form fills. This is how you move from optimizing for leads to optimizing for profit.

For a complete walkthrough of how to close the loop with Google Ads — including the free tracking setup and the Pro upload feature — see our guide to offline conversion tracking without a CRM. If you want deeper background on Google’s offline conversion import process and how it connects to Enhanced Conversions, we cover that in our Google Ads offline conversion tracking for WordPress guide.