Why proving technical SEO ROI is so difficult
Six months ago, there was a core update that would’ve tanked your website. But it didn’t.
It didn’t because your team fixed your canonicals, redirection issues, duplication issues, and JavaScript rendering eight months earlier. It was the kind of drudge work a technical engineer or developer got stuck with because the ticket was last on their list.
And you don’t have any proof of it, not really. Other than the experience that comes from years in SEO and recognizing that your site had all the hallmarks of sites hit by the update.
It could’ve cut your traffic in half. It didn’t.
There’s no parallel internet timeline where you didn’t do the work, so there’s no way to confirm it. There’s no record.
This is why technical SEO ROI resists proof. It’s an inference problem with no control group, and we keep pretending it’s a reporting problem we can tool our way out of.
The internet doesn’t stop
We are in two open systems when we work in digital, at least: the internet and the market. Three, if you count the maturity and expectations of internet users. Four, if you count our own website infrastructure. More than that, really, but we don’t have time to list them all.
The long and short of it is this: the sea we swim in is always shifting, moving, growing, and shrinking. There’s no way to pin down a single, solid “before” state, and there’s no clean way to project all of those influences into “what would’ve happened if I didn’t do anything?” We try to do it with things like Bayesian forecasting, but that’s still an educated guess.
Technical work might have an immediate impact on visibility today. Make the same change six months later, and it might not. That could solely be because Google decided to shift its crawl budget or change how it reads websites.
Cause and effect come unstuck in time. Google recrawls and reindexes on its own schedule, so any effect lands far from the change and is washed out across a recrawl cycle, defeating the before-and-after pairing every clean test needs.
Just like SEO as a whole, there’s a lot we can’t control. Trying to track all of the changes across the web that might influence our website would result in many gray hairs and sleepless nights.
Technical SEO adds another layer because we rarely ship in isolation. It’s never just “here’s this single change to the website.” It’s “here are about 30 fixes from five different teams going out on a Thursday, so if things collapse, we have people on Friday who can triage.” (Please don’t ship on Fridays.)
Much of the technical work is also done to keep our heads above water: managing technical debt, or doing the work needed to stay on top of updated regulations and new releases of codebases or frameworks. Enhancements and improvements are tough.
Technical work is a lot more like insurance or public health. You only realize how important it was when it stops working. What we’re doing with technical SEO is often disaster prevention, not building new cities. We can’t write an invoice for an earthquake that didn’t happen.
Track, grow, and measure your visibility across Google, AI search, social, local, and every channel that influences buying decisions.
The control group was never there
Another reality of technical changes, SEO-led or not, is that most of them are sitewide and, by necessity, have to be sitewide. There’s no control group. Render pipeline, crawl budget, site speed. It touches everything at once, so there’s no untouched slice left to act as the control.
Two examples to consider:
- 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, which is invisible in analytics.
- A migration done right: The win condition is “we didn’t lose traffic.” A flat line, maybe a slight uptick. Migration work only becomes visible when it fails.
Your only comparison becomes the past, which existed under different external conditions. Time itself is now the trick. The only things to compare are relative, over time, and incremental, and the results shift depending on which metrics you use to measure success and which assumptions you and your leadership bring to the conversation.
When possible, we do want to run a proof of concept. SEO A/B testing, essentially. Pick a segment, make the change there and nowhere else. Measure and decide. But that isn’t always possible, and it requires a different kind of buy-in.
We’re also at a point where LLMs make everything probabilistic. Every answer is personalized, and many of the measurements we rely on have become less deterministic.
So keep it relative
There are two levels of relative here:
- How to prioritize work.
- How to measure the impact.
How we prioritize the work helps determine the impact we want to make.
My approach to prioritizing technical work is to look at impact first. How much of the website does this issue affect, and how much of that impact lands on priority sections or pages? After that, it’s standard scoping and grooming discussions led by the development teams.
But for me, impact is what matters.
Now, when it comes to measurement and reporting, much of the SEO industry, myself included, is talking about how we actually measure everything now, not just technical work. We’re in a bit of a weird limbo because of everything LLMs have accelerated.
We don’t have the “what would’ve happened if…” for our own websites, but we do have our competitors. Observing how competitors’ websites respond to global events, such as Google updates, is probably the closest we’ll get to answering that question in technical SEO work. It’s an ROI-by-proxy adjacent to share of voice.
And the funding
Technical SEO is infrastructure. Insurance. If you’re having trouble getting it done or getting it funded, look at your framing.
At its core, technical SEO is insurance against the shocks of an open system. Treat it that way. It’s not a revenue driver.
Yes, it can deliver meaningful improvements and help that line go up and to the right, but the workhorse, the 80%, the majority of technical SEO, is keeping the engine running. The work doesn’t promise upside. It lowers the odds and the cost of getting tanked. The core update that didn’t sink you is the claim that paid out.
So do what I’ve recommended before and talk to finance. Learn how they quantify, value, and evaluate insurance, security, and infrastructure.
Start looking at your technical SEO that way. Start talking about it that way.
Technical SEO is growth resilience your flywheel can’t move without, not an investment you can’t justify.
Read more at Read More
Exclude first-party audiences.
Get visibility into your ad placements.
Project spend with budget reporting.
Analyze audience demographics.