301 Redirect: Meaning, Setup and SEO Impact

A 301 redirect is a permanent server-side instruction that sends visitors and search engines from an old URL to a new one, and passes along the ranking signals the old URL had earned. It is the correct tool whenever a page's address changes for good: after a URL rename, a domain move, or merging two pages into one.

I set up or audit redirects on nearly every project I touch, because a wrong one is one of the fastest ways to lose rankings during a rename or migration. This site runs its own redirects through a Vercel configuration file I maintain by hand, and I will use its actual rules as examples throughout, since they cover the most common real-world cases: www to bare domain, old paths to renamed pages, and the .html to clean-URL switch.

What a 301 redirect actually does

A 301 redirect is a response your server sends before any page content loads. Instead of returning the page, it returns a status code, 301, plus a Location header pointing at the new URL. The browser follows automatically, so a visitor barely notices, but the exchange happened at the HTTP level, before anything rendered. That is what separates a real redirect from a page that merely says "click here to continue," or one that uses JavaScript to change the address after loading.

The number comes from the HTTP status code standard, where the 3xx range covers redirection and each number carries a specific meaning. 301 means "Moved Permanently": the resource you asked for now lives somewhere else for good, and you, or the crawler, should use the new address from now on. That permanence is the entire point, and it is what tells Google to treat the new URL as the real one. Redirects are one piece of the larger technical foundation covered in my technical SEO basics guide.

301 vs 302 vs 307 vs 308: the difference that actually matters

All four codes redirect a request, but they split along two questions: is the move permanent or temporary, and must the request method, such as GET or POST, stay the same. Get the permanence question wrong and you either strand ranking signals on a URL you meant to retire, or hand signals permanently to a URL that was only ever meant to be temporary.

For a normal page move, browsers and search engines treat 301 and 308 the same way in practice. Both signal a permanent move, and Google's own documentation states that its indexing pipeline uses either one as a signal that the redirect target should become canonical. The difference only matters technically when the original request was not a simple GET, for example a form submission, where 308 guarantees the browser resubmits the same request to the new URL and 301 does not always. For the SEO outcome you care about, treat 301 and 308 as equivalent, treat 302 and 307 as equivalent, and keep those two pairs separate from each other.

This is not a theoretical distinction on this site. Every redirect in its Vercel configuration is written with a permanent flag set to true, which Vercel serves as a 308, not a 301. I did not choose 308 on purpose. It is simply what the platform returns for a permanent redirect, and Google's documentation confirms it is treated the same as a 301 for ranking and canonicalisation purposes. If your host or framework does the same, there is nothing to fix.

What happens to rankings and links when you 301 a page

Google's own documentation on site moves and redirects treats a 301, or a 308, as a strong signal that the new URL is now the canonical version of that content. Over time, and Google does not commit to an exact timeframe for this, the new URL starts appearing in search results in place of the old one. The ranking signals associated with the old URL, including the value of links pointing at it, consolidate onto the new one.

"Over time" is doing real work in that sentence. A redirect does not move rankings instantly. Expect the transition to take anywhere from a few days for a single page on a well-crawled site to several weeks for a full site migration with thousands of URLs. Google's own guidance on site moves says plainly that it is normal to keep seeing old URLs in results for a while even after the new ones are indexed and the redirect is live. If the destination page is not indexed yet, that consolidation has nothing to attach to, which is where indexing a page on Google becomes the actual prerequisite, not the redirect itself.

The transfer is not instant and not guaranteed to be complete in every case Google has described, but a same-content 301 pointed at the right destination is, in practice, the closest thing to a lossless move available. Two things damage the transfer: pointing the redirect at an unrelated page, which Google will simply not treat as the same content, and running the redirect through more than one hop, covered later in this guide.

When to use a 301 redirect, and when not to

Use a 301 whenever a URL's content has permanently moved and the old address should never be used again: renaming a page for a clearer URL, merging two overlapping pages that are quietly competing for the same ranking, sometimes called keyword cannibalization, into one stronger page, moving from http to https, switching from www to a bare domain or back, or retiring an entire domain in favour of a new one. In every one of these cases, the old URL has no future, and a 301 is the honest, permanent statement of that.

Do not use a 301 for anything temporary. A sale page that will return next month, an A/B test variant, or a maintenance page should use a 302 or 307 instead, so search engines keep the original URL as the one worth indexing. Do not use a 301 as a substitute for a canonical tag either: if both URLs need to stay live and reachable, a redirect is the wrong tool, because it removes the old one from service entirely. My canonical URL guide covers that distinction with the decision laid out directly against redirects and noindex.

And do not 301 a page to an unrelated destination just to preserve its authority. Redirecting a dead service page to your homepage "to be safe" tells Google the homepage is now the canonical version of content it is not actually about, and Google increasingly treats an irrelevant redirect target as a soft 404 rather than honouring it. If the old page has no real replacement, let it 404 or 410 cleanly rather than forcing a fake match.

