Six months ago, a core update could have crushed my website. But it did not.
It did not because my team had already fixed canonicals, redirect problems, duplication issues, and JavaScript rendering gaps eight months earlier. It was the kind of unglamorous technical work that often lands with an engineer or developer because the ticket has been sitting at the bottom of the list.
And I do not really have proof. What I have is experience from years in SEO and the ability to recognize that the site had the same warning signs I have seen on sites hit hard by similar updates.
Traffic could have been cut in half. It was not.
There is no parallel internet timeline where I skipped the work, so there is no clean way to confirm what would have happened. There is no record of the disaster that never arrived.
That is why technical SEO ROI is so hard to prove. I see it as an inference problem with no control group, even though the industry often treats it like a reporting problem we can solve with one more tool.
The internet doesn’t stop
When I work in digital, I am working inside at least two open systems: the internet and the market. I could add a third if I count the maturity and expectations of internet users. I could add a fourth if I count my own website infrastructure. In reality, there are even more moving parts than that.
The point is simple: the environment I am trying to measure is always shifting, expanding, shrinking, and changing shape. There is no fixed “before” state I can pin down, and there is no clean way to model what would have happened if I had done nothing. Bayesian forecasting and similar methods can help, but they are still educated guesses.
A technical change might improve visibility today. If I make that same change six months later, it might do very little. That could happen simply because Google changed its crawl budget behavior or adjusted how it reads websites.
Cause and effect do not always stay close together in SEO. Google recrawls and reindexes on its own schedule, so the impact of a technical fix may land long after the release. By then, the result is spread across a recrawl cycle and the clean before-and-after comparison I would want for a proper test has already blurred.
As with SEO overall, there is a lot I cannot control. If I tried to track every change across the web that might influence my site, I would end up with sleepless nights and a lot more gray hair.
Technical SEO adds another layer because these changes rarely ship in isolation. It is almost never, “I made one change to the website.” It is more often, “Thirty fixes from five teams are going live on Thursday so we still have people around on Friday if something breaks.” Please do not ship on Fridays.
A lot of technical SEO also keeps the site above water. I am managing technical debt, staying current with regulations, and adapting to new releases of codebases, platforms, and frameworks. True enhancements matter, but even those can be difficult to isolate.
Technical work is closer to insurance or public health than a standard growth campaign. I usually realize how important it was only when it stops working. Much of technical SEO is disaster prevention, not new-city construction. I cannot invoice for an earthquake that did not happen.
The control group was never there
Another reality is that many technical changes, whether SEO-led or not, are sitewide because they have to be. There is no control group. Render pipelines, crawl budget, and site speed touch everything at once, so there is no untouched slice of the site left to compare against.
Two examples make this clear.
- Sunsetting 301 redirects more than a year old: The server stops reading every redirect line on every page load. The benefit is crawl and resource efficiency, but that benefit is mostly invisible in analytics.
- A migration done right: The win condition is “we did not lose traffic.” Maybe the line stays flat. Maybe it ticks up slightly. Migration work usually becomes obvious only when it fails.
My only comparison is the past, and the past existed under different external conditions. Time becomes the problem. I can compare relative movement, incremental change, and long-term trends, but the outcome shifts based on which metrics I choose and which assumptions leadership brings into the conversation.
When I can, I want to run a proof of concept. In practice, that means something close to SEO A/B testing: choose a segment, make the change there and nowhere else, measure the result, and decide what to do next. But that is not always possible, and it requires a different kind of buy-in.
I am also working in a search environment where LLMs make more things probabilistic. Answers are personalized, discovery paths are less predictable, and many of the measurements I have relied on are less deterministic than they used to be.
So I keep it relative
There are two levels of relative thinking I come back to: how I prioritize technical work and how I measure its impact.
The way I prioritize the work helps determine the impact I am trying to create.
When I prioritize technical SEO, I start with impact. How much of the website does the issue affect? How much of that impact lands on priority sections or priority pages? After that, I move into the usual scoping and grooming conversations with development teams.
For me, impact is the anchor.
Measurement and reporting are harder. A lot of the SEO industry, myself included, is now rethinking how we measure almost everything, not just technical SEO. LLMs have accelerated that shift and left many of us in an uncomfortable middle ground.
I do not have a perfect “what would have happened if…” comparison for my own website. But I do have competitors. Watching how competitor sites respond to global events, especially Google updates, is probably the closest I can get to that missing counterfactual in technical SEO. It is ROI by proxy, sitting close to share of voice.
And the funding
Technical SEO is infrastructure. It is insurance. If I am struggling to get it done or funded, I need to look closely at how I am framing the work.
At its core, I see technical SEO as insurance against the shocks of an open system. I should treat it that way. It is not always a direct revenue driver.
Yes, technical SEO can produce meaningful improvements and help the line move up and to the right. But the workhorse, the 80%, the majority of the discipline, is keeping the engine running. The work does not always promise upside. It lowers the odds and the cost of getting hit. The core update that did not sink the site is the claim that paid out.
That is why I recommend talking to finance. I want to understand how finance teams quantify, value, and evaluate insurance, security, and infrastructure.
Then I can start looking at technical SEO that way. More importantly, I can start talking about it that way.
Technical SEO is growth resilience. It is the foundation my flywheel cannot move without, not an investment I should be apologizing for.
Inspired by this post on Search Engine Land.
Leave a Reply