How to Set Up Redirects When You Change or Remove a URL

A redirect is a claim. It says: the thing you asked for lives here now. Every bad redirect is that claim being false, and no amount of correct server configuration repairs a false claim.

So before you touch a config file, answer three questions about the old URL.

1. Does the thing that URL was about still exist somewhere on this site?
2. Would a person who clicked the old link recognize the destination as the answer to what they clicked?
3. Is the removal permanent, or does this URL come back?

Question two decides most cases, and it is the one almost nobody asks. If the honest answer is no, you do not have a redirect problem. You have a removed page, and there are better tools for that.

Count the rows. Four of the eight are a 301, and that ratio is already more generous than most sites deserve. If your redirect map is 100 percent 301s pointing at three destinations, it was not built from a decision. It was built from a default.

The status code is the whole message. Everything else is your server's opinion.

The method column matters for APIs and form submissions, not for a page somebody reaches from a results page. That request is a GET either way. For URL changes on a content site, 301 and 308 are interchangeable, and 301 is what nearly every server, CDN and CMS gives you by default. Take the default.

Two other kinds of redirect exist and both are worse. A meta refresh in the page head is read as permanent when it is instant and as temporary when it is delayed, but the engine has to fetch and parse a whole HTML document to find a routing decision a response header could have carried on the first byte. A JavaScript redirect is worse again. Google's redirect documentation is blunt: "Only use JavaScript redirects if you can't do server-side or meta refresh redirects", warning that if rendering fails, "Google might never see it". You would be making a routing instruction depend on a render pass that is queued, deferred and occasionally skipped.

"Always use 301" is advice that is right most of the time and expensive in the cases where it is wrong.

The browser caching row is the one that bites teams. A 301 deployed by mistake keeps firing for returning visitors long after you have reverted the rule, because their browser never asks your server again. A wrong 302 is a config bug you fix in five minutes. A wrong 301 is a config bug plus a support queue.

Genuine 302 cases are narrow but real:

• A split test that routes some visitors to a variant URL. The test ends in three weeks. A 301 there tells the indexing pipeline to treat the variant as the canonical version of the page, which is precisely the outcome you do not want.
• A product that is out of stock and coming back. The URL is not dead. Keep it, keep it indexed, and say on the page when it returns.
• A short campaign URL repointed each quarter. /offer/ is a permanent address whose destination is temporary.
• Language or region routing on a root URL where the regional pages must each stay independently indexable.

Everything else on a normal site is a 301.

Here is the sentence most redirect guides never quote, from Google's site move documentation:

"Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."

Notice where it lives. It is documented under site moves, not under redirects, which is why a guide written from the redirect page alone never mentions it.

The mechanic is simple once you see the redirect as a claim. If the destination does not answer the request the old URL answered, a system evaluating that destination can conclude the content is missing, mark it a soft 404, and drop the old URL anyway. You get every downside of the removal, plus visitors who land somewhere confusing and go straight back to the results page.

Destination quality is a spectrum, not a yes or no:

The two blue widget rows are the useful pair. Same removal, same site, two destinations, and the only difference is whether a person arriving there would feel answered or dumped.

There is a widely repeated claim that a 410 deletes a URL from the index faster than a 404. Check the current documentation before you plan around it. Google's guidance on how status codes affect its crawlers groups them together: "All 4xx errors, except 429, are treated the same", and it states that URLs already indexed that return a 4xx status "are removed from the index". Individual Google representatives have described a marginal difference in the past. The published documentation does not promise one, so do not build a timeline on it.

That leaves the real reasons to use 410, none of which depend on crawler behavior:

• It records intent for your own team. A 404 in a crawl report stays ambiguous forever: deliberate removal, or a broken route somebody needs to fix? A 410 answers that inside the response.
• Other consumers can act on it. Link checkers, feed readers and third party crawlers can treat 410 as final and stop retrying. Many treat 404 as possibly transient, because it often is.
• It stops the page being resurrected by accident. A 404 invites a well meaning teammate to "fix the broken link" six months from now.

Two details people get wrong here.

The body of a 404 or 410 response still matters. Return the status code, and also return a real page: a plain statement that the page is gone, a search box, and links to the two or three closest live pages. A blank error page wastes somebody who was interested enough to click.

Do not serve a helpful page with a 200 status. That is the literal definition of a soft 404: the content says error, the header says success. Search Console flags it, and you have taught your own reporting to lie to you.

If the page needs to stay reachable for people but out of search results, a redirect and a 410 are both wrong. Robots.txt versus noindex covers the tool that is actually right for that job.

