Technical SEO for a SaaS Product: Core Web Vitals, Crawlability, and Rendering Strategy

This Is Not AI Search Optimization

It's worth being explicit about scope before anything else, since the two topics sound similar and get conflated constantly: this guide covers technical SEO for traditional search engines — Google and Bing crawling, rendering, and ranking a real web page — not the separate, newer discipline of optimizing content to be cited by AI answer engines like ChatGPT or Perplexity. Those are genuinely different disciplines with different mechanics, even though both get called “SEO” casually. This guide is entirely about the former: the real, official, documented mechanics of how Google actually measures page performance, crawls a site, and decides what to index, sourced directly to Google's own Search Central and web.dev documentation rather than SEO-industry folklore.

This connects to one existing guide worth naming directly: our guide on choosing a tech stack covers the general decision framework for picking languages and frameworks; this guide covers a specific, real consequence of one part of that decision — rendering strategy — that has direct, measurable SEO implications most teams don't weigh explicitly when making that choice.

The Three Core Web Vitals and Real Thresholds

These exact thresholds come directly from Google's own “Web Vitals” documentation on web.dev, last updated October 31, 2024 (web.dev, “Web Vitals”): LCP is “good” at 2.5 seconds or less, “needs improvement” between 2.5 and 4 seconds, and “poor” above 4 seconds; INP is “good” at 200 milliseconds or less, “needs improvement” between 200 and 500 milliseconds, and “poor” above 500 milliseconds; CLS is “good” at 0.1 or less, “needs improvement” between 0.1 and 0.25, and “poor” above 0.25. Google's own methodology page explains these thresholds were derived from analyzing real, aggregate field data across many sites to identify values correlating with a genuinely good user experience, not arbitrary round numbers (web.dev, “How the Core Web Vitals metrics thresholds were defined”).

INP replaced FID as the official responsiveness metric

It's worth being precise about a real, dated change in this specific metric set, since a meaningful amount of SEO content still references the old metric: Interaction to Next Paint officially replaced First Input Delay as the third Core Web Vital on March 12, 2024, a transition Google announced in May 2023 and formally completed on that date (Google Search Central Blog, “Introducing INP to Core Web Vitals,” May 2023; web.dev Blog, “Interaction to Next Paint becomes a Core Web Vital on March 12”). The practical reason for the change: FID only measured the delay before a browser could begin processing a user's first interaction, while INP measures responsiveness across a page's entire lifespan, capturing a more complete and representative picture of how sluggish or responsive a page actually feels to a real user interacting with it repeatedly, not just once.

Are Core Web Vitals Actually a Ranking Factor?

It's worth being honest about the limits of this guide's own sourcing here: while Google's general position — that content relevance dominates and page experience acts as a secondary, tiebreaking signal — is well-established and consistently reflected across Google's own published page-experience materials, this research could not independently verify one single, specific, verbatim, dated quote from a named Google spokesperson stating this exact framing in those exact words. Rather than present a paraphrase as a direct quotation, this guide states Google's position based on its own documented framing rather than attributing invented exact wording to any specific named individual.

The practical takeaway for a founder worth taking from this nuance directly: optimizing Core Web Vitals is real, worthwhile engineering work with a genuine (if secondary) SEO benefit, but it is not a substitute for having genuinely relevant, well-written content that actually answers what a searcher is looking for. A team that spends significant engineering effort chasing perfect Core Web Vitals scores while neglecting content quality and relevance is very likely optimizing the smaller lever at the expense of the larger one — per Google's own stated framing, not this guide's independent opinion.

A Real Case Study: Rakuten 24

This case study is directly published and hosted by Google itself on web.dev, last updated August 24, 2022 (web.dev, “Rakuten 24”), and reports a genuinely comprehensive set of results from the same controlled test: alongside the +53.37% revenue-per-visitor gain and +33.13% conversion-rate improvement, the optimized page also produced a +15.20% increase in average order value, a +9.99% increase in time on site, and a -35.12% reduction in exit rate. It's worth being precise about what a single case study can and can't establish: this is one real, specific, well-documented result from one company's specific product and audience, not proof that every Core Web Vitals optimization produces comparable gains for every product. What it does establish, credibly and directly from Google's own published materials, is that page-performance improvements can produce real, measured, substantial business impact well beyond a marginal ranking benefit — the direct effect on user behavior and conversion is often the more immediately compelling reason to invest in this work, independent of any SEO ranking benefit at all.

