URL Targeting

URL targeting is how you tell Split Test Pro which pages an experiment runs on. Every experiment has at least one targeting rule; you can stack rules to match broader patterns or carve out exceptions.

The URL Parts

For each rule, you pick which part of the URL to match against:

URL part	What it matches	Example
Full URL	The complete URL, including protocol, domain, path, and query string.	https://shop.example.com/products/widget?utm=email
Domain only	Just the hostname.	shop.example.com
Path only	The path after the domain, leading slash included.	/products/widget
Hash / fragment	The #… portion of the URL, leading # included. Empty string when the URL has no hash.	#reviews

For most experiments you want Path only — it’s the part of the URL that identifies the page within your site, independent of domain or query parameters.

The Operators

Each rule has an operator that determines how the matching works. Every operator has a positive and negative form:

Operator	What it does	Negative form
Equals	Exact match.	Does not equal
Contains	The URL part contains the value as a substring.	Does not contain
Starts with	The URL part begins with the value.	Does not start with
Ends with	The URL part ends with the value.	Does not end with
Regex	The URL part matches the regular expression.	Does not match regex

The negatives are useful for exclusions — “run on every product page except /products/sold-out” is two rules: one positive (Path starts with /products/) and one negative (Path does not equal /products/sold-out).

Worked Examples

A single product page

URL part:  Path
Operator:  Equals
Value:     /products/your-product

This matches only that exact path. /products/your-product?ref=email matches (because the query string isn’t part of Path); /products/your-product/ with a trailing slash does not (literal equality).

All product pages

URL part:  Path
Operator:  Starts with
Value:     /products/

The trailing slash in the value is intentional — it prevents accidentally matching /products (the index page) or /products-old.

Every page in a section

URL part:  Path
Operator:  Contains
Value:     /collections/winter

Matches /collections/winter, /collections/winter-jackets, /de/collections/winter, anything containing that substring.

Anchor links to a section

URL part:  Hash / fragment
Operator:  Equals
Value:     #reviews

Use this when the same page renders different content depending on the anchor — a product page that scrolls to #reviews, a docs page with a sidebar that highlights #installation, a landing page where #pricing reveals a panel. Include the leading # in the value; the matcher compares against window.location.hash exactly as the browser sees it.

Note: targeting is evaluated on page load, not on hash changes. If a visitor lands on /page and then clicks an in-page link to #reviews, the experiment won’t activate until the next full navigation.

Just the home page

URL part:  Path
Operator:  Equals
Value:     /

The path of the home page is /. Equals / matches only the home page; Starts with / matches every page on your site.

Everywhere except checkout

Use two rules — one positive, one negative:

Rule 1:  Path  Starts with  /
Rule 2:  Path  Does not contain  /checkout

Rule 1 is optional here — an experiment with only “not” rules already runs on every page the exclusions allow.

Match a specific UTM source

URL part:  Full URL
Operator:  Contains
Value:     utm_source=email

Restricts the experiment to email traffic. To scope it further — say, only product pages and only email traffic — keep both conditions in a single rule, because separate include rules are alternatives (either one matching is enough). A Full URL regex covers both at once:

URL part:  Full URL
Operator:  Regex
Value:     /products/.*utm_source=email

Power users: regex

URL part:  Path
Operator:  Regex
Value:     ^/products/(widget|gizmo)$

Regex is the escape hatch when none of the other operators express what you need. Use sparingly — regex bugs are hard to debug, and a wrong character can silently exclude all your traffic.

Combining Multiple Rules

Rules come in two kinds, split by their operator: include rules use a positive operator (Equals, Contains, Starts with, Ends with, Regex) and “not” rules use a negative one (Does not equal, Does not contain, and so on). When an experiment has several rules, the two kinds combine differently:

• The visitor’s URL must match at least one include rule — include rules are alternatives (any-of).
• The URL must also pass every “not” rule — exclusions always apply.
• An experiment with only “not” rules runs on every page the exclusions allow.

Stacking include rules is how you target several distinct patterns:

Rule 1:  Path  Starts with  /products/widget
Rule 2:  Path  Starts with  /products/gizmo

The experiment runs on either widget or gizmo product pages.

A single rule can also hold multiple values (one per line), and the same split applies within a rule: an include rule matches if any line matches — so the two rules above collapse into one Starts with rule with two lines — while a “not” rule passes only if no line matches.

Exclusion Patterns

Negative operators (Does not equal, Does not contain, etc.) are how you carve exceptions. Every “not” rule must pass for the experiment to activate, so “match X but not Y” is simply two rules:

Rule 1:  Path  Starts with  /products/
Rule 2:  Path  Does not equal  /products/sold-out

This runs on every product page except /products/sold-out. If you prefer a single rule, a regex with a negative lookahead expresses the same thing:

URL part:  Path
Operator:  Regex
Value:     ^/products/(?!sold-out$).*

Exclusions also stand on their own: an experiment whose only rule is Path does not contain /checkout runs everywhere except checkout — see the “Everywhere except checkout” example above.

Querying With the Preview URL

Once your rules are set, paste a real URL from your site into the Preview URL field. The match banner tells you immediately whether the rules would activate on that page. See Screenshots and Preview.

The pattern that works:

1. Define your rules.
2. Paste an example URL where the experiment should run → confirm “Match.”
3. Paste an example URL where the experiment should not run → confirm “No match.”
4. If both behave correctly, your targeting is solid.

What URL Targeting Doesn’t Do

• It doesn’t check device type — that’s device targeting, a separate setting.
• It doesn’t check referrer — for traffic-source segmentation, embed a UTM parameter and target on Full URL.
• It doesn’t check logged-in status, cart contents, or geo — these require a JS variant that runs the check and conditionally fires a custom event.
• It doesn’t run before page load for SPA route changes — see Single-Page Apps.

Common Mistakes

• Forgetting the leading slash. Path Equals products/widget will never match (paths always start with /). Should be /products/widget.
• Using a domain in the Path. Path is just the path — Path Equals https://example.com/widget will never match. Use Full URL if you want to match the whole thing.
• Trailing slash mismatches. Some platforms add a trailing slash, some don’t. Use Starts with instead of Equals to be tolerant.
• Targeting / with Starts with. This matches every page on your site, since every path starts with /. Use Equals for the home page only.

Next Steps

• Add device-level filtering to your URL rules: Device Targeting.
• Visualize whether your rules match: Screenshots and Preview.
• Avoid stepping on another experiment’s targeting: Running Multiple Experiments.