This case produces the most bad redirects, because the impression count feels like a reason to act fast. Here is how to work through it properly in Google Search Console.

Step 1. Get the URLs the engine is still serving. Search Console, Performance, then Search results. Set the date range to Last 3 months, open the Pages tab, and export.

Step 2. Get the URLs you actually have. Your XML sitemap is the fastest source, or run a crawl if the sitemap is not trustworthy. Submitting a sitemap and checking indexed pages covers getting that list clean.

Step 3. Subtract. Anything in the Performance export that is missing from your live list is a candidate: a URL the engine still has indexed and still shows to people, whatever your server returns for it today.

Step 4. Read the demand, not the volume. For each candidate, apply a Page filter (URLs containing that path), then switch to the Queries tab. Those queries are the actual reason the URL still surfaces.

Step 5. Decide per URL using the table in the first section.

The rule that saves you here: the decision is driven by whether those queries are still served somewhere on your site, not by the impression count. A removed URL with 4,000 monthly impressions is not an argument for redirecting it to the homepage. It is an argument for asking whether you should have a page for those queries at all.

Every figure below is an illustrative example, not SparkCliks data:

Three different answers came out of one export. A single bulk rule could not have produced any of them.

This is where redirect advice turns into folklore, so it is worth separating what is on the record from what is not.

On the record. Google's crawler documentation describes a 301 as "a strong signal that the redirect target should be processed" and a 302 as "a weak" one. In July 2016, Gary Illyes, then a webmaster trends analyst at Google, stated publicly that 30x redirects do not lose PageRank, and John Mueller indicated at the time that this was already how the systems had been working. That is a public statement from a company representative rather than a line in the documentation, and it is about PageRank specifically.

Not on the record. Any percentage. If you have seen a claim that a 301 passes 85 or 90 or 99 percent of "link equity", none of those numbers came from a search engine. The most cited of them traces back to the damping factor in the original 1998 PageRank paper, which describes something else entirely: the probability that a modeled random surfer keeps clicking rather than jumping to a fresh page. It was never a statement about redirects, and repeating it as one is how a modeling constant became an industry fact.

Also not on the record: that rankings transfer. They do not move as a unit. The destination page is evaluated as itself, on its own content, for each query.

So what can you actually count on from a redirect?

1. People and crawlers requesting the old URL arrive at the new one.
2. A permanent redirect is a strong instruction about which URL should be treated as canonical, stronger than a canonical tag, which the documentation calls a hint. If those two ever disagree on your site, how canonical tags work and fail covers what happens next.
3. Links pointing at the old URL keep resolving. They keep counting as links to your site rather than links to an error.

What you cannot count on is that the destination will rank for the old page's queries, because that depends entirely on the destination.

One practical consequence: keep the redirects. Google's site move documentation says to "Keep the redirects for as long as possible, generally at least 1 year." Teams strip them after a quarter and are then surprised when referral traffic stops. External links, bookmarks, old newsletters and printed materials all outlive a quarter.

Nobody builds a four hop chain on purpose. Chains accumulate. A rename one year, an HTTPS migration the next, a trailing slash rule added by somebody fixing an unrelated problem, and now one old URL takes three hops to reach a live page.

The documented limits are worth knowing exactly. Google's crawler guidance says: "By default, Google's crawlers follow up to 10 redirect hops. However, specific products' crawlers may have different limits." The site move documentation adds the practical version: Googlebot can follow up to 10 hops in a chain, but "we advise redirecting to the final destination directly." Note the per product caveat, because the crawler fetching your images is not necessarily the one fetching your HTML.

Ten hops sounds like room to spare. It is not. Here is what each hop actually costs:

Loops are the failure mode where the chain never terminates. A browser gives up and shows ERR_TOO_MANY_REDIRECTS. Search Console reports Redirect error in the Page indexing report. The usual causes, in rough order of frequency:

• A trailing slash rule and a lowercasing rule each undoing the other's output.
• A CDN and an origin server both enforcing HTTPS, where the CDN terminates TLS so the origin always sees plain HTTP and always redirects.
• A CMS level redirect and a server level redirect for the same path, pointing at each other.
• A redirect whose destination still matches its own source pattern.

The fix for both problems is one discipline. Every redirect points at a final 200 response, never at another redirect. When you change a URL that was already the destination of an older rule, update that older rule rather than adding a new one behind it. That single habit is the difference between a redirect map that stays flat for years and one that grows a hop every quarter.