How to set up a 301 redirect, platform by platform

The concept is the same everywhere: tell the server or platform the old path, the new path, and that the move is permanent. Where that rule lives depends on what your site runs on.

Step 1: Decide the exact old URL and the exact new URL

Write down both URLs in full, including https and the exact path, before touching any configuration. Decide whether query parameters and trailing slashes on the old URL should carry through to the new one. Getting this pair wrong is the single most common cause of a redirect that "does not work," when in fact it works exactly as configured, just not as intended.

Step 2: Choose where the redirect belongs

On WordPress, use a redirect plugin such as Redirection, which is free and lets you add rules from a dashboard without touching code. On Apache hosting, redirects live in the site's .htaccess file. On Nginx, they live in the server block configuration, which usually needs your host or a developer to edit. On Shopify, use Online Store, then Navigation, then URL Redirects in the admin, the path at the time of writing (September 2026); some stores now surface this under Content instead, so check both if you do not see it immediately. If you are still choosing a platform, my comparison of WordPress, Wix and Shopify covers how each handles redirects and clean URLs out of the box. On Vercel or Netlify, redirects live in a configuration file in your repository, which is how this site handles every one of its own.

Step 3: Write the redirect rule

The syntax differs by platform, but the shape is always old path, new path, permanent. Here is the same www-to-bare-domain redirect written for three common setups, plus the format this site actually uses.

# .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.yoursite\.in [NC]
RewriteRule ^(.*)$ https://yoursite.in/$1 [L,R=301]

# Nginx (server block)
server {
  server_name www.yoursite.in;
  return 301 https://yoursite.in$request_uri;
}

# vercel.json
{
  "redirects": [
    { "source": "/(.*)",
      "has": [{ "type": "host", "value": "www.yoursite.in" }],
      "destination": "https://yoursite.in/$1",
      "permanent": true }
  ]
}

This site's own vercel.json uses exactly that www-to-bare-domain pattern, plus simple one-line rules for renamed pages: /about and the old /about.html both resolve to /about-us, and /tools.html resolves to the current tools page. Every one of them is a single source-to-destination pair with the permanent flag set to true, which is the 308 behaviour covered earlier in this guide.

Step 4: Deploy and clear any caching

Push the change live, then clear caches that might still be serving the old response: your CDN, a WordPress caching plugin, or your own browser cache when you test. A redirect that is correctly configured but sitting behind a cached response on the old URL will look broken for anyone hitting the cache, including, briefly, Googlebot, which follows redirects as part of a normal crawl, covered in what crawling is in SEO.

Step 5: Test the redirect with curl or browser DevTools

Open a terminal and run curl with the -I flag against the old URL. The response headers should show a 301 or 308 status and a Location header pointing at the exact new URL. In a browser, open DevTools, go to the Network tab, load the old URL, and check the first request's status code the same way.

Do not just watch the browser address bar change and assume success. A page that "ends up in the right place" can still be doing it with a 302 or a JavaScript redirect, which behaves differently for search engines even when it looks identical to a visitor.

Step 6: Update internal links and the sitemap

Point your navigation, footer and in-content links at the new URL directly, rather than leaving them to travel through the redirect. Update the XML sitemap to list only the new URL. This is not required for the redirect to function, but every internal link still pointing at the old URL is a small, permanent tax: an extra hop for every visitor and every crawl. My internal linking guide covers auditing links site-wide after a change like this.

Redirect chains and redirect loops

A redirect chain is what happens when URL A redirects to B, which itself redirects to C. Each hop adds latency, and Google has said it will generally stop following a chain after a handful of hops, which means the final destination can end up not being credited at all. Chains build up quietly over years, usually because a page got renamed twice and nobody went back to point the first redirect straight at the final URL.

A redirect loop is worse: A redirects to B, and B redirects back to A. Browsers and crawlers detect this and give up with an error rather than looping forever, which means the page is effectively dead for every visitor and for Google. Loops usually appear after a migration where both the old and new server configurations were left active, each trying to send the other's URL back.

The fix for both is the same habit: whenever you add a new redirect, check whether the destination is itself a redirect, and if it is, repoint your new rule at the final, live URL instead of chaining onto it. A quick curl check on the destination before you deploy catches this in seconds.

How to check that a redirect is actually working

Three checks cover almost every case. First, curl with the -I flag from a terminal, which shows the exact status code and Location header with nothing hidden by the browser. Second, your browser's DevTools Network tab, which shows the same information plus every hop in a chain if there is more than one. Third, Google Search Console's URL Inspection tool, covered in my Search Console guide for beginners, which tells you whether Google itself sees the redirect and whether it has already updated its canonical choice to the new URL.

