SaaS Technical SEO Guide: Common Issues & How We Fix Them

In the last 10+ years of running Grow and Convert and doing SEO for hundreds of B2B SaaS businesses and startups, the first thing we have done and still do with any new client is run a technical SEO audit as part of building out their SaaS SEO strategy. We run this audit before any new content goes into production, so we can identify and fix issues that might otherwise hold back rankings and pipeline.

Across many of these engagements, we’ve also heard the same story from founders, content marketing teams, and SaaS marketers that their previous SEO agency ran a monthly technical audit and showed them a running list of issues they were fixing or “actively working on.” Most of those issues were real, but the ones that actually impacted the site’s ability to rank for keywords that drive organic traffic, qualified leads, trial signups, demo requests, and pipeline usually required engineering or web development work to fix, which rarely got prioritized.

In our experience, most technical SEO audits mix together two very different types of problems. That’s why when we audit SaaS websites, we separate these issues into two categories: 

• Structural technical SEO: These are decisions made during a site redesign, replatforming, or major launch that can compound for years and are often expensive to reverse. For SaaS companies, it includes decisions such as whether to host the blog on a subdomain or subfolder, whether the marketing site renders server-side or client-side, and how the overall site structure is organized.
• Maintenance technical SEO: These are recurring, smaller fixes that audit tools tend to flag, such as broken links, redirect chains, missing meta descriptions, schema, and other crawl hygiene issues. These issues are real, but they usually don’t compound the same way and can be handled through quarterly audits or basic monitoring.

In this article, we walk you through the technical SEO issues we most often see on SaaS websites, in roughly the order they impact rankings and pipeline.

Issue 1: The Blog Is Hosted on a Subdomain Instead of a Subfolder

Google has publicly said that subdomains and subfolders are treated equally, but across many SaaS SEO engagements, we’ve seen that hosting content in a subfolder consistently outperforms a blog on a subdomain in both organic traffic and rankings.

That’s why we treat subfolder hosting as the default recommendation for any SaaS company starting a blog or planning a migration, and we often recommend migrating existing subdomain blogs back to subfolders when the SEO upside justifies the engineering effort.

We usually see this problem on SaaS websites where the marketing site is built on a custom framework or static site generator, and the engineering team doesn’t want to maintain a CMS as part of the main site. So they just stick a blog running on WordPress, Webflow, or another CMS on a subdomain. But this comes with a serious SEO tradeoff that engineering teams usually don’t consider. 

The problem is that subdomains behave like separate domains, and the backlinks you’ve earned through link building, the brand authority, and the topical relevance built on your main domain don’t carry over cleanly to the subdomain blog, even though both appear to be the same brand to users. As a result, the blog ranks with less authority than it would if it were a subfolder on the root domain.

Our Circuit case study is one of the clearest examples. Circuit had previously moved its blog to a subdomain and saw rankings drop. When they moved the blog back to a subfolder on the root domain, traffic recovered and, within six months, grew from around 920 sessions per month to over 14,577. 

How to Fix?

Host your blog at /blog/ on your root domain.

If your blog is already on a subdomain, plan a migration that includes:

• A reverse proxy or CMS setup that serves the blog from /blog/ on the main domain
• 301 redirects from every existing subdomain URL to its new subfolder URL
• Updated internal links across the marketing site, footer, and product to point to the new URLs
• An updated XML sitemap submitted to Google Search Console

If the content is intended to rank in organic search and contribute to your overall SaaS SEO strategy, content marketing, and link building efforts, it should usually reside on the main domain. 

We also recommend the same principle to other content hubs that often end up on subdomains for engineering convenience, such as help centers, community forums, resource libraries, and changelogs.

Issue 2: The Marketing Site Renders Client-Side Instead of Server-Side

Most SaaS marketing sites are built by the same engineering team that builds the product, on the same JavaScript framework (typically React, Next.js, Vue, or Nuxt). That choice makes sense from a stack-consolidation and engineering-ownership perspective. 

