TL;DR
Google marks a page Not tagged when it has "never loaded your Google tag", and it publishes a list of pages it flags by mistake [2]. A Magento store hits two entries on that list with one URL, and its consent setting can add more expected rows. Clear those first. The rest get three checks: the store's Content Security Policy, a challenge page in front of the store, and container position.
Key Takeaways
- Magento's success page sends any visitor without a just-placed order to the cart [7], so it's a low-traffic page and a redirect, two of the four common false positives Google lists [2].
- On the Magento Cookie Restriction Mode consent method, the container waits for Allow only while Magento's own Cookie Restriction Mode switch is on.
- On External CMP the container always loads [1], so the EEA consent diagnostics point at real labeling gaps.
- A Content Security Policy block shows in the browser console by host name, and Google wants each of its top-level domains listed separately [6].
- Ignore removes a URL; Dismiss hides a diagnostic, including the tag gateway recommendation on stores running the extension's Worker [1] [3].
Two screens, three statuses
In Google Ads, open Data manager from the Tools menu and click Manage on the Google tag. In Google Analytics, click Configure tag settings on the data stream. In Tag Manager, open the Google tag, click Admin, and choose Tag coverage under Tools [2]. Tag Diagnostics sits under "Tag quality", behind View diagnostics [3].
Tag coverage lists up to 10,000 URLs, each with a status [2]:
| Status | Google's definition |
|---|---|
| Not tagged | "Pages that have never loaded your Google tag" |
| No recent activity | "Pages that haven't loaded your Google tag in the last 30 days, but have in the past" |
| Tagged | "Pages that have loaded your Google tag in the last 30 days" |
"Google tag" here means the gtag.js snippet or the GTM container, not the tags configured inside the container [2]. A status "is dependent on sufficient volume to provide a signal that the page is tagged", so on live traffic alone a page can take up to 24 hours to update, while Tag Assistant reads it in real time [2]. URLs come from detected pages, Tag Assistant suggestions and your own additions [2].
Hover over a Not tagged status and Google shows more detail [2]. In the reports that reach our support desk, that detail names a content security policy or a consent platform as the possible blocker. Google doesn't document how it arrives at it, so read it as a hint about which check to run first.
Which Not tagged rows are Google's own false positives?
Google names four kinds of correctly tagged page that may still be flagged: low-traffic pages ("thank you pages after ordering an item" is its example), redirects, URLs that differ only by a trailing slash, and URLs that differ only in capitalization [2]. Magento's order confirmation page is two of those at once.
The success page's controller, Adobe's public code, checks the checkout session first. Unless the session holds the IDs of a just-placed order, it sends the visitor to the cart with setPath('checkout/cart') [7]. It also clears the last successful quote from the session before the page renders, so even the buyer who reloads the confirmation lands in the cart [7]. Every other request is a redirect, and the real page gets one view per order.
The fix is Google's own. Connect Tag Assistant, place a test order, and watch the container fire on the confirmation page. If it fires, Google says a false alarm "should resolve itself within 24 hours", and you can Ignore the page in Tag coverage [2]. Don't add a second tag: a false positive comes from traffic volume and the redirect, and an extra tag changes neither.
If your store confirms orders on a different URL, list it in the extension's Success Page Paths setting, meant for when "the success page path is different from the default Magento path" [1]; our guide to tracking custom and one-page checkouts covers the rest. For slash and capitalization pairs such as /women/tops and /women/tops/, Ignore the version your navigation doesn't link to [2].
Does your consent setting explain the rest?
The extension's Consent Management Method, a PRO setting, has two values [1]. The default, Magento Cookie Restriction Mode, "uses Magento's built-in cookie banner. GTM loads only after the user accepts cookies". With External CMP, "GTM always loads, and the CMP handles consent via Google Consent Mode v2" [1]. The option arrived in v1.16.1 (March 6, 2026) [1].
That wording assumes Magento's banner is on, and the banner is a separate switch: Stores > Settings > Configuration, then Web under General, then Default Cookie Settings, then Cookie Restriction Mode [8]. Set to Yes, it shows visitors a notice with "the Allow button to grant consent" [8]. With the switch on, the container waits for Allow. With it off, the extension loads the container on every page, whichever consent method is selected.
| Your setup | Container | A Not tagged row from consent | The diagnostic that matters |
|---|---|---|---|
| Cookie Restriction Mode method, Magento switch Yes | Waits for Allow | Expected on pages visitors leave before clicking Allow | "Update your consent settings" |
| Cookie Restriction Mode method, Magento switch No | Loads on every page | Consent isn't the cause | The EEA consent diagnostics, if shown |
| External CMP | Loads on every page [1] | Consent isn't the cause | "Some pages missing consent for EEA users", "Consent missing for EEA users", "Consent mode installation out of order" |
On the first row, Google raises its diagnostic when EEA data "is not labeled with consent and we have been able to determine that you block tags for your entire website", and it sends you to Manage default consent settings in the Google tag [3]. Google writes that setting for stores that don't use consent mode or whose "Google tags are prevented from loading until a user interacts with your consent banner" [4]. Choosing "Yes. Automatically mark this data as consented" means, in Google's words, "you confirm that all data sent to Google is post consent and should be labeled as consented" [4]. Whether your store can make that statement is for whoever owns consent at your company to decide. If you also run consent mode, through a Consent Mode v2 module for instance, Google says those defaults "aren't applied to your tags" [4], and the third row's diagnostics are the ones to read.
On the second and third rows, the EEA diagnostics mean data "is not labeled with consent", and Google's fix is to "verify that the data is labeled with consent" [3]. Our guide to Consent Mode v2 on Magento 2 covers the labeling side.
Three checks for what's still Not tagged
Run these in order on each remaining URL.
1. Is the store's own policy blocking Google? Google's diagnostic here is "Content Security Policy blocks some resources", raised when essential tag resources are blocked because the policy doesn't list their origins [3]. Open the flagged page with the browser console showing; a blocked host is reported there by name. Compare it with Google's host list for the product that loads it, and mind the rule multi-country stores trip on: "Each Google top-level domain (TLD) must be specified individually, since CSP syntax does not allow the use of wildcards on the right side of the hostname" [6]. Ad pixel hosts follow the pixel switches since v1.17.1 (July 7, 2026) [1], as our guide to setting up the ad pixels from one admin explains. For checkout and payment pages, read the CSP section of our Google Tag Manager installation guide; for a policy that changed with a Magento upgrade, see verifying GA4 events.
2. Is a challenge page answering instead of your store? This is a pattern we see in support: before peak season, a store tightens its bot protection, and Not tagged rows start appearing on ad landing pages that the protection now answers with a challenge page instead of the store. Treat this as a possibility to rule out: request a flagged URL the way an automated client would and read what comes back. On Cloudflare, for example, every challenge page type carries the header cf-mitigated: challenge [9]; other CDNs document their own.
curl -s -o /dev/null -D - https://www.your-store.com/your-landing-page | grep -i cf-mitigated
3. Is the container high enough, and is the extension current? "Tag found too low on page" appears when the Google tag or the GTM container sits too far down the page code [3] [5]; the Magento settings and optimizers that move scripts are covered in the same GTM guide. Then check the version: v1.17.0 (May 18, 2026) through v1.17.3 carried a client-side bot flag that, per the v1.17.4 change log, let "a single crawler" suppress "tracking for every real shopper later served that cached page", so upgrade before you read the report, as our article on keeping bot traffic out of GA4 explains [1].
Ignore, Dismiss, and the recommendation to leave alone
Ignore works on a URL: hover over its row in Tag coverage and click Ignore, and it leaves the list and Tag Diagnostics until you add it back [2]. Dismiss works on a diagnostic: in the Google tag settings, open the Diagnostics tab, click the three-dot menu on the item under "Tag quality", and click Dismiss [3]. Not every alert can be dismissed, a dismissed one can return if more pages or users are affected, and dismissed items stay visible for 90 days [3].
"Your tag data may be restricted" appears when Google detects a CDN it supports, Cloudflare for example, without Google tag gateway for advertisers enabled. Google's fix is to enable the gateway "or you can dismiss the recommendation", and it uses this exact item as its example of a dismissible alert [3]. It's still rolling out gradually, so your account may not show it yet [3]. If your store serves the container through the extension's First-Party Tracking Worker, the user guide is blunt: "Do NOT use Cloudflare's built-in 'Google Tag Gateway' feature" [1]. Dismiss the recommendation and leave the Worker as it is; serving GA4 and GTM from your own domain has its setup.
FAQ
Do server-side events make a page count as tagged?
No [2]. Tag coverage only sees the browser tag; for server-side events, since v1.17.4 and with Require Visitor Consent for Server-Side Events switched on, the Measurement Protocol and the Conversions API addons follow the shopper's Consent Mode v2 choice too, as our guide to server-side events and consent explains [1].
Why are ad landing pages in the report before anyone has visited them?
Google adds the landing pages of your ad creatives and Performance Max campaigns to the report [3]. Until a visit loads the tag there, the page is Not tagged by Google's definition [2]. Open it in Tag Assistant for an immediate read.
Will campaign URLs with UTM parameters show up as separate rows?
No. The URL column shows "the domain and path only and doesn't include query parameters" [2].
Read each warning against what the Magento 2 Google Analytics 4 extension actually does on that page, then fix only the ones that are real. The current release is v1.17.5, September 16, 2026 [1].
Sources
- WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved October 6, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- About the Tag coverage summary, Google Ads Help, retrieved October 6, 2026, https://support.google.com/google-ads/answer/12270036?hl=en
- Troubleshoot tag issues with Tag Diagnostics, Google Ads Help, retrieved October 6, 2026, https://support.google.com/google-ads/answer/14681508?hl=en
- Configure your Google tag settings (Manage default consent settings), Tag Manager Help, retrieved October 6, 2026, https://support.google.com/tagmanager/answer/12131703?hl=en
- Fix tags not placed correctly, Google Ads Help, retrieved October 6, 2026, https://support.google.com/google-ads/answer/14718526?hl=en
- Use Tag Manager with a Content Security Policy, Google Tag Platform documentation, last updated September 18, 2026, retrieved October 6, 2026, https://developers.google.com/tag-platform/security/guides/csp
- Magento Open Source 2.4.8 source:
Checkout/Controller/Onepage/Success.php,Checkout/Model/Session/SuccessValidator.phpandCheckout/Model/Session.php(clearQuote), GitHub magento/magento2, retrieved October 6, 2026, https://github.com/magento/magento2/blob/2.4.8/app/code/Magento/Checkout/Controller/Onepage/Success.php - Cookie law compliance (Cookie restriction mode), Adobe Commerce Admin User Guide, retrieved October 6, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/start/compliance/privacy/compliance-cookie-law
- Detect a Challenge Page response, Cloudflare challenges documentation, last updated May 5, 2026, retrieved October 6, 2026, https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/detect-response/