Technical SEO decides what Google can reach. On-page SEO decides what Google concludes once it gets there. Almost every disagreement about where the line sits dissolves once you use that split, and almost every wasted SEO budget comes from getting the order wrong.
The distinction matters for one practical reason. These are sold as one thing, “SEO”, and they are bought as one thing, so people routinely pay for content improvements when the actual problem was a rule in a text file. I have opened Search Console on sites where a year of blog writing sat behind a single Disallow: line. The writing was fine. Nothing was ever going to read it.
The short answer
Technical SEO is everything that determines whether a search engine can find, fetch, render, and store your page as a document. On-page SEO is everything that determines whether that stored document wins a particular query. Technical failures are usually binary, site-wide and finite: the page is either reachable or it is not, and once fixed it stays fixed. On-page work is per page, comparative, and never finished, because it depends on what your competitors publish next. Do the technical pass first, because on-page improvements only compound on pages that are actually in the index.
One test that sorts any task
When a task is ambiguous, ask which of these two things it changes:
- Does it change what Google can access? That is technical.
- Does it change what Google concludes? That is on-page.
A redirect chain changes access. A rewritten H1 changes conclusion. A robots.txt rule changes access. An internal link from a stronger page changes conclusion, and also, slightly, access. That last case is why the line looks blurry, and the overlap section below deals with it honestly rather than pretending it does not exist.
The test survives contact with unusual cases better than the usual lists do, because it asks about the mechanism rather than the label. Hreflang looks like a content concern and is technical, because it changes which document gets served to whom. Word count looks technical to people who have read too many checklists and is on-page, because it only ever affects a judgment.
What belongs to each
| Task | Which | Why |
|---|---|---|
| robots.txt rules | Technical | Controls fetching |
| XML sitemaps | Technical | Controls discovery |
| Status codes and redirects | Technical | Controls reachability |
| Canonical tags | Technical | Decides which URL is stored |
| Core Web Vitals | Technical | Server, theme and asset level |
| JavaScript rendering | Technical | Decides what content exists at all |
| hreflang | Technical | Decides which document is served |
| Index coverage problems | Technical | Storage, not ranking |
| Title tags | On-page | A judgment about relevance |
| Headings and structure | On-page | Tells Google what the page argues |
| Content depth and accuracy | On-page | The thing being judged |
| Keyword targeting | On-page | Which query the page is for |
| Internal linking | Both | Discovery and relevance at once |
| Structured data | Both | Emitting it is technical, choosing it is on-page |
| Image optimisation | Both | File size is technical, alt text is on-page |
The three rows marked Both are not a cop-out. They are the genuine overlap, and knowing which half of each you are buying is the difference between a useful brief and an argument three weeks in.
The overlap, explained properly
Internal linking is the clearest case. A link does two jobs simultaneously. It gives Googlebot a path to the page, which is access, and it passes a signal about what the destination is about, which is conclusion. When a page is not being crawled often enough, links are a technical fix. When a page is crawled fine but ranks for the wrong query, the same links are an on-page fix. Same tactic, two problems, and you should know which one you are solving before you start.
Structured data splits by who does it. Deciding a page deserves FAQPage markup, and writing answers worth marking up, is on-page work about that page. Making the templates emit valid JSON-LD across every page of a type, and keeping it valid when the templates change, is technical. Most sites need the second before the first buys anything, because hand-written schema on twelve pages tends to drift out of validity within a year.
Images split cleanly down the middle. Compression, format, dimensions and lazy loading are technical and belong to the pipeline. Alt text and filenames are on-page and belong to whoever writes the page.
Why the order is not negotiable
On-page SEO has a precondition: the page has to be in the index. If it is not, everything you do to it is stored effort with no delivery date.
This is the pattern I see most often in audit work. A site has genuinely good pages, well written, properly structured, and a chunk of them sit in Crawled, currently not indexed or never got discovered at all. The owner’s instinct is to improve the pages, because that is the advice everywhere. Sometimes that is right, since that particular status can mean Google looked and decided the page was not worth storing. Often it is not, and the real cause is a canonical pointing somewhere else, a noindex the theme emits on paginated archives, or a sitemap listing URLs that redirect.
Running the full list of Search Console indexing statuses against the site first tells you which situation you are in, and it costs an afternoon rather than a content budget.
There is a second reason for the order that has nothing to do with waste. A technical pass tells you how much on-page work you actually need. Until you know which pages are indexed, which are duplicated, and which are being served to Google differently from how they are served to you, any estimate for on-page work is a guess.
Which one your symptoms point at
| What you are seeing | Probable discipline |
|---|---|
| Pages missing from Google entirely | Technical |
| Search Console shows coverage errors | Technical |
| The wrong page ranks for your main term | On-page, sometimes canonicals |
| Rankings dropped across the whole site at once | Technical |
| Traffic flat while competitors climb | On-page |
| Page one, position eight, no clicks | On-page, specifically the snippet |
| New pages take months to appear | Technical |
| You rank for your brand and nothing else | On-page |
| Site is fast for you, slow in field data | Technical |
The row worth dwelling on is “rankings dropped across the whole site at once”. Sudden and uniform almost always means something structural changed: a deployment, a plugin update, an accidental staging rule going live. Gradual and uneven is usually competitive, which is on-page and content territory.
What each actually looks like as a job
A technical engagement is an investigation followed by a finite list. Crawl the site, cross-check it against Search Console, separate the problems that cost traffic from the noise, then fix them. It has an end, and the technical SEO audit checklist is that list in the order I work through it. That is how my audits are structured, and it is why technical SEO tends to be bought as a project rather than a retainer.
On-page work is per page and ongoing. Take a page, decide what query it should win, and change the title, headings, structure, internal links and depth until it deserves to. Then the next page. On-page SEO is bought by the batch for that reason, and it does not have a natural end, because the standard is set by whoever else is competing.
The two also fail differently, which is worth knowing before you hire. Technical work either fixed the thing or it did not, and you can verify it the same day. On-page work is a bet on a judgment, and the feedback loop is weeks. Anyone selling you certainty on the second one is selling you something else.
Where indexing sits
Since this is the work I do most, the honest placement: indexing is technical SEO, and it is the narrowest, most verifiable part of it. Whether a URL is in Google’s index is a fact you can check, not an opinion you can argue about. That is unusual in this field and it is why the discipline is worth separating out at all.
It is also why the order in this guide is not a stylistic preference. Indexing sits at the bottom of the stack. Everything on-page depends on it having gone right.
Advice about this pair that is wrong
“Technical SEO is a one-time thing.” It is finite per problem, not one-time. Every deployment, plugin update and theme change can reintroduce the same class of fault, which is why sites that ship regularly need periodic checks rather than a single pass.
“Content is king, technical is optional.” Content is the thing being judged, so it is decisive between pages that are all in the index. It is worth nothing on a page that is not. The two statements are not in tension, they just apply at different stages.
“You need a technical audit before anything.” Not always. A site with fifteen pages, on a maintained platform, with clean coverage in Search Console, does not need an audit. It needs someone to write better pages. The audit earns its cost when the site is large enough, or old enough, for structural faults to hide in it.
The short version
Technical SEO is about access. On-page SEO is about conclusion. When a task is ambiguous, ask which of the two it changes and the answer usually falls out. Fix access first, because conclusions are only drawn about documents that made it into the index, and every hour of on-page work spent on a page Google cannot store is an hour spent on nothing.
Quick answers
Can on-page SEO fix a page that is not indexed?
No, and this is the most expensive mistake in the pair. If a page is not in the index it is not competing for anything, so a better title changes nothing. Rewriting content is sometimes part of the fix for "Crawled, currently not indexed", because that status can mean Google judged the page not worth storing, but that is a quality problem being solved for an indexing reason. If the page is blocked, redirected, canonicalised elsewhere or returning an error, no amount of on-page work will touch it. Check the index status before you commission a word of copy.
Is page speed technical SEO or on-page SEO?
Technical, in almost every practical case. The things that actually move Core Web Vitals live in the server, the theme, the image pipeline and the third-party scripts, and none of those belong to a single page. The exception is a page carrying something the rest of the site does not, such as one enormous hero image or an embedded map that only appears there. Then it is a page-level fix, but it is still a technical one.
If I can only pay for one, which comes first?
Technical, unless you already know the site is clean. The reason is order of operations rather than importance: on-page work compounds only on pages Google can reach, render and store, so buying it first can mean paying for improvements nothing will ever read. A technical pass also tells you how much on-page work is actually needed, because it surfaces which pages are indexed and which are quietly missing.
Is schema markup technical or on-page?
It sits in the overlap and the honest answer is that it depends who ships it. Deciding that a page should carry FAQPage or Product markup, and writing the values that go in it, is on-page work tied to that page's content. Making the site emit valid JSON-LD on every page of a type, and keeping it valid through template changes, is technical. Most sites need the second before the first is worth doing.
Do I need both, or is one enough for a small site?
A small site usually needs a single technical pass and then ongoing on-page work. Technical problems tend to be structural and finite: the sitemap is wrong, the theme emits a stray noindex, the trailing slashes are inconsistent. Fix them once and they stay fixed until something changes the templates. On-page work is per page and never finishes, because it depends on what competitors publish next.