Iframe tracking issues
An iframe is a nested browsing context with its own document, origin, and storage partition. Analytics running inside an iframe report the iframe's URL (not the parent page), see the parent as the referrer, and — under storage partitioning — cannot share cookies with the top-level site. This produces orphaned pageviews, self-referrals, and broken identity. This page explains the constraints.
Why iframes complicate measurement
An iframe loads a separate document inside the parent. JavaScript inside it sees window.location of the iframe's own URL, and document.referrer typically shows the parent page. If the iframe is cross-origin, the same-origin policy blocks it from reading the parent's DOM or storage, so a tag inside cannot know the parent page's URL without explicit messaging.
Identity and referrer breakage
Browsers now partition storage by top-level site, so a cross-origin iframe gets its own cookie/storage jar separate from the parent. That means an analytics client id set inside the iframe does not match the parent's, fragmenting identity. The iframe's hit also records the parent as its referrer, which can surface as a self-referral when the embed and host share a domain family.
Fixes include sending the parent's URL into the iframe via postMessage so the tag reports the real page, and deciding deliberately whether the iframe should be tracked at all.
- Iframe JS sees its own URL, parent as referrer
- Cross-origin frames cannot read parent DOM/storage
- Storage partitioning gives the iframe a separate cookie jar
- Pass parent context via postMessage if the embed must report it
How it appears in analytics and logs
Pageviews for an embed/widget URL with the parent page as referrer usually mean a tag is firing inside an iframe, not on the visible page itself.
Diagnostic use case
Explain why an embedded widget or checkout in an iframe produces pageviews for an unfamiliar URL, or shows the host page as a referrer.
What WebmasterID can help detect
WebmasterID records events from the context that fires them, so you can tell parent-page activity from iframe-embedded activity rather than blending them.
Common mistakes
- Expecting an iframe tag to read the parent page's URL or cookies.
- Counting iframe pageviews as host-page pageviews.
- Ignoring storage partitioning when reasoning about embed identity.
Privacy and accuracy notes
Cross-origin iframes are increasingly storage-partitioned by browsers; do not rely on shared third-party cookies. This page is educational, not legal advice.
Related pages
- Self-referrals and lost attribution
A self-referral is when your own site shows up as a referring source in your reports. It usually means a session was broken and a new one started attributed to your domain, often when a visitor crosses subdomains or returns from a payment provider. Self-referrals fragment sessions and steal credit from the real source. This page explains the causes and the fix.
- Cross-domain tracking issues
A single user crossing from one domain to another (site to a separate checkout or booking host) should stay one user and one session. Without cross-domain tracking, the second domain starts a fresh session and often a self-referral, double-counting users and breaking attribution. This page explains how the GA4 linker passes the client ID and the common reasons it does not arrive.
- Hostname leakage across properties
Your measurement ID is visible in page source, so anyone can paste it on another site and have that traffic report into your property. Staging copies, scraped clones, and proxies do this too. The leaked hits inflate and pollute your data with another domain's traffic. This page explains hostname/property leakage and the valid-hostname filtering that contains it.
- Website Observability
Separate embed activity from host-page activity.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.