# 301 Redirects on a SaaS Site: When and How to Use Them

> Set up 301 redirects when you merge pages, rename features, or rebrand your SaaS site. Step-by-step setup for common stacks and how to verify the redirect worked.

Source: https://comppound.com/blog/301-redirects-on-a-saas-site-when-and-how-to-use-them (published 2026-10-30)

Say you run a [B2B SaaS](/blog/what-is-programmatic-seo-a-b2b-saas-guide-to-scaling-organic-traffic) company with a blog and a handful of product pages. You decide to rename your "Enterprise Plan" page to "Custom Pricing" because sales kept getting questions about the old name. Anyone who clicks an old link lands on a 404 page, and every link you earned points nowhere. A 301 redirect sends both visitors and search engines permanently from the old URL to the new one, so that traffic and any SEO value attached to the old address moves to the new address instead of disappearing.

The redirect only makes sense when the old page is gone for good. If you are temporarily taking a page down for maintenance, use a 302 redirect instead, because it tells search engines the page will come back. For a rebrand where the entire domain is changing, you redirect every page on the old domain to its matching page on the new domain, not only the homepage. A redirect chain, where page A sends visitors to page B and page B sends them to page C, slows the trip and can make search engines drop the chain, so always point the old URL directly at its final destination.

Here is how to decide where the old page should go. Choose the new page if it covers the same topic and serves the same buyer. Merge several old pages into one new page only when the topics truly overlap and the new page answers the questions both old pages answered. If there is no matching page on your site, do not redirect to the homepage as a catch-all. Send visitors to a relevant category page or let the old URL return a 404 with a helpful error page that links to your most useful content.

AI answers change what happens after the redirect. Search engines and AI crawlers both follow redirects, but AI systems may keep the old URL in their index longer than a search engine does. An AI answer generated six months after your redirect might still quote the old page if it was cited widely before the move. Treat the redirect as the technical half of the job. The other half is updating internal links, sitemaps, and any external placements you control so the new URL appears wherever the old one used to be.

Set up the redirect based on how your site is built. On WordPress, most SEO plugins let you enter the old URL and the new URL in a redirects screen, then save. On Webflow, you add redirect rules in the project settings under hosting. On Shopify, you create URL redirects in the online store navigation settings. On a custom stack, your developer adds the rule to the server config or application code. If your site runs on Apache and you can edit server files, you add a line to the .htaccess file that maps the old path to the full new URL, including the domain. Comppound builds redirect mapping into the production system for each account so the rule is documented instead of living in one person's head.

After the redirect is live, check it before you assume it works. Open the old URL in an incognito window and watch the address bar change to the new URL. Use your browser's developer tools to look at the network tab and confirm the server returns a 301 status code, not a 302 or a 200 with a meta refresh. Run a site crawl to find any pages still linking to the old URL and update those links to the new one. Check Google Search Console to see whether the old URL has dropped from the index and the new URL has taken its place. If the old URL still appears in search results weeks later, resubmit the new URL for indexing and check that no internal page still links to the old address.

The mistake that costs the most time is redirecting everything to the homepage. Visitors arrive expecting pricing and land on your product overview, so they leave. Search engines treat mass homepage redirects as soft 404s and may stop passing value to the new page. Another common error is forgetting to update the sitemap. Search engines keep requesting old URLs listed in the sitemap, which wastes [crawl budget](/blog/crawl-budget-does-a-saas-site-need-to-care) and delays discovery of the new page. Remove the old URL from the sitemap and add the new one at the same time you create the redirect.

A redirect is a fix, not a strategy. It preserves what you already had when a page moves or disappears. It does not create new rankings or fix thin content on the destination page. Before you redirect, make sure the new page is worth sending traffic to: it should answer the visitor's question, load quickly, and match the intent behind the old URL. If the destination page is weaker than the old one, improve it first, then redirect.

**Managing redirects on modern stacks**
If you’re running a Jamstack site built with **Next.js** and deployed on Vercel, redirects live in a `vercel.json` file. Add an entry like:

```json
{
  "redirects": [
    {
      "source": "/enterprise-plan",
      "destination": "/custom-pricing",
      "permanent": true
    }
  ]
}
```

After committing the change, Vercel rebuilds the site and the 301 is served from the edge network. The same pattern works for Netlify (`_redirects` file) and for Gatsby (`gatsby-node.js` with `createRedirect`). The key is that the rule is part of source control, so the mapping survives personnel changes and can be audited alongside code reviews.

For **headless CMS‑backed sites** (e.g., Contentful + Next.js), the redirect is still defined in the hosting layer, but you often need a dynamic lookup because URLs are stored as content entries. A common approach is to create a “URL mapping” content type that contains `oldSlug` and `newSlug`. Your server‑side middleware reads this table and issues a 301 when a request matches an `oldSlug`. This keeps the mapping editable for marketers without touching code.

**Auditing redirects before launch**
A quick manual test is useful, but a systematic audit catches hidden dependencies. Use a crawling tool (e.g., Screaming Frog, Sitebulb, or an open‑source crawler like `wget --spider`) to:

