404 Page SEO for SaaS: How to Handle Broken Links Without Losing Rankings

A B2B SaaS company in Pune migrated their marketing site from WordPress to Webflow in 2024. The migration was clean — no downtime, design looked great. But nine months later, their organic traffic had dropped 34%.

The cause: 47 blog posts and 12 landing pages had been moved to new URLs during migration. The old URLs were returning 404s. Dozens of backlinks — earned over two years — were now pointing to dead pages. Google had deindexed most of them. Link equity that had taken years to build: gone.

They were shocked that no one had caught this. The site "worked" — it loaded, it looked good. But the SEO damage was happening silently in the background.

404 errors are one of the most underestimated technical SEO issues on SaaS sites. This guide covers how to find them, how to fix them, and how to prevent them from happening in the first place.

What Is a 404 Error and Does It Actually Hurt SEO?

A 404 (Not Found) status code is returned by a server when a requested URL doesn't exist. The page is missing — either it was deleted, moved without a redirect, or was never created at all.

The direct SEO impact depends on context:

Google has said that 404 errors on pages with no inbound links don't hurt rankings. That's technically true. But SaaS sites frequently have 404s on pages that do have backlinks (from product review sites, directories, guest posts, press mentions) — and those are genuinely damaging.

The Three Root Causes of SaaS 404 Errors

1. Site migrations without redirect mapping

The most common cause — and the most damaging. When a SaaS company moves from WordPress to Webflow (or Webflow to Next.js, or any CMS to another), URL structures almost always change. Old blog slugs like /blog/2023/04/saas-seo-tips become /blog/saas-seo-tips. Without 301 redirects from old to new, every existing backlink and internal link becomes a 404.

2. Deleted or restructured content

SaaS sites frequently delete or consolidate pages: old feature pages after a rebrand, blog posts that became outdated, pricing tiers that were discontinued, case studies removed for confidentiality reasons. Each deletion is a potential 404 — especially if the page had backlinks or was referenced in external directories.

3. URL parameter drift and case sensitivity

UTM parameters, trailing slashes, uppercase/lowercase inconsistencies, and encoded characters in URLs all generate 404 variants. /Blog/Saas-SEO/ and /blog/saas-seo may return different responses depending on your server configuration. Users and crawlers accessing capitalized or parameter-appended URLs that don't exactly match your canonical URL pattern hit 404s.

How to Find 404 Errors on Your SaaS Site

Method 1: Google Search Console (Coverage report)

The free and most authoritative source. In Search Console: Index → Pages → filter by "Not found (404)." This shows every URL Google has crawled that returned a 404, plus the pages that link to it (under "Referring pages" for each URL). Prioritize any 404 that has referring pages — those are your backlink-equity-loss situations.

Method 2: Screaming Frog crawl

Screaming Frog crawls your site and finds all 404 responses from internal links. Free up to 500 URLs. Under Response Codes → Client Error (4xx). Export to CSV and sort by inlinks count — more inlinks = higher priority to fix.

Method 3: Ahrefs or Semrush broken backlinks report

If you have access to Ahrefs or Semrush, their "Broken Backlinks" reports show external links pointing to 404 pages on your site. This is the most critical report for link equity preservation. Sorted by referring domain count — fix the 404s with the most referring domains first.

Method 4: Server access logs

Your hosting provider (Vercel, Netlify, AWS) has access logs showing every request and response code. Filter for 404s to see which URLs are being hit most frequently — including by real users, not just crawlers. This catches 404s that Googlebot hasn't discovered yet but users are already hitting.

How to Fix 404 Errors: The Decision Tree

When you find a 404 page, the fix depends on context:

If the content moved to a new URL → 301 redirect

Set up a 301 permanent redirect from the old URL to the new URL. This passes link equity to the new location and tells Google the move is permanent. Google will update its index to use the new URL and transfer ranking signals within weeks.

If the content was deleted and a closely related page exists → 301 to best match

If you deleted a blog post about "SaaS email marketing," redirect it to your most relevant surviving content — maybe your email marketing category page or a related post. This recovers the backlink equity to somewhere useful rather than letting it disappear into a 404.

If the content was deleted and no relevant page exists → 301 to homepage or parent section

For pages with significant backlinks and no close match on your site, redirect to the homepage or the relevant section homepage (e.g., /blog/ for a deleted blog post). A homepage redirect is better than leaving a 404. It's not ideal — some SEOs argue against redirecting irrelevant content to the homepage — but for pages with link equity, a homepage redirect is almost always better than a 404.

If the page had no backlinks and isn't linked internally → leave as 404

Not every 404 needs fixing. Orphaned URLs with no inbound links and no traffic can stay as 404s. Don't create redirect chains for pages that genuinely don't matter. Focus effort on pages with backlinks or significant internal link equity.

