Technical SEO: The Unglamorous Layer That Decides Everything Above It
Technical SEO is the work nobody wants to buy and almost every stalled site needs. It produces no new content, nothing anyone can put in a presentation, and it is regularly the single largest improvement available.
The pattern repeats: a company publishes consistently for a year, the content is genuinely good, and nothing moves. The instinct is to publish more. The actual problem is usually a layer underneath, where a rendering fault, an index full of pages that should not exist, or a crawl budget being spent on parameters is putting a ceiling on everything.
Six Layers, In Dependency Order
Each layer caps the ones above it. Working downward from content is why so much technical work gets done and produces nothing.
Most technical audits present findings as a flat list, which conceals the single most useful fact about them: these problems are not independent. A page that cannot be reached does not benefit from better schema. A page that renders empty does not benefit from faster loading. Sequencing is not a nicety here, it is the difference between work that compounds and work that is wasted.
The order is not negotiable and it is regularly ignored. I have been brought into sites where a team spent a quarter on Core Web Vitals while a third of the catalogue was excluded from the index by a canonical rule nobody had reviewed. The performance work was competent. It was also irrelevant until the layer beneath it was fixed.
So the first question on any engagement is not what is wrong. It is what is the lowest broken layer, because everything above it is currently capped and everything below it is fine.
What Technical SEO Actually Covers
Crawling and reachability
Server responses, robots directives, redirect chains, orphan pages and anything returning a status that contradicts what you intended. The cheapest problems to fix and the most damaging to leave.
Rendering
Whether what a crawler receives matches what a person sees. The defining risk on JavaScript-heavy builds, and invisible to every visual review. Covered in content that is not crawled and links a crawler cannot follow.
Crawl budget and index composition
On larger sites, deciding what should never be indexed is the highest-value work available. Parameters, facets, expired items and near-duplicates accumulate until most of what search engines know about you is worthless. See index bloat.
Site architecture and internal linking
How deep pages sit, how authority travels, and whether your commercial pages are reachable in two clicks or five. See crawl depth and internal linking at scale.
Structured data
Generated at template level from the same data that renders the page, matched to visible content, and validated across the whole catalogue rather than on three sample pages. See schema at scale.
Performance
Core Web Vitals fixed in templates and infrastructure rather than through another plugin, measured on real devices and real networks. See template-level performance.
How a Technical Engagement Runs
The technical checklist:
- Server responses correct and consistent, with redirect chains flattened
- Rendered HTML confirmed to contain the content and links a person sees
- Index composition measured, with a deliberate decision on every page type
- Faceted navigation and parameters controlled rather than left to accumulate
- Commercial pages within three clicks of the homepage, and never orphaned
- Structured data generated at template level, accurate and matched to the page
- Core Web Vitals measured with field data on the pages that carry revenue
- A pre-release check so the next deploy does not reintroduce what you just fixed
Why Technical Debt Keeps Coming Back
Most sites I audit have been audited before. Understanding why the fixes did not hold matters more than finding them again.
It is nobody's job
Technical SEO sits between marketing, engineering and product, which in practice means it belongs to none of them. Naming an owner fixes more than most of the individual items on the list.
It gets fixed page by page
Individual page fixes do not survive the next content update. Template and infrastructure-level fixes hold. The difference is the single biggest determinant of whether an engagement still shows results a year later.
Releases reintroduce it
A plugin, a redesign, a new feature, a migration. Without a pre-release check, every deploy is an opportunity to undo the work. This is a process problem wearing a technical costume.
Nothing visible happens
The work produces no artefact anyone can admire, so it loses priority arguments to a content calendar every time. The counter is measuring the right leading indicators, so the effect is visible before rankings move.
How to Tell It Is Working Before Rankings Move
Technical work has a reporting problem. The effects are real and they arrive as a diffuse lift across many pages rather than a visible jump on a tracked term, which means a rank tracker will show almost nothing for weeks while something substantial is happening underneath.
The leading indicators are better. Watch the ratio of pages crawled to pages that matter, how quickly changes are picked up, the gap between discovered and indexed URLs, and the position distribution of your whole footprint rather than a sample of terms. When technical work lands, the distribution shifts before any individual ranking does.
That last measure is the one I care most about on larger sites, because it captures the thing that actually changed: thousands of pages moving up slightly, which is invisible in a top-twenty ranking report and very visible in revenue. The reasoning is in the position 11 to 100 trap and reporting on revenue rather than vanity metrics.
The Failure That Passes Every Review
Worth its own section, because it is the most damaging modern technical problem and the hardest to spot internally.
A page assembled in the browser looks identical to a person and can arrive at a crawler as an empty shell. Every stakeholder review passes. Every screenshot looks right. The design agency delivered exactly what was specified. And the content that was supposed to rank is, as far as a search engine is concerned, not there.
The variants matter. Sometimes the text renders but the internal links do not, because navigation is bound to click handlers rather than real href attributes, so crawlers cannot travel through the site. Sometimes it renders on a fast connection and times out on a slow crawl. Sometimes it works for the homepage and fails on templates nobody tested. Partial failures are more common than total ones and considerably harder to diagnose.
Checking it is straightforward and almost nobody does it: fetch the page without executing scripts and read what comes back. If your headings, body copy and navigation links are not in that response, you have found the ceiling. The fixes range from server-side rendering to pre-rendering to simply putting real links in the markup, and the right answer depends on your stack rather than on a rule.
The rendering check:
- Fetch key templates with JavaScript disabled and read the raw response
- Confirm headings and body copy are present, not just the shell
- Confirm internal links exist as real href attributes a crawler can follow
- Test every template type, not just the homepage
- Check what happens on a slow connection, not only on office wifi
- Compare the rendered DOM against the raw HTML for the pages that carry revenue
What Changes on a Large Site
Below a few thousand pages most of this is straightforward. Above it, the same problems change character entirely.
Crawl budget stops being theoretical
On a small site crawlers see everything regardless. Past a certain size they do not, and every URL wasted on a parameter combination is a page that does not get revisited. Reclaiming that allocation lifts pages you never directly touched.
The unit of work becomes the template
Nobody hand-fixes forty thousand pages. Every decision is a template or a system decision, which raises the stakes on each one and makes review discipline far more important.
Index composition dominates
Most large sites have far more indexed URLs than pages worth ranking. Deciding what should never be indexed is usually worth more than anything you could publish. See faceted navigation.
Governance becomes the constraint
With several teams shipping to one domain, the limiting factor stops being knowledge and becomes ownership: who can approve a URL change, who reviews a template. See SEO governance.
This is the point where technical SEO stops resembling a checklist and starts resembling engineering management. The analysis is a smaller share of the work than the specification, the sequencing and the sustained effort of getting things through a backlog that has other owners with other priorities.
What I Fix First, and What I Deliberately Leave
Given a typical audit output, the order is fairly consistent regardless of platform, because the dependencies are consistent.
What I deliberately leave is anything cosmetic in an audit tool that has no traceable effect on revenue: severity flags on pages with no traffic, minor markup warnings, and score-chasing generally. Every hour spent there is an hour not spent on the layer that is actually capping the site.
Technical SEO Questions
What is technical SEO, in plain terms?
Everything that decides whether a search engine can reach your pages, read them, understand them and afford to keep coming back. It sits underneath content and links, and when it is broken it quietly caps both. Nothing on the page looks wrong, which is why it survives so long.
How do I know if I have a technical problem?
The usual signal is effort without movement: you publish consistently, the content is genuinely good, and rankings do not respond. Other tells are large gaps between pages submitted and pages indexed, traffic that fell after a release with no algorithm update to blame, and Search Console reporting far more known URLs than you believe you have.
Is technical SEO a one-off project or ongoing?
The repair is a project. Keeping it fixed is a habit. Every release, every plugin, every template change and every migration can reintroduce problems, which is why sites that fix everything once are usually back within eighteen months. The ongoing part is small if somebody owns it and expensive if nobody does.
Do you do the implementation or just the recommendations?
I write the specifications, prioritise them and work with your developers through delivery. I do not push code to your repository. In practice the specification and the sequencing are the scarce parts; most teams can implement perfectly well once someone tells them exactly what and in what order.
How does technical SEO relate to Core Web Vitals?
Speed is one layer of it and rarely the most valuable. I have seen sites obsess over a performance score while half their catalogue was not indexed. Fix reachability, rendering and indexation first, then speed, and fix speed at template level rather than by installing another optimisation plugin.
Does this matter for small sites?
Less than for large ones, and not zero. A fifty page site rarely has crawl budget problems, but it can absolutely have rendering failures, a broken canonical setup or a migration that lost half its redirects. The work is smaller and the same principles apply.
What about JavaScript frameworks?
They are fine when rendered properly and a serious liability when not. The failure mode is specific: the page looks perfect to a person and arrives effectively empty to a crawler, and it passes every visual review on the way to production. This is the single most damaging pattern I find on modern builds.
How long before technical fixes show results?
Indexation changes can appear within days. Crawl efficiency improvements show up over weeks as pages get visited more often. Ranking effects follow over one to three months, and they arrive as a general lift across many pages rather than a jump on one, which makes them easy to miss if you only track a handful of terms.
Related: the SEO audit, enterprise SEO, marketplace SEO, website rebuilds, mobile experience, and the full list of services.
Publishing consistently and nothing is moving?
That is the signature of a broken layer underneath the content, and no amount of publishing fixes it. I find the lowest broken layer, specify the repair, and set up the habit that stops it coming back.
Book a Free Strategy CallGet an SEO Audit
