This site has two separate mechanisms for loading Google Tag Manager. One of them has never fired a single tag. The other was added by a tool that had no way of knowing the first one existed.
The one that's configured, but empty
Drupal's google_tag contrib module is installed and enabled — confirmed directly in sync/core.extension.yml, where google_tag: 0 sits under the module: key alongside every other active module on the site. It ships its own configuration entity for exactly this purpose: define one or more GTM containers, attach conditions, let Drupal render the snippet through its own render pipeline. Its settings file, sync/google_tag.settings.yml, has exactly one meaningful line: default_google_tag_entity: ''. Empty string. The module has been sitting there, enabled, with nothing to actually load.
The one that isn't configured at all
On 2026-08-29, an unrelated theme-cleanup session — different tooling, different day's work, chasing an "Agentic Browsing" audit checklist — added Google Tag Manager a second way. Commit 77de1bd hardcodes the full GTM bootstrap snippet directly into linkhub_page_attachments_alter() in the theme's .theme file, container ID GTM-K9234GQX written straight into the JS string, with '#weight' => -10000 to force it ahead of every other script in <head>. A minute later, commit 83ad1f3 adds the matching <noscript> iframe fallback directly into html.html.twig, right after the opening <body> tag — exactly where Google's own installation instructions say it belongs.
Two tools, zero awareness of each other
Neither addition references the other. The module-based config wasn't touched, disabled, or even mentioned in either commit message. The theme-level snippet wasn't built as a replacement for the module — there's no comment, no commit note, nothing suggesting whoever wrote it checked whether Drupal already had a sanctioned way to do this. It reads exactly like what it probably was: a checklist item ("add GTM") executed against the theme layer, by a process with visibility into .theme files and Twig templates but none into the module configuration sitting a few directories over in sync/.
Why "unconfigured module plus hardcoded snippet" isn't actually the safe outcome
It's tempting to read this as harmless — one mechanism does nothing, the other does the job, no actual duplicate tags fire. But that's only true today, by accident of ordering. If anyone ever fills in default_google_tag_entity in the module — the normal, sanctioned way to turn GTM on — the site gets two GTM containers loading on every page, one through Drupal's own render array system and one hardcoded at weight -10000 directly in a hook. Nothing in either file would warn that person the other mechanism exists. The module's admin UI has no idea the theme already ships a GTM snippet; the theme's hook has no idea the module is one form-save away from doing the same job properly.
The actual gap
This isn't a story about someone choosing the wrong tool for the job. It's about the site accumulating two answers to the same question because nobody checked whether an answer already existed before writing a new one. A single grep -rn "google_tag\|GTM-" sync/ *.theme *.twig across the codebase — thirty seconds, no domain knowledge required — would have surfaced both mechanisms before the second one was written. That check didn't happen, and now removing either one requires knowing the other is there to fall back on, which is exactly the kind of context that doesn't survive a handoff between tools, sessions, or people.