The Complete Guide to Technical SEO

What technical SEO is (and is not)

Technical SEO is the practice of optimizing your website's infrastructure so that search engines can crawl, index, and understand your content. It is the foundation beneath every other SEO effort.

If your site is not crawlable, your content will not be indexed. If it is not indexed, it cannot rank. If it is not understood (through structured data and clear architecture), it cannot match the right queries. Technical SEO is the prerequisite for everything else.

What it is not: technical SEO is not a one-time setup. It is an ongoing discipline. Sites change, content is added, platforms are updated, and Google's crawler evolves. A site that was technically sound a year ago may have accumulated problems since.

Crawlability: can Google reach your pages?

Crawlability is the first gate. If Googlebot cannot reach a page, nothing else matters.

How crawling works

Googlebot discovers URLs from three sources:

1. Links — following links from known pages to new ones (see Google's crawling documentation)
2. Sitemaps — reading your XML sitemap for URLs to crawl (sitemaps.org protocol)
3. URL submission — via Google Search Console (URL Inspection tool)

Once discovered, the crawler fetches the page, parses the HTML, and follows the links on that page to discover more URLs.

Common crawlability problems

• Robots.txt blocking — a misconfigured robots.txt can block Googlebot from entire sections of your site
• Noindex on important pages — a leftover noindex tag prevents indexing even if the page is crawled
• Orphan pages — pages with no internal links pointing to them may never be discovered
• Server errors — 5xx errors and timeouts cause the crawler to give up
• Redirect chains — long redirect loops waste crawl budget and can fail
• JavaScript-rendered content — if content requires JS to render, ensure Googlebot can execute it

How to audit crawlability

1. Check robots.txt — use the robots.txt tester in Google Search Console to verify you are not blocking important paths
2. Run a crawl — use Screaming Frog or Sitebulb to simulate a crawl and find orphan pages, broken links, and blocked resources
3. Review GSC Coverage report — see which URLs are crawled, indexed, and excluded, and why
4. Test important pages — use URL Inspection in GSC to see exactly how Googlebot renders a specific page

Indexation: are your pages in Google's index?

Being crawled is not the same as being indexed. Google crawls far more pages than it indexes — it only indexes pages it considers valuable enough to serve in results.

What controls indexation

• Noindex directives — a meta robots noindex tag or X-Robots-Tag header tells Google not to index a page
• Canonical tags — tell Google which version of a duplicate page to index
• Crawl budget — Google allocates a finite crawl budget per site; low-value pages waste it
• Content quality — thin, duplicate, or low-quality pages may be crawled but not indexed

Managing indexation strategically

Not every page should be indexed. Use noindex strategically on:

• Search result pages on your own site (faceted navigation, internal search)
• Tag and category archives that duplicate content
• Paginated archives (index the first page, noindex the rest)
• Thin pages like author archives with one post
• Staging or test pages

Canonical tags: consolidating duplicates

Duplicate content confuses Google. Canonical tags solve this by telling Google which URL is the "canonical" (preferred) version. Google's documentation on consolidating duplicate URLs explains how canonical signals work.

Common canonical issues:

• Missing canonical tags on pages accessible via multiple URLs
• Self-referencing canonicals pointing to the wrong URL (e.g., HTTP instead of HTTPS)
• Conflicting canonicals (page A canonicals to page B, which canonicals to page A)
• Canonical tags ignored by Google (when signals are weak or contradictory)

Use our Canonical Tag Checker to audit your canonical implementation.

XML sitemaps: your map for Google

Your XML sitemap tells Google which URLs you want indexed. It is not required (Google can discover pages via links), but it speeds up discovery and helps with monitoring.

Best practices:

• Include only canonical, indexable URLs (no redirects, no noindex pages)
• Keep sitemaps under 50,000 URLs and 50MB uncompressed (split into multiple sitemaps if needed) — per the sitemaps.org protocol
• Submit in Google Search Console and monitor the processing status
• Update when you add or remove significant content
• Use lastmod dates accurately — do not update them without real changes

Validate your sitemap with our XML Sitemap Validator.

Site architecture and internal linking

Good site architecture helps users and search engines navigate your site. The goal: every important page should be reachable within 3–4 clicks from the homepage.

The flat architecture principle

A flat architecture means:

• Homepage → category pages → subcategory pages → individual pages
• No page is more than 4 clicks from the homepage
• Internal links create multiple paths to every page (not a single chain)

Internal linking best practices

• Descriptive anchor text — "complete guide to SEO" not "click here"
• Contextual links — links within content carry more weight than navigation links
• Relevant connections — link between topically related pages
• Breadcrumbs — implement breadcrumb navigation with BreadcrumbList schema
• No orphan pages — every page should have at least 2–3 internal links pointing to it

Faceted navigation and URL parameters

E-commerce and directory sites often have faceted navigation (filters for size, color, price). Each filter combination can create a unique URL, generating thousands of low-value pages.

Solutions:

• Use URL parameters in Google Search Console to tell Google how to handle parameters
• Apply noindex to filter combinations that do not warrant indexing
• Use rel=canonical to consolidate similar filter pages
• Block excessive parameter combinations in robots.txt

Core Web Vitals and page experience

Core Web Vitals are Google's page experience metrics. They are confirmed ranking factors and affect how Google evaluates page quality. See Google's page experience documentation for the full list of signals.

The three Core Web Vitals

1. LCP (Largest Contentful Paint) — measures loading performance. Target: under 2.5 seconds. The largest element on the page (usually an image or heading) should load within 2.5s.

2. INP (Interaction to Next Paint) — measures interactivity and responsiveness. Target: under 200ms. The page should respond to user input (clicks, taps) within 200ms.

3. CLS (Cumulative Layout Shift) — measures visual stability. Target: under 0.1. Elements should not shift as the page loads (no jumping buttons or text reflow).

How to optimize LCP

• Optimize the largest above-the-fold element (often a hero image or hero text)
• Serve images in WebP or AVIF format, compressed and sized appropriately
• Use a CDN for global delivery
• Preload critical resources (hero images, fonts, CSS)
• Eliminate render-blocking CSS and JavaScript
• Use server-side rendering or static generation where possible

How to optimize INP

• Minimize JavaScript execution time (code-split, defer non-critical JS)
• Break up long tasks (anything over 50ms blocks interaction)
• Optimize event handlers — debounce scroll and resize handlers
• Use web workers for heavy computation
• Reduce third-party scripts (analytics, chat widgets, ads)

How to optimize CLS

• Set explicit width and height attributes on images and videos
• Reserve space for ads and embeds with fixed-size containers
• Avoid inserting content above existing content (e.g., banners that push content down)
• Use CSS transform for animations (not properties that trigger reflow)
• Preconnect to third-party origins to reduce late-loading resources

Measuring Core Web Vitals

• PageSpeed Insights — lab data and field data (CrUX) for any URL
• Google Search Console — Core Web Vitals report shows site-wide status
• Chrome UX Report — field data for your domain
• Lighthouse — lab data in Chrome DevTools

Read our Core Web Vitals Complete Guide for a deep dive.

Structured data and schema markup

Structured data is the language machines speak. It tells search engines exactly what your content is — an article, a product, a FAQ, an event — in a format they can parse with certainty.

Why structured data matters

• Rich results — schema can qualify your pages for enhanced SERP features (star ratings, FAQ accordions, breadcrumb trails)
• Entity clarity — schema defines your brand and content as entities the knowledge graph understands
• AI extractability — structured data helps AI engines parse and cite your content
• Knowledge graph — Organization and Person schema feed Google's Knowledge Panel

Essential schema types

1. Organization — on the homepage, defines your brand entity (name, logo, URL, sameAs links to social profiles)
2. Service or Product — on commercial pages, defines what you offer
3. Article — on blog posts, defines the content type, author, and date
4. FAQPage — on Q&A pages, makes questions and answers machine-readable
5. BreadcrumbList — on all inner pages, defines the page's position in the site hierarchy
6. HowTo — on instructional content, enables step-by-step rich results

Implementation best practices

• Use JSON-LD (not Microdata or RDFa) — it is the format Google recommends
• Include schema in the HTML source (not injected via JavaScript, if possible)
• Match schema to visible content — do not mark up content that is not on the page
• Validate with Google's Rich Results Test before deploying
• Monitor the GSC Enhancements report for schema errors

Read our Schema Markup Complete Guide for implementation details.

Sources & Further Reading

• Google Search Central — Consolidate duplicate URLs

Official documentation on canonical tags, how Google selects canonicals, and handling duplicate content.
developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

• sitemaps.org — Sitemaps Protocol

The official sitemaps protocol specification, co-sponsored by Google, Bing, and other search engines. Defines the 50,000-URL and 50MB limits.
sitemaps.org/protocol.html

• Google Search Central — Page experience

Documentation covering Core Web Vitals, mobile-friendliness, HTTPS, and intrusive interstitials as page experience signals.
developers.google.com/search/docs/appearance/page-experience

• Google Search Central — Mobile-first indexing

Official guide explaining how Google uses the mobile version of content for indexing and ranking.
developers.google.com/search/docs/crawling-indexing/mobile-first-indexing

• Google Search Central — Manage localized versions

Documentation on hreflang implementation for multi-region and multilingual sites.
developers.google.com/search/docs/specialty/international/localized-versions

• Google Search Central — JavaScript SEO basics

Guide to ensuring Googlebot can render and understand JavaScript-rendered content.
developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

• Google Search Central — Introduction to structured data

Explains JSON-LD, Microdata, and RDFa formats and Google's recommendation to use JSON-LD.
developers.google.com/search/docs/appearance/structured-data/intro-structured-data

Mobile-first indexing and mobile optimization

Google uses mobile-first indexing — it crawls and indexes the mobile version of your site as the primary version, as documented in Google's mobile-first indexing guide. If your mobile site is broken or incomplete, your rankings will suffer.

Mobile optimization checklist

• Responsive design — one URL that adapts to all screen sizes
• Tap targets — buttons and links at least 48px with adequate spacing
• Font sizes — base font at least 16px, readable without zooming
• No intrusive interstitials — pop-ups that cover content on mobile are penalized
• Mobile-friendly forms — appropriate input types, no tiny fields
• Test with Google's Mobile-Friendly Test — verify before and after changes

HTTPS and security

Security is a ranking signal. Google prefers HTTPS sites, and browsers now flag HTTP sites as "not secure."

Security checklist

• SSL certificate — valid and not expired, covering all subdomains
• HTTPS everywhere — all pages and resources served over HTTPS
• HSTS header — tells browsers to always use HTTPS
• Mixed content — no HTTP resources on HTTPS pages (images, scripts, CSS)
• Redirect HTTP to HTTPS — 301 redirect all HTTP traffic to HTTPS
• Security headers — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options

International SEO: hreflang and multi-region

If you serve multiple languages or regions, hreflang tags tell Google which version of a page to show to which audience.

hreflang implementation

• Use the correct format: rel="alternate" hreflang="lang-region" (e.g., hreflang="en-gb" for English UK)
• Include a self-referencing hreflang tag (each page should reference itself)
• Include an x-default hreflang for users who do not match any specified language
• Place hreflang in the HTML head, in the sitemap, or in the HTTP header (pick one, do not duplicate)
• Validate with Google's International Targeting report in GSC

JavaScript SEO

Modern sites use JavaScript frameworks (React, Vue, Next.js). JavaScript SEO ensures Googlebot can render and understand JS-rendered content. See Google's JavaScript SEO basics for the full guide.

Key considerations

• Server-side rendering (SSR) or static generation (SSG) — preferred for SEO; content is in the HTML source
• Client-side rendering (CSR) — Googlebot can render JS, but it is slower and less reliable; content may not be indexed on the first crawl
• Hybrid rendering — SSR for content, CSR for interactivity (common in Next.js)
• Dynamic rendering — serve pre-rendered HTML to bots and JS to users (a workaround, not a long-term solution)

Testing JS-rendered content

• Use the URL Inspection tool in GSC — "View Rendered Page" shows what Googlebot sees after JS execution
• Check that critical content (text, links, schema) is present in the rendered DOM
• Ensure internal links are real <a href> tags, not JS click handlers

The technical SEO audit checklist

Run this checklist quarterly and after any major site change.

Crawl and index

• ☐ No critical crawl errors in Google Search Console

• ☐ XML sitemap submitted and processing

• ☐ Robots.txt does not block important pages

• ☐ No unexpected noindex tags on important pages

• ☐ Canonical tags correct on all pages

• ☐ No orphan pages (all pages have internal links)

Performance

• ☐ LCP under 2.5s on key pages

• ☐ INP under 200ms on key pages

• ☐ CLS under 0.1 on key pages

• ☐ Images optimized (WebP/AVIF, lazy-loaded)

• ☐ No render-blocking resources above the fold

Structure and markup

• ☐ Organization schema on homepage

• ☐ Article schema on blog posts

• ☐ Service/Product schema on commercial pages

• ☐ FAQ schema on Q&A pages

• ☐ Breadcrumb schema on all inner pages

• ☐ All schema validates in Rich Results Test

Mobile and security

• ☐ Mobile-friendly (passes Google's Mobile-Friendly Test)

• ☐ HTTPS on all pages, no mixed content

• ☐ Security headers configured

• ☐ HTTP redirects to HTTPS

International (if applicable)

• ☐ hreflang tags correct and validated

• ☐ Self-referencing and x-default hreflang present

• ☐ Country targeting correct in GSC

The bottom line

Technical SEO is not glamorous, but it is the foundation everything else stands on. A site with perfect content and a strong link profile will still underperform if it is slow, uncrawlable, or misunderstood.

The good news: technical SEO is the most controllable pillar. Unlike links and content quality, technical issues have clear fixes. Audit regularly, fix issues promptly, and keep the foundation solid. Everything you build on top of it will perform better.