What is technical SEO? A guide for people who aren't developers

Technical SEO is everything that decides whether a search engine can find your pages, load them, understand them and trust them. Not what the pages say — that is content. Whether they can be read at all.

It gets explained badly, usually as a 10,000-word checklist aimed at developers. Here is the version for the person who owns the website.

The house metaphor, and where it stops being useful

Technical SEO is the foundation. On-page SEO — the words, the headings, the structure of the argument — is the rooms. Off-page — links, mentions, reviews — is your reputation in the neighbourhood.

The metaphor earns its keep because it gets the dependency right: beautiful rooms on a cracked foundation eventually collapse, and a perfect foundation with empty rooms attracts nobody.

Where it breaks down is scale. A cracked foundation is catastrophic; most technical SEO problems are not. They are more like a house where one room has been wallpapered over the door. Everything else works fine. That one room is invisible, and nobody notices until someone goes looking for it.

How a search engine actually reaches you

Four things have to happen, in order, before you can rank at all. Most technical problems are a failure at one specific step — which is why “my SEO is broken” is almost always a more specific problem than it sounds.

Crawl, render, index, rank

Discover
Google finds the URL — by following a link from a page it already knows, or from your sitemap. A page with no internal links pointing at it and no sitemap entry may simply never be found.
Orphan pages are more common than people expect, especially after a redesign.
Crawl
It requests the page. Anything blocking that request — a robots.txt rule, a login wall, a server that times out under load — stops everything downstream.
Render
It runs the page, including JavaScript, to see the finished result. If your content only appears after a script runs, this is where sites quietly lose. What Google renders is what Google judges.
Index
It decides whether the page is worth storing. Thin pages, near-duplicates and pages that contradict their own canonical tag get dropped here — and Search Console will tell you which, and why.
Rank
Only now does any of the content, keyword or link work matter. Everything above is the entry fee.

What “healthy” and “broken” actually look like

A healthy siteA site with problems

LoadingMain content visible in under 2.5 secondsSix seconds, or a blank screen then a jump

MobileBuilt for the phone first, tappable, no sideways scrollDesktop layout squeezed down, tiny tap targets

IndexingEvery page you care about is indexedKey pages sitting in "Discovered — currently not indexed"

SecurityHTTPS everywhere, one canonical version of the domain"Not secure" warning, or four URL variants all live

StructureAnything important is 2–3 clicks from the homepageOrphan pages, redirect chains, dead internal links

In short: Almost no real site is entirely one column. The job is finding which two rows are yours.

The parts, in the order they are worth fixing

Not a checklist of equals. This is roughly the order of impact I see in practice.

Fix first

Crawling and indexing. Can Google reach your pages and is it choosing to keep them? Nothing else matters until this is yes. Blocked resources, accidental noindex tags left over from a staging site, and canonical tags pointing at the wrong URL are the usual culprits — and all three are invisible from the front end.

Duplicate URLs. The same page reachable at several addresses splits its own signals. Trailing slash and non-trailing-slash versions, http and https, www and bare domain, and endless URL parameters. Pick one, redirect the rest, and say so with a canonical tag.

Core Web Vitals and real speed. Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift. As a ranking factor it is modest and frequently oversold. As a reason visitors leave before reading anything, it is enormous.

Important

Mobile. Google ranks based on the mobile version of your site, not the desktop one. If they differ, the mobile one is the one that counts.

HTTPS. Table stakes now. A browser warning costs you more visitors than the ranking signal ever cost you positions.

Site architecture. How pages link to each other tells Google what you think matters. Anything important should be two or three clicks from the homepage, and should have real internal links pointing at it from related pages.

Worth having once the above is done

Structured data. Schema markup does not make you rank higher. It makes you eligible for rich results — stars, FAQ dropdowns, prices — which lifts how many people click you at the position you already hold.

Sitemaps and robots.txt. A sitemap lists what exists; robots.txt says what to skip. Neither is glamorous and both are quietly load-bearing, particularly on large sites.

What you can check yourself, this afternoon

None of this needs a developer. Work down the list — it will tell you whether you have a problem worth paying someone to look at.

The free self-audit

0/ 6

Open Search Console and read the Pages reportIndexed versus not indexed, with Google’s own reason for each exclusion. If you do one thing, do this.
Run PageSpeed Insights on three real pagesNot just the homepage — a service page and a blog post too. The homepage is usually the fastest page on any site and the least representative.
Open your own site on your phoneOn mobile data, not office wifi. Try to tap the main button with a thumb. Most mobile problems are obvious in ten seconds.
Check for the padlockAnd then type your domain four ways — with and without www, http and https. They should all end up at the same URL.
Search Google for site:yourdomain.comA rough count of what is indexed. Wildly more than you expected means duplicates; wildly fewer means an indexing problem.
Crawl it with Screaming FrogFree up to 500 URLs. Finds broken links, redirect chains, missing titles and duplicate meta descriptions without you knowing what any of that means yet.

What genuinely needs someone else

Being honest about the line: JavaScript rendering problems, structured data implementation, restructuring a site’s architecture without breaking what already ranks, untangling redirect chains across a migration, hreflang for multiple languages, diagnosing why Core Web Vitals fail on real devices when the lab score looks fine, and recovering from a manual action.

Those need someone who has done them before, mostly because the failure mode of getting them wrong is worse than not doing them at all.

The short version

Technical SEO is not a competitor to content — it is the thing that decides whether the content is allowed to compete. Most sites need a few specific problems found and fixed once, then a check every few months to catch drift.

If you are not sure whether yours has anything wrong with it, the Search Console Pages report is free and takes five minutes. If that turns up something you would rather not untangle yourself, that is the job I do.

Common questions

What is technical SEO in simple terms?

Everything that affects whether a search engine can find your pages, load them, understand them and trust them — as opposed to what those pages actually say. Speed, crawlability, mobile, security, structure and structured data. It is the foundation the content sits on.

Is technical SEO a one-off job or ongoing?

Mostly one-off, then occasional. The big structural fixes are done once and stay done. What needs watching is drift — a redesign that breaks internal links, a plugin that slows the site down, a page template that quietly stops being indexed. A check every few months catches all of it.

How do I know if my site has technical problems?

Google Search Console tells you free. The Pages report shows what is indexed and what is excluded, and the reason for each exclusion. If pages you care about are sitting under 'Crawled — currently not indexed' or 'Discovered — currently not indexed', you have a technical problem worth investigating.

Does site speed really affect rankings?

It is a ranking factor, but a modest one, and it is routinely oversold. Speed matters far more for whether visitors stay than for where you rank. A page that takes six seconds loses people before it ever gets the chance to be judged.

Do I need structured data?

It will not make you rank higher on its own. It makes you eligible for rich results — the star ratings, FAQ dropdowns and price labels in search results — which raises how many people click at the same position. That is worth having, but fix crawling and indexing first.

Can I do technical SEO myself?

Some of it. Checking Search Console, running PageSpeed Insights, testing on your phone and confirming HTTPS need no technical skill at all. Fixing JavaScript rendering, restructuring architecture, or diagnosing Core Web Vitals failures generally does.