Implementing 301 Redirects by Platform

Next.js App Router

Add redirects to next.config.js (or next.config.ts). Each redirect object includes source, destination, and permanent flag.

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Single redirect
      {
        source: '/blog/old-post-slug',
        destination: '/blog/new-post-slug',
        permanent: true, // true = 301, false = 302
      },
      // Wildcard redirect (old blog structure to new)
      {
        source: '/blog/:year/:month/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Redirect entire old section
      {
        source: '/resources/:path*',
        destination: '/blog/:path*',
        permanent: true,
      },
    ]
  },
}

For large redirect lists (50+ redirects), store them in a JSON file and import them into next.config.js dynamically to keep the config readable:

// redirects.json
[
  { "source": "/old-url", "destination": "/new-url", "permanent": true },
  ...
]

// next.config.js
const redirects = require('./redirects.json')
module.exports = {
  async redirects() {
    return redirects
  },
}

Vercel (vercel.json)

If you're deploying on Vercel and can't use Next.js config (e.g., a static site), use vercel.json redirects:

{
  "redirects": [
    {
      "source": "/old-page",
      "destination": "/new-page",
      "permanent": true
    },
    {
      "source": "/blog/:slug*",
      "destination": "/resources/:slug*",
      "permanent": true
    }
  ]
}

Webflow

Webflow has a built-in redirect manager under Site Settings → SEO → 301 Redirects. Add old URL → new URL pairs. Webflow handles the 301 automatically. Limitation: Webflow doesn't support wildcard or regex redirects — each redirect must be added individually. For large migration redirects (100+ URLs), this is manual work.

Pitfall: Webflow's redirect editor is case-sensitive. /Blog/Post and /blog/post are treated as different source URLs. Add both variants if your old URLs had uppercase characters.

WordPress

Use the Redirection plugin (free) or Rank Math's redirect manager (Pro). Both have bulk import via CSV — paste a list of old URL → new URL pairs and import. For server-level control (faster than plugin-level), use Apache .htaccess or Nginx config directives.

# Apache .htaccess — single redirect
Redirect 301 /old-page/ https://yourdomain.com/new-page/

# Apache .htaccess — wildcard
RedirectMatch 301 ^/old-section/(.*)$ /new-section/$1

The Soft 404 Problem: When Google Thinks Your Page Is Missing

A soft 404 is a page that returns a 200 OK HTTP status code but displays a "page not found" message — or thin, irrelevant content. Google's crawler sees a 200 response but detects the page is essentially empty or not useful, and treats it as a 404.

Common soft 404 scenarios on SaaS sites:

• Custom 404 pages returning 200: You built a nice 404 page but forgot to set the HTTP status to 404. Google sees 200 OK and tries to index it as a real page — a page with the title "Page Not Found" and no useful content.
• Empty search results pages: /search?q=nothing returns 200 with no results. Google sees a 200 page with minimal content.
• Expired CMS content: Blog posts that return 200 but show "This post has been removed" copy with no other content.
• Placeholder pages: Pages created before content was written, returning 200 with "Coming soon" text.

To check: use Google Search Console → Inspect any URL. If a "page not found" page shows as "URL is on Google," you have a soft 404. Fix: ensure your 404 page returns a true 404 HTTP status code.

Setting the correct 404 status in Next.js

// app/not-found.tsx (App Router)
// This file automatically returns 404 status — no extra config needed

export default function NotFound() {
  return (
    <div>
      <h1>Page Not Found</h1>
      <p>The page you're looking for doesn't exist.</p>
      <a href="/">Go home</a>
    </div>
  )
}

// pages/404.tsx (Pages Router)
// Next.js automatically returns 404 status for this file
export default function Custom404() {
  return <div>404 - Page Not Found</div>
}

Building a 404 Page That Recovers Traffic

Most SaaS 404 pages are either (a) the default server error page, or (b) a branded "oops" page that leads to a dead end. Both lose the user. A well-designed 404 page can recover 20–30% of users who would otherwise leave.

What a good SaaS 404 page should include:

1. Clear, human message

Explain what happened without technical jargon. "This page has moved or doesn't exist" is better than "404 Not Found." Acknowledge the user's frustration briefly and redirect their attention to finding what they need.

2. Search bar

The most effective 404 recovery element. A user who reached a dead URL was looking for something — give them a way to search for it immediately. If you're on Next.js, a simple search input that passes the query to your blog search or Google site search is enough.

3. Navigation links to important pages

Include links to your highest-value pages: homepage, pricing, blog index, demo/contact. Someone landing on a 404 from a backlink may be a qualified prospect — don't lose them because there's nowhere to go.

4. Popular or recent content

Showing 3–5 recent blog posts or popular resources on the 404 page gives users a reason to stay and explore. It's a low-effort way to turn a dead-end into a discovery moment.

