301 Redirects: What They Are and When to Use Them

A changed URL can look like a minor housekeeping job until search traffic, backlinks and customer bookmarks still point at the old address. For a small business managing its own website, a 301 redirect is the usual way to tell browsers and search engines that a page has moved permanently. Used carefully, it keeps visitors moving towards useful content and helps preserve the signals attached to the old URL. Used carelessly, it can create loops, irrelevant journeys and a site structure that becomes harder to maintain. The decision is not simply whether to install a rule: it is whether the move is permanent, whether the destination answers the same need, and whether the server really sends the intended HTTP response.

Use a 301 when the move really is permanent

The important word is permanent. A 301 redirect suits a URL that has been replaced and is not expected to return. Common examples include changing a page slug, consolidating two overlapping articles, moving a product or service page into a clearer site structure, or migrating a website to a new domain.

That is different from temporarily sending visitors elsewhere while a page is unavailable or a short-lived campaign is running. The redirect chosen should reflect what is actually happening. Treating every forwarding requirement as a 301 may leave search engines with misleading signals about which URL should ultimately appear in results.

Under RFC 9110 section 15.4.2, 301 Moved Permanently means the target has been assigned a new permanent URI. A server should normally communicate the preferred new address in the HTTP Location header. This is an HTTP behaviour, not simply a clickable link on an otherwise unchanged page. The related 308 status also signifies a permanent move, but unlike 301 it preserves the original request method when a client follows the redirect. For ordinary GET requests to a moved article this distinction is often invisible; it may matter for endpoints that receive POST requests. Developers should therefore assess application endpoints separately from simple public page migrations.

Redirect visitors to the closest useful replacement

The destination matters as much as the redirect itself. If an old article about local SEO has been replaced by a newer, more complete local SEO guide, directing the old URL to that guide makes sense. Sending every retired URL to the homepage usually does not. A visitor who expected a specific answer should not have to begin the search again.

This is particularly important when consolidating content for SEO. If several pages cover substantially the same intent, a business may choose one strong page, improve it to cover the useful material and redirect redundant URLs to it. The resulting destination should genuinely satisfy the searches and links that previously reached those pages.

When there is no meaningful replacement, allowing the retired address to return an appropriate 404 or 410 response can be more accurate than pretending the homepage answers the original query. A product that has a genuinely equivalent successor is different from a discontinued service the business no longer offers. Write down why each redirect target is appropriate, and ask the content owner to confirm that essential information was not silently lost. Google warns that redirecting large groups of unrelated old URLs to one destination can produce soft-404 behaviour. The goal is a helpful user journey, not a technically successful hop to any page with a 200 response.

Map redirects before changing a site structure

A handful of redirects can be managed individually. A larger redesign or migration deserves a redirect map before any URLs change. List the current addresses, decide which will remain, identify the most relevant destination for each retired URL and flag pages that have no sensible replacement.

This exercise often exposes problems before launch. Two old pages may be mapped to a destination that covers only one topic, or a planned new URL may itself be due to redirect elsewhere. Resolving those issues on paper is considerably easier than diagnosing them after search engines and customers encounter the new structure.

A useful mapping register includes the existing URL, planned destination, content decision, expected status, responsible person and tested result. Where a business changes from one domain to another, inventory pages, images and downloadable documents that are still linked internally or externally. Do not forget variants such as an old HTTP URL, a trailing-slash form or outdated capitalisation. These may require configuration-specific handling; they are not evidence that the same generic rule will work on every hosting platform. Ask the developer to identify which redirects live in the web server, application or content-management system, because overlapping rules can create surprises after deployment.

Avoid chains and loops

A redirect chain occurs when one URL redirects to another, which then redirects again. This often develops gradually: an article moves from A to B, then a later redesign moves B to C. Rather than leaving A pointing to B, update it so A points directly to C. The same principle applies across larger migrations.

A loop is more serious because the redirects send a visitor around in a circle. For example, A points to B while B points back to A. Browsers cannot reach a final page, and the visitor receives an error instead of content. Testing the complete route after implementation is therefore part of the job, not an optional technical check.

