Guide · 9 September 2026
Technical SEO: a working definition
Technical SEO is the eligibility layer: whether a URL can be discovered, fetched, rendered and kept. Content quality matters after that chain holds. This page is the reasoning I use on real sites — not a keyword list, and not a set of invented averages.
Author
Written by Palak Bhatt
Definition
A working definition
I treat technical SEO as the set of constraints that decide whether a URL is even a candidate: can a crawler find it, fetch it, render the thing a person would see, and keep that URL as the one that represents the document? If any step fails, improving the copy is theatre.
That is different from “on-page SEO” (the document itself) and different from link-building or content strategy. It is also different from a plugin settings screen. Robots, sitemaps and meta tags are outputs. The decisions sit in templates, headers, URL design and what you allow to exist.
A useful test: if I cannot point at a URL pattern, a status code, a header, or a rendered DOM difference, I do not yet have a technical finding. I have a feeling. Feelings do not ship.
Crawl
Crawl: discovery and waste
Crawling is two jobs that people collapse into one word. Discovery is how the crawler learns the URL exists — usually an internal link, sometimes a sitemap, occasionally a redirect or an external mention. Fetch is the HTTP request that follows. A URL in a sitemap that nothing links to is a rumour. A URL that is linked from everywhere but blocked in robots.txt is a door you advertised and then locked.
Waste is the more expensive problem on large sites. Faceted filters, sort orders, session parameters and infinite combinations of the same template will happily consume fetches that should have gone to the category or article that actually earns demand. “Crawl budget” is not a mystic quota I can quote you. It is whether the crawler spends its visits on candidates or on copies. One robots or parameter rule at the template is worth more than a thousand URL-level patches.
I start from what exists (a crawl) and what Google already found (Search Console), then ask which of those URLs should never have been candidates. The sitemap should agree with that answer. If it lists noindexed archives or staging leftovers, the sitemap is not a map — it is a junk drawer with an XML wrapper.
Index
Index: what Google keeps
Indexation is a decision, not a participation trophy. Google can fetch a URL and still refuse to keep it: thin duplicates, soft-404s, canonical conflicts, noindex, or a page that looks like a shell. “Submitted and indexed” in Search Console means the URL is in the index. It does not mean that URL is the one that will represent the query.
The useful comparison is crawl map versus index map. What did we allow to exist? What did Google keep? Where those sets disagree, you have the actual work — not a content calendar. I have watched teams rewrite titles on URLs that were never going to be kept because a canonical or a parameter duplicate already won.
Status codes matter here in a boring way. A 200 that is empty, a 404 that still has history, a 302 that has been “temporary” for three years: each one teaches the index something you may not have intended. I would rather see an honest 404 than a soft homepage serving “not found” in the body with a 200 on the wire.
JavaScript
JavaScript: two versions of the page
On a client-rendered stack the first response is often a shell. The product — the copy, the internal links, sometimes the title — arrives after JavaScript runs. A person with a browser waits. A crawler may wait, may retry, may store an earlier state, or may index what the first response contained. That is not a morality tale about “Google cannot render JavaScript.” It can. It does not promise to do it the same way, at the same time, for every URL.
The practical question is: which commercial content must be in the HTML of the first response if you cannot rely on a later render? Links in a menu that only hydrate on click are not links to a crawler. Structured data injected after paint is markup the index may never see. I compare raw response to rendered DOM on the templates that make money, and I write the ticket against that diff — not against a framework slogan.
Headless and hybrid setups are the same job with more moving parts: what the CDN caches, what the origin returns to a Googlebot user-agent, and whether preview or staging headers leak into production. If your QA never looks at “view source” and only looks at the painted page, you are QA-ing a different document from the one search sees first.
Canonicals
Canonicals: a hint, not a switch
A rel=canonical tag is a request. Google may honour it, ignore it, or pick a different URL because the links, sitemap and content told a different story. Treating the tag as a command is how sites end up with parameter URLs in the index while the “clean” URL sits unused — or the reverse.
Self-canonicals should match the URL you actually want: scheme, host, trailing slash, and whether www exists. I still find tags that point at a staging host, a http URL, or a parameterised version of themselves. Those are not edge cases. They are what happens when a CMS default and a reverse proxy disagree.
Cross-URL canonicals are for true duplicates — print views, tracking parameters, a session copy — not for “this article is related so please consolidate.” If two URLs have different intent, a canonical between them is a lie, and the index will eventually notice. Prefer one URL that exists, or a redirect, over a tag that asks Google to pretend.
Redirects
Redirects: one hop, one reason
A redirect is a sentence: this URL is finished; that URL is the continuation. Chains (“A → B → C”) waste crawl and dilute the sentence. Loops waste it entirely. I flatten to one hop whenever I can, and I care more about the map than about whether the status is 301 or 308. Persistent move, not a decorative 302 that has been in place since the last redesign.
The unit of work is a pattern, not a hero URL. Trailing slashes, uppercase paths, leftover.html extensions, old campaign parameters — if you only 301 the homepage and a dozen “main pages,” you have not redirected the site. You have redirected the pages someone remembered in a meeting.
Redirects are also how migrations fail in slow motion. A catch-all to the homepage turns every obsolete URL into a soft-404 with a smile. I would rather 404 a URL I cannot map than send it to a page that does not continue the same intent.
Migrations
Migrations: the URLs nobody designed
A redesign or a CMS move is a technical SEO project whether the slide deck says so or not. The demand you already earned lives on URLs. If those URLs die without a mapped successor, the next quarter’s “traffic drop” is not a mystery. It is a missing spreadsheet.
I inventory what Search Console still shows, what the crawl finds, and what analytics still receives — including query strings, paginated archives, expired products and PDF leftovers. Design files list the new information architecture. They almost never list the old one. The gap between those two lists is the migration.
Sequence matters. Freeze new URL invention late in the build. Ship redirects with the cutover, not “in a follow-up sprint.” Recrawl the patterns you claimed to move. Then read coverage for the URLs that were supposed to disappear. A migration without that loop is a launch, not a transfer.
Performance
Performance: templates, not screenshots
Core Web Vitals are field measurements of how a page feels to people, not a Lighthouse score to screenshot for a slide. I will not invent a “good LCP number” for your industry here. I will say this: Largest Contentful Paint and layout shift are usually locked into the template — the hero image, the font chain, the banner that shoves the title after consent.
That means the unit of work is again the template that carries commercial intent, not every blog URL in the crawl. Fixing a marketing landing that nobody searches for while the category template ships a 4 MB hero is a category error. I treat performance as a shipping constraint on the pages that earn, the same way I treat status codes.
Lab tools are useful for isolating which asset or script is the villain. They are not the result. If we cannot name the element that paints late, we do not yet have a performance ticket.
Schema
Schema: markup that matches the page
Structured data is a machine-readable restatement of what the page already says. It is not a ranking lever you bolt on. Google’s rich-result features have eligibility rules; markup that describes a review, a price, or an FAQ that is not on the page is a policy problem, not an SEO win. I will not invent ratings, review counts, or aggregate scores to “complete” a schema block.
On this site, JSON-LD is generated from the same facts that are visible: identity, breadcrumbs, services, the questions on the page. That is the standard I use for clients. If the visible page cannot support a type, we do not emit the type.
Schema also fails in the JavaScript case. If the only JSON-LD is injected after hydration, you may have a valid-looking Rich Results test on a rendered snapshot and an empty document in the first response. Same rule as content: decide what must be in HTML if the render is late or skipped.
Project
When this becomes a project
This page is informational. It is here so a developer, a founder or a marketing lead can share one picture of the chain. It is not a substitute for looking at your URLs.
If the commercial URLs cannot be fetched, rendered or kept — or you are about to move them — that work has an owner on this site:Technical SEO. That page is the engagement: tickets, acceptance checks, and whether I implement or brief your team. If you do not yet know which break you have, start with anSEO audit.
I will not attach a before/after percentage to this guide. When a teardown is published, it will name the stack, the break, what shipped, and the limits of the evidence.
Questions
Questions this guide usually raises
Is technical SEO just “on-page SEO” with a different name?
No. On-page work is usually titles, headings and the copy on a URL that already exists. Technical SEO is whether that URL can be fetched, rendered, kept, and found again without wasting the crawl on copies. You can write a perfect page on a URL Google never keeps.
Do I need a plugin for this?
A plugin can emit robots, sitemaps and tags. It cannot decide which templates should be candidates, flatten a redirect chain, or put commercial HTML in the first response. Treat plugins as printers, not as the architecture.
Where should I start if I do not know what is broken?
Start with Search Console coverage and a crawl of what actually exists, then compare that to the URLs that make money. If you still cannot name the break, an audit is the diagnostic product — this guide is the map, not the engagement.
Will a supporting article exist for each of these topics?
Only when that article has a different job from this pillar. I will not publish twenty thin posts that repeat these sections with a new H1.
Implementation lives on the service page
This guide is the map. If you need tickets, a render comparison, or a redirect map that can be scheduled, that is Technical SEO as a project.