5. Contact or support option

For SaaS sites with existing users, a link to support or a note that they can contact you if they expected to find something specific is a good trust signal. Users who bookmark a product feature page and return six months later to find it 404'd are often existing customers — don't abandon them.

What NOT to include

• The URL that 404'd in the page title — don't encourage Google to index the 404 page as unique content
• The 404 page in your XML sitemap
• Redirect loops (a 404 page that redirects to itself)
• Pop-ups or interstitials — users are already frustrated

404s and Crawl Budget

For smaller SaaS sites (under 500 pages), crawl budget is rarely the limiting factor. But for SaaS sites with large blogs, help centers, or documentation (1,000+ pages), a high volume of 404s in your internal link graph wastes Googlebot's crawl budget on dead-end requests.

Every time Googlebot crawls an internal link that returns 404, it spends crawl budget on a response that yields no indexable content. Multiply this across dozens of broken internal links and you have a material reduction in how many of your real pages Google crawls per day.

The fix: run a regular crawl audit (Screaming Frog or similar) and fix broken internal links — either by updating the link to the correct URL or removing the link. Don't just add a redirect if the link itself can be updated at source.

Redirect Chains and Redirect Loops: Two Things to Avoid

Redirect chains

A redirect chain is when URL A redirects to URL B, which redirects to URL C. Each hop in the chain adds latency, loses a small amount of link equity, and increases the chance of a loop. Google follows redirect chains, but the final destination receives slightly less equity than if the original URL redirected directly there.

Best practice: when adding a new redirect, check if the destination URL is itself a redirect — and if so, update the new redirect to point directly to the final destination. No chain should be longer than one hop.

# BAD — 3-hop chain
/old-url-1 → /old-url-2 → /old-url-3 → /new-url

# GOOD — direct redirect
/old-url-1 → /new-url
/old-url-2 → /new-url
/old-url-3 → /new-url

Redirect loops

A redirect loop is when URL A redirects to URL B, which redirects back to URL A. Browsers show an error ("too many redirects"). Google simply stops crawling. These are usually caused by misconfigured rewrites in Next.js, Nginx, or Vercel configs where a rule intended to redirect HTTP to HTTPS accidentally catches HTTPS URLs too.

To detect: use curl with verbose output to follow redirects:

curl -L -I https://yourdomain.com/old-url

# Look for:
# HTTP/2 301  → first redirect
# HTTP/2 301  → second redirect (should be the final destination)
# HTTP/2 200  → correct — arrived at destination
# If you see 301 repeating more than twice, you have a chain or loop

The 404 Monitoring Workflow

One audit isn't enough — 404s appear continuously as content gets updated, URLs get changed by developers, and external sites link to pages that no longer exist. Set up ongoing monitoring:

Weekly: Check Google Search Console Coverage report

Search Console → Pages → "Not found (404)." Sort by "Discovered" date to see new 404s that appeared this week. Any page with referring URLs listed should be fixed within days.

Monthly: Crawl with Screaming Frog

Full site crawl to catch broken internal links. Export Client Error (4xx) tab and compare to last month. Any new 404s from internal links should be updated at source (fix the link) or redirected.

After any deployment: Spot-check key URLs

Any time you deploy a site update, run a quick check on your 10 most important URLs (homepage, pricing, top 5 blog posts, key feature pages). A misconfigured rewrite rule or new redirect can break previously working pages.

#!/bin/bash
# Simple URL health check — add to your deployment script
URLS=(
  "https://yourdomain.com"
  "https://yourdomain.com/pricing"
  "https://yourdomain.com/blog/"
  "https://yourdomain.com/blog/your-top-post"
)

for url in "${URLS[@]}"; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  echo "$status $url"
done

301 vs 302: When to Use Each

For 99% of SaaS SEO use cases, you want 301. The only reason to use 302 is if the page will genuinely return to its original URL within days or weeks. If you've been using 302 where you meant 301, update them — each 302 on a moved page is leaking link equity.

SaaS-Specific 404 Patterns to Watch

Dashboard and app URLs getting crawled

App subdomain URLs (app.yoursaas.com/dashboard/user/123) sometimes get scraped by external sites and linked to. When users change, these URLs 404. Make sure your robots.txt disallows the app subdomain from crawling — and configure your Next.js/app to return 404 (not 200) for unauthenticated routes.

Product update pages and changelog entries

SaaS companies often link to changelog entries and product update posts from email campaigns, external blog posts, and press releases. These accumulate backlinks. When the changelog URL structure changes (common during rebrands), those pages become high-priority 404s.

Integrations and partner pages

SaaS integration pages (/integrations/zapier, /integrations/slack) are frequently linked to from partner directories and integration marketplaces. When these pages get restructured, the directory links become 404s. Monitor these specifically — they're high-authority external links.