Technical SEO for SaaS

The technical audit you paid for has 140 rows and no order of operations. Image alt text sits next to a rendering failure that hides 300 pages. An engineer opens it, reads four rows, and closes the tab. That is how most SaaS technical SEO dies, not from disagreement but from a list nobody can start.

Rank the work by what it does to revenue and the list gets short. Three or four items normally account for almost all of the available movement, and one of them is almost never page speed.

Rank technical work by revenue impact, not by audit order

A technical fix is worth doing when it changes whether a page that can convert gets found, stored and shown. Everything else is hygiene. Sorted that way, the order for a typical B2B software site looks like this.

Anyone who hands you that list in the opposite order is selling audit hours. The layout of the crawl paths in row five is a separate discipline covered in SaaS site architecture for SEO, and it is worth reading alongside this.

Rendering: what Next.js, Webflow and Framer each do to your HTML

Before anything else, find out what a crawler sees when JavaScript never runs. Open a page, view source, and search the raw HTML for a sentence from the middle of the copy. If it is missing, you have a rendering problem and nothing below matters yet.

Platform	Default output	Common SaaS failure	Fix effort
Next.js App Router	Server components render HTML by default	A 'use client' directive added high in the tree turns a whole section client-only	Low, once someone audits the directives
Next.js Pages Router	Static or server-side depending on the data function	getServerSideProps missing, so the page ships an empty shell	Low to medium
Webflow	Static HTML published at build	CMS collection lists paginated with JS-only controls	Low, mostly configuration
Framer	Static HTML for page content, hydrated components on top	Interactive sections and CMS lists that only populate after hydration	Medium, sometimes needs a template change
React SPA on a CDN	Empty div plus a bundle	Everything, including title and meta description	High, this is a rebuild

The frameworks are rarely at fault. The pattern is that someone adds a client-only component to make a testimonial carousel work, the directive cascades, and the copy underneath disappears from the raw HTML. Nobody notices for five months because the page still looks correct in a browser.

If your marketing site is React-heavy, the rendering question deserves its own treatment, and the deeper version of this section sits in the JavaScript SEO guide.

Indexation bloat is where most SaaS sites actually bleed

Here is the position this guide takes: the average SaaS technical problem is not speed, it is a site that has quietly grown from 400 useful URLs to 9,000 crawlable ones. Google spends its attention on the 8,600 that will never earn a click, and the 400 get recrawled monthly.

The usual sources, in the order they show up:

• Filter and sort parameters on blog, resource and integration listings, each combination generating a URL
• Tag and category archives created automatically by the CMS, often one archive per tag with a single post on it
• Gated resource pages that exist at both a public URL and a post-form thank-you URL
• Staging or preview environments left crawlable, typically on a Vercel or Netlify preview domain
• Paginated hubs with no upper bound, generating empty pages past the last real result
• Print, AMP, or locale variants of pages the company stopped maintaining two years ago

Fixing this is mostly deciding, not engineering. Every URL class gets one of four dispositions: index it, noindex it, block it, or delete and redirect it. Write that decision down per class so the next person does not reverse it.

Search Console’s Page Indexing report is the fastest read, provided you look at the exclusion reasons rather than the headline number. Crawled and currently not indexed almost always means a quality or internal linking problem. Duplicate without user-selected canonical means your templates disagree with each other. Discovered and currently not indexed on a large programmatic set means Google has decided the set is not worth the crawl.

Core Web Vitals at the template level, and the thresholds that matter

Three numbers, each measured at the 75th percentile of real Chrome users over a rolling 28-day window. Largest Contentful Paint under 2.5 seconds. Interaction to Next Paint under 200 milliseconds, which replaced First Input Delay in March 2024. Cumulative Layout Shift under 0.1.

Field data from the Chrome User Experience Report is what counts. Lighthouse gives you a lab score that is useful for diagnosis and useless as a target, which is why teams chase a 98 in Lighthouse while their real users sit at 3.1 seconds on mobile.

Work at the template level or do not bother. A SaaS site typically has six to ten templates, and one LCP fix on the blog post template improves 400 URLs at once. The usual wins:

