What Is Technical SEO? The Foundation of Search Visibility

Technical SEO is the set of site-level practices that make sure search engines can find, crawl, render, and index your pages, and that the pages themselves load fast enough and behave well enough for people to actually use them. It does not deal with what your content says or how many sites link to you. It deals with whether a search engine can reach your content at all, and whether the experience around that content holds up once a visitor clicks through.

A useful way to think about it: content and links are what make a page worth ranking, but technical SEO is what makes a page eligible to rank in the first place. A brilliant article on a page that returns the wrong status code, blocks Googlebot in robots.txt, or takes nine seconds to load is, for search purposes, close to invisible.

This guide covers the core areas that make up technical SEO: crawlability, indexability, site architecture, page experience (including Core Web Vitals), HTTPS, mobile-first indexing, structured data, JavaScript rendering, and how to monitor technical health over time.

Crawlability: can search engines reach your pages?

Before a page can rank, a search engine’s crawler has to find it and fetch it. A few mechanisms control that process:

• robots.txt tells crawlers which paths they’re allowed to request. A misconfigured disallow rule is one of the most common ways sites accidentally hide themselves from Google.
• XML sitemaps give search engines a direct list of the URLs you want crawled and indexed, which is especially useful on large or frequently updated sites.
• Internal linking helps crawlers discover pages and understand which ones you consider important; pages with no internal links pointing to them (orphan pages) are much harder to find.
• Crawl budget, Google’s term for the set of URLs it can and wants to crawl on a given site, is shaped by your server’s crawl capacity and by how much Google judges your content worth crawling. Google’s own guidance for large sites recommends consolidating duplicate content and using sitemaps and robots controls so crawlers don’t waste time on low-value URLs, since crawl budget is a real constraint mainly for sites with very large or frequently changing URL counts, not for the typical small or mid-sized site.

Indexability: can a crawled page actually get indexed?

Being crawled doesn’t guarantee being indexed. A page can be fetched successfully and still get excluded for several reasons:

• A noindex meta tag or HTTP header explicitly tells search engines not to index the page.
• Canonical tags point search engines to the “preferred” version of duplicate or near-duplicate content; an incorrect canonical can cause Google to index the wrong URL or drop a page entirely.
• URL parameters (tracking tags, session IDs, faceted filters) can generate large numbers of near-duplicate URLs that dilute crawl and indexing resources if left unmanaged.

Google Search Console’s Page indexing report is the primary tool for diagnosing this: it shows which URLs are indexed and which are excluded, along with the reason (crawled but not indexed, blocked by robots.txt, duplicate without user-selected canonical, and so on). This report replaced the older “Index Coverage” report under its current name, and it’s the one to reference when auditing indexing problems today.

Site architecture

How a site is structured affects both crawl efficiency and how easily users (and search engines) understand what a page is about relative to the rest of the site. The basics that hold up across most sites:

• Keep important pages within a few clicks of the homepage; deeply buried pages get crawled less often and pass less internal authority.
• Use a logical URL structure that reflects the site hierarchy (category, subcategory, page) rather than arbitrary IDs.
• Use breadcrumb navigation, both for users and because it gives search engines an explicit signal of where a page sits in the site hierarchy.
• Watch for faceted navigation (filter and sort combinations on e-commerce or listing sites) generating huge numbers of crawlable, near-duplicate URLs. This is one of the most common large-site crawl-budget problems.
• Avoid orphan pages, pages with no internal links pointing to them, since they’re effectively invisible to both crawlers and users browsing the site normally.

Core Web Vitals and page experience

Core Web Vitals are the specific metrics Google uses to quantify real-world page experience. There are three, and Google publishes explicit thresholds for what counts as a good user experience, measured at the 75th percentile of page loads, split between mobile and desktop:

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading performance, time until the largest visible element renders	2.5s or less	2.5s to 4s	over 4s
INP (Interaction to Next Paint)	Responsiveness, the latency of user interactions across the full page visit	200ms or less	200ms to 500ms	over 500ms
CLS (Cumulative Layout Shift)	Visual stability, how much visible content shifts unexpectedly during load	0.1 or less	0.1 to 0.25	over 0.25

These thresholds are documented directly by Google in its Web Vitals reference. One terminology note worth being precise about: INP replaced First Input Delay (FID) as the official responsiveness metric in March 2024. If you still see FID mentioned as a current Core Web Vital in a tool or article, that’s outdated; FID is retired, and INP measures responsiveness more comprehensively because it accounts for the full duration of an interaction rather than just its initial delay.

