Content Edits with GTM? Just Say No.

    1024 466 Ravi Chandramouli

    Google Tag Manager (GTM) makes it easy for marketers to add and update website tags with just a few clicks, and without needing to edit website code. We’ve touted its virtues previously on this blog, including the ease by which it can be learned and launched, and of course, the fact that it’s free.

    In some cases, however, the easiest path is the wrong one. The urge to make SEO changes using GTM, for example, is a trend I don’t recommend.

    In the Moz blog post How to Implement SEO Changes Using Google Tag Manager, the author points out a common challenge faced by marketers of getting website changes in the development queue—specifically SEO changes. Among other solutions, he suggests using GTM to deliver custom scripting to make these changes, therefore bypassing IT or CMS restrictions.

    “Tag managers are mostly used to implement off-the-shelf tags, like Google Analytics or Facebook tracking,” he writes. “A lesser-known functionality is to implement custom HTML snippets (which can include JavaScript code) … This allows us to bypass CMS restrictions and development queues, directly applying changes to things like page titles, canonical tags, and on-page content.” The author goes on to show scripting examples of how to do this with jQuery and GTM.

    In the past, GTM hadn’t been considered a reliable way to make SEO changes because Google (and other search engines) couldn’t sufficiently execute JavaScript. Recently, however, there is evidence that such changes are being picked up by Google, including implementation through tag managers.

    Unfortunately, just because something is possible doesn’t mean it’s a good idea. As a technical lead, I can tell you that using a tag manager for SEO testing and content edits is very a bad practice for high traffic sites. I have witnessed firsthand how these kinds of workarounds—particularly how injecting “code” without testing it through the software development life cycle—can go terribly wrong.

    Let’s consider for a moment a new site launch. The backlog for defects is a mile long until someone on the marketing team realizes they can inject scripting to the site to make a content edit with jQuery. Marketing makes that change and heads home for the weekend. Little did they know that the IT team was preparing a deployment for a critical error defect to go live that night. When IT did their release, a conflict in code on the UI ended up breaking the login screen. The IT team couldn’t find the error in their code and had to keep the site down through the weekend until it was learned that another team injected the conflicting code and the edit was rolled back.

    Yeah, that happened.

    Less debilitating but still problematic, adding more JavaScript and DOM manipulation can slow down page load time. Even Google’s own John Mueller doesn’t recommend using Google Tag Manager for SEO purposes. “Getting SEO reasonably right is hard enough without adding a layer of unpredictability on top,” he explained.

    A Better Solution for Implementing Changes: Transparency

    As in the rest of life, most problems are rooted in a lack of communication. Instead of fighting the process, try working with it. Most IT departments are open to hearing why a change is important and discussing how to best implement it. If you or a colleague wants to run a test through Optimizely, let IT and other parties who manage the site know what’s going on. All stakeholders in site management and development should have an understanding of the 3rd party tools and how they are integrated. Maybe consider creating a message board where tests can be posted, including whom to contact if anything goes wrong.

    Even changing something as simple as a page title can start to cause a ripple effect of confusion. When someone starts circumventing the process, it becomes impossible for backend developers to know where changes are being made. Instead of making surface-level changes in Google Tag Manager, talk with the CMS or content team first; ask whether they can place components or tag changes inside the CMS right from the start.

    Transparency, in other words, is the key.

    While I’ve advocated here for marketing departments to understand the software development life cycle, equally important is helping the IT department understand the importance of speed to market as well as how marketing tools can help free up their time and resources, so they can focus on higher priority tickets.

    Instead of band-aiding the site with quick fixes, aim for a joint understanding of website responsibilities and coordination. Your site and all the teams involved will be better for it.

    Key Takeaways

    • Using a tag manager for SEO testing and content edits is not a best practice and can wreak havoc on high traffic sites
    • Even changing something as simple as a page title can start to cause a ripple effect of confusion. When someone starts circumventing the process, it becomes impossible for backend developers to know where changes are being made
    • Adding more JavaScript and DOM manipulation can slow down page load time
    • Instead of fighting the process, try working with it— most IT departments are open to hearing why a change is important and discussing how to best implement it
    • Instead of band-aiding the site with quick fixes, aim for a joint understanding of website responsibilities and coordination

    newslettersignup-promo

    AUTHOR

    Ravi Chandramouli

    All stories by: Ravi Chandramouli
    2 comments

    Leave a Reply

    Your email address will not be published.