March 25, 2025

Transferring Google Tag Manager to a new domain or website

If you’ve stumbled across this article, you are probably in a position where you have GA4 installed on your site using Google Tag Manager but are now changing your site’s domain or creating a new site and wanting to reuse an existing GTM container.

First things first, this is possible. You can reuse the GTM container from the current domain on a new domain, GTM will work just fine. However, the tricky part comes with evaluating what is actually in the container.

In this article, we will look at three potential scenarios you might find yourself in (while transferring Google Tag Manager to a new domain or website) and guide you through the process of identifying any updates needed for your container to work on the new domain.

Here’s what you will learn in this article

Three scenarios
Changes in the GA4 property
Scenario 1: Your GTM container is basic
Scenario 2: Your GTM container is advanced, but only the site’s domain changes
- Triggers
- Tags
- Variables
Scenario 3: Your GTM container is advanced, and the site’s design is different
- Triggers
- Variables
- Tags
Additional considerations
Final words

Three scenarios

Each scenario mentioned here will have a dedicated section going through some of the different updates you’ll need to make in your container:

Scenario 1: Your container is pretty basic. For example, it includes only a basic Google Tag, along with a few additional event tags or tracking pixels.
Scenario 2: Your GTM container exceeds the basic definition, e.g. you have numerous triggers and tags across multiple platforms. However, you’ve only changed your site’s domain, and the actual design remains the same.
Scenario 3: Your GTM container is beyond the definition of basic, and you’ve also changed the website’s design.

Depending on the scenario that best suits yours, you can find the section of this article that will be the most helpful for you.

Changes in the GA4 property

Before we get into the different scenarios, there are some things that you will need to do–regardless of the scenario you are in–when using GA4 in the GTM container:

Update the domain in your GA4 property

In your GA4 property, go to Admin > Data collection and modifications > Data Streams.

Click on the Web stream with the domain you’ve just updated. Scroll down to Configure tag settings under Google Tag (near the bottom).

Select the “Configure your domains” option under Settings.

Here, you need to list all the domains using the Google Tag within your GTM container. This is likely just one site, but you may have multiple domains if you have any cross-domain tracking. If your website has subdomains, you don’t need to worry about including those.

[Optional] Change the name of the GA4 property

If your GA4 property’s name is using the old URL, you can easily update it. This is not necessary, but it would make things more consistent and less confusing.

Go to Admin > Property > Property Details.

Update the Property name input and click “Save” at the bottom.

[Optional] Change the URL in the data stream settings

Even if you don’t change the URL in the data stream, there will be no impact on your tracking, but it would be good to do so for the sake of consistency.

In your GA4 property, go to Admin > Data collection and modifications > Data Streams.

Click on the Web stream with the domain you’ve just updated, click the pencil icon under Stream Details, and update the Stream URL.

Scenario 1: Your GTM container is basic

If the GTM container you’re working with is basic (e.g., a basic Google tag, maybe several additional event tags, and remarketing pixels), there is not much for you to do. This is the easiest scenario for you.

Assuming that you’ve kept the site the exact same and just changed the domain, you shouldn’t expect any issues with reusing the container, and all tags can remain as is.

You just need your developer to install the existing GTM container script into your new site’s code. Once they have completed the implementation, I suggest using Preview mode and DebugView (for GA4) to check that everything is working as expected.

Continue to monitor your reports for the days following and ensure there are no significant decreases in user or event counts compared to before.

Scenario 2: Your GTM container is advanced, but only the site’s domain changes

In this scenario, you’ve changed the domain, and your GTM container includes many tags, triggers, and variables that might rely on the previous domain’s value.

Triggers

The biggest impact will likely be on your triggers. Any trigger conditions that depend on “some events” can use built-in variables like Page URL (and potentially the page path, depending on whether your site pages will have different names), Page Hostname, Referrer, or Click URL, which could be set to the previous domain’s URL.

The variables that you’ve used are most likely Page URL or Click URL, and the triggers most likely to have this would be the Page View and Just Links triggers, but it’s possible for any of them to be URL-based, so you will need to review them all.

One tip to make things easier is to search “Page URL” (and each of the other built-in variables) in your GTM container, and it will show you the triggers that are using it.

Another tip (moving forward) is to use the Page Path variable instead of the Page URL, if possible, to avoid these scenarios in the future (for any page-based triggers). The difference between the Page URL and Page Path is that Page URL returns almost the entire URL while Page Path returns the value that comes after the hostname (but before the query parameter).

If the page path remains the same and just the domain is changing, then you don’t need to update any triggers depending on it. Similarly, when using any of the X URL variables, if you can, avoid using the domain. Use the “contains” feature and just enter the URL path.

Other variables that capture the URL that could be used in triggers include:

The HTTP referrer, and the URL and Auto-Event Variable (with the “Element URL” type) variables, which can be set to the full URL.
You may have a data layer variable (in the case of single-page app tracking) or a JavaScript variable that collects the page URL.

Any constant variables that may have been set to the site’s domain.

Variables

If you have a Lookup or Regex table based on the page URL, you may be using the website’s original domain to build the regular expressions, so this will need to be updated (e.g., content groups).

Instead of using the Page URL variable, you can use the Page Path variable, which excludes the domain. This way, if you change the website URL in the future, you won’t have to worry about updating these tables.

Scenario 3: Your GTM container is advanced, and the site’s design is different

If you’re in the Scenario 3 boat, you should still review the previous chapter for Scenario 2 since this will talk about all the updates you need to make based solely on the domain change.

This chapter will focus on what you need to do when your site’s design is also different: think updates to the CSS selectors and HTML.

Triggers

The most significant impact will likely be on CSS selectors or DOM elements used in triggers. If the design update changes class names, IDs, or element structures (e.g., buttons, form fields, and navigation links), you need to ensure that GTM’s triggers still target the correct elements.

Any trigger conditions that fire on “some events” could be based on one of the affected built-in variables, including most of the Click and Form variables, such as Click Classes, Click ID, Form Classes, or Form ID.

Another variable that capture values related to the design of your site that could be used in triggers is the Auto-Event variable, which can be set to various aspects of the element, like Element Classes or ID.

Same as above, you can search the type of variable and find all the triggers that are using them. If you’ve been using a good naming convention for tags, triggers, and variables, it should be pretty easy to search for things you need to update, like “aev” or “dom”.

Variables

If you have a Lookup or Regex table based on Click Classes or Click ID (or something else that is different now), you may be using the website’s original design to build the regular expressions, so this will need to be updated.

Custom JavaScript variables might rely on CSS selectors or DOM elements, and variables like DOM Element and Element Visibility can be configured to use either an ID or a CSS selector to collect values. If these selectors or elements change, the variables will no longer return the expected results.

Additional considerations

Beyond just the URLs changing, explore your site and determine if the behavior of any of the pages has changed. Do you have any pages that act like a single-page app, i.e., the URL changes, but the webpage doesn’t refresh? If so, you will need to add custom tracking on these pages since GA4 might not be able to collect the automatic page_view event.

Although it may not be what you want to hear, starting from scratch is also an option. If your setup is complex, fairly old, and contains a lot of items, there’s a chance that some of those items are no longer relevant. So maybe it’s time to start fresh!

Create a new container and build the new setup there. It’s very likely that the new container’s setup will be smaller (because you will be creating only those tags, triggers, and variables that are actually relevant to the business now). Think of this as an opportunity to do some “spring cleaning” (it’s that time of year, after all!).