Google's site-move guidance recommends direct destination redirects rather than a series of hops. A chain may add latency for users and complicate troubleshooting even when a crawler can technically follow it. Check where an old link starts and where it finally lands, not only whether the first response is 301. In a multi-stage redesign, review the oldest retained redirect rules as well as the ones newly added. Include both ordinary browsing and automated checks that inspect the HTTP status and Location header. A successful visual landing page can mask unwanted intervening steps.

Update internal links as well as adding redirects

A 301 provides a safety net for old links, but it should not become the normal route through the website. Once a URL changes, update navigation, article links, calls to action, sitemaps and other links under your control so they point directly to the new address.

This produces cleaner journeys and makes future maintenance easier. It also prevents an old site architecture from surviving invisibly through layers of redirects. External backlinks may remain outside your control, which is precisely where a well-planned 301 continues to earn its keep.

Check canonical signals on the new page, and make the XML sitemap list the intended current URLs rather than addresses that redirect away. A redirect is a stronger statement about a URL move than simply putting a canonical tag on two pages; these tools solve related but different problems. Keep the intended destination consistent across internal linking, sitemap entries and primary navigation. For sites with multilingual or regional versions, ask a specialist to inspect relevant language and regional annotations so that an apparently simple structural move does not break the site's intended alternates.

Check what happened after launch

Testing should include more than opening one old URL in a browser. Check representative redirects from each part of the site, confirm that they reach the intended final page and make sure important new URLs return normally rather than redirecting unexpectedly. Crawl tools can help an owner or agency identify chains, loops and internal links that still reference retired addresses.

Search performance deserves attention too. A migration can change several things at once, so keep a record of the redirect map and the date the change was made. That makes later diagnosis much more practical if an important page loses visibility or a previously useful landing page stops receiving visits.

For key URLs, record the observed status code, final destination, outcome and date tested. Confirm that the target displays the promised content, does not accidentally carry a noindex directive and does not immediately redirect elsewhere. Where the website uses a cache or content delivery network, verify that the real production response matches the intended configuration. Google Search Console can help identify discovery and indexing problems after a move, but its reporting does not prove that every redirect rule works for every visitor. Compare relevant groups of queries and pages rather than assuming total traffic will remain constant immediately after a migration.

Understand which checks are genuinely different

There are at least three kinds of verification. First, the server-level check asks whether the old address returns the correct HTTP status and Location header. Second, the content check asks whether the destination page actually satisfies the old user need. Third, the search check asks whether crawlers and search reporting are gradually recognising the new location. These stages reinforce one another but do not automatically pass together. A perfect HTTP 301 can still lead to an irrelevant page, while a readable new page can coexist with an old URL that was never redirected.

Be precise about temporary exceptions. RFC 9110 distinguishes 302 Found and 307 Temporary Redirect from the permanent 301 and 308 responses. The 307 preserves the request method when followed; historical 302 behaviour may change a POST to GET. Google uses permanent redirects as a signal that the target should be canonical, whereas temporary redirects do not carry the same signal. Therefore a short-term outage and a settled permanent page migration should not be handled as if they were the same event. The correct decision follows the intended business behaviour and the actual HTTP contract.

Keep a redirect register instead of relying on memory

Small sites often accumulate technical decisions over years. A redirect added during one redesign may be forgotten by the next person working on the website. Keeping a simple register of the old URL, destination and reason for the change creates valuable context for future SEO work.

The objective is not to collect as many redirects as possible. It is to maintain a clear relationship between retired content and the best current destination. When every redirect has a reason, points somewhere relevant and is tested after changes, a 301 becomes what it should be: a controlled part of maintaining a useful, searchable website.

Assign ownership of the register to someone who can review it when content is consolidated or a new site is launched. Include why an exception was approved, whether any redirect still supports valuable external references and when its continued need should next be considered. Do not set an arbitrary universal expiry date: the right retention depends on the links that remain and the stability of the new information architecture. A practical close-out includes the final tested map, the developer's implementation notes, sample response evidence and a list of issues needing follow-up. That document helps the next person distinguish intentional redirects from accidental routing faults.

Primary technical sources: RFC 9110, HTTP 301 definition and Google Search Central, redirects and Google Search. For larger moves, consult Google's URL migration guide. These sources describe protocol behaviour and search guidance; none promises that an individual site will retain exactly the same search traffic after a move.