By Mazhar SiddiqiPublished Updated
Technical SEO and on-page SEO get lumped together because both happen on your own website. The distinction still matters, and not for tidy labelling. It decides what you fix first. Rewriting a title tag will not help a page Google cannot index. A perfectly fast site will not rank a page that answers the wrong question.
The one-line version.
Technical SEO is about the site: can search engines reach it, render it, understand its structure, and trust it? On-page SEO is about the page: when someone searches for this, is this page the clearest, most useful answer?
Think of a library. Technical SEO is the building, the shelving, and the catalogue system. On-page SEO is whether each individual book has a clear title, a sensible table of contents, and actually covers what the spine says it does.
Technical SEO vs on-page SEO, side by side.
| Technical SEO | On-page SEO | |
|---|---|---|
| Scope | Whole site, templates, server | One page at a time |
| Core question | Can Google crawl, render, and index this? | Is this the best answer for the query? |
| Typical problems | Pages not indexed, wrong canonicals, redirect chains, slow templates, JavaScript-only content | Vague titles, mismatched intent, thin sections, weak internal links, cannibalisation |
| Who usually fixes it | A developer | A writer, editor, or SEO, sometimes with a developer |
| Main tools | Search Console indexing reports, URL Inspection, a crawler, Lighthouse | Search Console queries, SERP review, the page itself |
| Failure looks like | The page is invisible, whatever its quality | The page is visible but ranks low or gets few clicks |
Technical SEO: the foundation.
Technical SEO is concerned with infrastructure. Problems here are rarely dramatic on the page itself, which is why they hide so well. A single wrong canonical tag on a template can quietly remove hundreds of pages from the index. A slow product template drags down every product.
The core checklist:
- Crawlability. robots.txt allows what matters; important pages are linked, not orphaned.
- Indexation. No accidental
noindex; the Search Console Pages report shows important URLs as indexed. - Canonicals and duplicates. Every page declares one preferred URL; parameter, trailing-slash, and www variants resolve to it.
- Redirects. Single-hop permanent redirects, no chains, no loops, no internal links pointing at redirects.
- XML sitemap. Only indexable, canonical, 200-status URLs, with accurate last-modified dates.
- Rendering. Important text and links exist in the HTML, not only after JavaScript runs.
- Core Web Vitals. LCP within 2.5 seconds, INP within 200 milliseconds, CLS under 0.1, measured on real users.
- Structured data. Valid schema that matches what is visible on the page.
- HTTPS and mobile. Secure everywhere, usable on a phone, since Google crawls mobile-first.
Most of these are fixed in code, templates, or server configuration. That is why technical SEO work stalls so often when the person who found the issue cannot change the codebase. More on that in the technical SEO service.
On-page SEO: giving each page a job.
On-page SEO works at the level of a single URL. It starts with intent, which is easy to skip and expensive to get wrong. Someone searching "technical seo vs on-page seo" wants a comparison. Someone searching "technical seo services" wants a provider. Same words, different jobs, different pages.
- Search intent. The page type matches what people searching actually expect: guide, comparison, product, service.
- Title tag. Clear, specific, under roughly 60 characters, with the main topic near the start.
- One H1 and a logical heading structure that someone could skim and understand.
- The answer, early. The first paragraphs address the query directly rather than warming up.
- Depth where it matters. The sub-questions the searcher will have next are covered on the page.
- Internal links with descriptive anchor text, to and from related pages.
- Meta description written to earn the click, not to repeat the title.
- Images with useful alt text and sensible file sizes.
The question to keep asking is plain: if this page were the only result, would the searcher be satisfied? When several pages on the same site try to answer the same query, on-page work also means separating or consolidating them so they stop competing with each other. The on-page SEO page goes into how that mapping is done.
Where content SEO fits (and why people confuse it).
Content SEO sits one step before on-page SEO. On-page work improves pages that exist. Content work decides which pages should exist at all: which topics have real demand, which ones the site can realistically compete for now, and how those pages link into the services or products that pay the bills.
A simple way to separate the three. Technical SEO: can it be found? Content SEO: should it exist? On-page SEO: is it the best version of itself? There is a dedicated page on content SEO if that is the gap.
Off-page SEO, for completeness, happens away from the site: links and mentions from other websites that build authority. It matters most once the first three are in order, because authority amplifies pages that are already crawlable and well targeted. It cannot rescue ones that are not.
How to tell which problem you have.
Search Console usually tells you, if you know where to look.
| What Search Console shows | Probable constraint |
|---|---|
| Important pages "Discovered - currently not indexed" or "Crawled - currently not indexed" | Technical (or quality signals Google uses to decide) |
| Google chooses a different canonical than you declared | Technical: duplicates or conflicting signals |
| Indexed, but average position 30 or worse for the target query | On-page relevance, or authority |
| Position 5–15 with plenty of impressions and few clicks | On-page: title and description |
| Two of your URLs swap positions for the same query | On-page: cannibalisation |
| Rankings fine, traffic fine, conversions poor | Neither: it is a page experience or offer problem |
Which should come first?
Start with technical SEO when the site has crawl, indexation, rendering, or performance issues. There is little value in polishing content on pages search engines cannot reliably access. Once the foundation is solid, on-page work tends to produce clearer, faster gains, because each improvement lands on a page that can actually be seen.
In practice the work overlaps more than the labels suggest. Internal linking is on-page strategy and site architecture at the same time. Structured data supports the topic of a page, but it is implemented in code. The useful approach is not to pick a camp. It is to find the constraint that is holding the site back right now, fix that, and then look again.
Not sure where the constraint is? An SEO audit that ends in a prioritised list, rather than a 200-row spreadsheet, is usually the fastest way to find out.