Most technical SEO checklists were written for publishers and online stores. A SaaS website has problems those checklists never mention: a logged-in application sharing a domain with the marketing site, documentation on a third-party platform, a blog on a subdomain nobody chose deliberately, JavaScript frameworks rendering pages the crawler cannot see, and thousands of parameterised URLs generated by the app. The result is a familiar pattern in SaaS audits: good content, decent links, and pages that quietly fail to rank because of structural decisions made years ago by engineers who were not thinking about search.
This guide covers the technical SEO issues that are specific to, or disproportionately common in, SaaS websites, and how to fix them without a replatform.
Site Architecture: App, Marketing, Docs and Blog
The first question in any SaaS technical audit is where things live.
Keep the marketing site and blog on the root domain
Google has said it can treat subdomains and subfolders similarly, but in practice a blog at blog.yourproduct.com is often evaluated with a degree of separation from yourproduct.com, and links earned by the blog do less for the product pages. If your blog is on a subdomain for historical reasons, moving it to yourproduct.com/blog/ with proper redirects is usually one of the highest-value technical projects a SaaS marketing team can run. Plan the redirect map carefully and expect a short period of volatility.
Put the application on a subdomain and keep it out of the index
app.yourproduct.com should be blocked from indexing. The usual leaks are login pages, password-reset pages, shared report URLs and public-facing dashboards appearing in search. Use a noindex header or meta tag on anything behind or around authentication, and check Search Console’s page indexing report for app URLs that have slipped through.
Decide deliberately about documentation
Help centres and developer docs often rank for valuable long-tail queries (“how to [do task] in [category tool]”) and attract links from tutorials. If your docs live on a vendor subdomain, that value accrues partly to the subdomain. A subfolder is better for SEO; a subdomain is often unavoidable with third-party doc tools. If you must use a subdomain, make sure it is crawlable, internally linked from the main site, and not blocked by the vendor’s default robots settings.
Check for accidental duplicate properties
Staging sites, regional clones, old marketing sites and “www” versus non-“www” versions are frequently left indexable. Each one dilutes signals and can outrank the page you intended. Staging should be behind authentication, not just a noindex tag that gets removed on deploy.
Crawlability and Indexing
Robots.txt: block the app, not the assets
A common mistake is a robots.txt that blocks the JavaScript and CSS directories needed to render the marketing pages, or one that blocks the entire site from a template left over from launch. Confirm that /app/, /api/ and internal search results are disallowed, and that the marketing pages and their assets are not.
Parameter and faceted URLs
Template galleries, integration directories and changelogs often generate URLs with sort, filter and pagination parameters. Each combination is a separate URL to Google. Decide which versions should be indexable, canonicalise the rest, and keep parameterised URLs out of the sitemap.
Rendering
If the marketing site is built on a JavaScript framework, confirm that the content Google sees matches what users see. Use the URL inspection tool in Search Console to view the rendered HTML. Common failures: pricing tables loaded after an API call, feature content behind tabs that never renders, and internal links generated by click handlers rather than real anchor tags. Server-side rendering or static generation for marketing pages removes most of this risk.
XML sitemap
The sitemap should contain only canonical, indexable, 200-status URLs for the marketing site, blog and (if on the same domain) docs. It should not contain app URLs, redirected URLs, parameter variants or pages marked noindex. Regenerate it as part of the deploy process rather than by hand.
Canonicals and Duplicate Content
SaaS sites create duplicates in predictable places:
- Trailing-slash and case variants of the same URL that both return 200.
- Pricing pages with currency or billing-period parameters.
- Integration pages generated from a template with near-identical copy. These need genuinely distinct content, not just a swapped partner name.
- Localised pages without
hreflang, or with hreflang pointing at redirected URLs. - Syndicated blog content republished on Medium or partner sites without a canonical back to the original.
Every indexable page should have a self-referencing canonical, and every variant should point at the canonical version. Audit this with a crawl rather than by inspection; the problems are rarely visible from the page itself.
Performance and Core Web Vitals
SaaS marketing sites are heavy: product demos, embedded videos, chat widgets, analytics, A/B testing scripts, session recording, and the framework itself. Each one is justified individually; together they produce slow pages and layout shift.
Practical priorities:
- Measure with real-user data in Search Console’s Core Web Vitals report and PageSpeed Insights rather than lab scores alone.
- Defer or lazy-load third-party scripts that are not needed for the first screen, and remove the ones nobody can justify.
- Set explicit dimensions on images and embeds to prevent layout shift, especially for hero demos and screenshots.
- Serve images in modern formats and at the size they are displayed.
- Watch for interaction delay caused by heavy JavaScript on pages with calculators or configurators.
Page experience is one input among many, and a fast page with weak content will not outrank a slower page with better content. But on competitive commercial queries where content quality is similar, it is a factor you control entirely.
Internal Linking for SaaS Sites
SaaS sites tend to have a strong navigation for product pages and almost no contextual linking between content and commercial pages. The blog accumulates links from outreach and PR, and little of that authority reaches the category, feature or comparison pages that convert.
Fixes that work:
- Link from every relevant article to the commercial page it supports, in the body text, with descriptive anchors.
- Build hub pages around each core topic so that articles, docs and product pages reinforce each other. Our guides to internal linking strategy and topic clusters cover the structure.
- Make sure comparison and alternatives pages are reachable from the main navigation or a footer, not only from each other. See our guide to SaaS comparison pages.
- Check for orphaned integration and template pages generated programmatically but linked from nowhere.
Structured Data for SaaS
Structured data will not make a page rank, but it helps search engines understand what the page is and can enable richer results. For SaaS the useful types are Organization (with logo and social profiles) on the homepage, SoftwareApplication on product pages where appropriate, Article or BlogPosting on content, FAQPage where you genuinely have FAQs, and BreadcrumbList throughout. Validate with Google’s Rich Results Test, and do not mark up content that is not visible on the page.
Monitoring: What Breaks After Every Release
SaaS companies ship constantly, and marketing sites are often deployed from the same pipelines. Technical SEO regressions arrive with releases: a noindex left on from staging, a redirect rule dropped, a canonical template broken by a component change, a sitemap that stopped regenerating.
A lightweight monitoring routine:
- Automated checks after each deploy for robots.txt, sitemap validity, canonical presence and noindex on key templates.
- A weekly review of Search Console’s page indexing report for new “excluded” reasons.
- A monthly crawl of the marketing site compared against the previous one.
- A quarterly full audit using a process like our SEO audit roadmap.
A SaaS Technical SEO Checklist
| Area | Check |
|---|---|
| Architecture | Blog and marketing on the root domain; app on a noindexed subdomain; docs crawlable and internally linked; no indexable staging or duplicate properties |
| Crawling | Robots.txt blocks app and API paths only; parameter URLs canonicalised; rendered HTML matches visible content |
| Indexing | Sitemap contains only canonical 200 URLs; no app or login pages in the index; noindex used deliberately |
| Duplicates | Self-referencing canonicals; one URL per page; distinct copy on templated pages; correct hreflang |
| Performance | Third-party scripts justified and deferred; image dimensions set; real-user Core Web Vitals passing on key templates |
| Internal links | Articles link to commercial pages; hubs for core topics; no orphaned programmatic pages |
| Structured data | Organization, Article/BlogPosting, Breadcrumb and relevant product markup validated |
| Monitoring | Post-deploy checks; weekly indexing review; monthly crawl comparison |
FAQs
Should a SaaS blog be on a subdomain or a subfolder?
A subfolder on the main domain is the safer choice for SEO, because the authority the blog earns supports the product pages directly. Subdomains are reasonable for the application, status page and sometimes documentation, where separation is a technical necessity.
Does it hurt rankings if app pages get indexed?
Indexed login, reset and dashboard URLs waste crawl attention, can expose information you did not intend to publish, and occasionally outrank the marketing page for branded queries. They should be noindexed and, where possible, kept behind authentication.
How often should a SaaS site be technically audited?
A full audit each quarter is a sensible default for a site that deploys frequently, with lightweight automated checks after each release and a weekly glance at Search Console’s indexing report in between.
Conclusion
Technical SEO for SaaS is mostly about boundaries: keeping the application out of the index, keeping the marketing content fully crawlable, and making sure the authority earned by content reaches the pages that sell. Fix the architecture, automate the checks that catch regressions, and the rest of your SEO work stops leaking. If you suspect structural issues are holding your product pages back, Ranking Frontier’s SaaS SEO services start with exactly this kind of audit, and our guide to SEO auditing services explains what a thorough review should cover.
