Google Optimize Regex Rule to Ignore URL Subfolders

A user lands on your variant B landing page, clicks "search," and gets bounced straight back to variant B. They click again. Same loop. They are now trapped in a hall of mirrors of your own making, and your A/B test is the one holding the door shut.

That was my Tuesday once. The fix was one regular expression. To run a Google Optimize test on a root page like /explore while ignoring subfolders such as /product and /product/myproduct, you add .*$ to the URL targeting rule so the test stops matching anything past your target path. One line. No code deploy. The full setup is below.

Quick heads-up before we go further: Google sunset Optimize, so you can't spin up a brand-new test in it anymore. I'm leaving the original technique intact because the thinking is the part that lasts. The exact same regex logic carries straight over to URL filters in GA4, Looker Studio, and Google Tag Manager triggers — so this isn't a museum piece, it's a pattern you'll reuse the next time a tool asks you "which URLs count?"

Want a refresher on regex itself first? Two reads: what regex is and why it feels like a developer's worst nightmare and a fuller guide on what regex is and how to use it.

What was Google Optimize, and why subfolders broke the test

Google Optimize was Google's free A/B and multivariate testing tool. You'd point it at a URL, define a variant, split traffic, and let it run.

The trouble starts the moment your target URL has children. For a client, I ran a split-traffic test between an existing web app and a new landing page that replicated its behavior. We split traffic with a URL pageload event, which is exactly what you're supposed to do.

But the web app had features the landing page didn't — search, mostly. Every time a variant B user tried to use search and link back into the main app, Optimize saw a URL that still "matched" the test and shoved them back to variant B. So they searched, got bounced, searched again, got bounced again. Users of variant B were stuck in an endless cycle of searching for more stuff but never finding it. The test wasn't measuring behavior anymore. It was caging it.

This is the kind of thing that doesn't show up in a setup tutorial. It shows up at 11pm when a client emails asking why their funnel went sideways. Honest about the catch: every targeting tool has an edge like this, and the only way you learn where they are is by hitting them.

The fix: one regex rule to ignore the subfolders

After a fair bit of digging, I found that Google Optimize supports regular expressions on URL targeting. That's the whole unlock. You can use a regex to ignore everything beyond the landing page — in this case /explore — and target the landing page only.

The rule:

.*$

By applying .*$ to the URL targeting, you prevent the test from considering anything beyond the target URL /explore. The test matches the page you actually want and lets every subfolder past it go free. No more bounce loop. Variant B users could finally use search and stay where they clicked, and the split test went back to measuring something real instead of trapping people.

Google's own documentation on regex URL targeting is here if you want the source: Google Optimize URL targeting reference.

The same regex logic still works after Optimize

Optimize is gone, but URL matching is forever. Every analytics and tag tool that asks "which pages does this rule apply to?" gives you a matches regex option, and the logic you just used transfers one-for-one:

• GA4 — page-path and event filters in Explorations and audience definitions take regex. Same idea: match the root, ignore the children.
• Looker Studio — filter controls and field filters support regex matching, so you can scope a report to a single landing page without dragging its subfolders in.
• Google Tag Manager — Page URL / Page Path triggers have a matches RegEx operator. This is where most teams will rebuild what Optimize used to do for them.

So the muscle memory is worth keeping. The tool changed; the question — which URLs count? — didn't.

A reminder I give every client: get your tracking foundation right before you start slicing it with clever rules. If your conversion tracking in Google Analytics is solid and your UA-to-GA4 transition is clean, a regex filter is a scalpel. On a messy stack, it's just a faster way to cut the wrong thing. When the attribution chain has to be airtight — and we've built and maintained pipelines spending hundreds of millions over the years — one wrong value upstream breaks everything downstream. If you'd rather hand the whole signal path to someone who's wired this a hundred times, that's our tracking and analytics work.

FAQ

What does the .*$ regex do in Google Optimize URL targeting?

It tells the targeting rule to stop matching at your target path and ignore everything after it. Applied to a root page like /explore, it prevents the test from also matching subfolders such as /product and /product/myproduct, so those child pages aren't pulled into the experiment.

Why were users getting stuck in my A/B test variant?

Usually because the URL targeting rule matches more pages than you intended. When the variant URL still "matches" on pages the user navigates to, the tool keeps serving the variant and effectively traps them. Tightening the URL match with a regex so it only fires on the exact page you want fixes the loop.

Can I still use Google Optimize?

No. Google sunset Optimize, so you can no longer create new experiments in it. The regex URL-targeting technique still matters because the same logic applies in GA4 filters, Looker Studio filters, and Google Tag Manager triggers.

Where do I run A/B test URL targeting now that Optimize is gone?

Most teams move the URL-matching logic into Google Tag Manager triggers (Page URL / Page Path with the matches RegEx operator) and pair GTM with a current testing tool. GA4 and Looker Studio also accept regex in their page-path and field filters for reporting.

Does regex URL matching work the same in GA4 and GTM as it did in Optimize?

Yes, in spirit. The operators are named slightly differently, but matches regex behaves the same way: you write a pattern, and the rule applies to every URL the pattern matches. The .*$ approach to scoping a root page and ignoring its subfolders carries straight over.

Do I need to know full regex to use this?

No. For this specific job you only need the one pattern. If you want to go deeper, start with our explainer on what regex is and why it earns its worst-nightmare reputation, then the longer how-to guide on using regex.