1. **Export all existing URLs** from your sitemap or from a full site crawl.
2. **Apply the redirect list** to the list of URLs to simulate the final destination.
3. **Flag any URL that ends up on a 404, a non‑HTML file, or a different domain**.

If the simulated destination is a 404, you’ve either mistyped the target or the new page isn’t published yet. Fix the mapping before the change goes live to avoid losing link equity.

**Updating AI‑specific signals**
AI‑driven answer platforms (e.g., Google’s AI snippets) pull content from structured data as well as raw HTML. After a redirect, you should:

* **Refresh JSON‑LD schema** on the new page to reference the same identifiers (e.g., `productID`) that the old page used. This helps AI models associate the new URL with the same entity.
* **Republish any “FAQPage” schema** that included questions from the old page. If the FAQ is moved, copy the `@id` values to the new page so AI can continue to surface the same answers.
* **Monitor the “Rich results” report** in Search Console for any dip in “FAQ” or “How‑to” impressions, indicating that the AI pipeline hasn’t caught up with the redirect.

**Ongoing health checks**
Redirects can degrade over time if other teams add new links that bypass the rule. Schedule a **monthly audit** with these steps:

1. **Run a site crawl that includes the old URLs**. Capture any 301 responses that still exist.
2. **Cross‑reference the crawl** against your master redirect list. Any stray 301s that point to the homepage or a generic page should be investigated.
3. **Check the “Redirect Errors” report** in Google Search Console. Google flags redirect chains longer than two hops or loops that could harm crawl efficiency.
4. **Validate the HTTP status** of the final destination using a HEAD request (`curl -I https://example.com/custom-pricing`). The response should be `200 OK`; a `4xx` or `5xx` indicates a broken destination that needs fixing.

If you discover a chain (e.g., `/enterprise-plan` → `/pricing` → `/custom-pricing`), collapse it to a single rule. Chains add latency for both users and crawlers and can cause search engines to drop the link equity after a few hops.

**Expanded pitfalls and remedies**
* **Redirect loops** – Occasionally a new page is also set to redirect back to the old slug, creating an infinite loop. The loop is detected by most browsers as “[too many redirects](/blog/too-many-redirects-on-a-saas-site-how-to-fix-the-error).” Prevent this by reviewing any existing redirects before adding a new one and by naming your URL parameters consistently (avoid using query strings that trigger automatic redirects).
* **Canonical tag mismatch** – If the new page retains a ``, crawlers may still attribute value to the old address. Update the canonical tag to point to the new page or remove it if the page is the canonical version.
* **Mixed protocol redirects** – Redirecting from `http://` to `https://` is essential, but doing it in two separate steps (first `http://old` → `http://new`, then `http://new` → `https://new`) creates a chain. Combine them into a single rule that goes directly to the secure final URL.
* **External backlinks ignored** – Some high‑authority backlinks still point to the old page. Use a tool like Ahrefs or Majestic to export the backlink list, then reach out to site owners asking them to update the link. While the 301 preserves value, a direct link is cleaner for AI citations that surface the new URL.

**Documentation and hand‑off**
Because redirects are easy to forget, treat each rule as a ticket in your product backlog. Record:

* **Old URL** – Full path including protocol.
* **New URL** – Destination after the redirect.
* **Reason** – E.g., “Rebrand of Enterprise Plan to Custom Pricing.”
* **Owner** – Person responsible for verifying the migration.
* **Date implemented** – Helps track when the rule should be reviewed for relevance.

Storing this information in a shared spreadsheet or in your issue tracker (Jira, Asana, etc.) ensures that any future engineer can see why the rule exists and can retire it when the old URL is no longer required for inbound links or historical analytics.

[See how we do it](/services/seo-growth)

## Frequently asked questions

### Does a 301 redirect pass SEO value to the new page?

A 301 redirect is a permanent redirect, and search engines generally treat the new URL as the replacement for the old one. Signals such as links pointing to the old page can transfer to the new page, though the new page still needs to match what visitors were looking for. There is no fixed timeline for when search engines complete that transfer.

### Can I redirect multiple old pages to one new page?

Yes, but only when the old pages cover the same topic and the new page answers the questions all of them answered. Redirecting unrelated pages to a single destination confuses visitors and can look like a soft 404 to search engines. If the topics do not overlap, keep the old URLs separate or let them return a 404 with a helpful error page.

### How do I check that a 301 redirect is working?

Open the old URL in an incognito browser window and confirm the address bar changes to the new URL. Check the browser's developer tools network tab to verify the server returns a 301 status code. Then run a site crawl to find internal links still pointing to the old URL and update them to the new one.

## About Comppound

Comppound runs SEO and AI search for B2B SaaS companies: a person sets the plan and reviews samples and every high-risk page, and AI speeds up production.

- [Check a page free](https://comppound.com/tools/seo-checker): Check one of your pages before you change anything else
- [See pricing](https://comppound.com/pricing): Want the content written, reviewed and published for you?