How To Track Which Landing Page Each Lead Came From

You run three landing pages for your business — one for each service. Last month you got 47 leads through your WordPress forms. Which page produced the ones that actually became customers?

You open Google Analytics and see that /services/repairs got 1,200 sessions and /services/installations got 800. The bounce rates look reasonable and the average session duration is healthy. But your inbox has 47 form submissions with nothing more than a name, email, phone number, and message. There is no indication of which page the visitor originally landed on before they filled out your form.

This is the gap that catches most small business owners off guard. Google Analytics shows aggregate traffic patterns — sessions per page, bounce rates, channel breakdowns. What it cannot do is attach a specific lead to a specific landing page. You know 47 people submitted forms and three pages received traffic, but you cannot draw a line between the two. The result is you keep spending money on all three pages — or worse, you cut the wrong one based on traffic volume alone.

This guide shows you two methods to solve the problem. Method 1 uses a plugin and takes about two minutes. Method 2 is a manual implementation with hidden fields and JavaScript that takes roughly 30 minutes. Both capture the exact landing page URL with every WordPress form submission so you can finally see which pages are pulling their weight.

---

Why You Cannot See Which Landing Page Sent Each Lead

No tool in your default WordPress stack is designed to record this. Google Analytics tracks pages. Form plugins track submissions. Neither connects the two at the individual lead level.

What Google Analytics Shows (And What It Does Not)

Google Analytics 4 gives you a Landing Page report under the Engagement section. This report shows the first page visitors see when they arrive on your site, along with metrics like sessions, engaged sessions, engagement rate, and conversions. If you have set up a form submission event, you can even see the conversion rate per landing page.

What you get is an aggregate view. You can see that /services/repairs had a 3.2% conversion rate from 1,200 sessions, meaning roughly 38 conversions. But you cannot click into that number and see a list of the 38 people who converted, their names, or what they wrote in your form. GA4 deals in anonymised, aggregated behavioural data — not individual lead records.

When you follow up with a lead and they become a customer, you need to trace that revenue back to a specific landing page. Aggregate conversion rates cannot tell you whether the leads from /services/repairs were worth more than those from /services/installations. For that, you need per-lead data.

Landing Page vs Traffic Source vs Conversion Page

These three terms get conflated constantly, so let us define them clearly.

Landing page is the URL of the first page a visitor sees in a session. If someone clicks a Google Ad pointing to /services/repairs, that remains the landing page even after they navigate to /about, /pricing, and /contact.

Traffic source is the channel, medium, campaign, or platform that sent the visitor — what UTM parameters capture (utm_source=google, utm_medium=cpc). The traffic source tells you where the visitor came from. The landing page tells you where they arrived.

Conversion page is the URL where the form was submitted. If your contact form lives on /contact, the conversion page is /contact regardless of where the visitor first landed. Many form plugins record this natively, which causes confusion — people assume it is the landing page when it is just the page the form sits on.

For proper attribution, you want all three. Together, they tell you which entry point is working, which campaign drove the visit, and which form converted the lead.

Why WordPress Forms Do Not Capture This By Default

Form plugins like WPForms, Contact Form 7, and Gravity Forms collect what visitors type plus some metadata — timestamp, IP address, and the URL of the page containing the form. But the landing page URL is not metadata a form plugin can access. By the time the visitor reaches the form, the original entry URL exists only in the browser’s session history.

This is a fundamental architectural gap. The information lives in the browser. The form submission is processed on the server. Without a bridge between the two — typically a cookie or hidden field populated by JavaScript — the data is lost.

---

How Landing Page Tracking Works

Every reliable method for capturing landing page data uses the same fundamental approach: store the URL early, retrieve it later. The specifics vary, but the pattern is consistent.

The Cookie Method

On the first page load in a session, a small JavaScript snippet reads window.location.href and stores it in a first-party cookie. On subsequent page loads, the script checks whether the cookie already exists. If it does, the script does nothing. This is critical: the cookie must not be overwritten on subsequent pages, or you record the most recent page rather than the first one.

When the visitor submits a form, the landing page URL is read from the cookie and attached to the submission — either via a hidden form field that JavaScript populates, or via a server-side cookie read.

The cookie method is lightweight and reliable. It works across page loads, survives navigation through your site, and requires no server-side session management. The only question is how long the cookie should last.

Conversion Windows

The conversion window determines how long the landing page cookie persists. There are three common options.

