Technical SEO
What is technical SEO?
Google describes search as three separate stages: crawling, indexing and serving. Technical SEO is everything that keeps a page moving cleanly through all three.
What is technical SEO?
Technical SEO is the work that makes a website easy for a search engine to crawl, render and index, and stable and fast enough for the people who land on it. It covers crawl access, indexing rules, canonical URLs, site architecture, internal linking, sitemaps, mobile rendering, structured data and page speed.
It does not write content, create demand or earn links: it removes the reasons a good page would otherwise fail to be found.
Search happens in three stages, not one
Google crawls a page, decides whether to index it, then decides whether to serve it for a particular query. Each stage can fail on its own, and the failures look nothing alike.
Crawling is discovery. Googlebot finds a URL, requests it and renders it roughly the way a browser would. If the URL is blocked in robots.txt, returns a server error, sits behind a login, or depends on JavaScript that never finishes, the crawl stalls and nothing downstream can happen.
Indexing is understanding and storage. Google analyses what it fetched, works out what the page is about, checks whether it duplicates something else, and picks one canonical version to keep. A page can be crawled and still not indexed, which is the most commonly misdiagnosed problem on a small site.
Serving is the ranking step. Only pages in the index are candidates for a query, and the ones shown are those judged most useful for that specific search. Technical work does not win this step by itself. It makes sure the page is allowed to compete for it.
Not indexed and not ranking are different problems
Those two sentences sound identical to most business owners and mean completely different things. A page that is not indexed is invisible: it cannot appear for any query, at any position, for anybody. A page that is indexed but not ranking is perfectly visible to Google and simply losing to something better.
The fixes have nothing in common. Not indexed points at access and selection: a robots rule, a noindex tag left on after launch, a canonical pointing somewhere else, a redirect chain, a soft 404, or a page so thin that Google decided not to keep it. Not ranking points at relevance, depth, intent match and the strength of whatever is currently winning.
Read the full breakdown: Not indexed and not ranking are different problemsHide the full breakdown: Not indexed and not ranking are different problems
Google Search Console tells you which one you have, free, in about thirty seconds. Paste the URL into the inspection tool and it reports the indexing status, the canonical Google chose, when it was last crawled and whether the page is eligible to appear. The Page indexing report does the same job across the whole site and groups pages by reason.
Do this before spending money on anything else. Publishing more content on a site that is not being indexed properly is the most expensive mistake in this whole category, and it is common.
What technical SEO actually covers
None of this is exotic. It is a list of things that either work or do not, and most of them can be verified in an afternoon by anyone willing to look.
- Crawl access: robots.txt allows the pages you want found and blocks nothing important by accident.
- Indexing rules: no stray noindex tags surviving from a staging site, and no pages you care about sitting in the excluded list.
- Canonical URLs: one address per piece of content, with http, https, www and non-www all resolving to a single version.
- An XML sitemap listing the canonical URLs you want indexed, submitted in Search Console and updated automatically rather than by hand.
- Internal links that are real anchor tags with an href attribute, because a link Google cannot follow is not a link.
See the full checklist: What technical SEO actually coversHide the full checklist: What technical SEO actually covers
- A structure where every important page is reachable from the home page in a few clicks, and no page is orphaned.
- Mobile rendering that serves the same content and markup as desktop, because Google indexes the mobile version of your pages.
- HTTPS across the whole site, with no mixed content warnings and no certificate about to expire.
- Loading and layout stability good enough that the page is usable at the moment it looks usable.
- Structured data that matches what a visitor can actually see on the page.
- Clean status codes: 200 for live pages, a single 301 for moved ones, and no chains of redirects hopping through three URLs.
- Real 404 handling, so a dead URL says it is dead instead of quietly returning a near-empty page that Google treats as a soft 404.
Notice what is missing from that list. Technical SEO does not include writing, offers, reviews or links. It is the floor the rest of the work stands on, which is why it is worth doing first and rarely worth doing twice.
Structure is a technical signal
How pages link to each other decides which ones get crawled often and which ones get forgotten.
Search engines discover most pages by following links from pages they already know about. A page nothing links to is effectively invisible even when it sits in the sitemap, which is why orphaned pages are a technical failure rather than a content one.
Structure also communicates importance. Pages linked from the main navigation and from many other internal pages are crawled more often and treated as more central to the site. Pages buried five clicks deep get crawled rarely, so edits to them take much longer to register.
The practical version: group pages into topics, give each topic a hub, link every page in the topic to that hub and back again, and write link text that names the destination. Avoid linking with the words click here, because the anchor text is one of the few clues about what sits on the other side.
Where technical SEO stops and the rest begins
These three get blurred together in sales conversations. Keeping them apart makes it obvious what any given problem actually needs.
| Item | What it is | Typical work | What it cannot do |
|---|---|---|---|
| Technical SEO | Making the site crawlable, indexable, stable and quick | Crawl and index fixes, architecture, speed, structured data | Make a thin page worth ranking |
| On-page SEO | Making one page unmistakably about one thing | Titles, headings, depth, intent match, internal links | Fix a page Google cannot reach |
| Off-page SEO | Signals that happen away from your website | Links, mentions, citations, reviews, brand search | Rescue a site with indexing problems |
The order matters. Fixing access first is far cheaper than buying attention for pages that cannot be served in the first place.
Speed sits inside page experience, not on top of ranking
Google groups loading, responsiveness and visual stability into page experience, and describes it as one input among many rather than a dominant one.
Core Web Vitals are field metrics. They come from real visits on real devices and connections, not from one test run on a fast laptop on office wifi. A lab tool is useful for diagnosis, but the measurement that counts is what your actual visitors experienced.
Treat the thresholds as a user experience floor rather than a ranking lever. A fast page with nothing to say still loses to a slower page that answers the question properly. The honest commercial argument for speed is the visitor who gives up before the page appears, not the algorithm.
The thresholds to hold a developer to
Google publishes a good threshold for each metric on web.dev. These are live values, so re-check them rather than trusting a year-old audit.
SourceGoogle web.dev, Web Vitals thresholds
Interaction to Next Paint replaced First Input Delay as the responsiveness metric, so any audit still reporting FID was written against an outdated standard.
How to tell whether the technical work was really done
Ask for evidence rather than adjectives. Everything below is visible to you in a free Google tool, which means nobody has to take an agency's word for anything.
In Search Console, the Page indexing report should show the pages you care about as indexed, with the not indexed reasons explained rather than ignored. A large gap between submitted and indexed URLs is the clearest single sign that something structural is wrong.
Read the full breakdown: How to tell whether the technical work was really doneHide the full breakdown: How to tell whether the technical work was really done
The URL inspection tool should report your preferred address as the Google-selected canonical. If Google picked a different URL, you have near-duplicate pages competing with each other, and the fix is a canonical tag plus consistent internal linking. Canonicalisation consolidates duplicates for search, it does not delete pages from your site.
The Core Web Vitals report should be read as field data, with mobile and desktop looked at separately. A green lab score sitting next to a failing field report means real visitors are having a worse time than the test did.
Finally, crawl the site yourself with any crawler and pull four lists: redirect chains, broken internal links, pages with no inbound internal links, and duplicate titles. Those four catch most of what matters on a site under a few thousand pages.
Related answers
The neighbouring questions people usually ask next, plus the guide that assembles the whole picture.
Why did my Google rankings drop?
The difference between a technical fault, a content problem and an algorithm update, and how to tell which one you are looking at.
Why did my Google rankings drop?How do I improve website speed?
What actually moves Largest Contentful Paint on a real site, in the order worth doing it.
How do I improve website speed?What is schema markup?
The other half of machine readability: telling a search engine what your page means, not just what it says.
What is schema markup?The local SEO guide
How technical foundations, content and local signals fit together for a business with a physical service area.
The local SEO guideNot sure whether your site is actually being indexed?
We will look at the crawl, index and speed picture and tell you what we find, including the parts that are fine.
Straight answers.
Is technical SEO a one-off project or ongoing work?
Mostly one-off, with maintenance. The heavy lifting happens once: fixing crawl and index problems, sorting canonicals and redirects, improving architecture and speed. After that it becomes monitoring, because sites drift.
Things that reintroduce problems: a theme or plugin update, a new page template, a developer copying a staging site over the live one with noindex still set, or a migration. A monthly look at the Page indexing report catches nearly all of it early.
Can I do technical SEO myself?
Parts of it, yes. Verifying the site in Search Console, submitting a sitemap, reading the Page indexing report and inspecting individual URLs need no code and no budget.
Where it gets specialist is server configuration, redirect logic, JavaScript rendering and anything involving a migration. Those are the places where a mistake takes a site down rather than just failing to help.
Do Core Web Vitals really affect rankings?
They are part of page experience, which Google describes as one of many signals rather than a dominant one. A page will not outrank a better answer because it loads faster.
They matter more for people than for position. A page that responds slowly loses visitors before it gets the chance to lose rankings, which is the stronger reason to fix it.
Does technical SEO help with AI search?
Indirectly, and the mechanics are not fully documented. What is knowable is that a page has to be crawlable and readable before any system can use it, whether that system is a search index or an assistant summarising the web.
So the technical floor is the same: accessible pages, clean markup, structured data that matches the visible content, no rendering that hides the substance behind scripts. Nobody can guarantee a citation in an AI answer, and anyone selling one is guessing.
How long before technical fixes show up in search?
Indexing changes can register in days once Google recrawls the affected URLs, and you can request a recrawl for a small number of important pages. Ranking changes take longer because ranking is a comparison against everything else.
The honest register: expect movement over weeks and months, not days. Anyone promising instant results after a technical fix is overselling.
Is a website migration a technical SEO job?
Yes, and it is the highest risk one. A migration changes URLs, templates and often the server, so every redirect, canonical and internal link has to be mapped before launch rather than repaired afterwards.
The failure mode is severe and slow to recover from: old URLs returning 404s, redirect chains, and a sitemap still listing addresses that no longer exist. Plan the redirect map first, then launch.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- Google Search Central: In-depth guide to how Google Search works (opens in a new tab)Crawling, indexing and serving, described by Google rather than inferred.
- Google Search Central: Introduction to robots.txt (opens in a new tab)
- Google Search Central: How to specify a canonical URL (opens in a new tab)
- Google Search Central: Mobile-first indexing best practices (opens in a new tab)
- Google Search Central: Understanding page experience in Google Search results (opens in a new tab)
- Google web.dev: Web Vitals (opens in a new tab)The current thresholds for LCP, INP and CLS, and the 75th percentile rule.
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.