Published 24 June 2026

Technical SEO that actually moves revenue

Most technical SEO work fails not because the fixes are wrong, but because nobody connected them to money. A page that cannot be crawled, rendered or loaded fast enough is a page that cannot earn a dollar, and that is the only frame that earns budget. Here is how I diagnose and prioritise technical SEO so the output is pipeline, not a longer Jira backlog.

Start from the money, not the audit

The fastest way to waste a quarter is to run a crawl, export 4,000 issues, and start at the top of the list. Severity in a crawler is not severity in your P&L. A missing meta description on a page that converts at 3% is worth more attention than a broken canonical on a tag archive nobody buys from. So before I touch a single config, I build a map: which URL templates generate revenue or pipeline, what they convert at, and how much non-brand organic traffic each template currently earns.

This is unglamorous and it is the whole game. On most sites, 80% of organic revenue comes from a handful of templates: the product or pricing page, a few money-keyword landing pages, the top-of-funnel guides that feed them, and (for ecommerce) category pages. Everything else is long-tail noise that should be cheap to serve and cheap to ignore when it breaks. Once you have that map, every technical decision has a denominator. "Should we fix faceted-navigation crawl waste?" becomes "does crawl waste touch the templates that make money, and by how much?" That question has an answer; "is this a P1?" does not.

I score fixes on a simple model: impact = affected_revenue_template_traffic × expected_lift × confidence, divided by engineering cost. It is rough, but it forces the conversation onto the right axis. A fix touching one high-converting template usually beats a fix touching 900 archive pages, even though the crawler flags the latter as "more issues".

What actually blocks indexation on real sites

Indexation is binary in its consequences: a URL that is not indexed earns nothing from search, full stop. Yet teams obsess over rankings while pages quietly fall out of the index. The recurring culprits I see, roughly in order of how often they cost real money:

Render-blocking or render-dependent content. The primary content, links, or canonical only exist after JavaScript executes. Google can render, but rendering is deferred and budgeted, so critical content arrives late or inconsistently.
Soft 404s. Pages that return 200 OK but show "no results", an empty state, or a thin near-duplicate. Google detects the pattern and drops them, often taking neighbouring URLs' trust with them. Faceted filters with zero inventory are the classic factory for these.
Parameter and crawl-budget waste. Session IDs, sort orders, tracking params, and infinite filter combinations spawn millions of low-value URLs. Googlebot spends its allowance on garbage and re-crawls your money pages less often, so updates and new products take longer to index.
Accidental directives. A stray noindex left over from staging, a robots.txt Disallow that blocks a JS bundle needed for rendering, a canonical pointing to the wrong variant, or hreflang that contradicts the canonical. Each is a one-line mistake with outsized blast radius.
Orphan pages and broken internal linking. Pages with no internal links pointing to them. They may be in the sitemap, but PageRank flows through links, and an orphan is starved. New SaaS sites do this constantly: they ship a programmatic comparison or integration template and never link to it from anywhere a crawler will reach quickly.

Note what is not on this list: title tag length, keyword density, the dozens of cosmetic warnings crawlers love. Those matter at the margin. Indexation blockers are existential, and they are where I spend the first week.

Diagnosing with the three instruments that disagree

You need three data sources, and the value is precisely in where they disagree. Any single tool lies to you in a predictable direction.

Google Search Console is ground truth for how Google sees you, but it is sampled and laggy. Live in the Page indexing report and read the exclusion reasons literally: "Crawled - currently not indexed" usually means thin or duplicate content (a quality signal, not a bug); "Discovered - currently not indexed" almost always means crawl-budget starvation or a slow server; "Soft 404" and "Duplicate, Google chose different canonical" each tell you exactly where to look. Then use the URL Inspection tool's live test and view the rendered HTML, not the raw source. If your <h1>, body copy, and internal links are missing from the rendered HTML, you have a rendering problem no amount of content work will fix.

