TL;DR
I fixed a heading problem on a client site, confirmed it, wrote it up and moved on. Three weeks later it was back. Nobody had touched the page. A theme update had restored the template. The fixes most likely to be silently reverted are the ones that were invisible in the first place.
I once fixed a heading problem on a client’s site, confirmed it, wrote it up, and moved on. Three weeks later it was back. Nobody had touched the page. A theme update had restored the original template and taken my change with it.
Nobody noticed for months, because heading markup does not show on screen. That is the whole trap: the fixes most likely to be silently reverted are the same ones that were invisible in the first place.
Why it happens
Most site owners edit in the interface. The interface writes to whatever layer is easiest: a page, a block, a builder module, sometimes a database row that overrides the template.
The template underneath still says what it always said. So the fix and the source of the problem now disagree, and the next thing that touches the template wins. A theme update, a builder version bump, someone duplicating a page from the old layout, a section reset.
The change was never wrong. It was just made in the wrong layer, and the wrong layer is the default one.
Which fixes are at risk
Anything invisible. Headings, canonicals, meta robots, structured data, alt text on template-driven images. If reverting it produces no visible change, nobody will spot the revert.
Anything you did in a page builder on one page that is really a template problem. Fixing seven blank H1s on one home page is a page edit. The builder emitting a heading per section container is a template problem, and it will emit them again on the next page anyone builds.
Anything a plugin also has an opinion about. Two things writing the same tag is a fight you will lose at an unpredictable moment.
Visible things are self-policing. If a theme update moves your logo, someone will mention it that afternoon.
This is why heading problems in particular survive for years. They are emitted by a template, they are invisible on screen, and any fix made in the editor is sitting in the layer that loses.
The aggregate picture is consistent with things quietly going backwards. WebAIM crawled the top million home pages in February 2026 and found skipped heading levels on 41.8% of them, up from 39% the year before, with detected errors per page rising 10.1% year on year. Whatever is happening across the web, it is not a slow accumulation of fixes holding.
The scale of the exposure
HTTP Archive’s 2025 Web Almanac puts 54% of the web on a CMS, WordPress at 64.3% of those, and roughly 60% of WordPress sites running a page builder, with Elementor at 43%. So a very large share of sites are built in exactly the arrangement where this happens, with an editing layer sitting on top of a template layer, updated independently, by different people, on different schedules.
The same data shows WordPress passing mobile Core Web Vitals on 45% of sites against 85% for Duda. That gap is not the platform being slow. It is what years of additive edits in the top layer accumulate to.
Making a fix that holds
- Fix at the lowest layer that produces the problem. If the theme emits it, change the theme. If a plugin emits it, change the plugin’s setting rather than overriding its output downstream.
- Use a child theme. Editing a parent theme directly guarantees the update eats it. This is old advice and it is still the single most common cause of reverted work I find.
- Prefer a setting to a code edit where one exists, because settings survive updates and code edits in the wrong place do not.
- Then verify after the next update, not after the change. Verifying immediately proves you made the edit. Verifying in a month proves it survived, and those are different claims.
The unglamorous part that actually works
Keep a change log. What changed, when, why, and where in the stack.
I keep one for every site I touch and it sounds like bureaucracy until the first time a theme update reverts something and you genuinely cannot remember whether you fixed it, meant to fix it, or dreamt it. On a site where three people make changes, the log is the only thing that distinguishes “this was never done” from “this was done and undone.”
It also makes the revert diagnosable. A dated list next to a theme update date usually identifies the culprit in about a minute.
The short version
- Invisible fixes get silently reverted. Mine lasted three weeks.
- The editing layer and the template layer disagree, and the template wins eventually.
- 60% of WordPress sites run a page builder. This arrangement is the norm, not an edge case.
- Fix at the lowest layer that causes it. Child theme, not parent.
- Prefer a setting to a code edit.
- Verify after the next update, not after the change.
- Keep a change log. It is the only way to tell “never done” from “done and undone”.
If a site should be ranking and it isn’t, that’s the work I do. Technical SEO covers themes, templates and the markup they emit. If you’re not sure which of several plausible problems is costing you, that’s what an SEO audit is for.