• Preload the LCP image and stop lazy-loading anything above the fold
• Reserve height for hero images, embedded video and cookie banners to kill layout shift
• Self-host fonts with font-display swap, or cut to system fonts on body copy
• Defer or remove third-party scripts, which on most SaaS sites means the chat widget, the session recorder and four analytics tags
• Serve images in modern formats at the size they actually render

Be realistic about the payoff. Moving a template from 3.4 seconds to 2.3 seconds is worth doing for conversion rate on your paid traffic. Expecting it to move a page from position 14 to position 4 will disappoint you. Google has described these metrics as closer to a tiebreaker than a primary factor, and the ranking evidence matches that.

What the log files say Googlebot actually spends crawl on

Everything above is inference until you read the logs. Server logs are the only record of which URLs Googlebot requested, how often, what status it received and how long the response took. Nothing else answers the question of where your crawl actually goes.

Screaming Frog’s Log File Analyser handles this for a few hundred thousand lines. Past a few million, push the logs into BigQuery and query them, which is how most enterprise teams do it. Either route is documented in the technical SEO crawlers roundup along with what each one costs.

Google’s own guidance says crawl budget management only becomes a concern above roughly a million URLs, or for medium sites with tens of thousands of frequently changing pages. That is true for the budget itself. It is not true for crawl distribution, which goes wrong on sites of any size the moment the internal linking favours the blog over the product.

Structured data and international basics that are worth shipping

Structured data is presentation, not ranking power, and treating it as a ranking lever wastes weeks. Ship the small set that earns something and stop.

Organization schema on the homepage with the legal name, logo and sameAs links to your verified profiles. This feeds knowledge panel and entity resolution, which increasingly matters for whether an answer engine associates a product with a company. SoftwareApplication schema on the product and pricing pages. BreadcrumbList on every template that has a visible breadcrumb. Article schema on blog posts with a genuine author entity, not a byline that resolves nowhere.

Skip FAQPage as a traffic play. Google restricted FAQ rich results to authoritative government and health sites in August 2023, and HowTo rich results were retired around the same period. Both still help machines parse your page, so keep them if they are already in the template, but do not build a project around them.

Internationalisation only pays once you have real localised content. Hreflang on machine-translated pages signals nothing worth having. If you are running locale subfolders, every variant references every other variant plus x-default, and the URLs referenced must be the exact canonical version. One mismatched trailing slash invalidates the whole cluster.

The severity ranked fix list to hand one engineer

This is the artefact worth producing from any audit. One table, sorted by impact, with an honest effort estimate next to each row so a founder can plan a sprint rather than a programme.

Print it, put dates on it, and refuse to start at the bottom. If you want it as a repeatable instrument rather than a one-off, the SaaS technical SEO audit checklist covers the same ground in a form you can run quarterly, and the sprint module on fixing what blocks indexing walks through the first four rows with worked examples.

Where technical SEO stops paying

A clean technical base is a ceiling raiser, not a demand generator. Pages with no search demand, no unique content and no links will not rank because you shortened a redirect chain. That is the honest failure mode, and it is the reason technical projects sometimes produce nothing after six weeks of engineering time.

The second failure mode is scope. Teams treat technical SEO as an infinite backlog and keep an engineer busy on it forever. It is not infinite. For a 400 page SaaS site the genuinely valuable work is roughly four to six weeks once, then two days a quarter of monitoring, plus a real project whenever you migrate or rebrand. Anything more is an agency finding things to bill for.

The third is measurement. Technical changes and content changes ship in the same week, then nobody can say which one moved the number. Stage them apart, or run them as controlled tests the way the SaaS SEO experiments guide sets out, so the next argument about priorities has evidence behind it.

What to do in the next two weeks

Run a crawl with rendering off and rendering on, and compare the URL counts. Pull the Page Indexing report and read the exclusion reasons rather than the totals. Fetch three commercial pages with curl and check the copy is in the raw HTML. Then write the fix list above with real dates against it.

That sequence takes about a day and answers the only question worth asking: can your pages be found and stored at all. For the rest of the programme, the SaaS SEO hub covers where technical sits next to content and links, the migration playbook is what you read before any replatform, and the SaaS SEO ROI calculator will tell you whether four weeks of engineering time is the right place to spend the quarter at your ACV. The tooling to run any of it is compared in the SaaS SEO tools roundup.