Server log files are the only place you see what Googlebot actually does, as opposed to what you hope it does. Verify the bot by reverse DNS (don't trust the user agent), then answer three questions: which URL patterns get the most Googlebot hits, how often your revenue templates are crawled versus your junk, and what status codes the bot receives. On one large catalogue the logs showed roughly 60% of Googlebot's requests hitting parameterised URLs that should never have been crawlable; the money pages were being re-crawled once a fortnight. That is a crawl-budget leak you cannot see in Search Console at all.

A crawler (Screaming Frog, Sitebulb, or similar) gives you the structural picture: internal link depth, redirect chains, canonical and hreflang consistency, response codes at scale. Crucially, run it twice: once with JavaScript rendering off and once on. The diff between the two crawls is your JavaScript-dependency report. Anything that appears only in the rendered crawl, links, canonicals, content, is content you are betting Google will render correctly and promptly. That bet is sometimes fine and sometimes catastrophic, which is the next section.

The rendering decision: SSR, prerender, or hydration

This is where engineering and SEO actually collide, and where most of the avoidable damage happens. Google does render JavaScript, so the lazy claim "JS is fine for SEO now" is technically true and practically misleading. Rendering is a second pass, it is resource-budgeted, and it is where soft 404s and missing content creep in. For pages that must rank and convert, I do not want my indexation contingent on a rendering queue. The decision tree I use:

Server-side rendering (SSR) or static generation for anything that earns. Pricing, product, category, money-keyword landing pages, and the guides that feed them should arrive as complete HTML in the initial response: content, internal links, canonical, structured data, all present before a line of client JS runs. This removes rendering from the critical path entirely. With Next.js, Nuxt, Astro, SvelteKit and friends, this is no longer exotic.
Prerendering (a render-and-cache layer) as a pragmatic retrofit when you have a legacy SPA you cannot rebuild this quarter. It is a crutch, not a strategy: you are maintaining a parallel rendering pipeline that can silently drift from the live app. Acceptable as a bridge; do not let it become permanent.
Client-side rendering only for things that don't need to be found, authenticated dashboards, app interiors, anything behind a login. Spend zero rendering anxiety there.

The hydration trap deserves its own warning. Modern frameworks server-render the HTML and then "hydrate" it with JS to make it interactive. Done well, the crawler gets full HTML immediately and you get a fast page. Done badly, hydration ships a huge JS bundle that blocks the main thread, the content is technically present but the page is a brick to interact with, and your INP collapses. SSR solves indexation; it does not automatically solve performance. You can be perfectly indexable and still lose the sale because the page is unusable for 4 seconds. I have spent a lot of time in the internals of local-first AI software where everything runs client-side by necessity, and the discipline that teaches, ruthlessly minimising what the client must execute before it is useful, is exactly the discipline a hydration-heavy marketing site needs.

A useful test: disable JavaScript in the browser and load your most important page. If the content, the primary links, and the canonical are all there, you have made the right rendering call. If you see a spinner or a blank frame, you are gambling your indexation on Google's render queue and your conversions on the user's patience.

Core Web Vitals as a revenue lever, not a badge

Core Web Vitals get treated as a green-badge vanity exercise. That is backwards. The ranking effect is real but modest, a tiebreaker among comparable results. The revenue effect is large and direct, because the same slowness that nudges your ranking down also makes humans abandon before they convert. The thresholds Google publishes are the floor to aim for at the 75th percentile of real users (field data, not lab):

LCP (Largest Contentful Paint) ≤ 2.5s. Time to the main content painting. This is the one most tied to bounce and abandonment; a hero image or above-the-fold copy that lands slowly costs you the visitor before they read a word.
INP (Interaction to Next Paint) ≤ 200ms. Responsiveness across the whole visit, the metric that replaced FID. This is the hydration killer above: a page that looks loaded but ignores taps and clicks. On conversion-critical flows, checkout, form submission, configurator, INP is the metric I watch hardest because it maps directly to "did they complete the action".
CLS (Cumulative Layout Shift) ≤ 0.1. Visual stability. Layout shift makes users misclick and erodes trust on exactly the elements, CTAs, price, add-to-cart, that you need them to act on.

Tie it to money like this. The published research and my own before/after numbers point the same way: meaningful LCP improvements on transactional pages move conversion rate by single-digit to low-double-digit percentages, and the relationship is non-linear, the jump from 4s to 2.5s buys far more than 2.5s to 1.5s. So I model it: if a money template gets, say, 50,000 monthly organic sessions at a 2% conversion and a €400 average value, a one-point conversion lift from fixing LCP is not "a nicer score", it is roughly €40,000 a month. That is the sentence that gets the engineering time approved.

Two diagnostic rules. First, always separate field data (Chrome UX Report, what real users experience) from lab data (Lighthouse, a single throttled run). Lighthouse is for debugging the cause; CrUX is for judging whether you actually have a problem. A green Lighthouse score with failing field data means your synthetic test does not resemble your users, often mobile users on mid-tier devices and real networks. Second, segment by template and device. A site-wide average hides the fact that your mobile product pages, the ones that print money, are failing while your desktop blog is green.

Crawl budget and the architecture of waste

Crawl budget is misunderstood as something only enterprise sites worry about. The mechanism matters everywhere: Googlebot allocates finite attention, and every request spent on a worthless URL is a request not spent re-crawling a page that earns. On small sites the budget is generous enough that it rarely bites; the moment you add faceted navigation, a parameterised search, a calendar, or programmatic templates, you can manufacture millions of crawlable URLs overnight and starve the pages that matter.

The fixes, in the order I reach for them:

Don't generate the URL in the first place. The cleanest fix is architectural: render filter combinations behind interactions that don't create crawlable, linkable URLs unless that combination is genuinely a landing page worth ranking. Most filter permutations are not.
Block at robots.txt for patterns Google should never crawl, e.g. internal search results and pure sort/session parameters. This conserves crawl budget directly. But remember: Disallow stops crawling, not indexing, a blocked URL can still appear if linked, and it cannot show a noindex because Google can't read the page. Never block resources needed for rendering.
Use noindex, follow for pages that must be crawled but not indexed, thin paginated tails, low-value filter pages you still want to pass link equity through.
Canonicalise honestly. Canonicals are hints, not commands; use them for genuine duplicates, not as a lazy band-aid over an architecture that shouldn't emit the duplicates at all.
Keep your XML sitemaps clean and honest. Only canonical, indexable, 200 URLs. A sitemap full of redirects and noindex pages teaches Google to trust it less, which slows discovery of the URLs you actually care about.

A pattern worth internalising for new SaaS sites in particular: you will be tempted to ship a large programmatic template, integrations, comparisons, location pages. That is fine and often lucrative, but it multiplies both crawl surface and thin-content risk. The rule is simple: a programmatic page earns the right to be indexable only if it has genuinely unique, useful content and an internal link from somewhere real. Otherwise it is a soft-404 factory waiting to drag down the templates around it.

Prioritising by revenue, not by ticket count

Bring it together into a sequence I would defend to a CMO. The output of a technical SEO engagement should not be "we closed 312 issues". It should be "we restored indexation on the pricing template, cut LCP on mobile product pages from 4.1s to 2.3s, and reclaimed crawl budget so new products index in days not weeks, here is the modelled pipeline impact of each".

Tier 1, indexation blockers on revenue templates. Anything stopping a money page from being indexed or rendered correctly. These are existential and usually cheap to fix relative to their value. Do them first, always.
Tier 2, Core Web Vitals on transactional and high-traffic landing templates. Field-data failures on the pages that convert, prioritised by sessions × conversion value. LCP and INP before CLS, generally, because they sit more directly on the conversion path.
Tier 3, crawl-budget reclamation. Worth real effort on large or programmatic sites, near-worthless on a 200-page brochure site. Size the prize before you spend the engineering hours.
Tier 4, everything the crawler flagged that doesn't touch revenue. Batch it, automate it, or consciously decline it. "We are choosing not to fix the 900 cosmetic warnings on archive pages" is a legitimate, defensible decision when the alternative is delaying a Tier 1 fix.

The discipline is saying no. Most backlogs are bloated with work that is real but worthless, and the cost is not just the wasted hours, it is the opportunity cost of the high-value fix you didn't ship because the team was clearing low-value tickets. Tie every item to a template, a traffic number, and a conversion value, and the priority order writes itself.

Where this is heading

The fundamentals, crawlable, renderable, fast, are getting more important, not less, and for a reason worth thinking about. As AI search and answer engines increasingly mediate discovery, they parse and quote your content from the same rendered HTML Google indexes. A page that depends on a fragile client-side render, or that is too slow and unstable for users, is also a page that AI crawlers will parse incompletely or skip. Clean server-rendered HTML, honest structure, and fast delivery are now table stakes for both classic search and the AI layer sitting on top of it. The teams that win the next few years are the ones treating technical SEO as what it always was, the difference between content that can earn and content that simply cannot, and pricing every fix in pipeline rather than in tickets closed.

Where this fits in my work

This is the kind of technical-SEO and growth work I ship end to end, not just advise on. You can see the full portfolio of sites, software and publications I’ve built, browse what I do, request my technical SEO and growth services, or get in touch about applying it to your site. Related reading: A structured-data playbook for rich results and AI citations and SEO measurement that survives a CFO’s scrutiny.

Back to all insights →