SEO for SaaS is a different purchase from local or ecommerce search work, and the differences are technical as well as commercial. The product is usually a JavaScript application, the marketing site often shares its stack, the buying cycle runs through a free trial rather than a checkout, and the queries that matter are frequently problem-shaped rather than product-shaped. That combination breaks the standard playbook in specific and predictable ways. This page sets out what an agency has to get right for a software product, what Google's documentation says about rendering and content quality, and which questions expose a plan that was written for a different kind of business.
The rendering problem, and why it is first
Google describes processing JavaScript in three stages: crawling, where Googlebot fetches URLs and checks robots.txt; rendering, where a headless Chromium executes the JavaScript on queued pages; and indexing of the rendered result. Its documentation notes that Googlebot queues pages for both crawling and rendering and that it is not immediately obvious when a page is waiting for which. The recurring failures it names are exactly the ones single-page applications produce: fragment-based routing where Googlebot cannot reliably resolve the URLs, soft 404s where meaningful HTTP status codes are impractical, and canonical URLs rewritten by JavaScript to something other than the one you specified. Google recommends the History API for client-side routing, meaningful status codes, and server-side rendering or pre-rendering, noting it makes a site faster for users and crawlers alike. If an agency does not raise this in the first meeting, it has not looked at your stack.
Query strategy for a product nobody is searching for yet
Most software categories have a small number of high-intent product queries and a very large number of problem queries where the buyer does not yet know a tool exists. A plan built only on the former is competing with every funded competitor for a few thousand searches; a plan built only on the latter fills the site with traffic that never trials. The workable shape is a spine of category and comparison pages that convert, supported by problem and job-to-be-done content that earns the audience, with internal links that connect the two. Ask an agency to show which queries it expects to win in each group, what page type serves each, and what it expects each group to do to trials rather than to sessions. Google's hiring guidance suggests asking what results a provider expects and in what timeframe, and how it measures success; for SaaS that answer should be expressed in signups, not impressions.
Content quality when the writer is not an operator
Google's guidance on helpful content defines people-first content as content created primarily for people and not to manipulate search rankings, and says its systems identify a mix of factors indicating experience, expertise, authoritativeness and trustworthiness, of which trust is the most important. It suggests being clear about who created the content, sharing details about the processes involved including any role automation played, and being able to answer why the content exists beyond ranking. For a software product this is a staffing question as much as an editorial one. An agency writing about a technical workflow it has never performed produces text that ranks briefly and converts poorly. The workable arrangement is usually an agency editor working from interviews with your engineers, support tickets and sales calls, with a named author who actually knows the subject.
Migrations, launches and the mistake that costs a quarter
SaaS marketing sites get rebuilt often, and a rebuild that changes URLs is a site move. Google recommends server-side permanent redirects from old URLs to new, prefers 301 or 308 where technically possible, and asks that updated sitemaps be submitted in Search Console so it learns about the new URLs. It warns that for medium-sized sites it can take a few weeks or more before the new URLs are shown instead of the old ones, and longer for larger sites. The failures it names are avoidable: noindex or robots.txt blocks left over from development, redirects pointing at URLs that do not exist, and sitemaps that were never updated. Before you approve a redesign, ask who owns the redirect map, who checks it after launch, and what the rollback plan is.
Questions people ask about seo for saas
Does a JavaScript app hurt SEO?
Not inherently, but it adds a rendering step. Google crawls, then renders with a headless Chromium, then indexes, and its documentation names fragment routing, soft 404s and JavaScript-rewritten canonicals as common failures. Server-side rendering or pre-rendering removes most of the risk.
Should a SaaS agency write the content or should we?
Usually both. Google's helpful content guidance stresses being clear about who created content and why, with trust the most important signal. An agency editor working from interviews with your own engineers and support team produces better material than either side alone.
How should SaaS SEO be measured?
By trials or qualified signups per page group, with impressions and indexed coverage as leading indicators. Google's hiring guidance tells buyers to ask what results are expected, in what timeframe, and how success is measured; get that in writing before the first invoice.
What happens to rankings when we redesign the site?
If URLs change it is a site move. Google recommends server-side permanent redirects, prefers 301 or 308, and asks for an updated sitemap in Search Console. It notes medium-sized sites can take a few weeks or more to settle, so plan the redirect map before the build, not after.