The problem is that when the marketing site renders entirely on the client side, search engines and their crawling algorithms have to work much harder to see your content, which usually results in delayed indexing, partial content rendering, and product pages that struggle to rank for keywords they should easily own.

The technical issue is that search engine crawlers don’t render JavaScript the way browsers do. Google does have a second-pass rendering stage for JavaScript, but it runs on a delay (sometimes days or weeks after the initial crawl), and pages with heavier JavaScript or rendering errors often don’t make it through cleanly. Other search engines, including Bing and the crawlers behind AI search products like ChatGPT and Perplexity, render JavaScript less reliably or not at all. 

We see this most often on SaaS sites built on Nuxt, Angular, or custom React frameworks, where the team has defaulted to client-side rendering for the marketing pages. In these engagements, we typically find that a meaningful portion of web pages are missing from Google’s index, even though every page is internally linked and submitted in the XML sitemap. 

Once the marketing site is switched to a server-rendered or statically generated configuration, indexation usually recovers within weeks.

You can diagnose this on your own site in under a minute. Disable JavaScript in your browser’s developer tools (in Chrome, open DevTools, then use the command menu to search for “Disable JavaScript”) and reload any marketing page. If the main content, headings, or internal links disappear, search engines that don’t fully execute JavaScript are seeing the same empty page.

How to Fix?

For the marketing site, use server-side rendering (SSR) or static site generation (SSG). Both deliver fully rendered HTML to crawlers on the first request, eliminating rendering delays and reliability issues.

If you’re on Next.js, this means using getServerSideProps or getStaticProps (Pages Router) or server components and static export (App Router). On Nuxt, it means running in ssr: true mode rather than SPA mode. For custom React or Vue setups, it means adding a server-rendering layer or migrating to a framework that handles it.

The deeper structural fix is to separate the marketing site stack from the product app stack. The product app can remain a client-rendered SPA since users authenticate before they see it, and SEO doesn’t apply. The marketing site should be its own deployment, ideally on a static site generator or an SSR framework, with content management handled through a CMS that the marketing team can edit without filing engineering tickets.

If switching frameworks isn’t realistic in the near term, the interim fix is dynamic rendering or pre-rendering specifically for crawlers. Services like Prerender.io serve a pre-rendered HTML version to crawlers while serving the SPA to users, which solves the indexation problem without changing the underlying stack. This works as a bridge but isn’t a long-term substitute for proper SSR or SSG optimization.

Issue 3: Thin and Duplicate Pages Don’t Have a Clear Canonical or Noindex Policy

Most SaaS websites accumulate thin pages or duplicate content over time, but many don’t have a consistent canonical or indexation policy for handling them.

We’ve seen login-gated marketing pages appearing in search results, internal search pages getting indexed, and UTM-tagged URLs attracting external links that should have pointed to the canonical version.

Individually, these issues may look minor. Collectively, they create a search profile where the marketing site has far more indexable web pages than it should. This can dilute link authority across near-duplicate pages, waste crawl budget, and make the site appear lower-quality because of its thin and duplicate content footprint.

Over time, this can also lead to indexing and ranking issues, especially on larger SaaS sites with hundreds or thousands of blog posts, feature pages, integration pages, comparison pages, resource pages, and template-based URLs.

How to Fix?

Apply canonical and noindex rules consistently at the template level so that every URL of the same type receives the same treatment automatically.

• Internal search URLs: Add noindex tags at the template level and exclude these URLs from XML sitemaps. Also, verify your robots.txt file isn’t accidentally blocking important sections of the site while handling internal search URLs.
• Filter, sort, and parameter URLs: Add a <link rel=”canonical”> tag pointing back to the clean, unparameterized version of the page. For very heavy filter combinations, consider adding noindex to specific parameter groups.
• UTM-tagged URLs: Make sure UTM parameters canonicalize back to the clean URL. If these URLs are being linked externally, update the source links when possible so authority flows directly to the canonical page.
• Paginated pages: Use a self-referential canonical tag on each paginated URL rather than canonicalizing page 2, page 3, and beyond back to page 1. Keep paginated pages crawlable and indexable so search engines can reach the deeper content linked from them. Avoid blanket noindexing paginated URLs, since that can also prevent crawlers from following links to deeper content. rel=next and rel=prev tags are no longer required for Google, though leaving them in place generally doesn’t hurt.
• Login-gated marketing pages: Add a noindex directive or serve a 401 or 403 status code, depending on whether you want the URL discoverable in any form.

