If you’re like me, you long ago committed to using Google Tag Manager as your one and only platform for configuring your site’s event tracking (and — though it perhaps isn’t the optimal way to go about it — maybe your structured data markup too). To set this up in GTM, you had to create Custom JavaScript variables that used CSS or jQuery selectors to identify the correct elements on the page, and then create tags that arranged those variables into scripts that would pass data to Google Analytics, and/or to Google Search, in a comprehensible format. Those CSS or jQuery selectors were precisely tuned to the unique HTML of the pages where the tags needed to fire, relying on the signature attributes —like id or class — of the key elements in order to identify them. You might have had to go through a frustrating trial and error process to configure some of those variables so that they would populate correctly every time, on every page, but you got there.
And now you hear that the site is going to be redesigned from top to bottom, and the HTML signatures you relied on are all going to vanish or change. PANIC!
On second thought, don’t panic, because it’s going to be fine. The reason it’s going to be fine is that you don’t have to wait for launch to get started revising your tags, triggers, and variables. You can get going on that as soon as you have access to the staging site, and you can do all your necessary refining and debugging there. This will put you in a position to get everything ready well in advance, and better yet, you can use innate features of GTM to automate the switchover, so that when the morning of launch arrives, the container will flip from the old site’s version to the new seamlessly, with no risk of a tracking outage. Since you might well be reading this following some desperate Googling, with a deadline fast approaching, let’s not waste any more of your time and get right into the details.
Step 1: Get Access to the Staging Site
Though it perhaps goes without saying, there’s not a thing you can accomplish without access to the new site on staging, as you’re going to need to see exactly what elements of the site are changing, and exactly how. For the best start, then, make sure you can get in there. You don’t need to start poking around on every page just yet. Just make sure you have the URL and the credentials for now.
Step 1a: Confirm that All Major Dev and Design Work Is Done
This seems worth noting formally: there is no point in going to the trouble of updating the content of your GTM container and getting it fully compatible with the new site if further major changes are still going to be made. Hopefully, since the site is in a staging environment rather than a dev environment, the bulk of that work is already done, but get confirmation from your dev and design contacts that you can start relying on the CSS classes, element id attributes, and other major HTML signatures of the site as they currently appear in staging without fear that next week the whole thing might look different. Otherwise, you’d have to go through this whole process more than once, and I doubt you’re enough of a masochist to enjoy that.
Step 2: Export Your Container
Once you feel confident that the staging site is stable and protected from further major alterations, it’s time to hop into GTM, as the next thing we’re going to want to do is make a copy of the current site’s container to use as the foundation of our work. There’s no need to start tagging the new site from a blank container. Most likely you’re running a lot of tags that don’t even depend on the site’s precise HTML; if, for instance, you’re firing a Universal Analytics tag on every page to power your GA pageview tracking, then that’s going to work just as well as ever with no changes required (unless your domain is changing as part of the redesign). Why go to the bother of recreating it if you don’t have to?
Moreover, even some of your page-specific tags are probably not going to have to contend with any code changes and will work exactly as always, and many more can likely be salvaged with some clever editing, far short of a complete teardown of the old tag. Anything worth doing is worth doing efficiently. So just go ahead and make a copy of the entire container.
Except… GTM unfortunately doesn’t offer up a “Duplicate Container” or “Copy Container” menu item, so we have to do a little export-import dance instead. You can most easily do this from the Admin screen, where the Export command is out front on the right and will give you the option of exporting any of the container’s past versions as well as the present one:
The Export command here will package your entire container as JSON and automatically trigger a local download. Though you might guess that immediately re-importing that exported container would be your next move, you’d be wrong, but only because even though GTM will absolutely allow multiple containers to live side-by-side within a single account, it doesn’t provide an option whereby you can import a container and create a brand new space for it as part of that same action. You instead have to create a new blank container, and then import the JSON you just exported into that blank one. That’s the only way to get a container duplicated. So, yeah, it might have been nice if you didn’t have to route the process through your local memory, but you have no choice here and it’s a relatively quick jump through this second of two hoops. Let’s jump!
Step 3: Create a New Container
In that same Admin screen, once you’ve read through that menu like six times looking for the “create new container” command and failing to find it, click the blue plus sign at the top right, which is how you actually make that happen:
That will bring you to a screen that asks you to name the new container and select its type. For our purposes today, the type will be “Web”, and as to a name, I recommend that you choose a name which makes your intentions impossible to miss, like one that starts with “NEW SITE” in all caps before stating the site’s domain:
Once you’ve got that dialed in, click “Create”.
Next, GTM is going to jump you into the installation process, because it’s assuming that you intend to actually install this container on some live site or site section elsewhere under your company’s umbrella. You’re not going to do that, so you can just hit “OK” on the screen that pops up containing the code snippets, which you are never going to end up actually pasting anywhere.
What you definitely will need to do before you move on, though, is take note of the new container’s Container ID, as shown in pink below:
Copy that and paste it into a text file, or just retain it in your clipboard. You’ll need it just a few steps from now.
Step 4: Publish Your Empty New Container
I recommend you get into the habit of publishing new GTM containers the instant you create them, so as to avoid the infuriatingly misleading 404 error message that Chrome will thwart you with otherwise. Go ahead and hit Submit and walk through the few steps required of you.
Step 5: Re-import Your Old Container
Now it’s time to complete the circle of actions that will leave us with a perfect duplicate of the site’s original container. Go back to the Admin screen, select your new “NEW SITE” container from the dropdown, and then select “Import Container” from the menu:
This will bring up another simple set of options. Click “Choose container file” and give it the JSON export that you downloaded minutes earlier. Then choose “Existing” under the workspace menu — since you haven’t even altered the workspace that you started with in any way whatsoever — and, finally, choose “Overwrite” as your import option:
When this is done, you’re ready to start the work in earnest.
Step 6: Install Tag Manager Injector in Chrome
This is not the first time that UpBuild’s blog has recommended Tag Manager Injector in a blog post, and it probably won’t be the last, because it’s that useful. Working on the same principle as GTM itself — which is the principle that a container can be created inside a webpage’s HTML into which JavaScript can be injected from elsewhere — Tag Manager Injector is a Chrome extension that creates a container on a domain of your choosing, into which a GTM container can be injected, allowing you to play around with, and debug, a full set of GTM tags and variables on a site without having to actually install GTM on that site for real. This is how we’re going to be able to manipulate our site’s GTM tags and variables to conform to the redesign, and debug them in full before launch takes place. So without Tag Manager Injector, this entire process would not be possible. We owe the makers of this extension a huge debt of gratitude.
Once you have the extension installed, fire it up and drop in the Container ID of the duplicate — the “NEW SITE” container — that you created earlier and placed in a text file, or your clipboard. Then navigate back to GTM and hit the Preview button to fire up the debugger panel. Finally, go back to the page and reload it, and presto: you’ve got a working duplicate of your live site’s GTM container up and running in Preview mode on your staging site.
From here, your experience is going to be a lot less predictable from one site to the next, so my directions are going to be less concrete. But essentially, you’re going to take a troubleshooter’s approach to every single tag, trigger, and variable in your container, and one thing I can tell you for sure is that the easiest of these to update — and the ones it will be most helpful to start with — are the triggers.
Step 7: Update Your Triggers
You no doubt have triggers that fire on every page, such as the trigger for your Google Analytics page view tag. But you likely have a lot more that only fire on certain URLs, or on certain other conditions that depend on the precise HTML of your site, such as the ID of a clickable element. These are the ones you need to update.
Start at the top of the list of triggers and work your way down. For any that fire on a particular URL or subset of URLs, find the URLs of the pages in question as they appear on the new site. There is a better than even chance that some URLs are changing as part of the redesign, and you need to make sure that you have those pages covered at their new URLs by the same triggers that applied to them before. Ascertain the format of the new URLs that these triggers apply to, and change the URLs accordingly inside each eligible trigger.
[If you can help it, don’t use Full URL variables here; the hostname is going to change between staging and launch, and careless use of Full URL variables would then create the only realistic set of conditions whereby triggers would work on the staging site but then break when launch occurred. Just use Page Path and concern yourself only with everything after the dot-com, or whatever your TLD might be.]
Now, do the same thing for any other triggers that fire according to specific and non-universal HTML signatures. If you use Form Submission triggers, make sure those are current (have all the forms that used to be on the old site made it to the new site? are there any new ones?). If you use Element Visibility triggers, make sure you’ve updated the code of the elements in question so they exactly match the new site (again look for changes of Class or id attributes). Update everything you can think of, then do a check of all your triggers and update the ones you missed the first time.
And now it’s time for an absolutely crucial note. You must rename every trigger (and eventually every variable and tag) in this container, whether you change it or not. This is to limit any risk of the new container version overwriting, or otherwise interfering with, the current site’s container before launch day arrives, and this risk will become clear at the end of the post when we talk deployment. I recommend once again putting NEW SITE in all caps at the front of the name of each trigger, variable, and tag. Nothing could be clearer than that. Here’s an example of how a trigger meant to fire on blog posts only might look after this kind of revision:
With your triggers all updated and renamed, the debugging that you will go on to do for your tags will be a lot easier because the range of possible errors will no doubt be a little narrower. As further means to that same end, the next step will be to:
Step 8: Update Your Variables
Variables that automatically pull from page elements that can always be found in the same place — like URL — naturally do not need to be manipulated here (though the tags that use them will, but we’ll get there in the next step). The bulk of the predefined variables that GTM comes with, out of the box, fall into this category. It’s the User-Defined Variables that are likely going to need to change, or at the very least that will need to be subjected to review here and now.
For any variables that pull from specific page elements as identified by CSS selectors, jQuery selectors, form fields, etc., you absolutely must open the relevant pages up in the debugging panel and see whether the variables populate as they do on the live site. If they don’t — which they probably won’t, because the code has changed — you need to tweak them until they do. Open them up in the editor and figure out how the HTML of the elements that they depend on has changed. For example, if you have a variable that you’ve traditionally used on blog post URLs to grab the post title, make sure to note that the element containing the title has changed from, e.g. <h1 id=”blog-template-title”> to <h1 id=”new-blog-template-title”>. Get every change like that reflected in the variables’ coding, and keep troubleshooting the process until you get each one working. And don’t forget to rename each of the variables — NEW SITE! — again whether they need to change or not.
Let’s put all that together and imagine a reworked Custom JavaScript variable that uses a jQuery selector to pull in each blog post’s title upon page view:
Step 9: Update Your Tags
Now for the biggest job: updating the tags, which are what make GTM what it is. This is where you’ll ultimately prove the success of the changes you made to the triggers and variables, and make the last of whatever further alterations need to be made. But the very first move you should make here is to verify that the triggers and variables that you renamed are being reflected here under their new names in the tags that depend on them. Then, once that’s done, open up all your Custom HTML Tags, and any others that reference specific URLs or other specific HTML elements from the old site, and modify and debug them as you did with the variables. Then, finally, rename every tag whether you change its contents or not, by putting NEW SITE at the front.
Let’s pack the previous trigger and variable examples into an imagined (and simplified) Custom HTML Tag that would track social shares of a blog post by pushing event tracking values to the data layer:
Step 10: Debug Everything
Now, with the debugging panel still open and everything fully updated and refreshed, it’s time to painstakingly walk through the entire staging site, carrying out every single user action that any of your GTM tags apply to, and making sure that they all fire exactly as they did on the old site. It’s a good idea to track your progress in e.g. a spreadsheet as you do this, since it might take you more than one debugging session to get through the whole container.
Once you have everything verified as working in Preview mode, you have officially come to the final step.
Step 11: Talk to the Devs
How are we going to get this new site’s GTM container to take over the old container when the moment of launch arrives? First I’m going to describe the ideal way to do it, which requires a helping hand from the devs. Then I’m going to describe what to do if, for whatever reason, you don’t have access to the devs or their hands.
By far the easier way to do this is to send the container code for your NEW SITE container to the site’s dev team, explain where the two snippets need to go in the source code of every page, and ask them to paste it in those places while the site is still in staging. You can then check on the success of their work in the same moment that you do your last round of tag checks: all you have to do is turn Tag Manager Injector off, fire up Preview mode on your NEW SITE container, and navigate over to the staging site. If it works with Tag Manager Injector deactivated, it can only mean that they installed GTM properly as you asked them to. If it doesn’t work, have a look under the hood and assess whether the code simply hasn’t been pasted in at all yet, or whether it was pasted in wrong. But once you’re sure it’s in there right, you can rest assured that the old container code will be replaced by the new when launch occurs, in the same way that every other line of code will be replaced. Then, all you need to do is run a post-launch check in GTM Preview mode, and another in Google Analytics for whatever tags manifest there, and you’re done.
If you’re out there on your own and you need to get the new container contents to take over for the old container contents at the same Container ID, there are two ways to go about it. One method (Option A) is considerably easier but requires you to flip the switch manually, and the other (Option B) requires more work up front, but will ultimately allow you to set it up completely in advance and trust that the event of launch will flip the switch for you. I’d say you should choose the former if:
- your site attracts a reasonably small amount of traffic (say, under 10K visits per day), and if
- you know the launch time down to the minute and can be at your desk when that minute hits, undistracted and ready to do 10 intense seconds of careful work.
If that describes your situation accurately, you’re going to want to choose:
Option A: We’ll Do It Live!
Remember back at Step 5 when we imported our duplicate container into our blank container and selected the Option of “Overwrite”? We’re basically going to do that again, overwriting the current site container with our NEW SITE container right when the moment of truth arrives. Here’s the precise order of actions I would recommend.
- A day or two before launch (basically, as close to launch as you can get with confidence you’ll have time to check everything), go back into the staging site, reactivate Tag Manager Injector and GTM Preview mode, and run a new set of checks on the NEW SITE container, just as you did in Step 9. Verify for yourself that no vital code actually changed, despite what the devs might have told you.
- Once you’re sure that your NEW SITE container is ready to roll, go back to the Admin screen and Export it. Make careful note of where it is.
- Get to your workstation a good 10–15 minutes before the stated launch time and make sure you cannot be distracted. Turn off your email, set an Away status on your work chat, put on your biggest “don’t bother me” headphones, and put your phone in a drawer.
- Navigate to GTM and pull up the container for the current site, then get to the Admin screen.
- Open a separate tab or window, clear your cache, and load up the live site. Put yourself in a position to keep doing hard refreshes until the new site loads in the old site’s place.
- As soon as the new site is up, go back to the tab with the GTM Admin screen open for the current site container. Hit Import Container, select the exported JSON of your NEW SITE container, choose Existing workspace, and then choose “Overwrite”.
- With the NEW SITE container having overwritten the current site container, you will have managed to get your new container contents firing at the old container’s ID. Check GTM Preview mode and the GA Real-Time Events report, and congratulate yourself on being able to breathe again.
Option B: Automate the Switch Within GTM
Now, if the site is enterprise-level and/or launch time is coming in the middle of the night or at some similarly inconvenient time of day, and for whatever reason you can’t get the dev team to swap out the container code for you, you’re going to want to pursue this… let’s politely say intricate… sequence of moves.
- Pre-launch, carry out the same first step as stated under Option A: run a new set of checks on the NEW SITE container, and confirm that no vital code has changed since you first created it.
- Find some sitewide HTML signature that distinguishes the current site from the new site. This needs to be some difference between the two sites’ code footprints that shows up as such on every page. A good choice would be something native to the new site’s navigation or footer, as those tend to show in the same exact way on every page of a site, and chances are there will be a class or id attribute or some such signifier that is present on the new site but not on the current one. Take every pain to verify that this is the case.
- Create a Custom JavaScript variable in the NEW SITE container that verifies the presence or absence of this signifier and returns a TRUE or FALSE value accordingly. Run through every major page template of the staging site in Preview mode and confirm that the variable is returning a value of TRUE on each page.
- Reproduce this exact same variable on the current site, and make absolutely sure that it is returning a FALSE value on every page there. You now have a variable that will return TRUE on any page of the new site, and FALSE on any page of the current site. This variable therefore knows which version of the site is running in the instant that any page loads.
- Open up every trigger in the NEW SITE container. Add a new condition to every one of these triggers specifying that the Custom JavaScript variable you created must return TRUE for the trigger to fire. Check again in Preview mode after this is done to make sure the triggers are still firing properly, and then publish this version of the container.
- Hop over to the current site’s container and open up every trigger there. Add a condition to each one specifying that the Custom JavaScript variable you created must return a value of FALSE for the trigger to fire. You have now edited every trigger on both versions of the container to require an internal check confirming that the proper version of the site is loading before it will fire. With this done, the two sets of triggers — and therefore the two sets of tags and variables — could coexist in one container with no risk of mutual interference.
- Export your NEW SITE container, then navigate to your current site container’s Admin screen and Import the export that you just downloaded, in the Existing workspace, but by selecting “Merge” instead of “Overwrite”. Because you went to the trouble of giving each NEW SITE trigger, variable, and tag a distinct name, the two containers can be merged without any contents being destroyed or compromised.
- You should now be done, and when the new site with its new code footprint takes over the old, the triggers should switch in that instant, and bring the new variables and tags with them.
- Optionally, once you’ve verified the total success of the new container, you might consider deleting all the old tags and removing the JS TRUE/FALSE check from each trigger, in the name of good housekeeping. Just make sure you do this completely and thoroughly and carefully, and test all the major page templates in the debugging panel before you publish.
The bottom line is: as long as get staging site access early enough and you have the time to put in the work, you absolutely can get your GTM container entirely ready for a site redesign far enough in advance that you risk no outage or glitch of any kind when the switch occurs, even if you can’t get a hold of the devs.
What say you all? Have you done this kind of thing before? Do you know of a way that any of my methods can be improved upon? Do you have a completely different approach that you think would be simpler or quicker than this one? Let me know in the comments!
