Crawlability and speed get filed under engineering and deprioritised forever. Here is how to make the cost visible.
Technical SEO has a positioning problem. It arrives in a ticket queue described in terms nobody outside the team can price — render-blocking resources, canonical conflicts, orphaned pages — and it loses every prioritisation meeting to a feature with a revenue number attached.
The work is not the problem. The framing is. Engineering teams are not hostile to technical SEO; they are triaging a backlog against stated business value, and technical SEO habitually arrives without any.
Translate the fault into money
A page that takes four seconds to become interactive does not have "a Core Web Vitals issue". It has a measurable drop-off between arrival and first meaningful action, and you can put a number on the sessions lost and what those sessions were worth.
The arithmetic is simple enough to do in a meeting. Take the sessions landing on the affected templates, the current conversion rate on those templates against a faster comparable, the average value of a conversion, and the gap between them. It will be approximate. Approximate and stated is infinitely more persuasive than precise and unmentioned.
The same is true of crawl waste. If a third of your crawl budget is spent on faceted URLs that will never rank, the cost is not abstract — it is the pages that are not being seen, and the revenue those pages would produce. Express it as "these forty product pages have not been crawled in six weeks" rather than as a percentage of budget, and the conversation changes.
The faults that actually cost money
In our experience the expensive problems are dull and repetitive. Indexation is the biggest: pages excluded by a stray directive, canonicalised to the wrong URL, or trapped behind parameters. A page that is not indexed cannot rank at any speed, and this class of fault routinely hides a meaningful share of a site from search entirely.
Then internal linking. Pages four or five clicks from the homepage with almost nothing pointing at them are treated as unimportant, because that is precisely what the site is saying about them. Fixing this is usually a navigation and template change rather than an SEO project.
Then rendering. If content depends on client-side JavaScript to exist at all, you are relying on a second, slower and less reliable pass to be seen — and, increasingly, on AI crawlers that may not execute scripts at all. This is why how a site is built is an SEO decision rather than a purely technical one.
Fix the foundations before the content
There is a common and expensive sequencing mistake: commissioning content before the site can support it. Publishing into an architecture that buries pages four clicks deep, or onto templates that are slow on mobile, means paying twice — once to create the content, and again later to make it findable.
Foundations first is not a technical preference. It is the difference between spend that compounds and spend that leaks. A content programme running on a sound site gets better every month as authority accumulates; the same programme on a broken site produces a library nobody can reach.
How to get it scheduled
Bring one item, not thirty. A technical audit that lands as a 60-page document with 200 findings will be read by nobody and actioned in no sprint. The same audit reduced to the three faults with the largest revenue attached, each with an estimate and an effort figure, gets into the next planning session.
Attach the estimate to the ticket itself rather than to a covering email. The ticket is what gets read in the prioritisation meeting, and it is competing with features that state their value in the title.
Offer to measure it afterwards, and then actually do so. Nothing buys credit for the next request like having been right about the last one — and if the estimate was wrong, you want to be the person who says so before someone else notices.
A test for whether it is worth doing
Before committing to a technical fix, write the sentence that will justify it afterwards. "We reduced time to interactive from 4.1s to 1.8s and enquiry rate from organic rose from 1.9% to 2.6%" is a sentence worth working towards.
If you cannot draft that sentence, you may be fixing something real but not something urgent. That is a perfectly respectable conclusion, and reaching it before the sprint rather than after it is the whole point of the exercise.
Common questions
- What is technical SEO?
- Technical SEO is the work that determines whether search engines can find, crawl, render and index a site at all — indexation directives, site architecture, internal linking, page speed, structured data and how content is rendered. It is distinct from content and link building in that it rarely creates demand; it removes the obstacles preventing existing demand from reaching you.
- How do you prioritise technical SEO fixes?
- By estimated revenue impact against implementation effort, not by severity score. Indexation faults usually rank first because a page that is not indexed cannot rank at any speed; internal linking and rendering problems follow; cosmetic warnings from audit tools generally come last. Bring the top three, each with an estimate, rather than the whole audit.
- Does site speed still affect rankings?
- It is a ranking factor, but a modest one compared with relevance and authority. Its larger effect is on conversion: slow pages lose visitors who have already arrived and already been paid for. That is why speed is usually a stronger business case as a conversion argument than as a ranking one.
- Should technical SEO come before content?
- Generally yes, where the technical faults affect indexation, architecture or template speed. Publishing content into a site that buries or fails to index it means paying twice — once to produce it and again to make it findable. Where the technical issues are cosmetic, content can proceed in parallel.