Once these rules are in place, you can audit the indexation report in Google Search Console quarterly. Look for sudden growth in indexed URLs, especially when that growth is not tied to new content production. That usually means a new template, parameter group, or URL pattern is being indexed without the right canonical or noindex rule.

If your indexed URL count is growing faster than your content volume, there’s almost certainly a canonical or noindex policy issue worth investigating.

Issue 4: Pages Don’t Follow a Scalable URL Taxonomy

Most SaaS product sites already have CMS collections for features, integrations, comparison pages, use cases, industries, FAQ pages, and help docs. The issue we often see is that these page types are created in isolation.

For example, different teams produce feature pages, integration pages, comparison pages, or industry pages, and each team organizes its pages around its own campaign or internal workflow.

The site has organized page types, but no consistent structure for how commercial pages relate to one another.

For example, a SaaS company might have:

• A feature page targeting “[feature] software”
• A use case page targeting “[job to be done] software”
• An industry page targeting “[feature] software for [industry]”
• An integration page targeting “[partner] integration”
• A comparison page targeting “[competitor] alternative”

Without a clear taxonomy, these pages often overlap, compete, or remain disconnected from one another. The site ends up with multiple commercial pages targeting adjacent intent, but no clear parent-child structure, internal linking model, or rule for which page should rank for which query type.

This is where URL architecture becomes more than a formatting issue. A strong SaaS URL taxonomy is part of your overall site structure and defines how commercial intent is organized across the site.

When this isn’t defined, several issues show up over time:

• Feature, solution, and industry pages start targeting the same keywords.
• Integration pages sit isolated from relevant feature and use case pages.
• Comparison pages are launched as one-off landing pages rather than as part of a scalable competitor hub.
• Internal linking becomes manual instead of template-driven.
• Breadcrumbs don’t reinforce the commercial hierarchy.
• XML sitemaps group pages by CMS origin rather than by search intent.
• Reporting can’t easily show which commercial page type is driving rankings, qualified traffic, trials, demos, or pipeline in Google Analytics or your internal dashboards.

How to Fix?

Build a commercial URL taxonomy and a clear site structure before scaling new SaaS landing pages. 

This means defining the role of each page type, the query class it should target, the URL pattern it should use, and how it should link to related pages.

A simple taxonomy might look like this:

Page type	Primary search intent	URL pattern
Feature pages	Product capability searches	/features/[feature]/
Use case pages	Job-to-be-done searches	/solutions/[use-case]/
Industry pages	Vertical-specific searches	/industries/[industry]/
Integration pages	Partner and ecosystem searches	/integrations/[partner]/
Comparison pages	Competitor-aware searches	/compare/[your-product]-vs-[competitor]/
Alternative pages	Category-switching searches	/alternatives/[competitor]/

Once the taxonomy is defined, apply it across the site:

• Move existing pages into the correct URL structure when the SEO benefit outweighs the migration risk.
• Add 301 redirects from old URLs to new URLs.
• Update internal links so related features, use cases, industry, integration, and comparison pages reinforce each other.
• Add breadcrumb logic that matches the taxonomy.
• Segment XML sitemaps by commercial page type.
• Track rankings, traffic, conversion rates, and pipeline by page type, not just by individual URL.

For SaaS companies, this matters most once the site has more than a handful of product-led SEO pages. At that point, every new feature, integration, use case, industry, and comparison page either strengthens the site’s commercial search architecture or adds another disconnected URL that has to be manually managed later.

A strong taxonomy lets the site compound and supports a scalable, high-quality content strategy, consistent on-page SEO, and ongoing optimization across the site. Each new page fits into a known structure, links to related pages by default, appears in the right sitemap, inherits the right breadcrumbs, and has a clear role in the broader keyword strategy.