You can check a site’s real-world Core Web Vitals performance, based on actual Chrome user data rather than a lab simulation, in the Core Web Vitals report in Search Console.

HTTPS as a baseline requirement

Google has treated HTTPS as a ranking signal since it said so explicitly: the Google Security Blog’s August 2014 announcement confirmed that secure pages get a ranking boost, while also describing it at the time as “a very lightweight signal” affecting a small share of queries and carrying less weight than strong content. Google noted it might strengthen the signal over time to encourage broader HTTPS adoption, and HTTPS has since become the de facto baseline expectation for any credible site, not a competitive edge. In practical terms, the bar today isn’t “does this site have HTTPS,” it’s “is the entire site served over HTTPS without mixed-content errors or broken certificate chains.”

Mobile-first indexing

Google has used the mobile version of a site’s content for indexing and ranking purposes, calling this mobile-first indexing, since completing the rollout across the web. The practical implication is that whatever Googlebot’s mobile crawler sees is what counts, so the mobile version needs to carry the same content, structured data, meta tags, and robots directives as the desktop version. A common failure mode is a mobile template that strips out content sections, internal links, or structured data that exist on desktop, which can quietly cost a site indexing and ranking signal it doesn’t realize it’s losing.

On the readability side, Lighthouse used to flag pages where a large share of text fell below a 12-pixel threshold as having a “legible font sizes” problem, but per Chrome’s own documentation, that audit was removed from Lighthouse as of version 13 (October 2025); Google’s stated reasoning is that font size isn’t treated as a distinct SEO ranking signal, even though it remains a real usability issue worth checking manually. There’s no official Google “minimum font size” rule, but a widely used industry rule of thumb still sets body text around 16px on mobile, partly because text smaller than that commonly triggers automatic zoom behavior in mobile browsers and tends to fail real-world legibility at typical phone-holding distances.

Structured data

Structured data (commonly implemented as JSON-LD, per Google’s recommended format) doesn’t change how content reads to a human visitor, but it gives search engines an explicit, machine-readable description of what’s on the page, which can make that page eligible for enhanced “rich result” display in search results. Google’s general structured data guidelines are clear on a few points worth flagging because they’re commonly misunderstood:

• Marking a page up correctly makes it eligible for a rich result; it does not guarantee that rich result will actually appear.
• The structured data must accurately reflect the visible content of the page; marking up content that isn’t actually present or visible to users violates Google’s policies.
• Required and recommended properties vary by markup type, and missing required properties disqualifies a page from that specific rich result entirely.

JavaScript rendering

Sites built with heavy client-side JavaScript frameworks introduce a separate technical layer most static HTML sites don’t have to think about. Per Google’s own JavaScript SEO basics documentation, Googlebot processes JavaScript pages in three phases: crawling, rendering (where a headless version of Chromium actually executes the JavaScript), and indexing, with rendering happening as a separate, resource-constrained step that can lag behind the initial crawl. Sites that rely entirely on client-side rendering for primary content risk delays in getting that content indexed, or in some cases, content that never renders correctly for Googlebot at all. Server-side rendering or pre-rendering reduces that risk by serving fully formed HTML on the first request rather than relying on the crawler to execute scripts correctly.

Measuring technical SEO health

Ongoing technical health is something you monitor, not a box you check once. The core toolkit:

• Search Console, for the Page indexing report, Core Web Vitals report, mobile usability data, and the URL Inspection tool for diagnosing individual pages.
• A crawler (such as Screaming Frog or Lumar) to simulate how a search engine would crawl your site, surfacing broken links, redirect chains, duplicate titles, and missing canonical tags at scale.
• Server log file analysis, to see what Googlebot is actually requesting and how often, which is the most direct way to confirm crawl budget is going to the right pages.
• Periodic technical audits, comparing current crawl/index/performance data against a prior baseline to catch regressions after a site migration, redesign, or CMS change.

One more current-state note worth including here: AI-generated answer surfaces like Google’s AI Overviews pull from the same indexed, technically sound pages that traditional search results draw from. Google’s own documentation states there are no special technical requirements to appear in AI Overviews beyond a page being properly indexed and eligible to show with a snippet in regular search results, which is one more reason getting the indexing fundamentals right still matters as much as it ever did.

Technical SEO isn’t a one-time setup task. Sites change, CMS platforms push updates, JavaScript frameworks get swapped, and Google’s own infrastructure and guidance evolve. Treating crawlability, indexability, Core Web Vitals, and structured data as something to monitor on an ongoing basis, rather than something fixed once during a launch, is what separates sites that stay visible from sites that quietly lose ground without anyone noticing why.