A session cookie is deleted when the browser closes — the most conservative option. A 1-day cookie persists for 24 hours, covering visitors who leave and return the same day. A 7-day cookie covers visitors with longer consideration cycles who might visit multiple times before submitting a form.

There is an important caveat for Safari users. Apple’s Intelligent Tracking Prevention (ITP) limits client-side JavaScript cookies to a maximum of 7 days. If the referring domain is classified as a tracker and the URL contains link decoration (query parameters like gclid or fbclid) — which is the case for most ad clicks — that limit drops to 24 hours. According to StatCounter, Safari holds roughly 16% of the global browser market as of early 2026, so this affects a meaningful share of visitors. For most businesses, a session cookie is sufficient and avoids ITP complications entirely.

For a deeper look at how click IDs like gclid can disappear between pages, see our guide on fixing gclid loss between pages in WordPress.

---

Method 1 — Capture Landing Page Data Automatically (Recommended)

If you want landing page tracking working today without writing any code, TrueConversion handles the entire process automatically. It captures the landing page URL, conversion page URL, traffic source, UTM parameters, and ad platform click IDs (gclid, fbclid, wbraid, gbraid, msclkid) for every form submission on your site.

The plugin stores the entry URL and any UTM or click ID parameters in a first-party cookie on first page load. When a visitor submits a form, TrueConversion reads the cookie and attaches the data to the submission record — no hidden fields to configure, no JavaScript to write, and no cache exclusion rules to set up.

TrueConversion works with 10 form plugins out of the box:

1. Contact Form 7
2. WPForms
3. Gravity Forms
4. Ninja Forms
5. Formidable Forms
6. Fluent Forms
7. Elementor Pro Forms
8. Forminator
9. Jetpack Forms
10. Any form via the [utm_tracker_fields] shortcode

Here is what a tracked entry looks like in the TrueConversion dashboard:

Field	Example Value
Name	Sarah Mitchell
Email	sarah@example.com
Landing Page	/services/repairs?utm_source=google&utm_medium=cpc
Conversion Page	/contact
Traffic Source	Google Ads (CPC)
UTM Source	google
UTM Medium	cpc
UTM Campaign	spring_repairs_2026
GCLID	EAIaIQobChMI…
Submission Date	2026-02-28 14:32:07

Every submission is stored with the full attribution trail. You can filter, sort, and export entries as CSV from the WordPress dashboard. No data leaves your server.

To learn more about how the plugin works under the hood, see the How It Works page.

---

Method 2 — Add Hidden Fields Manually

If you prefer a manual implementation, you need three components: a JavaScript snippet to store the landing page URL in a cookie, a hidden form field to hold the value, and a second script to populate the field from the cookie before submission.

Before we start, a common mistake: most form plugins have a built-in “Page URL” or “Embed URL” feature. This captures the conversion page, not the landing page. If your form lives on /contact and the visitor landed on /services/repairs, the native feature gives you /contact. Useful, but not what we are capturing here.

The JavaScript Snippet

Add the following script to your site via your theme’s functions.php, a plugin like Code Snippets, or a custom JavaScript file.

// Landing Page Cookie — runs on every page load
(function() {
  // Check if the landing page cookie already exists
  if (document.cookie.indexOf('tc_landing_page=') === -1) {
    // Cookie does not exist — this is the first page of the session
    var landingPage = window.location.href;

    // Set as a session cookie (no expires = deleted on browser close)
    document.cookie = 'tc_landing_page=' + encodeURIComponent(landingPage) + '; path=/; SameSite=Lax';
  }
})();

The indexOf check ensures that if the cookie already exists from an earlier page, the value is preserved. This keeps the first page recorded rather than the current page. For a longer conversion window, add an expires value: use 86400000 milliseconds for 1 day or 604800000 for 7 days.

Adding the Hidden Field

Add a hidden field to your form with a consistent name so JavaScript can target it. The process varies by plugin.

WPForms (detailed walkthrough):

1. Open your form in the WPForms builder.
2. Drag a Hidden Field from the Fancy Fields section into your form. (Note: Hidden Field requires a paid WPForms licence — it is not available in WPForms Lite.)
3. Click the hidden field to open its settings.
4. Set the Label to Landing Page.
5. Leave the Default Value empty — JavaScript will populate it.
6. Note the field’s CSS class or ID. WPForms generates an ID like wpforms-{form_id}-field_{field_id}. You will need this for the JavaScript in the next step.
7. Save the form.

Contact Form 7: Add [hidden landing-page id:landing-page ""] to your form template. CF7 supports hidden fields natively.

