What is technical SEO? A plain explanation

Technical SEO is the work that makes a website easy for search engines to crawl, render, index and serve quickly. It sits underneath everything else. A page that Google cannot reach or understand will not rank, however well it is written and however many links point at it.

It’s the least visible part of search work and often the part with the most headroom, because problems here suppress whole sections of a site at once rather than costing you a position or two.

What technical SEO covers

The scope is wider than most people expect. Six areas account for nearly all of it.

• Crawling. Whether search engines can reach your pages at all. Internal links, XML sitemaps, robots.txt rules and server response codes decide this between them.
• Indexing. Whether Google keeps a page once it has crawled it. Canonical tags, noindex directives, near duplicate pages and thin templates all change the answer.
• Rendering. Whether what you see in a browser matches what the crawler sees. Sites built on client side JavaScript frameworks often serve an empty shell first and fill it in afterwards, which delays indexing or stops it.
• Speed and stability. How quickly a page becomes usable and whether it jumps around while it loads. Core Web Vitals measure this from real Chrome users.
• Site structure. URL patterns, hierarchy, pagination, faceted navigation and hreflang. On large sites this is usually where the real money sits.
• Structured data. Schema markup that states what a page is in a format machines read directly rather than infer.

Why it has got more important

Two things changed. Websites got heavier and more of them render in the browser rather than on the server, so the gap between what a person sees and what a bot sees has widened. And search stopped being one destination. Google’s AI Overviews, ChatGPT, Perplexity and Copilot all fetch pages before they cite them, and most of them are less patient than Googlebot. Content that only exists after JavaScript executes is often invisible to them.

Scale changes the maths too. On a 200 page brochure site, crawling is rarely the constraint. On an ecommerce site where filters generate hundreds of thousands of URLs, Google will spend its crawl budget on parameter junk unless you stop it, and your actual product pages wait weeks for a recrawl.

How to find the problems

Start in Google Search Console. The Page indexing report tells you which pages Google has kept, which it has dropped and why. Two categories are worth reading closely: “Crawled, currently not indexed” usually points at quality or duplication, and “Discovered, currently not indexed” points at crawl capacity or weak internal linking.

Then crawl the site yourself, once with JavaScript rendering off and once with it on. Comparing the two is the fastest way to spot rendering problems. Run the live URL inspection tool on a handful of important pages to see the rendered HTML Google actually holds, rather than the HTML you think you published.

Fixes rarely need to be exotic. Most audits end up recommending the same handful of things: strip accidental noindex tags left over from staging, consolidate duplicate URLs with canonicals, cut low value pages out of the crawl path, compress and lazy load images below the fold, and get the primary content into the initial HTML response. Our technical SEO work starts with a crawl and a Search Console export rather than a tool score, because a score never tells you which pages earn money.

Related reading: our guides to indexability, SEO audits, creating an XML sitemap, HTTP status codes, SEO redirects, using PageSpeed Insights, web crawlers and HTTPS.

Common questions