Issue 5: 404s, Redirect Chains, and Broken Internal Links

For SaaS sites that undergo frequent product changes, redesigns, and migrations, this is one of the clearest examples of a maintenance-related technical SEO issue. It may not require daily attention, but it does need regular cleanup.

The most common causes of these issues are when features are renamed, and the old feature pages start returning 404s, when blog posts are deleted but remain in the XML sitemap, or when site migrations leave behind redirect chains where one URL passes through two or three intermediate URLs before reaching the final destination. 

None of these issues is critical or usually breaks the site on its own. But over time, they create technical drag, leading to crawlers wasting time on dead URLs, internal links passing through unnecessary redirects, and users occasionally landing on pages that no longer exist, which hurts user experience and crawl efficiency.

The most common patterns we see are:

• 404s with internal or external links pointing to them: Pages get deleted, but the links pointing to them don’t get updated. If the old URL had backlinks from your link building efforts, rankings, or meaningful internal links, redirect it to the closest relevant live page instead of letting those signals die on a 404.
• Redirect chains: URL A redirects to URL B, which redirects to URL C. The cleaner setup is for URL A to redirect directly to URL C.
• Redirect loops: URL A redirects to URL B, and URL B redirects back to URL A. This makes the page inaccessible to users and crawlers.
• Internal links pointing to redirected URLs: The link technically works, but every click and crawl has to pass through a redirect. 
• 302 redirects used for permanent moves: If a page has permanently moved, use a 301 redirect instead of a 302 so search engines understand that the new URL should replace the old one.
• Soft 404s: These are pages that return a 200 status code but display “not found,” “page no longer exists,” or similarly thin content. The response code says the page exists and functions normally, but the content says otherwise.

How to Fix?

Use Screaming Frog, Ahrefs Site Audit, Semrush, or a similar crawler to identify 404s, redirect chains, redirect loops, soft 404s, and internal links pointing to redirected URLs.

Then clean up each issue based on the URL type:

• For 404s, decide whether to restore the page, redirect it to the closest relevant live equivalent, or leave it as a 404 if the page was intentionally removed and has no meaningful links or traffic.
• For pages that are permanently removed and should not come back, consider using a 410 Gone status code instead of a 404. This gives search engines a clearer signal that the URL has been intentionally removed.
• For redirect chains, update the first redirect to point directly to the final destination URL.
• For redirect loops, fix the redirect rule causing the loop.
• For internal links pointing to redirected URLs, update the source links so they point directly to the final URL.
• For 302 redirects, replace them with 301 redirects when the move is permanent.
• For soft 404s, either improve the page so it serves a real purpose, redirect it to a relevant live page, or return a proper 404 or 410 status code.

After the cleanup, remove dead URLs from XML sitemaps.

For SaaS businesses, especially fast-moving startups that undergo multiple redesigns, migrations, feature launches, and pricing changes, this cleanup should happen right after each change goes live, so issues are caught immediately rather than accumulating into broader crawl and internal linking problems.

Issue 6: Schema Markup Is Missing or Doesn’t Match the Page Type

Schema markup is structured data that tells search engines what type of content is on a page, beyond what they can infer from the HTML alone. For a SaaS company, a well-implemented schema can unlock rich results and rich snippets in the SERPs and feed into Google’s knowledge panel for the brand.

Most SaaS websites have either no schema markup at all or generic schema generated by the theme or website template they use (usually the case on WordPress websites). 

The implementation is inconsistent across page types, and the schema often doesn’t match the page’s actual content.

The most common patterns we see are:

• No schema markup at all. The site has no structured data on any page, which doesn’t break anything but means it misses out on rich results opportunities and provides less context to AI search products.
• Wrong schema type used. A blog post tagged with Product schema, or a feature page tagged with Article schema. The schema technically validates but doesn’t accurately represent the content.
• Required fields missing. Schema types have required and recommended fields. When required fields are missing, the schema may not be eligible for rich results, even when it validates as syntactically correct.
• Product or SoftwareApplication schema added to the homepage to surface star ratings. A common misuse of schema on SaaS sites is adding the Product or SoftwareApplication schema with aggregateRating fields to the homepage, often pulling those ratings from third-party review sites such as G2, Capterra, or TrustRadius. Google’s structured data guidelines explicitly prohibit this. The reviewed item must be the main subject of the page, the ratings must be backed by reviews visible to users on the same page, and the reviews can’t be self-serving. Sites that misuse review markup this way can lose rich result eligibility across the entire site, often without warning.

How to Fix?

Audit the existing schema, then implement appropriate schema types for each page type at the template level so that every page of the same type receives the same treatment automatically.

• Audit: Run the Rich Results Test and Schema Markup Validator on a representative page of each template (homepage, blog post, feature page, integration page, comparison page, pricing page, help doc). Note what schema exists, what’s missing, and what’s flagged with errors.
• Implement at the template level: Add schema to each page template so new pages inherit the correct markup automatically. Don’t add schema page by page.

The most common schema types for SaaS sites are:

• Organization site-wide: company name, logo, social profiles, contact information. Add to every page that describes the organization (homepage, about page, etc.) through a global template.
• Article or BlogPosting on blog posts: author, publish date, modified date, headline, image.
• SoftwareApplication on product or feature pages: name, application category, operating system, offers. Only include aggregateRating if the page itself displays legitimate first-party reviews. Don’t pull ratings from third-party sites like G2 or Capterra or use self-reported numbers.
• HowTo on procedural content like setup guides or tutorials.

For SaaS sites, schema is a low-effort, low-risk investment that complements high-quality content with meaningful upside in search visibility and click-through rates from rich snippets. The goal shouldn’t be to add schema everywhere for its own sake, but to ensure every page type has schema that matches its purpose, and that the markup actually reflects the content visible to users.

Issue 7: Chasing Perfect PageSpeed Scores

Core Web Vitals are rarely the main ranking bottleneck for SaaS websites.

Most modern SaaS sites already use decent hosting, CDN delivery, caching, compressed assets, and frontend frameworks that make pages fast enough to meet basic performance thresholds for site speed and load times. 

Because of that, we rarely see cases where moving a page from a “good” PageSpeed score to a perfect score materially changes rankings. The issue is that teams often focus on the overall PageSpeed score rather than the specific performance problem affecting user experience on the page.

The most common patterns we see are:

• Oversized HTML documents: Googlebot can read large HTTP responses, but that does not mean large HTML documents are good for performance. HTML documents over 2MB often point to bloated templates, inline base64 images, large JSON blobs in the page source, excessive inline CSS or JavaScript, or uncompressed HTML.
• Hero image and web font issues hurting LCP: Largest Contentful Paint is often the hero image or above-the-fold heading on a SaaS marketing page. If the hero image is too large, served in the wrong format, not preloaded, or paired with render-blocking web fonts, the page can feel slow even if the overall score looks acceptable.
• Cumulative Layout Shift from cookie banners, popups, and lazy-loaded content: CLS often comes from elements that load late and push existing content down. Cookie consent banners, popups, embedded widgets, and lazy-loaded images without dimensions are common causes.
• Render-blocking JavaScript and CSS: Scripts and stylesheets that block the initial render delay everything else. This often comes from third-party tags loaded synchronously, large CSS files without critical CSS extraction, and JavaScript that is not deferred or loaded asynchronously.
• INP issues from heavy JavaScript: Heavy JavaScript bundles, third-party scripts, chat widgets, and analytics libraries can make a page feel unresponsive even when LCP and CLS are fine.

How to Fix?

Treat Core Web Vitals as a threshold to pass, not a score to perfect. Start by auditing different page types, not just the homepage.

Then fix the issue based on what the audit shows:

• For oversized HTML documents: Compress HTML with gzip or Brotli, move large JSON blobs out of the initial HTML, replace inline base64 images with proper image URLs, and reduce unnecessary inline CSS and JavaScript.
• For LCP issues: Compress hero images, serve them in WebP or AVIF, set explicit width and height attributes, preload the LCP image, use font-display: swap, and preload critical fonts where needed.
• For CLS issues: Add explicit dimensions or aspect-ratio CSS to images and embeds, reserve space for cookie banners and embedded widgets, and avoid inserting content above existing content after the page loads.
• For INP issues: Break up long JavaScript tasks, reduce unused JavaScript, load third-party scripts with async or defer, audit tracking libraries, and move non-critical JavaScript out of the initial bundle.
• For render-blocking resources: Defer non-critical JavaScript, extract and inline critical CSS, reduce large stylesheet dependencies, and delay non-essential third-party scripts like chat widgets, heatmaps, and marketing tags until after the page is interactive.

For SaaS sites, page speed optimization should be targeted rather than exhaustive. Fix the templates and scripts that create real performance problems on important web pages. Don’t spend weeks chasing a perfect score when the site already passes Core Web Vitals, and the same engineering time could be spent on higher-impact structural SEO efforts.

Issue 8: XML Sitemaps and Robots.txt Don’t Match What Should Be Crawled and Indexed

XML sitemaps and robots.txt files are supposed to help search engines understand which URLs should be discovered, crawled, and indexed.

We often see XML sitemaps that include redirected URLs, 404 pages, noindexed pages, parameter URLs, staging URLs, thin CMS-generated pages, or old blog URLs that should no longer be submitted.

At the same time, robots.txt files sometimes block important sections of the site from being crawled, including blog directories, integration pages, JavaScript assets, CSS files, or documentation pages that should be accessible to search engines.

The most common issues we see are:

• Noindexed URLs in the XML sitemap: These pages are being submitted to Google even though the page itself says not to index them.
• Redirected URLs in the XML sitemap: The sitemap includes old URLs that now redirect elsewhere instead of the final canonical URLs.
• 404 or 410 URLs in the XML sitemap: Deleted pages remain in the sitemap long after they have been removed.
• Parameter or filtered URLs in the XML sitemap: URLs with filters, sorting parameters, tracking parameters, or internal search parameters get submitted even though they are not meant to rank.
• Important pages missing from the XML sitemap: Feature pages, integration pages, comparison pages, or new blog posts are live and internally linked, but not included in the sitemap.
• Robots.txt blocking important content: Blog directories, docs, integration pages, or page assets are blocked from crawling, even though they need to be accessible for proper rendering and indexation.
• Robots.txt used where noindex would be more appropriate: If a page is blocked in robots.txt, Google may not be able to crawl the page and see the noindex directive. For pages that need to be removed from the index, a page-level noindex is usually the cleaner solution.

How to Fix?

Audit your XML sitemap and robots.txt file at least quarterly, and after any redesign, migration, CMS change, or major template launch.

Your XML sitemap should only include URLs that are:

• Canonical
• Indexable
• 200-status
• Important enough to be discovered and crawled
• Not blocked by robots.txt
• Not parameterized or duplicated versions of another page

Remove any URLs that are noindexed, redirected, broken, canonicalized to another URL, blocked by robots.txt, or not meant to rank.

Then review the robots.txt file to ensure it is not blocking important pages or assets. In most cases, SaaS sites should avoid blocking major content sections like /blog/, /features/, /integrations/, /compare/, /solutions/, /docs/, or /help/ unless there is a clear reason. 