Gravity Forms: Add a Hidden field from the Standard Fields section. Set the field label to “Landing Page” and leave the default value blank. Note the field ID number shown in the form editor.

Ninja Forms: Add a Hidden field from the Layout & Display section. Set the label to “Landing Page” and assign a key like landing_page.

Populating the Hidden Field from the Cookie

The final piece reads the cookie and writes the value into your hidden field. This must run after both the cookie-setting script and the form have loaded.

// Populate hidden field with landing page URL from cookie
document.addEventListener('DOMContentLoaded', function() {
  // Read the tc_landing_page cookie
  var cookies = document.cookie.split(';');
  var landingPage = '';

  for (var i = 0; i < cookies.length; i++) {
    var cookie = cookies[i].trim();
    if (cookie.indexOf('tc_landing_page=') === 0) {
      landingPage = decodeURIComponent(cookie.substring('tc_landing_page='.length));
      break;
    }
  }

  if (!landingPage) return;

  // WPForms: target by input name containing "landing-page" or by field ID
  var hiddenFields = document.querySelectorAll(
    'input[type="hidden"][name*="landing"], input[id*="landing-page"]'
  );

  hiddenFields.forEach(function(field) {
    field.value = landingPage;
  });

  // Contact Form 7: target by ID
  var cf7Field = document.getElementById('landing-page');
  if (cf7Field) {
    cf7Field.value = landingPage;
  }
});

Adjust the selectors to match the field IDs and names your form plugin generates. Inspect the rendered HTML to find the correct attributes.

Testing Your Setup

Test the entire flow end to end. A partial test will miss the most common failure modes.

1. Open an incognito/private browser window. This ensures no existing cookies interfere with the test.
2. Navigate to Page A with UTM parameters. For example: https://yoursite.com/services/repairs?utm_source=test&utm_medium=manual. This simulates a visitor arriving from a campaign.
3. Navigate to your form on Page B. Click through your site naturally to reach /contact or wherever your form lives. Do not go directly — you need to confirm the cookie persists across pages.
4. Submit the form and verify. Check the submission in your form plugin’s entries. The hidden field should contain the full URL from Page A — including the UTM parameters — not the URL of Page B where the form was submitted.

If the hidden field shows Page B instead of Page A, the cookie is being overwritten on each page load — check the indexOf logic. If the field is empty, the population script is not running or the CSS selector does not match your hidden field.

---

Common Reasons Landing Page Tracking Breaks

Even a correct implementation can fail under specific conditions. These are the issues we see most frequently.

Caching Plugins Serve Stale Forms

Page caching plugins like WP Rocket, W3 Total Cache, and LiteSpeed Cache serve pre-built HTML for faster load times. The JavaScript that populates hidden fields may be deferred or combined in a way that changes its execution order, leaving fields blank. The most reliable fix is to ensure your population script runs as an inline script rather than a deferred external file. For a full breakdown, see our guide on hidden fields not capturing UTM parameters.

AJAX Forms Replace the DOM After Load

AJAX submission itself is not the problem — the issue arises when the form plugin replaces DOM elements after the initial page load. If the form HTML is rebuilt dynamically, any values JavaScript wrote into hidden fields during DOMContentLoaded are wiped out. The solution is to re-populate hidden fields after the form’s AJAX events fire, or use a MutationObserver. For more detail, see our article on AJAX forms breaking Google Ads tracking.

Embedded Forms Cannot Read the Parent Page

If you embed a form using an iframe — common with Typeform, Cognito Forms, and some WordPress embed methods — the form inside the iframe cannot read cookies set on the parent page due to the browser’s same-origin policy. The workaround is to pass the landing page URL as a parameter on the iframe’s src attribute, which adds another layer of JavaScript to maintain. See our guide on tracking data lost in embedded forms and iframes.

Safari ITP Limits Cookie Lifetime

As covered above, Safari’s ITP caps JavaScript-set cookies at 7 days (24 hours for classified tracker domains). There is no client-side workaround. Server-side cookies set via HTTP headers are not subject to the same limit, which is one reason plugin-based solutions can offer more reliable tracking for longer conversion windows. For session-length tracking, ITP is not a factor.

---

What To Do With Per-Lead Landing Page Data

Capturing landing page data is the starting point for better decisions about your marketing spend. Here is how to use it.

Find Your Highest-Converting Landing Pages

Sort your form submissions by landing page URL and compare lead counts against traffic from Google Analytics. You now have a per-page conversion rate based on actual submissions, not just GA event counts.