It's worth being direct that Google's web.dev case-studies index references several other named companies (including Nykaa and Nikkei Style) with reported Core Web Vitals results, but this guide could only directly verify the Rakuten 24 figures above through its own research — the other cases are not cited here with specific numbers, since this guide holds itself to only presenting figures it has independently confirmed rather than repeating secondhand summaries of case studies it hasn't verified directly.

Crawlability Fundamentals

The Robots Exclusion Protocol has a real, traceable history worth knowing precisely: originally created informally by Martijn Koster in 1994, it existed for nearly three decades without a formal internet standard, until Google—which open-sourced its own robots.txt parser in 2019 as part of a standardization push—co-authored what became RFC 9309, published by the IETF in September 2022 (RFC 9309, “Robots Exclusion Protocol”). XML sitemaps have a similarly real, dated joint history: Google introduced its own Sitemaps protocol in June 2005, and on November 16, 2006, Google, Yahoo, and Microsoft jointly announced shared support for Sitemaps 0.90 through the neutral sitemaps.org initiative (Google Search Central Blog, November 2006), meaning a single sitemap file submitted once could inform multiple search engines rather than requiring separate, engine-specific submissions.

Google's own documentation on canonical URLs is worth reading directly for a detail many teams miss: Google describes redirects and the rel=“canonical” tag as “strong” signals for identifying a preferred URL among duplicates, while sitemap inclusion is explicitly called only a “weak” signal for the same purpose (Google Search Central, “Consolidate duplicate URLs”). Google's documentation also states directly that its systems cluster near-duplicate pages together and algorithmically select what it considers the best canonical URL for that cluster — meaning Google can, in some documented cases, choose a different canonical URL than the one a site explicitly specifies, treating a site's own rel=“canonical” declaration as a strong signal rather than an absolute, binding instruction.

Google's own sitemap documentation also specifies real, concrete technical limits worth knowing before a sitemap silently fails: a single sitemap file is capped at 50,000 URLs and 50MB uncompressed, and a site exceeding that must split its URLs across multiple sitemap files referenced by a single sitemap index file rather than submitting one oversized file Google's systems may simply refuse to fully process (Google Search Central, “Build and submit a sitemap”). Most SaaS marketing sites and documentation sections never approach this limit, but it is a real, exact number worth knowing precisely rather than approximating, since a team that later adds a large user-generated or programmatically-generated section (a public template gallery, a directory of integrations, per-customer public pages) can cross it without realizing a sitemap needs restructuring until pages inexplicably stop appearing in Search Console's coverage reports.

Crawl budget: a real concept, mostly irrelevant at small scale

A related concept worth naming honestly, since it circulates widely in SEO discussion but gets misapplied constantly: crawl budget, the finite amount of crawling attention Google allocates to a given site. Google's own documentation on the subject is direct about who this actually matters for: sites with a very large number of URLs (Google's own guidance specifically discusses this in the context of sites with millions of pages) or sites that generate new pages very rapidly. For a typical early-stage SaaS product with a marketing site, a handful of product pages, and perhaps a documentation section, crawl budget as a constraint essentially doesn't apply — Google's crawling capacity for a site this size is not remotely close to being the limiting factor in whether pages get indexed. The practical lesson worth taking from this directly: a small team spending real engineering time worrying about crawl budget optimization is very likely solving a problem it doesn't actually have yet, at the expense of more consequential work like the Core Web Vitals and content-quality factors covered elsewhere in this guide. Crawl budget becomes a genuine, real concern specifically once a site's URL count grows into the tens or hundreds of thousands, a scale most products reading this guide haven't reached.

Rendering Strategy: How Googlebot Actually Works

