Moving a template file from one directory to another shouldn't change what it renders. I moved html.html.twig to templates/layout/html.html.twig for Drupal 11 compatibility, and the rename quietly deleted an AdSense script tag and three Google Fonts links that had nothing to do with the move. Nobody noticed for hours.
What the old template actually had
The pre-rename html.html.twig hardcoded four tags directly inside <head>, above the placeholder tokens Drupal uses to inject its own aggregated CSS and JS:
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-5072092791126294" crossorigin="anonymous"></script><link rel="preconnect" href="https://fonts.googleapis.com"><link rel="preconnect" href="https://fonts.gstatic.com" crossorigin><link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;600&display=swap" rel="stylesheet">
None of these were managed through Drupal's library system or a hook. They were just sitting in the template source, written directly into the markup by whoever first built the theme, and they'd worked that way for months.
What the rename actually touched
The commit that moved the file also added a hook_page_attachments_alter() implementation, switched from a theme library to CDN-loaded jQuery, and renamed the template for Drupal 11's directory conventions. The commit message describes all three of those changes. It says nothing about the four lines above, because removing them wasn't a decision — the new template was written mostly from scratch to fit the new structure, and the four lines simply weren't carried over. A git diff between the old and new template shows them disappearing in the same diff hunk as the directory move, with no separate line item calling it out.
How long it sat broken
The rename landed at 16:34. The AdSense restoration landed at 18:21. The Google Fonts restoration landed at 18:01 — twenty minutes before the AdSense fix, which tells you they were caught and fixed as two separate discoveries, not one sweep. Almost two hours between the template rename and the first fix, closer to two and a half for the second. That's not a long outage by most standards, but it's long enough that if this were the only per-page ad revenue on the site, or the only correctly-configured web font, it would have mattered.
Why this kind of deletion is easy to miss
A template rename reads as a structural change: move a file, update the path that references it, done. Nothing about "renamed a Twig template" suggests "also silently dropped hardcoded third-party integrations." The bug doesn't throw an error. The page still renders. The <head> section is still well-formed HTML — it's just missing four lines nobody was specifically looking for, because the change that removed them was framed as being about something else entirely.
The actual failure mode here isn't "forgot to test." It's that a diff review naturally focuses on the stated purpose of a change — Drupal 11 compatibility, in this case — and reads everything else in the diff as incidental. Four lines of hardcoded markup, sitting outside any system that would have flagged their absence (no library dependency check, no automated tag audit, no monitoring on ad impressions), can vanish inside a refactor and stay invisible until someone happens to notice the ads are gone or a Lighthouse run flags missing font preconnects.
What would have caught it sooner
Neither of these tags were things Drupal's own systems knew to care about. AdSense and Google Fonts weren't registered as libraries, weren't attached through a hook, weren't dependencies of anything — they were just text in a file. The fix that followed, in both cases, moved them into hook_page_attachments_alter(), which puts them under version control in a place a future refactor is more likely to preserve, since it's PHP logic rather than markup living inside a file whose primary job is describing document structure. That's not a guarantee against the same class of bug recurring elsewhere, but it does mean the next person moving a template file has to specifically delete a function call to lose these, rather than just fail to copy four lines they didn't know were significant.
The broader lesson: anything hardcoded directly into a template that isn't the template's own stated purpose is exactly the kind of thing that survives by accident during normal edits and disappears by accident during structural ones. If it matters, it should live somewhere a refactor has to notice it.