The real insight comes when you track which leads become customers. If /services/repairs generates 40 leads per month and 12 become customers, while /services/installations generates 15 leads and 10 become customers, the installations page has a dramatically higher lead-to-customer rate. Without per-lead data, you would only see that repairs gets more traffic. This is the core value of landing page tracking — it shifts analysis from volume to quality. For a broader look, see our guide on lead source tracking for WordPress forms.

Feed Data Back to Google Ads

If you are running Google Ads, per-lead landing page data combined with gclid capture lets you import offline conversions back into Google Ads. This tells Google’s Smart Bidding algorithm not just that a conversion happened, but which landing page and which keyword produced a real customer.

When a visitor clicks an ad, a unique gclid is appended to the URL. Your tracking captures both the gclid and the landing page. When that lead becomes a customer, you upload the gclid and conversion value back to Google Ads via offline conversion import. Google associates the conversion with the specific click, keyword, ad, and landing page — and Smart Bidding uses this data to optimise future bids. Without this feedback loop, Smart Bidding optimises for form submissions, which may not correlate with actual revenue. For setup instructions, see our guides on offline conversion tracking without a CRM, Enhanced Conversions for Leads, and optimising Smart Bidding for real sales instead of junk leads.

Kill Pages That Generate Junk Leads

This is where the data pays for itself. When you can see that Page X generated 50 leads last quarter but zero became customers, while Page Y generated 10 leads and 8 converted to paying customers, the decision is clear. Reallocate ad spend from Page X to Page Y. Or rewrite Page X entirely — the copy may be attracting the wrong audience.

Without per-lead landing page data, you would look at Page X’s 50 leads and conclude it is your best performer. The landing page data gives you the evidence to reallocate spend with confidence.

If you are feeding conversion data back to Google Ads and encountering upload issues, see our troubleshooting guide on fixing offline conversion upload errors.

---

Landing Page Tracking vs Other Approaches

Here is how the main options compare.

Tool	Landing Page Data	Per-Lead Attribution	Setup Effort	Price
Google Analytics 4	Aggregate only	No	Low (already installed)	Free
WPForms User Journey	Full page path per lead	Yes	Low	From $199/yr (Pro plan required)
Attributer	Landing page + source	Yes	Medium (hidden fields per form)	From $29/mo
TrueConversion	Landing page + source + click IDs	Yes	Low (automatic)	Free plugin; Pro from $9.99/mo
Manual (hidden fields + JS)	Landing page only	Yes	High (custom code per form)	Free

Google Analytics gives you the broadest view but no per-lead detail. WPForms User Journey is excellent if you are already on WPForms Pro, though it captures page paths rather than full URLs with parameters. Attributer requires hidden field configuration for each form. TrueConversion handles everything automatically with no per-form setup. The manual method is free but requires ongoing maintenance when you add or change forms.

For a full breakdown of plans and features, see the TrueConversion pricing page.

---

Frequently Asked Questions

Can Google Analytics show which landing page each lead came from?

No. Google Analytics shows aggregate landing page data — total sessions, bounce rate, and conversion counts per page. It does not link individual leads to the specific landing page they arrived on. GA4 is designed for anonymised behavioural analysis, not per-lead attribution. You need a separate solution that captures the landing page URL alongside each form submission.

Does this work with WPForms Lite (free)?

WPForms Lite does not support hidden fields — that feature requires a paid licence. However, TrueConversion hooks into WPForms Lite automatically using server-side cookie reading, so you do not need hidden fields. Install TrueConversion and landing page data is captured for every WPForms Lite submission without any form modifications.

What is the difference between landing page and referrer?

The landing page is the first URL on your site that the visitor loaded. The referrer is the external URL they came from — google.com, facebook.com, or another website. The referrer tells you where the visitor was before your site. The landing page tells you where on your site they arrived. Both are useful, but they answer different questions.

What if my form uses AJAX submission?

AJAX submission itself does not break tracking. The issue occurs when a form plugin rebuilds the DOM after the initial page load, wiping out hidden field values. If values disappear on submit, check whether the form is replacing its HTML after load. You may need to re-populate the hidden field after the form’s initialisation event. See our guide on AJAX forms and tracking data.

Do I need to capture landing page AND traffic source?

Ideally you want both. The landing page tells you which entry point works. The traffic source tells you which campaign or channel drove the visit. Together, they answer questions like “Which Google Ads campaign sends the most leads to /services/repairs, and do those leads become customers?” Capturing only one gives you half the picture.

---