This is Google's own official, documented description of the process, worth reading directly rather than inferring from general SEO folklore (Google Search Central, “Understand JavaScript SEO Basics”). The real process Google describes runs in three stages: crawl (Googlebot fetches the raw HTML), render (the Web Rendering Service executes JavaScript to produce the fully rendered page, a step that is queued separately from crawling and can be delayed), and index (the fully rendered content is analyzed and added to Google's index). Google's own documentation names a specific, concrete technical limitation worth knowing directly: the Web Rendering Service does not persist local storage, session storage, or cookies across separate page loads, which means any content that depends on that browser-side state to render correctly may simply not appear to Googlebot at all, regardless of how well it renders for a real user in a real browser session.

SSR, SSG, and CSR: the practical SEO tradeoff

Bringing Google's own documented rendering process together into a practical framework for choosing a rendering strategy, connecting directly to the broader stack-choice framework our choosing a tech stack guide covers: server-side rendering (SSR) and static-site generation (SSG) both deliver fully-formed HTML to Googlebot on the very first crawl, removing any dependency on the separate, potentially delayed render step Google's own documentation describes. Client-side rendering (CSR), where a mostly-empty HTML shell is sent and JavaScript builds the actual page content in the browser, works with modern Googlebot per Google's own stated capability — but still depends on that separate render queue actually completing successfully and promptly, and remains more exposed to the specific local-storage and session-storage limitation Google documents directly.

The practical guidance worth taking from Google's own documentation, rather than a general SEO-industry preference: a CSR-only architecture is not automatically un-indexable the way older, pre-2019 SEO advice sometimes suggests, since Google's rendering capability genuinely improved and became continuously current starting that year. It does introduce a genuine, documented dependency on a separate processing step that SSR and SSG simply don't have, along with a specific, named technical limitation around persisted browser state. For a product where SEO-driven organic discovery genuinely matters — a marketing site, a content-heavy product, documentation pages — this is a real, concrete reason to weight SSR or SSG more heavily in the stack decision, distinct from any other performance or developer-experience factors that decision already involves.

Redirects and URL Structure

This distinction matters in practice more than most teams realize, because it's a common, real-world mistake to use a temporary redirect for what is actually a permanent change — often simply because a 302 is the default status code many frameworks and CDNs apply unless a team explicitly configures otherwise. Per Google's own documented framing, a genuinely permanent URL change (a rebrand, a real information-architecture restructure, a permanent domain migration) should use a permanent redirect specifically so Google actually transfers its accumulated ranking signal to the new URL, rather than continuing to treat the old URL as the canonical one indefinitely. The practical discipline worth building into any URL restructuring work: explicitly choose and verify the redirect type being served, rather than accepting whatever a specific tool or platform defaults to, since that default frequently doesn't match the actual, intended permanence of the change being made.

Measuring Core Web Vitals: Real, Official Google Tools

The distinction between lab data and field data is worth understanding precisely, since it's a frequent source of confusion: lab data comes from a single, simulated, controlled test run under standardized network and device conditions, which makes it reliably reproducible for debugging a specific change but doesn't reflect the actual variety of real devices, network conditions, and geographic locations real users experience. Field data, by contrast, is aggregated from real Chrome users who actually visited the page, which is exactly the dataset Google's own stated Core Web Vitals thresholds are measured against — meaning a page that scores well in a Lighthouse lab test but poorly in Search Console's field-data report is a genuinely real, common discrepancy worth investigating directly, not a tooling bug. A team relying only on lab data from local development testing, without ever checking real field data via Search Console or PageSpeed Insights, can reasonably believe a page performs well while Google's own actual measurement of real users says otherwise.

HTTPS as a Real Ranking Signal