It is also worth scanning the destination page itself once the redirect is confirmed, since a correct redirect pointed at a broken or thin page has not actually fixed anything. The free website SEO checker flags missing tags or indexing issues on the new URL in the same pass. A quick note on free online redirect checker tools: many are reliable, but some report the status after following the full chain rather than the first hop, which can hide a chain you should fix. When in doubt, trust a direct curl check over a third-party tool, since it shows the server's raw first response with nothing smoothed over.

Common 301 redirect mistakes

• Redirecting everything to the homepage. A blanket rule that sends every deleted URL to the homepage looks tidy but tells Google none of those pages had a real replacement, which can read as a soft 404 across the board instead of individual permanent moves.
• Using a 302 for a permanent move. Common on platforms that default to a temporary redirect. It works for visitors immediately but leaves the old URL as the one search engines may keep indexing.
• Redirect chains left over from a page renamed more than once. Each hop is invisible to a visitor and costly to a crawler. Always repoint straight at the final URL.
• Forgetting query parameters that need to carry through. A redirect that drops a tracking tag can break attribution even when the destination page itself is correct.
• Redirecting to a page in a different language or region without checking the setup for international visitors, even though the redirect itself works exactly as configured.

Most of these are copy-paste errors, not conceptual mistakes, which is exactly why they survive unnoticed for years. A quarterly pass with a site crawler, checking every redirect's actual status code rather than trusting that it "looks right" in a browser, catches all five before they cost you real ranking signal.

301 redirects vs canonical tags vs noindex

These three get confused constantly because they all deal with "this URL is not the main one," but they solve different problems and are not interchangeable. A 301 removes a URL from service entirely and sends everyone, human and crawler, to the new one. A canonical tag keeps both URLs live and reachable, and simply tells Google which one to index and credit. A noindex tag keeps a page live and reachable for visitors but asks Google not to store it in search results at all.

Redirect a URL that has no reason to stay reachable, such as an old page after a rename. Canonicalise a URL that must stay reachable for a real reason, such as a page reached through a tagged ad link or a filtered product listing. Noindex a page that is unique and fine to keep live but has no business appearing in search, such as a thank-you page. My guide to canonical URLs goes deeper into this exact decision, including the comparison table I use to choose between all three on every audit. Once you have set up the redirects a migration needs, realistic timelines for the ranking recovery that follows are covered in how long SEO actually takes.

Frequently asked questions

What is a 301 redirect in simple terms?

A 301 redirect is a permanent, server-level instruction that automatically sends visitors and search engines from an old URL to a new one. It happens before any page content loads: the server responds with the 301 status code and a new address, and the browser follows immediately. Search engines treat it as confirmation that the content has moved for good, and over time they transfer the old URL's ranking signals to the new destination instead of continuing to show the old one in results.

What is the difference between a 301 and a 302 redirect?

A 301 tells search engines the move is permanent, so they update their index to show the new URL and transfer ranking signals to it. A 302 tells them the move is temporary, so they keep the original URL indexed and treat the new one as a short-term detour. Using a 302 for a page that has actually moved for good means search engines may keep favouring a URL you never intend to use again, so match the code to the real situation.

Does a 301 redirect hurt my SEO rankings?

A correctly configured 301, pointed at genuinely equivalent content, does not meaningfully hurt rankings, and it is the recommended way to move a page. What does hurt rankings is redirecting to an unrelated page, chaining several redirects together, using a temporary 302 for a permanent move, or leaving old internal links and sitemap entries pointing at the redirected URL instead of the new one. The redirect itself is not the risk. How it is set up and where it points is.

How do I check if a 301 redirect is actually working?

The most reliable check is running curl with the -I flag followed by the URL from a terminal, which shows the exact status code and the Location header the server actually sent, with nothing hidden by a browser. Your browser's DevTools Network tab shows the same information for each hop if there is more than one redirect. Google Search Console's URL Inspection tool confirms whether Google itself has recognised the redirect. Do not rely on the browser address bar changing correctly, since that can happen with the wrong status code too.

Can I set up a 301 redirect on WordPress without a plugin?

Yes, by adding a rule to your site's .htaccess file if it runs on Apache hosting, using a RewriteRule that points the old path to the new one with a 301 flag. This works without installing anything, but a small mistake in the file can take the whole site down, so back up the file first. Most WordPress users are better served by a free plugin such as Redirection, which adds and manages redirects from a dashboard with no code and far less risk.

Related guides

• How to index your website on Google
• What canonical URLs are
• Technical SEO basics for business owners
• What crawling is in SEO
• Keyword cannibalization: how to find and fix it
• WordPress vs Wix vs Shopify compared
• Internal linking strategy guide
• XML sitemap guide

Your next step

Pick one redirect you actually need this week, write down the exact old and new URL, and set it up as a genuine 301 or 308, never a meta refresh. Then verify it with the free SEO checker before you move on.