SEO/AEO/GEO · Technical

Technical SEO

On a large ecommerce site, the content is rarely what holds rankings back. The infrastructure is. Crawlers can't render the pages, the site overrides its own canonical signals at scale, and crawl budget burns on redirect chains and dead links before Google ever reaches the products.

A blank browser window resting on a cross-section of exposed machinery — pipes, circuit lines, and data points being inspected by a magnifier — representing the technical infrastructure beneath a web page that decides whether it can be crawled and rendered.

The content isn’t the problem. The plumbing is.

Most enterprise SEO conversations open with what should we write. On a large retail site, that is rarely the constraint that matters. The pages already exist. The engine simply can’t read them, can’t reach them efficiently, or can’t tell which version is the real one. Fix the infrastructure and rankings you assumed you had to go earn turn out to have been sitting there the whole time, blocked by something no one owned.

That’s the pattern on big ecommerce sites: the visible content is fine, and the value is trapped underneath it.

Where large sites actually leak

They can’t be rendered. If your product name, price, and internal links only appear after JavaScript executes, most crawlers see an empty shell — and every AI crawler sees nothing, because none of them run JavaScript at all. Client-side rendering is the most expensive SEO decision most teams never realized they were making.

Crawl budget gets spent on garbage. On one enterprise site, only a low single-digit percentage of Google’s crawl activity was going to discovering new content, while 4,293 internal links still pointed at 404s and 11 of 15 sitemaps returned “couldn’t fetch.” New inventory went unranked because Google never efficiently reached it.

The site overrides its own canonicals. A tracking parameter baked into navigation links produced 257,362 “Google chose a different canonical” entries — Google overruling the site’s own canonical tags on roughly a fifth of all pages.

Redirect debt accumulates in templates. A single header link created 5,632 redirect chains — 92% of every chain on the domain. One footer template added over 12,000 redirect links across the subdomain it lived on.

Speed is a ranking decision made by accident. A ~10-second LCP and a 2.6 MB JavaScript payload is a Core Web Vitals problem and a conversion tax in the same breath.

Each of those is worth a piece on its own, and the further reading below goes deep on them. This page is the hub that ties them together.

One line in a header template accounted for 92% of every redirect chain on the site. That is what “technical SEO at scale” means: one template, multiplied by every page it renders on. The leverage — in both directions — lives in the infrastructure.

How I work this lane

I start in the crawl logs and Search Console, not the content calendar. The first job is to establish what Google can actually reach, render, and trust, because until that’s true, every content and link investment downstream is compromised. Then the fixes get sequenced by leverage: template-level changes that clear thousands of issues at once come before anything bespoke.

And I do the work, not just the audit. The schema, the redirect map, the rendering spec, the crawl-budget triage — those are things I build and hand to engineering as tickets, which is the only way to know a recommendation survives contact with the actual stack.

Where this fits

Technical SEO is the foundation the other three areas stand on — a beautifully written category page still can’t rank if a crawler can’t render it.

Further reading

Posts from this lane. Browse the full archive by category: Technical SEO

Nothing published in this lane yet. The first pieces are in the drafts pile.

Frequently asked questions

What is technical SEO for a large ecommerce site, and how is it different from regular SEO?

Technical SEO is the work that determines whether a search engine can crawl, render, and correctly index your pages at all — before content quality is even in play. On a small site it is mostly a checklist. On a large ecommerce site it is a systems problem: a single template touches tens of thousands of pages, so one bad link or one rendering decision isn’t one issue, it’s one issue multiplied by every page it appears on. That scale is exactly why the technical layer, not the content, is usually the binding constraint on enterprise retail sites.

Why can't Google or ChatGPT see my JavaScript site?

Because most crawlers do not execute JavaScript. Googlebot renders it on a delay and imperfectly; the AI crawlers (GPTBot, ClaudeBot, PerplexityBot) do not render it at all. If your product name, price, description, and internal links only appear after JavaScript runs, then to a crawler the page is an empty shell. The fix is server-side rendering, static generation, or a prerender layer that hands crawlers full HTML.

What is the single fastest technical SEO win on a big site?

Usually a template-level fix, because it clears thousands of issues in one change. On one enterprise site, adding a crawler directive to a single header link resolved 92% of every redirect chain on the domain, and a one-line footer fix cleared over 12,000 redirect links. Nothing in content offers that leverage. The first move is always to find the template-level problems that are quietly multiplied across the whole site.

How does crawl budget actually work, and when should I care about it?

Crawl budget is the finite attention Google gives your site — how many pages it fetches, how often. It matters once a site is large enough that Google can’t recrawl everything frequently. When budget is wasted on redirect chains, 404s, parameter duplicates, and slow responses, new and updated pages get discovered late or not at all. On one site, only a low single-digit percentage of crawl activity was going to new content, which is why fresh inventory sat unranked for weeks.

Does site speed really affect rankings, or just conversion?

Both, and they compound. Core Web Vitals are a confirmed ranking signal, and a slow site also gets crawled less often because Google throttles its crawl rate on slow servers. So a 10-second LCP isn’t only costing you conversions on the page — it’s costing you rankings and slowing how fast Google even sees your changes. Speed is one of the few technical fixes that pays back on traffic, rankings, and revenue at the same time.

Want a technical audit that reads the crawl logs, not just the homepage? Connect on LinkedIn  ·  Email me