Retire a page without losing its SEO

What a real cull turned up

A repositioning left this site with duplicate pairs competing against each other: two versions of the same about page at different paths, and a case studies page reachable at both a top-level URL and a nested one. Neither pair had a canonical tag — there were none anywhere on the site — so nothing indicated which URL was the real one.

Underneath that was a worse mismatch. The apex domain redirected to the www host, but every machine-readable reference the site emitted — the sitemap, the OpenGraph URLs, the JSON-LD — pointed at the apex. The site was telling crawlers to index one host while sending every visitor to another, and the redirect doing the sending was a temporary one.

Rule one: merge, don't delete

Before a URL is retired, its content has to exist somewhere. That is not a formality — a redirect to a page that does not answer the same question tends to get treated as a soft 404, so you lose the old URL and the new one inherits nothing. The order that works is: port the content properly, check the new page stands on its own, then redirect.

Merging is also the moment to fix what caused the duplication. Duplicate pairs are rarely an accident of routing; they are usually two attempts at the same page written months apart, and the merge is the first time anyone has to decide which one was right.

Rule two: permanent, and wildcarded

Next.js emits a 308 for permanent: true and a 307 otherwise. The difference is the whole point: a temporary redirect tells search engines to keep the original URL in the index, which is precisely what you do not want when the original is never coming back.

async redirects() {
  return [
    { source: "/who", destination: "/why", permanent: true },
    { source: "/about/case-studies", destination: "/case-studies", permanent: true },
    { source: "/about", destination: "/why", permanent: true },
    { source: "/about/:path*", destination: "/why/:path*", permanent: true },
    { source: "/services/brand-maximization", destination: "/services", permanent: true },
    { source: "/how", destination: "/how-it-works", permanent: true },
  ]
},

The fourth rule is the one worth copying. When a whole section moves, redirect the subtree with a wildcard so every child lands on its counterpart — the parent rule above it handles the section root. List children individually and you will miss one, usually the page someone linked to from an email newsletter in 2023.

Rule three: one host, agreed everywhere

Pick apex or www, then make every reference match: the metadata base URL, the canonical tag on every page, the sitemap, the OpenGraph URLs, and the structured data. A host redirect fixes visitors; it does not fix a sitemap that lists the other host, because that sitemap is still asking for the wrong URLs to be crawled.

The choice here was www, deliberately, for cookie scoping: cookies set on an apex domain are shared with every subdomain under it, and there are future subdomains planned. Serving the site from a subdomain of your own keeps that boundary available. Then the host redirect itself has to be permanent — a temporary one leaves both hosts alive in the index, which is the duplicate-content problem you were solving.

export const metadata: Metadata = {
  alternates: { canonical: "/knowledge-base" },
  title: TITLE,
  description: DESCRIPTION,
  // …
}

noindex is a different tool

A page that should exist but is not ready gets noindex, not a redirect. On this site that covered a case studies page whose data was still placeholder — real page, real route, genuinely unfinished — and a form example built for a client's platform, which needs to stay reachable and has no business competing in search.

The useful discipline is to make that state self-clearing where you can, so nobody has to remember to remove it. The knowledge base index noindexes itself only while it has nothing published, and drafts are noindexed by their own status field — both derived from the registry that drives the section, rather than typed into a page and forgotten.

What to check when the redirects are in

Confirm the status codes rather than trusting the config: a request to each old path should return 308 or 301 and land in one hop. Then check that the sitemap contains only live, canonical URLs on the chosen host, that no page canonicalises to a URL that redirects, and that internal links point at destinations rather than at retired paths — your own navigation is the easiest source of an unnecessary hop.

curl -sI https://www.example.com/old-path | head -2
# HTTP/2 308
# location: https://www.example.com/new-path

Then submit the changed URLs rather than waiting to be recrawled — a sitemap ping and an IndexNow submission after the deploy cost nothing and shorten the window where the old shape of the site is still the one on record.

A route cull is usually part of something larger — a repositioning, a rebuild, a migration — and it is worth planning alongside the rest of the site work rather than after it.

Questions