If your deploy process is "pull the live file, edit it, push it back," have you ever counted how many times that loop has run?
I opened one app's privacy.html looking for something else and noticed <header class="site-header"> appearing six times, while </html> closed the document exactly once. My first guess was a locale-switching script that injects a copy per language and toggles between them. But reading assets/app-i18n.js showed it only swaps text on nodes tagged [data-i18n] and toggles a lang attribute — it never creates multiple DOM copies. This wasn't a language mechanism. It was a real defect.
What would you have done?
Seeing this in one file, do you fix that file and move on, or sweep every other file that shares the same deploy process? Grepping 41 apps over SSH takes minutes. That's cheap compared to fixing one file and then finding the same symptom in the other 39 later.
ssh ... 'grep -rc "site-header" public_html/*/privacy.html public_html/*/terms.html public_html/*/support.html'Result: all 41 apps' privacy/terms/support.html — 123 files — showed the exact same six-fold nesting. Every other page in those same apps, including index.html, was clean. Whatever repeated edit cycle caused this had only ever touched these three files.
The cause
These three files each have a legal-copy section meant to preserve each app's original text. The deploy process appears to have gone: pull the live page → insert a new copy inside legal-copy → push it back. Repeating this without first clearing what was already there meant the entire previous page got shoved inside the new one, whole, each time. One shell stacked per cycle. The real legal text only survived in the innermost, sixth copy.
The fix
I set a rule: starting from the last (sixth, innermost) legal-copy opening tag, everything up to the next </section> is the real original text. I wrote a Python script to extract that, then reassemble one outer shell + the real text + the closing tags + the footer, and ran it across all 123 files. I diffed the extracted body against the source line by line to confirm nothing was lost.
There was a second trap here. "Original text" didn't always mean the same shape. Most apps had held plain text (<p class="meta">...), but three apps had preserved an entire earlier version of their own page as the "original" — including that page's own header and main. One more app had a full multilingual static page embedded as its "original." The "next </section>" boundary rule had no guarantee it would cut cleanly around these embeds — it only turned out safe because none of those embeds contained a <section> tag of their own, which I confirmed by counting tag balance before trusting the output.
Redeploying without repeating the same mistake
Pushing 123 files back out is itself the kind of repeated operation that created this bug in the first place. Having already hit a connection-closed failure around the eighth file when scp-ing one at a time, I pushed all 123 in a single tar pipe over one session instead. Verification ran three layers deep:
- Server-side: header count 1,
</html>count 1 — all 123 passed. - md5 match between the local fixed files and the server copies, all 123.
- Browser render check on a sample of apps, using the method that clears the Cloudflare challenge.
- Confirmed every internal link still ends in
.html— links inside an embedded old page were part of that original text, so they stayed untouched. Not mutating the preserved content was the whole point.
Self-check
If your deploy process is "pull live, edit, push back," check three things.
- Before inserting new content into an "original text" section, do you clear it first? Skip that, and self-nesting like this stacks one layer per cycle.
- When you spot an anomaly in one file, do you immediately sweep every other file on the same deploy path? Here, 41 apps and 123 files were affected at once — fixing just the one I noticed would have left 122 more broken in production.
- Does what you call "the original text" actually have one consistent shape? A boundary rule built assuming plain text can run straight into an embedded full page in some app you didn't expect.
I still haven't found the generator that caused this. If the original-text-preservation logic doesn't clear the existing legal-copy content before inserting a new page, the next deploy cycle could re-create the same six-fold nesting in these same three files. My repo was a generation behind what was already live came out of the same "edit-live-directly" deploy shape — same root, different symptom. If your deploy process is "pull, edit, push back," count right now how many layers it could actually stack.