Technical SEO
Everything that has to be true before a good page can rank: it must be reachable, renderable, indexable, unique, fast enough, and understandable to a machine. Here is the whole checklist in the order problems actually matter.
What technical SEO covers
Technical SEO is the work that lets a search engine reach, render, understand and index your pages. It covers crawlability, indexability, canonical URLs, internal structure, structured data and performance. It cannot make a thin page worth ranking, but any one of these failing will stop a good page ranking at all.
The useful mental model is a queue of gates. A page must be discovered, allowed, fetched, rendered, deduplicated and finally indexed. Work the gates in order: a Core Web Vitals project is wasted effort on a page blocked in robots.txt.
The audit order that finds real problems
| Gate | The question | Where you check it |
|---|---|---|
| Discovery | Can the page be found from a link or sitemap? | Internal links, XML sitemap |
| Permission | Is crawling allowed? | robots.txt, meta robots, HTTP headers |
| Fetch | Does the URL return 200 quickly? | Server logs, URL Inspection |
| Render | Is the content in the HTML the crawler sees? | Rendered HTML, view source |
| Dedupe | Which URL is canonical? | Canonical tags, parameters, Search Console |
| Index | Is it actually indexed? | Search Console page indexing report |
| Experience | Is it fast and stable for a real visitor? | Core Web Vitals field data |
Crawling and indexing
Crawling is a search engine requesting your URLs. Indexing is it deciding to store and consider them. The two fail for different reasons, and the fix is different too.
- Blocked in robots.txt: the crawler never fetches the page. It can still be indexed URL-only from links, which is why a blocked page sometimes appears with no description.
- Noindex: the page is fetched and deliberately excluded. Never combine noindex with a robots.txt block, because the crawler cannot read the directive it is blocked from fetching.
- Discovered, currently not indexed: usually a quality or duplication judgement, not a bug. Improve the page or consolidate it rather than resubmitting it.
- Crawled, currently not indexed: the engine looked and passed. Thin, templated, or near-duplicate content is the common cause.
- Soft 404: a page returning 200 with nothing meaningful on it. Return a real 404 or add real content.
Canonicals and duplicate URLs
Most duplication is accidental: tracking parameters, filtered category views, session IDs, trailing slash variants, and http alongside https. Each variant splits the signals a single page should be accumulating.
- One self-referencing canonical tag per page, using an absolute https URL.
- Keep the canonical, the internal links and the sitemap entry pointing at the same URL. Contradictions are why Google picks a canonical you did not choose.
- Redirect variant URLs with a 301 rather than relying on canonicals alone; a canonical is a hint, a redirect is a rule.
- Faceted navigation needs a deliberate policy: index the combinations people search for, block or noindex the combinatorial rest.
Site structure and internal links
Structure is a technical concern because it determines what gets crawled often and what gets forgotten. A page three clicks from the home page with several relevant internal links behaves very differently from an orphan reachable only from a sitemap.
- Every indexable page should be reachable from at least one other indexable page.
- Group related pages under a hub that links down, and have the pages link back up. That is the topic cluster pattern, and it is as much a crawl aid as a relevance signal.
- Use descriptive internal anchor text; it is one of the few anchor signals you fully control.
- Keep the important pages shallow. Depth is a reasonable proxy for how often a crawler returns.
Performance and Core Web Vitals
Field data beats lab data. Optimise for what real visitors on real devices experience, which is what Google uses for page experience assessment.
| Metric | What it measures | Usual cause of a bad score |
|---|---|---|
| LCP | Time until the largest visible element renders | Unoptimised hero images, slow server response, render-blocking CSS |
| INP | Responsiveness to user interaction | Heavy JavaScript on the main thread, oversized hydration payloads |
| CLS | Unexpected layout movement | Images without dimensions, injected banners, late-loading web fonts |
- Serve modern image formats at the size actually displayed, with width and height set.
- Self-host fonts, subset them, and preload the one used above the fold.
- Ship less JavaScript before interaction; defer anything not needed for the first screen.
- Cache aggressively at the edge for pages that do not change per visitor.
JavaScript rendering
Rendering happens on a second pass with its own queue. Anything essential — main copy, headings, internal links, canonical, structured data — belongs in the server response so it survives the first pass.
Test by reading the rendered HTML, not the browser DOM after your app has fully booted. If a link only exists after a client-side fetch, treat it as invisible for crawl purposes.
Frequently asked questions
What is technical SEO?
Technical SEO is the work that lets a search engine reach, render, understand and index your pages: crawlability, indexability, canonical URLs, site structure, structured data, and page performance. It does not make a page worth ranking; it removes the reasons a worthwhile page cannot rank.
How often should you run a technical audit?
Quarterly for a stable site, and after every template, platform or migration change. Most technical regressions arrive with a deploy rather than accumulating slowly.
Do Core Web Vitals affect rankings?
They are part of Google's page experience signals and act as a tiebreaker rather than a primary factor. Their bigger effect is on the visitor: a slow page loses people before content quality is ever tested.
Does Google index JavaScript-rendered content?
Usually yes, but on a delay and with a budget. Content that only exists after client-side rendering is indexed less reliably than server-rendered HTML, so put anything you need ranked in the initial response.