This is a genuinely unusual case in SEO where Google made a direct, unambiguous, dated statement rather than the usual pattern of vague or withheld ranking guidance (Google Search Central Blog (formerly Webmaster Central Blog), “HTTPS as a ranking signal,” August 2014). Google's own announcement described the signal as carrying “light” weight at the time, affecting “fewer than 1% of global queries,” while also stating the company's explicit intent to strengthen the signal over time as the industry migrated to HTTPS more broadly. For a SaaS product built and deployed today, this history is largely academic in one sense and directly relevant in another: virtually every modern hosting platform, including Vercel, provisions HTTPS by default, so actually implementing the signal requires no deliberate engineering work most teams wouldn't already be doing anyway. What remains directly relevant is verifying there are no mixed-content issues (HTTP resources loaded from an otherwise-HTTPS page), broken certificate chains, or inconsistent redirect behavior between HTTP and HTTPS versions of the same URL — each a real, checkable technical detail that can silently undermine a signal a team otherwise assumes is handled.

It is worth being precise about what this signal is not: Google's own 2014 announcement never claimed HTTPS alone would meaningfully move a page's ranking on its own, and no subsequent official Google statement has retracted the original “light” framing to claim HTTPS has since become a heavy or dominant ranking factor. The practical reason it still belongs in a technical SEO checklist is less about the ranking signal itself and more about a second, better-documented consequence: Google Chrome marks non-HTTPS pages as “Not Secure” directly in the address bar, a real, user-visible trust signal that affects click-through and conversion independent of any ranking impact at all — similar in spirit to the structured-data appearance benefit covered below, where the underlying ranking position matters less than how the result actually presents to a real visitor deciding whether to click or trust the page.

Structured Data and Rich Results

Google's own guidance on this is worth reading directly (Google Search Central, “Intro to How Structured Data Markup Works”): Google explicitly recommends JSON-LD as the preferred format for implementing structured data, and provides its own Rich Results Test tool specifically so a team can directly verify whether a given page qualifies for enhanced search appearance before relying on it. It's worth being precise about Schema.org's own history: the initiative is widely corroborated across secondary sources as having launched on June 2, 2011 as a joint effort among the major search engines, though this guide could not independently confirm that exact date directly against Schema.org's own about page in this research pass — the founding-companies detail and general 2011 timeframe are well-corroborated, but the precise date should be confirmed directly against schema.org before being treated as a hard fact in a context where that level of precision matters.

The practical reason structured data matters beyond a technical checkbox: rich results occupy more visual space in a search results page and often include information (ratings, prices, availability, step-by-step instructions) a plain blue-link listing can't show, which can meaningfully affect whether a searcher clicks a specific result versus a competing one with an identical, unenhanced listing. Implementing structured data correctly doesn't change a page's underlying ranking position, per Google's own framing of it as an appearance enhancement rather than a ranking signal — but a more visually prominent, information-rich listing at the same ranking position can still produce a real, measurable difference in click-through rate.

Mobile-First Indexing

Google's own Search Central blog post confirming completion, titled “Mobile-first indexing has landed,” documents the real, multi-year timeline directly: announced in November 2016, beginning actual rollout in March 2018, reaching a majority of indexed sites by December 2018, becoming the default for newly created sites from July 2019 onward, and finally reaching full completion across all sites by October 2023 (Google Search Central Blog, “Mobile-first indexing has landed,” October 2023). The practical implication for a founder building a product today, well after this transition completed: there is no longer a meaningful distinction to plan around between a “desktop-first” and “mobile-first” indexing strategy — the mobile version of a page is, per Google's own completed transition, the version that actually determines indexing and ranking, which means a mobile-unfriendly page isn't just a poor user experience for mobile visitors, it's the literal version of the page Google is evaluating for every visitor's search results, mobile or desktop.

Soft 404s and International Targeting

Google's own Search Central documentation on HTTP status codes and their meaning to Google Search is direct about why this specific mismatch matters (Google Search Central, “HTTP status codes, network, and DNS errors”): Google's crawler decides whether to keep, drop, or flag a URL largely based on the actual status code returned, not on visually inspecting whether the rendered page looks like an error page to a human. A soft 404 — a page returning 200 while showing empty search results, a generic “page not found” message, or a broken product listing — sends Google a signal that directly contradicts what a real user or a real crawler would conclude by reading the page's own content, which is exactly the kind of inconsistency Google's own documentation names as a real, common technical SEO defect worth actively auditing for, particularly on SaaS products with dynamically generated pages (search results, deleted user-generated content, expired listings) where a soft 404 can accumulate silently across thousands of URLs without ever triggering an obvious visible error anywhere in the product itself.

