Targeting

How to Target A/B Tests by URL

★☆☆ Technical level 1 of 3

Written by Neil Webley · Last updated 5 August 2026

Create precise URL-matching locations and avoid running a test on the wrong pages.

What is an A/B test location?

A location tells FreeCROTool where a test is allowed to run. It examines the visitor's current page address and compares it with the URL rules you create. An audience decides who may enter a test; a location decides which pages are eligible.

Locations are necessary because most experiments belong on a particular page or group of pages. Careful location rules prevent a product-page change from appearing on the basket, account area or another page with similar wording in its address.

Locations can be shared by more than one test

A location belongs to the project and can be attached to several tests. Reusing a location is helpful when experiments run across the same page or section of a website.

Editing a shared location affects every test that uses it. Check which tests use the location before changing its rules. If only one test needs different pages, clone the location, edit the copy and attach that copy to the test.

Saving in the Workspace does not change the live website

Saving a location keeps the change in the Workspace as a draft. Live tests continue using the previously published location rules.

FreeCROTool keeps a published copy of the project on a fast worldwide delivery system so visitor browsers can retrieve the settings quickly. This is often called a CDN; in everyday terms, it is the live copy used by your website visitors.

The live copy changes only when you publish the Workspace. Publishing sends all pending changes, including tests, locations, audiences and other project settings, to the live delivery system together.

Review every pending Workspace change before publishing.
Test URLs that should and should not qualify.
Coordinate publishing when several people are working in the same project.

Video walkthrough

Video coming soon Location creation walkthrough: naming, selecting part of the URL, comparisons and testing rules

How to create a test location

1. Choose a clear name

Name the page or section in plain language, such as “Homepage”, “All product pages” or “Spring campaign landing page”. Avoid names such as “Location 1”, which will be difficult to understand when the location is reused later.

2. Add a URL Match rule

URL Match is the only rule type needed for locations. Choose which part of the page address to examine, select a comparison and enter the value that should be matched.

3. Choose which part of the URL to examine

Just URL , examines the page address without the query string or hash. Use this when values after ? or # should not affect eligibility.
Full URL including ? and # , examines the complete address, including query-string parameters and the page fragment.
Just Querystring And Hash , examines only the portion beginning with ? or #. Use this when eligibility depends on campaign, filter or other parameter values rather than the page path.

URL comparison options

Equals , the complete selected URL value must be identical.
Contains , the selected URL value must include the text anywhere within it.
Begins with , the selected URL value must start with the text.
Ends with , the selected URL value must finish with the text.
Doesn't equal, contain, begin with or end with , excludes URLs using the corresponding comparison.
Matches Regular expression , uses an advanced pattern to match several possible URL formats.

Every comparison is also available as a case-insensitive option. Standard comparisons treat uppercase and lowercase as different; case-insensitive comparisons treat values such as /Products/ and /products/ as equivalent.

Prefer the simplest dependable comparison. Exact matches are easiest to understand. Begins-with is useful for a clearly defined site section. Contains can match unintended pages when the chosen text is too general. Regular expressions are powerful but require careful testing.

Useful A/B testing location examples

A location can contain more than one URL Match rule. Join rules with AND when every rule must pass, or OR when any one of the rules may pass. When AND and OR appear in the same location, use brackets to show which rules belong together.

AND narrows a location. For example, the URL must be a product page and must not be a clearance page.
OR widens a location. For example, either the pricing page or the plans page can qualify.
Brackets control how mixed rules are evaluated and make the intended logic easier for other people to review.

One specific page

Just URL
Equals
https://example.com/pricing/

Useful for: a test that should run only on one stable page. Check whether your website redirects between versions with and without a trailing slash.

Every page in a site section

Just URL
Begins with
https://example.com/products/

Useful for: a consistent experiment across every product page. Confirm that no unrelated page uses the same path prefix.

A campaign landing page requiring a parameter

(Just URL equals https://example.com/spring-sale/)
AND
(Just Querystring And Hash contains utm_campaign=spring_sale)

Useful for: a campaign experience that should appear only on the intended landing page and only when the required parameter is present. Remember that parameters can appear in a different order and may disappear after navigation.

Either of two specific pages

(Just URL equals https://example.com/pricing/)
OR
(Just URL equals https://example.com/plans/)

Useful for: one experiment that is relevant to a small, known set of pages. OR means that a visitor needs to be on either page, not both.

Product or category pages, excluding clearance

(
  (Just URL begins with https://example.com/products/)
  OR
  (Just URL begins with https://example.com/categories/)
)
AND
(Just URL doesn't contain /clearance/)

Useful for: a broad retail experiment that can run in either of two sections but must not appear on clearance pages. The brackets group the two permitted sections before the exclusion is applied.

Exclude an account or checkout section

(Just URL begins with https://example.com/)
AND
(Just URL doesn't begin with https://example.com/account/)
AND
(Just URL doesn't begin with https://example.com/checkout/)

Useful for: protecting clearly defined sections from a broader site test. The positive first rule defines the allowed website; both negative rules must then pass.

Several locale versions of one page

Just URL
Matches Regular expression
^https://example\.com/(en|fr|de)/pricing/?$

Useful for: an advanced test across known language paths. Escape punctuation correctly and test every accepted and rejected URL before publishing.

Worked examples coming soon

This section has been reserved for complete examples showing how location rules are configured and tested in FreeCROTool.

Simple URL match with an optional query string

Example to add: a location that matches the page whether or not a query-string value is present.

URL requiring a particular query-string value

Example to add: a more specific location using AND logic where the page path must match and a named query-string parameter must have the required value.

Mixed AND and OR rules with brackets

Example to add: a complete interface walkthrough showing two permitted page groups inside brackets followed by an exclusion that applies to both groups.

Common URL matching details to check

Trailing slashes: /pricing and /pricing/ may be treated differently.
Uppercase and lowercase: use a case-insensitive comparison when your site does not enforce one format.
Subdomains: www.example.com, shop.example.com and example.com are different addresses.
Query-string order: the same parameters may appear in a different order.
Encoded values: spaces and special characters may appear in encoded form.
Hashes: content after # may change without loading a new page.
Single-page applications: confirm that the test detects client-side navigation correctly.
Preview and staging domains: decide whether they should qualify as well as the live domain.

Before using a location in a live test

Test several URLs that must match.
Test similar URLs that must not match.
Check trailing-slash, query-string, hash and letter-case variations.
Confirm the rule on mobile and desktop where navigation differs.
Check every test that already uses the location.
Review all pending Workspace changes before publishing.