Google's site move guidance is explicit that you should "Change the internal links on the new site from the old URLs to the new URLs." That instruction gets skipped constantly, because the redirect makes everything look fine.

Redirects exist for links you do not control: other people's sites, old emails, social posts, bookmarks. Your own navigation is not that.

Leaning on redirects internally causes four specific problems:

• Every internal link pointing at a redirect makes a visitor pay a hop on a click you fully control. You built both ends of that link.
• It hides your site's real state. Your crawl comes back clean because everything resolves eventually, and "eventually" is doing a lot of work in that sentence.
• It compounds. Internal links are the raw material chains get built from.
• Navigation and footer links repeat on every page, so one stale nav link means a wasted hop reachable from every page you have.

Finding them takes about ten minutes. Crawl your own site with any crawler that reports response codes, filter for 3xx, then use the inlinks view to list which pages link to each redirecting URL. While you are in there, check four more places that quietly point at old URLs:

Then leave the redirects in place anyway. Fixing your internal links does not retire the rule, because you do not control the external half. Both jobs are real, and only one of them is optional to do this week. For where all of this fits in the wider maintenance picture, what technical SEO covers walks the full pipeline.

Four pairs exist on every site whether you have thought about them or not. In each one you pick a winner and redirect the other.

The correctness point behind all four: /pricing and /pricing/ are different URLs. A server is entirely free to serve different content at each, so a search engine has to treat them as distinct until something tells it otherwise. Serve identical content at both with a 200 status and you have manufactured a duplicate, and the choice of which one to index gets made by a canonicalization process instead of by you. The one exception is the root, where https://www.sparkcliks.com and https://www.sparkcliks.com/ are the same URL and the slash is implied.

Now the part that creates chains on otherwise well run sites. Combine these into one rule that produces the final URL in a single hop. A request for http://www.sparkcliks.com/Pricing should land on https://www.sparkcliks.com/pricing/ with one redirect, not four stacked ones firing in sequence.

Ordering matters too. Canonicalization rules run first and produce a normalized URL. Path level redirects run after, against that normalized form. Get the order backwards and every path redirect you write gets a canonicalization redirect appended to it automatically, turning your whole redirect map into two hop chains without a single mistake in any individual rule.

Whichever you pick, your internal links, your sitemap, your canonical tags and your redirect rules all have to agree, and that agreement is worth testing rather than assuming. The usual failure is a site that normalizes one way across most of itself and the other way in a section built later by different people, so the same link pattern is correct in the main navigation and costs a hop in the blog. Run the curl check in the next section against a marketing page and a blog post before you assume the two behave identically.

Two tools answering two different questions. curl tells you what your server does. Search Console tells you what the engine made of it. Use both, always.

Start with the full chain:

curl -sIL "https://www.sparkcliks.com/old-page"

-s silences the progress meter, -I requests headers only, -L follows redirects. You get one header block per hop. Read the status line and the Location header of each.

For a one line summary:

curl -sIL -o /dev/null \
  -w "%{num_redirects} hops, final %{http_code} at %{url_effective}\n" \
  "https://www.sparkcliks.com/old-page"

Now the gotcha that costs people an afternoon. -I sends a HEAD request, and some servers, CDNs and edge functions handle HEAD differently from GET. A redirect can look perfect on HEAD and behave differently for an actual visitor. Confirm with a real GET that dumps the headers and throws the body away:

curl -sL -D - -o /dev/null "https://www.sparkcliks.com/old-page"

The query string row catches a common silent failure: plenty of redirect rules drop everything after the ?, which quietly destroys the campaign tracking parameters on every redirected link you have ever put in an email. The last two rows catch the other one. A rule written as a prefix match for /pricing happily swallows /pricing-guide/ as well, and nobody notices until that page's traffic disappears.

Then check what the engine made of it:

• URL Inspection on the old URL. You want Page with redirect and the correct target. This confirms the engine has processed the redirect, which is a different fact from the redirect existing.
• Page indexing report. Page with redirect is an expected, healthy status for a retired URL. It is not an error and it needs no fixing. Redirect error is the one to act on: chain too long, a loop, an empty Location, or a URL that exceeded a length limit.
• Performance report. The old URL keeps appearing for a while after the change. Watch for the destination picking up those queries rather than for the old URL vanishing on a schedule you invented.
• Removals tool. It hides a URL from results for roughly six months. It is a bandage for something urgent and embarrassing while the real fix propagates. It removes nothing from the index and it expires.

Run the curl checks against a sample of ten old URLs, not one. Redirect rules are pattern matches, and a pattern that works on the URL you tested is not evidence about the ninety you did not.