Tracking AMP Page Performance Separately in GA4 (2026)

AMP Reports used to be a Universal Analytics feature: a Content Grouping rule you set up once in the old Admin panel, and every report would split AMP page views out from the rest of your traffic automatically. That entire system is gone. Universal Analytics stopped processing data on 1 July 2023, and its reporting interface was switched off for good around a year later, taking Content Grouping with it.

If you’re still serving AMP pages in 2026, whether through the official WordPress AMP plugin or a hand-rolled template, GA4 doesn’t tag them for you out of the box. There’s no is_amp_page dimension waiting in your reports. But with a bit of setup you can isolate AMP traffic just as cleanly as the old Content Grouping did, and in some ways more flexibly. Here’s how.

Step 1: confirm GA4 is actually seeing your AMP pages

AMP’s own spec blocks arbitrary third-party JavaScript, so the gtag.js snippet your theme injects into normal pages never runs on the AMP versions. You need the dedicated amp-analytics component instead, pointed at your GA4 measurement ID.

If you’re using the official WordPress AMP plugin, this is usually handled for you through Site Kit’s AMP integration, or through your AMP plugin’s analytics settings screen. If you built AMP templates by hand, the tag itself looks like this:

<amp-analytics type="gtag" data-credentials="include">
<script type="application/json">
{
  "vars": {
    "gtag_id": "G-XXXXXXXXXX",
    "config": {
      "G-XXXXXXXXXX": { "groups": "default" }
    }
  }
}
</script>
</amp-analytics>

Check that this is present before doing anything else. Open an AMP URL in an incognito window, watch it in GA4’s Realtime report, and confirm a page view actually lands. If nothing shows up, everything downstream of this step will look like AMP has zero visitors, which isn’t a tracking insight, it’s a tracking gap.

Step 2: filter AMP traffic without touching any code

Once GA4 is collecting AMP page views, the fastest way to look at them separately is a path filter. No configuration changes required:

1. Go to Reports > Engagement > Pages and screens, and use the search box above the table to filter by /amp.
2. For a proper side-by-side view, open any report and click Add comparison, then set dimension to Page path and screen class, condition to contains, and value to /amp. Add a second comparison for the same dimension with does not contain /amp to see non-AMP traffic alongside it.
3. In Explore, build a free-form report with Page path and screen class as the row dimension, then apply the same “contains /amp” filter to isolate it in a table you can export or save.

This works because the WordPress AMP plugin’s URLs are predictable. If your AMP setup uses a separate subdomain or a query string instead of a path suffix, swap the dimension or condition accordingly, but the mechanism is the same.

Step 3: make it permanent with a content group

Comparisons are fine for one-off checks, but if you want “AMP vs non-AMP” as a standing dimension you can drop into any report, use GA4’s content_group parameter. It’s the closest thing to UA’s Content Grouping, but it’s set at collection time rather than configured centrally in Admin.

If you can edit your AMP analytics tag directly, add the parameter there:

"vars": {
  "gtag_id": "G-XXXXXXXXXX",
  "config": {
    "G-XXXXXXXXXX": {
      "groups": "default",
      "content_group": "AMP"
    }
  }
}

Set content_group to your normal page template’s value (e.g. "Standard") on the equivalent non-AMP tag so both sides of the comparison show up consistently in reports. If you’d rather not touch tracking code, do it in Google Tag Manager instead: create a RegEx Table variable keyed off Page Path, matching /amp/?$ to output "AMP" and everything else to "Standard", then feed that variable into your GA4 Configuration tag’s content_group field. Once it’s live, content group appears as a selectable dimension throughout GA4, including in the standard Pages and screens report, without needing a comparison every time.

What’s actually worth comparing

Once AMP and standard traffic are split, the metrics that matter most are engagement rate and average engagement time, since AMP’s whole pitch was faster loading in exchange for a stripped-down layout, and it’s worth confirming that trade is still paying off. Bounce-style drop-off and conversion rate (if you’re tracking goals as key events) are the other pair worth watching. If AMP pages are underperforming your standard templates on engagement without a speed advantage to show for it, that’s a strong signal to retire AMP entirely rather than keep maintaining two versions of every page.

Frequently asked questions

Does GA4 track AMP pages automatically?

No. Standard gtag.js can’t run on AMP pages because of AMP’s script restrictions. You need the amp-analytics component (or Site Kit’s AMP support) pointed at your GA4 measurement ID, or GA4 simply won’t see that traffic.

What replaced Universal Analytics’ Content Grouping in GA4?

The content_group event parameter. It does a similar job, letting you bucket pages into named groups, but it’s set through your tag configuration (gtag or GTM) rather than as a rule you define once in the property’s Admin settings.

Is AMP still worth running in 2026?

Google dropped the AMP requirement for Top Stories placement back in 2021, and a lot of publishers quietly retired their AMP templates once that ranking incentive disappeared. If you’ve kept AMP running since, separating its analytics is exactly how you find out whether it’s still earning its keep or just adding maintenance overhead for no measurable benefit.

Can I use Google Site Kit for AMP tracking instead of editing code?

Yes, if you’re running the official WordPress AMP plugin. Site Kit detects it and wires up AMP-compatible analytics automatically, which is the least error-prone route if you don’t want to hand-edit amp-analytics tags or build a GTM container.