While reviewing robots.txt, also confirm the sitemap URL is declared at the bottom of the file (e.g., Sitemap: https://www.yoursite.com/sitemap.xml) so crawlers can find it even when they don’t check Google Search Console.

Also, avoid using robots.txt as your primary indexation control. Robots.txt controls crawling, not indexing. If a page should not appear in search results, use a noindex directive instead, and make sure the page is crawlable long enough for search engines to see that directive.

For SaaS websites, the sitemap should list the URLs you want search engines to crawl and index, and robots.txt should only block areas that genuinely should not be crawled. 

Issue 9: Staging, Preview, or App URLs Are Indexable

For SaaS companies, this issue usually becomes more important as the engineering and marketing stack gets more complex. The more environments, preview systems, CMS collections, and app surfaces the company has, the easier it is for non-production URLs to leak into search.

There may be a production marketing site, a staging site, CMS preview URLs, Vercel or Netlify deployment URLs, a documentation subdomain, a help center, a public product app, partner landing pages, and old campaign pages that were never fully removed. Over time, some of these URLs get discovered and indexed by search engines.

The issue is not just that these pages look messy in Google but that they can create duplicate versions of important marketing pages, expose thin or unfinished content, and make indexation harder to manage.

The most common patterns we see are:

• Staging subdomains indexed in Google: URLs like staging.company.com, dev.company.com, or test.company.com appear in search results.
• Preview deployment URLs indexed: Vercel, Netlify, Webflow, or CMS preview URLs get indexed alongside the production page.
• Duplicate marketing pages on alternate hosts: The same homepage, feature page, or blog post exists on both the production domain and a staging or preview URL.
• Public app URLs showing in search results: Product app URLs, login-gated pages, onboarding screens, or public user-generated pages get indexed even though they are not part of the marketing site’s SEO strategy.
• Old campaign or landing page environments still live: Temporary pages created for launches, ads, partner campaigns, or sales enablement stay accessible long after the campaign ends.
• Sitemaps include non-production URLs: XML sitemaps accidentally include staging, preview, or alternate-domain URLs instead of only canonical production URLs.

How to Fix?

Start by auditing what Google has indexed across your main domain and common subdomains.

Search for indexed URLs across different environments, like:

• site:staging.company.com
• site:dev.company.com
• site:company.vercel.app
• site:company.netlify.app
• site:app.company.com
• site:preview.company.com

Then decide how each environment should be handled.

For staging and preview environments, the cleanest fix is to require authentication so these URLs aren’t publicly crawlable in the first place. If authentication is not possible, add a noindex directive at the template level and make sure the pages are not included in XML sitemaps.

For duplicate production content on preview or deployment URLs, add canonical tags pointing to the production URL, but don’t rely on them alone in staging environments. If the environment should not be public, block access or noindex it.

For app URLs, decide whether the content has search value. Most authenticated app pages should not be indexable. Public app pages, user profiles, dashboards, reports, or shared assets should have a clear indexation policy based on whether they are useful landing pages or thin or duplicate content.

For old campaign pages, either keep them live and indexable if they still serve a purpose, redirect them to the closest relevant page, or noindex or remove them if they are no longer useful.

After cleanup, remove non-production URLs from XML sitemaps, and use the Removals tool only when you need to temporarily hide sensitive or urgently problematic URLs until the permanent fix takes effect.

Improve Your Technical SEO With Grow and Convert

Across hundreds of B2B SaaS engagements, we’ve found that technical SEO lays the foundation for the rest of the work to compound. When the structural decisions are right, every piece of content you publish, every internal link you add, and every keyword you target builds on a stable base. When they’re wrong, the rest of the work fights against a site that isn’t built to rank.

That’s why we treat technical SEO as a finite set of decisions to make well, not an ongoing retainer-level discipline. We make recommendations and fix the structural issues once, and audit the maintenance items quarterly. Then,  we put our time and budget into the work that actually moves the pipeline, like keyword research, content production, internal linking, and external link building tied to keywords that drive trials, demos, and revenue.

For more on the broader SaaS SEO strategy that technical work supports, see our articles on B2B SaaS SEO and Pain Point SEO.

• Our Agency: If you want to hire us to execute a conversion-focused SEO strategy built around driving demo requests, trial signups, and pipeline, not just traffic, you can learn more about working with us here.
• Join Our Team: If you’re a content marketer, writer, or SEO who’d love to do SEO and content marketing in this way, we’d love to have you apply to join our team.
• Our Course and Community: Individuals looking to learn our agency’s SEO and content strategy and become better marketers, consultants, or business owners can join our private course and community, taught via case studies and presented in both written and video formats.