A related, genuinely real internationalization mechanism worth naming for any SaaS product serving multiple languages or regions: Google's own documentation on international and multilingual sites describes the hreflang attribute as the mechanism for telling Google which URL to serve to users based on their language or region, preventing the wrong-language version of a page from being shown in search results or from being treated as duplicate content competing against a same-language equivalent (Google Search Central, “Tell Google about localized versions of your page”). For a product without a genuine multi-language or multi-region audience, this mechanism is simply not relevant yet, in the same way crawl budget optimization above is not relevant at small scale — but for a SaaS product that does maintain separate localized marketing or documentation pages, Google's own documentation states directly that omitting hreflang correctly can cause the wrong regional page to rank for a given searcher, or cause otherwise-legitimate localized pages to be treated as unwanted duplicates of one another rather than distinct, intentional variants.

301 chains and their real, documented cost

One further detail worth naming precisely, since it accumulates invisibly over a product's lifetime of URL changes: Google's own documentation on redirects recommends avoiding long redirect chains — a URL that permanently redirects to a second URL that itself permanently redirects to a third — because each additional hop adds real latency to the crawl and, per Google's own general guidance on the topic, makes it less certain how cleanly ranking signal actually consolidates onto the final destination URL. A single redirect is a normal, well-handled part of any evolving site's history; a chain of three or four accumulated over successive rebrands, URL-structure changes, or migrations is the kind of technical debt that is trivial to introduce one redirect at a time and only becomes visible in aggregate once a team actually audits its own redirect map end to end, which is worth doing periodically rather than assuming each individual redirect, added correctly in isolation, adds up to a clean result.

What This Guide Could Not Verify

Consistent with the standing rule across this series, it's worth naming directly several categories of claim that circulate widely in SEO content but that this guide's research could not confirm to a standard it's comfortable presenting as fact:

1. 1

   A specific verbatim quote from a named Google spokesperson on ranking-factor weight

   Google's general position (content relevance dominates, Core Web Vitals act as a secondary tiebreaker) is well-documented across its own materials, but this guide could not confirm one specific, dated, verbatim quotation from a named individual stating this in those exact words.

2. 2

   Generic "every 100ms of delay costs X% conversion" statistics

   Figures commonly attributed to Amazon or Google circulate widely without a traceable, verifiable original source — this guide relies on the directly verified Rakuten 24 case study above instead of an unsourced generic multiplier.

3. 3

   Specific figures for other web.dev-referenced case studies beyond Rakuten 24

   Google's own web.dev case-studies index references other named companies with reported results, but this guide only independently verified the Rakuten 24 figures directly — other cases are not cited with specific numbers here.

4. 4

   Schema.org's exact founding date confirmed on its own about page

   June 2, 2011 is well-corroborated across secondary sources as the founding date, but this guide could not directly confirm that exact date against schema.org's own current about page in this research pass.

A Practical Framework

Bringing the research above together into an actual sequence for a team addressing technical SEO for the first time:

None of this requires a dedicated SEO specialist to implement at a small scale — every source cited throughout this guide is a real, official, freely available piece of Google or IETF documentation, not paid or specialized tooling. What it requires is treating technical SEO as a real engineering discipline with checkable, official standards behind it, the same way the rest of this series treats every other engineering decision, rather than as a vague, folklore-driven set of best practices passed around without a traceable, verifiable source.

Frequently Asked Questions

Every real source in this guide traces back to Google's own official documentation or a genuine internet standard — not SEO-industry blog consensus repeated without attribution. A founder who reads Google's own Core Web Vitals thresholds, its own JavaScript SEO documentation, and its own canonical-URL guidance directly is working from the same source material Google's own search engineers publish and maintain, which is a meaningfully more reliable foundation than the secondhand, often-outdated SEO advice that circulates well after the underlying Google documentation it was based on has already changed.