SEO · 11 min read
Technical SEO, defined by where it stops
Technical SEO is the work that decides whether a page can be fetched, rendered, understood and served at all. It is defined more usefully by its boundary than by its task list: it removes reasons a page cannot compete, and it does not give anybody a reason to choose you.
Written by Zubair Afzal, FounderUpdated
Definition
What technical SEO is
Technical SEO is the practice of making sure a website can be fetched, rendered, interpreted and served by a search engine. It is concerned with the machinery of access and understanding rather than with the substance of what is said. If the question is "can this page compete", it is technical. If the question is "does this page deserve to win", it is not.
Google describes its own process in three stages: crawling, in which pages are downloaded; indexing, in which the content is analysed and stored; and serving search results. The documentation is explicit that indexing is not guaranteed and that not every page Google processes will be indexed. Technical SEO operates almost entirely on the first two stages.
A fourth stage is worth naming even though Google folds it into indexing: rendering. Modern pages frequently assemble themselves in the browser, so what a crawler downloads and what a visitor sees can be two different documents. That gap is invisible in most reporting and is the single most expensive technical fault we encounter.
The reason to define the discipline by its boundary rather than its task list is practical. Task lists grow. Every audit tool adds findings, and a list of three hundred issues is indistinguishable from a list of three that matter. The boundary gives you a test to apply to each one: does this change whether the page can be crawled, rendered, indexed or delivered? If not, it belongs to a different piece of work.
The mechanism
Four gates, each of which can quietly close
Nothing reaches a search result without passing all four. Most technical faults are one of these gates closing without anybody noticing.
- 1Fetched — The crawler requested the address and received a usable response.Blocked in robots.txt, error status, timeout
- 2Rendered — The content that exists after scripts run is the content the engine holds.Content only assembled in the browser
- 3Indexed — The page was judged worth storing, and was not folded into a duplicate.noindex, canonical elsewhere, judged low value
- 4Served — The page is eligible to appear for a query, and can be delivered acceptably.Better answers exist, or delivery is poor
Scope
The four areas the work divides into
Anything described as technical SEO that does not sit in one of these is either content work, off-site work, or a finding from a tool that nobody has thought about yet.
Access
Whether a crawler can reach the page and what it is told when it does. Robots directives, status codes, redirect behaviour, server reliability and response time, authentication that accidentally covers public pages, and the addresses a site generates from filters and parameters. This is the layer where an entire section can disappear because of one line in a file.
Rendering
What content exists after the page has finished assembling itself. Whether text and links are present in the initial response or arrive later from scripts, whether resources required to build the page are themselves blocked, and whether navigation produces real addresses rather than states that only exist in the browser.
Interpretation
Whether the engine can work out what each page is and how the pages relate. Canonical declarations, duplicate consolidation, sitemaps, internal link structure, pagination, language and region declarations, and structured data that describes what is genuinely on the page rather than what somebody wished was there.
Delivery
Whether the page arrives acceptably for a real person on a real device. Core Web Vitals measured on actual visits rather than in a test, image and font handling, script weight, and layout stability. This is the area with the clearest business case outside search, which is usually the honest way to fund it.
Vocabulary
The terms a technical recommendation will use
Enough to read a proposal without nodding along. Each of these has documentation behind it that is shorter and clearer than most explanations of it.
- Crawling — a search engine requesting your pages. Being crawled is not being indexed, and neither implies being ranked.
- Rendering — running the page’s scripts to produce the content that will actually be indexed. Skipped in some circumstances, including when the initial response already says not to index the page.
- Indexing — storing and analysing the page. Google states that this is not guaranteed for every page it processes.
- robots.txt — a file that tells crawlers which addresses not to request. It prevents fetching, not indexing, and a blocked page can still appear as a bare result.
- noindex — an instruction in the page or the response header that the page should not be listed. It requires the page to be crawlable, which is why combining it with a robots.txt block does not work.
- Canonical — a declaration that this page and another are the same thing, and which one should be treated as the version of record. It is a hint, not an instruction.
- Status code — what the server says about an address. 200 is fine, 301 is a permanent move, 404 is gone, 410 is deliberately gone, 5xx is a fault at your end.
- Redirect chain — one address pointing at another which points at a third. Each hop adds delay and risk, and they accumulate silently across years of site changes.
- Soft 404 — a page that returns a success code while telling the reader nothing is there. Common in applications that handle missing content in the browser.
- XML sitemap — a list of the addresses you consider worth crawling, with change dates. It is a suggestion, not a guarantee, and it should not contain anything you have told the engine to ignore.
- Crawl budget — the combination of how much crawling your server will tolerate and how much the engine wants to do. Google documents it as a concern for large sites rather than for most.
- Structured data — machine-readable markup describing what the page contains. It makes certain result types eligible; it does not cause them, and it must describe visible content.
- hreflang — declarations connecting versions of the same page in different languages or regions. Reciprocity is required, and a one-sided declaration is generally ignored.
- Index bloat — thousands of low-value addresses indexed because the site generates them, typically from filters, search results, sorting parameters or session identifiers.
- Log file analysis — reading your server’s record of what crawlers actually requested. The only source that shows attention rather than intention.
Boundaries
Where technical SEO stops and something else starts
| Dimension | Technical SEO | Content SEO | Off-site SEO |
|---|---|---|---|
| The question it answers | Can this page be reached, understood and delivered? | Is this the best available answer to the search? | Does anybody outside this site treat it as credible? |
| What it produces | Specifications, fixes, and configuration that stays fixed. | Pages, structure, and decisions about what to write and what not to. | Coverage, citations, references and relationships. |
| Who does the work | Diagnosed by a specialist, implemented by developers. | Writers and subject experts, directed by demand research. | People who talk to publishers, organisers and partners. |
| What neglect looks like | Pages missing from the index, unexplained drops, invisible content. | Pages that exist and rank for nothing, because nothing needed them. | A technically perfect site that no established source has ever mentioned. |
| What it cannot do | Create demand, or make a thin page worth ranking. | Rescue a page a crawler cannot reach. | Compensate for a page that does not answer the question. |
| How you know it worked | Indexed pages, crawl errors, rendered content and field performance all move within weeks. | The specific searches you targeted start producing enquiries over months. | References accumulate from sources you would be happy to be listed beside. |
The honest limit
What technical work cannot do
Technical SEO removes reasons for a page not to compete. It does not supply a reason for anybody to choose it. A site with nothing to say, made perfectly crawlable, is a site with nothing to say.
This matters commercially because technical findings are easy to generate and easy to invoice. Any crawler will produce hundreds of them on any site, sorted by a severity rating the tool invented. A supplier who leads with the count rather than with the consequence is selling volume.
The test worth applying to every finding is what it unblocks. A blocked directory, a rendering failure, a canonical pointing at the wrong page, a redirect chain on your best-linked address — those unblock something specific and nameable. Missing alternative text on a decorative image, or a heading level out of order in a footer, does not, however genuine the accessibility argument for fixing it separately.
It also matters for expectations. When the technical constraint is genuinely removed, what follows is that the pages get judged on their merits. Sometimes that is a rapid recovery, because the merit was already there and something was in the way. Sometimes it reveals that the pages were never going to win, and the next piece of work is a different one entirely.
Questions
Questions people ask after reading a technical proposal
What is technical SEO, in one sentence?
It is the work that determines whether a page can be fetched, rendered, understood and served by a search engine — as opposed to the work that determines whether the page is worth serving.
Everything that follows from that definition is detail. Crawl access, status codes, rendering, canonicalisation, sitemaps, structured data validity, international configuration and delivery performance are all answers to the same question: can this page compete at all.
Is technical SEO a one-off project or ongoing?
Both, in different proportions. The diagnostic and remediation phase is a project with an end. Keeping the site from re-acquiring the same faults is a standing arrangement, because sites change and every release is an opportunity to break something invisible.
The useful compromise for most businesses is a proper diagnosis once, the fixes implemented, and then a small recurring check tied to releases rather than to the calendar.
Do we need technical SEO if our site is small?
Usually not as an ongoing service, and saying otherwise is where a lot of retainers come from. A forty-page site on a mainstream platform generally has a handful of technical issues, most of which are settled in a day.
The exceptions are worth knowing. A site that renders its content in the browser rather than on the server, a site that has just moved or is about to, a site that generates addresses from filters, or a site with an unexplained drop — those are technical situations regardless of size.
Is site speed part of technical SEO?
Yes, in the sense that delivery is part of whether a page can be served well. Google documents Core Web Vitals as part of how page experience is assessed, and the metrics are measured on real visits rather than in a testing tool.
It is worth separating two arguments though. Speed as a ranking consideration is modest and contested; speed as a conversion and cost consideration is neither. Most performance work is justified by the second without needing the first.
Should our developers do this, or an agency?
Diagnosis and specification is a search job. Implementation is a development job. The failure mode in both directions is real: agencies that hand over findings nobody can build, and development teams that fix the symptom listed rather than the cause behind it.
The arrangement that works is a written specification per issue — what to change, where, why, and how the fix will be verified — implemented by whoever owns the codebase, then checked by whoever wrote the specification.
How do I know whether we have a technical problem at all?
Three signals are worth more than any audit tool. A large gap between the number of pages you publish and the number indexed. Content that is visible in a browser but absent from the page source a crawler receives. And a traffic change with a sharp edge on a specific date rather than a gradual slope.
Absent all three, the constraint is more likely to be that the pages are not the best available answer to the searches you want, which is a content and authority problem wearing technical clothes.
Not sure whether your problem is technical
It is a diagnosable question rather than a matter of opinion. Send us the site and what you are seeing, and we will tell you which of the four gates is closed, or that none of them is.
Last updated