Bridge SEO

Redirects for SEO: which code, and when to use each

6 min readUpdated Aug 2026
A redirect is a response telling the client that what it asked for lives somewhere else. Which status code you send is not cosmetic: it states whether the move is permanent, whether the client may reuse the answer, and whether it should repeat its request the same way. Those three things decide almost everything that follows.

What a redirect actually is

/old-page 301 /new-page 200 served one hop: the address changes, the page still arrives

A response, not a rule. The server answers with a status code in the redirection class and a header naming the new location, and the client decides what to do with that.

The semantics of each code are defined in RFC 9110, which is the useful place to start because it is stable. Search engine behaviour built on top of those semantics is not stable, changes without notice, and is documented separately by each engine. Keeping the two apart in your head is worth the effort: the protocol tells you what a code means, and an engine's documentation tells you what that engine currently does about it.

The two questions behind every code

Choosing a code is not a matter of memorising a list. Two questions settle it.

  • Is this permanent?

    A permanent redirect says the old address is finished and the new one replaces it. A temporary one says the original address is still the right one and something about right now is different. The distinction matters because clients are permitted to remember a permanent answer, and because search engines treat the two differently when deciding which address to show.

  • Must the request method survive?

    Older codes were specified loosely enough that clients commonly changed a form submission into a plain retrieval when following them. Newer codes exist specifically to remove that ambiguity, preserving whatever the original request was. If the redirect can be reached by anything other than an ordinary page load, this question is not academic.

Two answers, four codes: 301 and 308 when the move is permanent, 302 and 307 when it is not, and of each pair the newer code, 307 or 308, is the one specified to preserve the request method; the pair has a page of its own. The choice is usually obvious once the questions are asked in that order.

What redirects cost

Every redirect is a round trip that produces no content, and that cost is paid by the visitor.

A single one is negligible. A chain, where the first address points to a second which points to a third, multiplies it, and chains form without anybody deciding to make one: a rule added years ago, a canonicalisation rule added since, and a marketing address added last month can compose into three hops that nobody designed.

Chains also degrade differently from other faults. Clients follow a limited number of hops before giving up, and different clients give up at different points, so a chain that grows past somebody's limit fails for them and works for everybody else. Loops are the same fault taken further and fail for everyone.

The rule that avoids both is to point at the final destination rather than at the next step. Where a chain already exists, collapsing it is usually a matter of editing the first rule rather than removing the later ones.

Where redirects are configured

The same redirect can come from several places, and knowing which one issued it is most of the diagnosis.

A web server can issue it from its own configuration. An application can issue it in code. A content system can issue it from a database somebody edits through an interface. A layer in front of your server can issue it before the request ever arrives. In many sites, more than one of these is active and none of the people responsible knows about the others.

When a redirect behaves unexpectedly, the useful first question is not what it does but where it comes from. A rule you cannot find is usually being issued by a layer you were not thinking about, and the way to establish that is to ask each layer directly rather than to read configuration files in the order you happen to remember them.

Before you change canonicalisation

Two changes on this page deserve a warning ahead of the step rather than a note afterwards.

  • Changing which form of your domain is canonical

    The choice between a bare domain and a prefixed one, or between protocols, moves every address on the site at once. Done correctly it is invisible; done with a rule that matches too broadly it produces a loop that takes the whole site down rather than part of it. Test the rule against a handful of addresses before it applies to all of them.

  • Applying redirects in bulk

    A bulk change during a restructure carries the same shape of risk. A mapping with one wrong entry sends one page somewhere odd; a pattern with one wrong assumption sends thousands. Patterns are worth writing, and they are worth testing against a sample that includes the awkward cases: addresses with parameters, with unusual characters, and the ones that were already redirects before you started.

Both changes are also the two where keeping a record matters most, because the thing you will want in six months is the list of what used to be where.

What this section covers

The pages below take the working decisions apart: the modern pair of codes that keeps a request's method intact, finding and collapsing chains, and diagnosing loops, where a rule fights itself until nothing arrives at all.

FAQ

Which redirect code should I use?

Answer two questions: is the move permanent, and must the request method survive. Permanent moves use a permanent code so clients and search engines treat the new address as the replacement. Where the original address is still correct and something temporary is happening, a temporary code is the honest answer.

Do redirects slow down a site?

One is negligible; chains are not, because each hop is a round trip producing no content. Chains also form by accumulation rather than by design, as rules added at different times compose, which is why a periodic check pays even when nothing has been reported.

What happens if redirects form a loop?

Clients follow a limited number of hops and then stop, so a loop fails for everybody. A long chain fails for some clients and not others, depending on where each gives up, which makes it harder to diagnose than a loop and easier to leave in place.

Where do I set up a redirect?

In your web server's configuration, in your application's code, in a content system's interface, or in a layer in front of your server. More than one is often active at once, which is why identifying the source is usually more of the work than writing the rule.

Redirects, hop by hop

Status codes, chains and loops: this section follows a request until something answers it. The platform these pages describe is Bridge CDN, where an account is created.