What Is a 301 Redirect?

A 301 redirect is a permanent redirect that instructs browsers and search engines to send all traffic from one URL to another, permanently. The number 301 is the HTTP status code returned in the server response header. When a server responds with a 301, it is explicitly telling the client: "This resource has permanently moved. Update your records and go here instead."

Understanding what is a 301 redirect is one of the most foundational concepts in technical SEO. Every time you move a page, restructure your site, change domains, or switch from HTTP to HTTPS, you need 301 redirects in place. Without them, visitors land on broken pages, and every backlink you have ever earned loses its value overnight.

The "permanent" aspect is what separates a 301 redirect from other redirect types. It signals to Google, Bing, and other search engines that the original URL should be removed from their index and replaced by the destination URL. Over time — typically within a few weeks to a few months — the destination URL inherits the search rankings that the original URL held.

You can verify any redirect type on your own URLs using the RankNibbler redirect checker, which shows you the exact HTTP status code, response headers, and the full redirect chain for any URL you enter.

How 301 Redirects Work: The HTTP Protocol

To truly understand a 301 redirect, it helps to understand what happens at the HTTP protocol level. Every time a browser requests a page, it sends an HTTP request to a web server. The server responds with a status code. Status codes in the 3xx range are redirect codes, telling the browser to look elsewhere for the content.

Here is the sequence of events when a 301 redirect fires:

A user (or search engine bot) requests http://www.example.com/old-page.
The server receives the request and checks its redirect rules.
The server responds with HTTP status 301 Moved Permanently and includes a Location header pointing to the new URL.
The browser reads the Location header and immediately sends a second request to https://www.example.com/new-page.
The new page responds with 200 OK and serves the content.

The raw HTTP response for a 301 looks like this:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Length: 0
Connection: close

The browser caches this redirect. That means once a user has visited a 301-redirected URL, their browser remembers the destination and goes straight there on future visits without contacting the server again. This is efficient but can cause problems during testing — you may need to clear your browser cache to see updated redirect behaviour.

Search engine crawlers like Googlebot follow 301 redirects and update their index to reflect the new URL. Google has said that link signals (what SEOs call "link equity" or "PageRank") associated with the original URL are passed to the destination URL. The process is not instant: Google typically takes several crawl cycles to fully consolidate the signals, which can take anywhere from days to several months depending on the crawl frequency of your site.

If you want a deeper understanding of how crawlers interpret your site's signals, run a site audit with RankNibbler to surface redirect issues, broken links, and other crawlability problems across your entire domain.

301 vs 302 vs 307 vs 308: Full Comparison

The HTTP specification defines several redirect status codes, each with a different intended meaning. Choosing the wrong one is one of the most common technical SEO mistakes. Here is a full breakdown of the four redirect types you are most likely to encounter:

Code	Name	Permanent?	Method Preserved?	Passes Link Equity?	Browser Caches?	Best Used For
301	Moved Permanently	Yes	No (GET)	Yes (full)	Yes	Permanently moved pages, domain migrations, HTTP to HTTPS, www consolidation
302	Found (Temporary)	No	No (GET)	Limited / none	No	A/B testing, maintenance pages, short-term redirects where the original URL will return
307	Temporary Redirect	No	Yes	None	No	Temporary redirects where the HTTP method (POST, PUT) must not change
308	Permanent Redirect	Yes	Yes	Yes (full)	Yes	Permanent redirects for non-GET requests (API endpoints, form submissions)

301 vs 302 Redirect: What Is the Real Difference?

The 301 vs 302 redirect distinction is the one that matters most for SEO. A 301 tells search engines the move is permanent; a 302 tells them the original URL is still the canonical resource and will return. When Google sees a 302, it generally keeps the original URL in its index and does not transfer link equity to the destination. If you accidentally use a 302 for a permanent move, your new URL may never accumulate the ranking signals it needs, and your old URL will eventually drop out of the index with nothing to replace it.

There are legitimate uses for 302 redirects. If you are running an A/B test and sending half your traffic to a variant URL, a 302 is correct — you do not want Google to consolidate both pages into one. Similarly, if your site is undergoing scheduled maintenance and you are temporarily redirecting visitors to a status page, a 302 tells Google to keep the original URL indexed because it will come back.

A practical rule of thumb: if the original URL will never serve content again, use a 301. If there is any chance the original URL will be active again in the future, use a 302. When in doubt — especially for site-wide infrastructure changes like HTTP to HTTPS — always use a 301.

Quick test: Not sure what type of redirect your site is serving? Paste any URL into the RankNibbler redirect checker to see the exact HTTP status code and response headers in seconds.

307 vs 308: When Do These Matter?

The 307 and 308 codes were formalised in later HTTP specifications to address an ambiguity in the original 301 and 302 definitions. In theory, a 301 redirect should change the method from POST to GET, but in practice browsers already did this. The 307 and 308 codes make this explicit: the HTTP method used in the original request must be preserved in the redirect.

For standard website SEO purposes, 307 and 308 are rarely encountered. They are primarily relevant for API developers and applications that make non-GET HTTP requests. If you run a REST API and you permanently move an endpoint, a 308 is the correct choice. For anything content-related — pages, blog posts, product listings — you will almost always use a 301.

When to Use 301 Redirects

There are five primary scenarios where a permanent redirect is not just recommended but essential. Missing any one of these can cost you significant organic traffic.

1. Moving a Page to a New URL

The most common use case. You have published a page at /blog/seo-tips-2020 and you want to update the URL to /blog/seo-tips. Or your site has been rebuilt and the URL structure has changed entirely — for example, from /p?id=123 to /products/blue-widget. In both cases, every old URL that has ever been linked to, bookmarked, or indexed by Google needs a 301 redirect pointing to its new equivalent.

Skipping this step means all your existing backlinks point to 404 error pages. Google will eventually drop those URLs from its index. Any PageRank those backlinks carried is lost. Setting up 301 redirects preserves that earned authority and tells Google exactly where to find the new content.

2. Domain Migration

Moving from one domain to another — whether for a rebrand, acquisition, or consolidation — is one of the highest-risk technical SEO operations you can perform. A domain migration done correctly with comprehensive 301 redirects can maintain over 90% of organic traffic within a few months. Done without redirects, or with a redirect map full of gaps, you can lose the majority of your traffic for a year or more.

For a domain migration, you need to:

Map every significant page on the old domain to its nearest equivalent on the new domain
Implement 301 redirects at the server level, not through JavaScript or meta refresh tags
Redirect all variants: HTTP and HTTPS, www and non-www, with and without trailing slashes
Update your XML sitemap to reflect the new domain
Submit a change-of-address notification in Google Search Console
Monitor crawl coverage and organic traffic for at least 12 weeks after launch

See our SEO glossary for definitions of other terms that come up during a domain migration, including crawl budget, PageRank, and canonical tags.

3. HTTP to HTTPS Migration

Every site should be served over HTTPS. It has been a Google ranking factor since 2014, it protects user data, and modern browsers display security warnings for HTTP sites. If your site still has pages accessible over plain HTTP, you need 301 redirects to push all traffic to the HTTPS versions.

The standard setup redirects all four variants of your domain to a single canonical form:

http://example.com → https://www.example.com
http://www.example.com → https://www.example.com
https://example.com → https://www.example.com

This ensures Google sees one canonical domain and consolidates all link equity into a single URL rather than splitting it across four variants. Learn more about the relationship between HTTPS and SEO in our guide to HTTPS and SSL.

4. WWW to Non-WWW Consolidation (and Vice Versa)

Your domain has two versions: www.example.com and example.com. From a technical perspective, these are entirely different hosts. If both versions are accessible without redirecting one to the other, you have a duplicate content problem. Google may split your ranking signals between the two, effectively halving the authority of your pages.

Pick one preferred version — most SEOs choose the www version for legacy reasons, though non-www is perfectly fine — and 301 redirect the other. This is sometimes called "www canonicalisation." A canonical tag alone is not sufficient for this; you need a true server-side 301 redirect to fully consolidate the two versions.

You can check whether your site has this problem using the redirect checker: enter both versions of your domain and confirm they both resolve to the same final URL with a 301 status code.

5. Fixing Broken URLs and Deleted Pages

Over time, every website accumulates broken links — pages that were deleted, restructured, or simply forgotten. If those pages have external backlinks or are still being crawled by Google, a 404 error is wasted potential. A 301 redirect to the most relevant live page recovers that link equity and ensures visitors land somewhere useful rather than a dead end.

Use a broken link checker to find 404 pages on your site, then cross-reference them with your backlink profile to prioritise which ones deserve 301 redirects. Not every 404 needs to be redirected — only those with meaningful inbound links or significant search traffic history.

Keeping duplicate content in check also plays a role here. If two pages cover similar topics, consolidating them with a 301 redirect from the weaker page to the stronger one can improve the surviving page's rankings. Read our guide on what is duplicate content for a fuller explanation of this strategy.

How to Implement 301 Redirects

The correct implementation method depends on your web server, platform, or programming language. Here are the most common approaches with working code examples for each.

Apache: .htaccess 301 Redirects

Apache is the most widely used web server for shared hosting environments. Redirects are configured in the .htaccess file in your site root. There are two main approaches: the simple Redirect directive and the more powerful RewriteRule directive.

Redirect a single page:

Redirect 301 /old-page https://www.example.com/new-page

Redirect an entire directory:

Redirect 301 /old-folder/ https://www.example.com/new-folder/

Redirect HTTP to HTTPS using mod_rewrite:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Redirect www to non-www (HTTPS):

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

Redirect non-www to www (HTTPS):

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

Redirect an old domain to a new domain (preserving paths):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com [NC]
RewriteRule ^(.*)$ https://www.newdomain.com/$1 [R=301,L]

The [R=301,L] flags mean "redirect with a 301 status code" (R=301) and "stop processing rules after this match" (L). Always include the L flag to prevent rules from conflicting with each other.

You can generate .htaccess redirect rules automatically with the RankNibbler .htaccess redirect generator.

Nginx: 301 Redirects in Server Blocks

Nginx handles redirects in its server configuration files, typically located in /etc/nginx/sites-available/. Unlike Apache, Nginx does not use .htaccess files; all configuration is in the main config or included files.

Redirect a single URL:

server {
    listen 80;
    server_name www.example.com;

    location = /old-page {
        return 301 https://www.example.com/new-page;
    }
}

Redirect all HTTP to HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Redirect www to non-www:

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # main site config here
}

Redirect an old domain to a new domain:

server {
    listen 443 ssl;
    server_name olddomain.com www.olddomain.com;
    return 301 https://www.newdomain.com$request_uri;
}

After editing Nginx configuration files, always run nginx -t to test the configuration before reloading the server with systemctl reload nginx.

WordPress: 301 Redirects

WordPress sites running on Apache can use .htaccess rules directly (see above). However, the most practical approach for most WordPress users is a redirect plugin, which lets you manage redirects through the admin dashboard without touching server files.

Redirection plugin (free, by John Godley): The most popular WordPress redirect manager. Supports individual URL redirects, regex-based redirects, 404 monitoring, and import/export of redirect lists. Find it in the WordPress plugin directory. Once installed, go to Tools > Redirection to add your rules.

Yoast SEO Premium: Includes a redirect manager under the SEO menu. Integrates directly with Yoast's other SEO features and can automatically create redirects when you change a post's slug.

Rank Math: Also includes a built-in redirect manager for 301, 302, and 307 redirects, plus automatic redirect creation on slug change.

If you prefer to handle redirects programmatically in WordPress without a plugin, you can add rules to your theme's functions.php file using the wp_redirect() function:

add_action('template_redirect', function() {
    if (is_page('old-page-slug')) {
        wp_redirect(home_url('/new-page-slug'), 301);
        exit;
    }
});

Note the exit after wp_redirect(). Without it, WordPress will continue executing code and the redirect may not fire correctly.

Shopify: 301 Redirects

Shopify has a built-in URL redirect tool in the admin. Go to Online Store > Navigation > URL Redirects to add individual redirects. You can also import redirects in bulk using a CSV file with two columns: redirect from and redirect to.

Shopify automatically creates 301 redirects when you change the handle (slug) of a product, collection, or page from within the admin, as long as you check the "Create a URL redirect" box that appears when you make the change.

Limitations to be aware of on Shopify: you cannot redirect from one external domain to Shopify directly (domain migration redirects must be handled at the DNS/registrar level or through Shopify's domain management). Shopify also does not give you access to a raw .htaccess file, so all redirects must go through the admin interface or the API.

For bulk Shopify redirects during a platform migration, export your redirect list as a CSV and upload it via the URL Redirects import tool. You can have up to 100,000 URL redirects on most Shopify plans.

Node.js (Express): 301 Redirects

If you are running a Node.js application with Express, redirects are handled in your route handlers:

Redirect a single route:

app.get('/old-page', (req, res) => {
    res.redirect(301, '/new-page');
});

Redirect HTTP to HTTPS using middleware:

app.use((req, res, next) => {
    if (req.headers['x-forwarded-proto'] !== 'https') {
        return res.redirect(301, 'https://' + req.hostname + req.originalUrl);
    }
    next();
});

Redirect www to non-www:

app.use((req, res, next) => {
    if (req.hostname.startsWith('www.')) {
        const newHost = req.hostname.replace(/^www\./, '');
        return res.redirect(301, 'https://' + newHost + req.originalUrl);
    }
    next();
});

Note that the x-forwarded-proto header is set by proxy layers like Nginx, Heroku, or AWS load balancers. If your Node.js app sits behind a proxy, you need to enable trust for that proxy with app.set('trust proxy', 1) so Express reads the correct protocol.

PHP: 301 Redirects

For plain PHP applications, a 301 redirect is set with the header() function before any output is sent:

<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://www.example.com/new-page");
exit();
?>

The exit() call is critical — without it, PHP will continue executing the script and potentially output content that conflicts with the redirect header. Headers must always be sent before any HTML or whitespace is output.

Redirect Chains and Redirect Loops

Two of the most damaging redirect problems you can create are chains and loops. Both waste crawl budget, slow down page load, and dilute link equity.

What Is a Redirect Chain?

A redirect chain occurs when URL A redirects to URL B, and URL B redirects to URL C (or further). The user and search engine bot have to follow multiple hops before reaching the final destination.

Example of a chain:

http://example.com/old-page
    → 301 → https://example.com/old-page
    → 301 → https://www.example.com/old-page
    → 301 → https://www.example.com/new-page

Each additional hop in a redirect chain introduces latency. More importantly, Google has indicated that link equity can diminish slightly with each extra redirect hop. A three-hop chain loses more equity than a direct redirect.

The correct fix is to update the source redirect so it points directly to the final destination URL:

http://example.com/old-page → 301 → https://www.example.com/new-page

Redirect chains commonly build up over time during site migrations. You migrate from HTTP to HTTPS (creating one hop), then rename a URL (creating a second hop on the HTTPS version), then migrate again (adding a third). Periodically auditing your redirects and flattening any chains is good site hygiene. The RankNibbler redirect checker shows you the full chain for any URL so you can identify and fix multi-hop redirects.

What Is a Redirect Loop?

A redirect loop occurs when a URL redirects to itself, directly or via a cycle. URL A → B → A creates an infinite loop. Browsers will detect this and show an error like "Too many redirects" (ERR_TOO_MANY_REDIRECTS in Chrome) after a few hops.

Common causes of redirect loops:

A typo in the destination URL that accidentally matches the source URL
Conflicting redirect rules, where two rules trigger each other
An HTTP-to-HTTPS rule that fires even on HTTPS requests, because the server is not correctly detecting the protocol
A WordPress redirect plugin rule conflicting with a server-level .htaccess rule

The most frequent loop is the HTTP-to-HTTPS loop. It happens when:

Your .htaccess rule checks for HTTPS and redirects if it is not present
SSL is terminated by a load balancer or CDN before the request reaches Apache
Apache sees the request as HTTP even though the user connected over HTTPS
The redirect fires even for HTTPS users, creating a loop

The fix is to use the X-Forwarded-Proto header when SSL is terminated upstream:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Link Equity and 301 Redirects: What Actually Gets Passed?

The concept of "link equity" (historically called PageRank) refers to the ranking value that flows from one page to another through hyperlinks. When a page has many high-quality backlinks, it has high link equity. That equity influences where the page ranks in search results.

When you set up a 301 redirect, Google passes the link equity from the old URL to the new URL. For many years, the SEO community believed that some equity was "lost in the redirect" — estimates ranged from 10% to 15% loss. Google's John Mueller clarified in 2016 and again in subsequent years that a properly implemented 301 passes essentially all link equity, with no significant loss.

However, there are real-world factors that affect how much equity is transferred in practice:

Relevance: Google considers whether the destination page is topically relevant to the source page. A redirect from /blue-widgets to /blue-widgets-for-sale passes equity well. A redirect from /blue-widgets to your homepage passes less equity because the topical match is weaker.
Redirect chains: Each additional hop in a chain does reduce signal transfer, particularly for indirect hops that the crawler has to follow through multiple requests.
Time: Equity transfer is not instant. Google needs to recrawl the source URL, follow the redirect, recrawl the destination URL, and process the change. This can take weeks or months.
Crawl frequency: High-authority pages get crawled more frequently. If your source URL was crawled rarely before, the redirect may take longer to be processed.

To accelerate link equity transfer after a redirect, submit your updated sitemap to Google Search Console and use the URL Inspection tool to request crawling of your most important redirected URLs.

The Impact of 301 Redirects on SEO Rankings

Done correctly, a 301 redirect maintains the vast majority of your organic search rankings. Done incorrectly, it can wipe them out. Here is what to expect at each stage of a redirect or migration:

Immediately After Implementation

Expect some ranking volatility. Google is processing the change, re-evaluating the destination URL, and consolidating signals. You may see temporary drops or fluctuations in rankings for the redirected pages. This is normal and expected. Do not panic and remove the redirects — that will make things worse.

Two to Four Weeks After

For high-traffic pages that get crawled frequently, Google typically processes 301 redirects within two to four weeks. You should start to see the destination URL appearing in search results where the source URL used to appear. If you have updated your sitemap and submitted it to Search Console, this process tends to be faster.

Three to Six Months After

Full ranking recovery for large-scale migrations typically takes three to six months. Complex migrations with thousands of URLs, significant URL structure changes, or domain changes take longer than simple URL renames. Monitor Search Console for coverage errors, crawl stats, and any unusual drops in indexed pages throughout this period.

Permanent Ranking Loss

Some ranking loss may be permanent in these situations:

Redirecting to an irrelevant page (e.g., redirecting all 404s to the homepage)
Multiple redirect hops in a long chain
Broken redirect chains where one hop returns a 404
Using a 302 instead of a 301 for a permanent move
Redirecting to a page with thin or low-quality content compared to the source

A full site audit after any major redirect operation is essential. It will surface broken redirect chains, pages that are still returning 404s, and any redirect loops before they have a chance to do lasting damage to your rankings.

Common 301 Redirect Mistakes

These are the mistakes that SEOs and developers make most frequently with redirects, and how to avoid each one.

Mistake 1: Redirect Chains

As described above, URL A → B → C creates a chain. Flatten every chain so A redirects directly to the final destination C. This is especially important during platform migrations where multiple rounds of redirects have accumulated over time.

Mistake 2: Using 302 for Permanent Moves

The most expensive mistake in terms of SEO impact. If you are permanently moving a page, always use 301. Audit your redirects regularly and convert any 302s on permanently moved content to 301s.

Mistake 3: Not Covering All Domain Variants

HTTP, HTTPS, www, and non-www are four distinct variants of every URL. All four must redirect to your single canonical form. Failing to cover all four splits your link equity and creates duplicate content issues. Test all four variants with the redirect checker.

Mistake 4: Redirecting to the Homepage

When a page is deleted and has no natural replacement, many site owners redirect it to the homepage. Google has specifically called this out as a "soft 404" — a URL that technically returns a 200 or 301 but does not serve content matching the original URL's intent. Google may treat these as 404s anyway and not pass link equity. Always redirect to the most relevant existing page.

Mistake 5: JavaScript-Based Redirects

Redirecting via JavaScript (window.location = 'https://...' or meta refresh tags) is not the same as a server-side 301. JavaScript redirects do not pass link equity in the same way, depend on the crawler executing JavaScript, and are significantly slower for users. Always use server-side 301 redirects for SEO-critical redirects.

Mistake 6: Forgetting Internal Links

After setting up 301 redirects, update your internal links to point directly to the new URLs. Relying on redirects for internal navigation wastes crawl budget and adds unnecessary latency for users. Use Search Console or an internal link audit to find pages that still link to the old URLs and update them.

Mistake 7: Not Monitoring After Implementation

Setting up redirects and walking away is a recipe for problems. Redirects can break when servers are updated, plugins conflict with rules, or someone edits a config file without realising the impact. Schedule regular checks of your most important redirects using an automated tool.

Testing 301 Redirects

Before and after implementing any redirect, you should verify that it is working correctly. Here are the most reliable ways to test.

Using the RankNibbler Redirect Checker

The RankNibbler redirect checker is the fastest way to verify a redirect. Enter any URL and it returns the full redirect chain including every hop, the HTTP status code at each step, the response time, and the final destination URL. This is particularly useful for identifying chains and confirming that all four domain variants redirect correctly.

Using cURL (Command Line)

cURL is the most reliable command-line tool for checking HTTP responses. The -I flag fetches only the response headers without downloading the body:

curl -I https://www.example.com/old-page

To follow the full redirect chain and see headers at each step, use -L (follow redirects) combined with -I:

curl -IL https://www.example.com/old-page

The output will show the status code and headers at each URL in the chain. Look for HTTP/1.1 301 Moved Permanently followed by a Location: header at the source URL, and HTTP/1.1 200 OK at the final destination.

Using Browser Developer Tools

Open Chrome or Firefox DevTools (F12), go to the Network tab, check "Preserve log," and navigate to the URL you want to test. The redirect chain will appear as multiple entries in the network log, each showing its status code. This method is useful for debugging redirect loops because the browser will show the loop attempts before giving up.

Testing All Domain Variants

For comprehensive testing, check these four URLs for every domain:

http://example.com/path
http://www.example.com/path
https://example.com/path
https://www.example.com/path

All four should return a 301 and resolve to the same canonical final URL. If any variant returns a 200 directly (without redirecting), you have a duplicate content issue.

Bulk Redirect Management

Large sites — ecommerce stores, news publishers, enterprise sites — often need to manage hundreds or thousands of redirects at once. Manual management is not practical at scale. Here is how to approach bulk redirects efficiently.

Building a Redirect Map

Before implementing anything, create a redirect map: a spreadsheet with two columns — old URL and new URL. For a domain migration, this means crawling the old site, mapping every URL to its nearest equivalent on the new site, and flagging any URLs with no direct equivalent so you can decide whether to redirect them to a category page, the closest related page, or leave them as 404s.

The mapping process should be informed by:

Traffic data: Prioritise URLs that receive significant organic or direct traffic
Backlink data: Prioritise URLs with external backlinks, regardless of traffic
Search Console data: Check which URLs are indexed and receiving impressions
Content similarity: Map to the most topically relevant destination, not just the structurally closest one

Implementing Bulk Redirects on Apache

For Apache, large redirect lists should use a redirect map file with mod_rewrite and the RewriteMap directive rather than individual Redirect or RewriteRule lines. Processing hundreds of individual rules in .htaccess is slow; a map file is looked up in constant time:

# In httpd.conf or VirtualHost config (not .htaccess):
RewriteMap redirectmap txt:/path/to/redirectmap.txt

# In .htaccess:
RewriteEngine On
RewriteMap redirectmap txt:/path/to/redirectmap.txt
RewriteCond ${redirectmap:%{REQUEST_URI}} !=""
RewriteRule ^ ${redirectmap:%{REQUEST_URI}} [R=301,L]

The redirectmap.txt file contains one rule per line:

/old-page-1    /new-page-1
/old-page-2    /new-page-2
/old-category  /new-category

The RankNibbler .htaccess redirect generator can help you format your redirect rules correctly for Apache without writing the syntax by hand.

Implementing Bulk Redirects on Nginx

For Nginx, use a map block in your main configuration file to handle large redirect sets efficiently:

map $request_uri $redirect_uri {
    /old-page-1     /new-page-1;
    /old-page-2     /new-page-2;
    /old-category   /new-category;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    if ($redirect_uri) {
        return 301 $redirect_uri;
    }
}

Monitoring Redirects Over Time

Redirect management is not a one-time task. Set up regular monitoring to catch broken redirect chains, new 404 errors from redirected pages that were subsequently changed, and any redirects that are no longer needed (which add unnecessary server overhead).

Tools to use for ongoing monitoring:

Google Search Console Coverage report — shows 404 errors and redirect issues
RankNibbler site audit — crawls your site and flags redirect chains, loops, and broken redirects
Server access logs — show which old URLs are still being requested so you know which redirects are still active

Pro tip: After any large-scale redirect implementation, submit your XML sitemap to Google Search Console immediately. This signals to Google that you have updated your site structure and prompts a faster re-crawl of the affected URLs.

Frequently Asked Questions About 301 Redirects

Does a 301 redirect pass 100% of link equity?

Google's official guidance since 2016 is that a properly implemented 301 redirect passes the same link signals as a direct link, with no meaningful reduction in equity. Earlier beliefs about a "PageRank tax" on redirects have been largely debunked by Google's own statements. However, redirecting to a topically irrelevant page, or using redirect chains, will reduce the practical benefit you receive.

How long does it take Google to process a 301 redirect?

For frequently crawled pages (high-traffic or high-authority pages), Google typically processes a 301 redirect within days to a few weeks. For less crawled pages, it can take months. You can speed up the process by submitting your sitemap and using the URL Inspection tool in Google Search Console to request crawling of specific URLs.

Can I reverse a 301 redirect?

Yes, but it is not straightforward. Because browsers cache 301 redirects, users who have already visited the old URL will be sent directly to the destination by their browser, even after you remove the redirect. Google will eventually recrawl the old URL and remove the association with the destination, but this can take weeks or months. Reversing a 301 should be done thoughtfully, with a clear understanding that temporary ranking disruption is likely.

What is the difference between a 301 redirect and a canonical tag?

A canonical tag is a hint — it tells Google which version of a page is preferred, but it does not prevent users or bots from accessing the non-canonical version. A 301 redirect is a directive — it forces both users and bots to the destination URL and makes the source URL inaccessible. For fully decommissioned pages, use a 301 redirect. For pages you want to keep accessible but signal a preference to Google, use a canonical tag. In many cases, you should use both.

Should I use a 301 or a 302 when testing a new page design?

Use a 302 for A/B testing or design previews. A 302 tells Google the original URL is the canonical version and the test URL is temporary, so no equity is transferred and your test variant will not accumulate rankings of its own. Switching to a 301 during a test could cause Google to consolidate the two pages unexpectedly.

What happens to my rankings during an HTTP to HTTPS migration?

Most sites see little to no ranking impact from an HTTP to HTTPS migration done correctly with 301 redirects. Some sites see a modest ranking improvement because HTTPS is a positive ranking signal. The critical steps are: implement server-side 301 redirects from HTTP to HTTPS, update your XML sitemap to list HTTPS URLs, update your Google Search Console property to the HTTPS version, and update your canonical tags to point to HTTPS URLs. See our guide to HTTPS and SSL for a full migration checklist.

Do 301 redirects affect page speed?

Yes, each redirect adds one round-trip of network latency. A single 301 redirect typically adds 100–300ms of load time depending on server response time and geographic distance. This is why minimising redirect chains is important: a three-hop chain adds three times the latency of a single redirect. For performance-critical pages, direct users to the correct URL without any redirects in the first place, and update all internal links to point directly to the final destination.

Can too many 301 redirects hurt my site's crawl budget?

Yes. Every redirect requires an additional HTTP request from Google's crawler. If your site has thousands of redirect chains or poorly consolidated redirect rules, Googlebot spends more of its crawl budget following redirect hops rather than discovering and indexing new content. For large sites, this can delay indexation of new pages. Flattening redirect chains, updating internal links to point directly to destinations, and removing stale redirects for long-defunct pages all help preserve crawl budget.

What is a "soft 404" and how does it relate to 301 redirects?

A soft 404 occurs when a URL returns a 200 OK response but the page content is effectively empty, a "page not found" message, or wholly irrelevant to what was previously at that URL. Google can also treat redirect-to-homepage patterns as soft 404s, where a 301 technically works but the destination has no topical relevance to the source. Soft 404s do not pass link equity and may be excluded from the index. Avoid them by redirecting to genuinely relevant content or returning a true 404 status code for permanently deleted pages with no natural replacement.

How do I handle 301 redirects for paginated URLs?

For paginated series (e.g., /blog/page/2, /blog/page/3), if the series is being reorganised or removed, redirect each paginated URL to the first page of the series or the most relevant category page. Do not redirect all paginated URLs to the homepage. If you are merging two blog archives, redirect each old paginated URL to the equivalent paginated URL on the new archive. Avoid creating redirect chains where page 2 of the old archive redirects to page 2 of a URL that then redirects to page 1.

Is there a limit to how many 301 redirects I can have?

There is no hard limit set by Google or any HTTP standard. However, there are practical server limits. Apache processes .htaccess redirect rules sequentially, so very large numbers of individual Redirect directives can slow server response times. Use RewriteMap on Apache or map blocks on Nginx for large redirect lists to keep performance consistent. On Shopify, the platform-imposed limit is 100,000 URL redirects. Most other platforms have no practical limit beyond server memory constraints.

Do 301 redirects work for images and other non-HTML resources?

Yes. 301 redirects work for any resource type: images, PDFs, JavaScript files, CSS files, and API endpoints. If you move an image that is hotlinked from external sites or included in Google Images results, a 301 redirect will preserve the link equity from those external links and tell Google to update its index to the new image URL. For PDF documents with backlinks, 301 redirects are particularly important to preserve any link equity accumulated by the document.

Use the RankNibbler redirect checker and the .htaccess redirect generator to test and create your redirect rules. For a broader look at your site's technical health, run a free site audit or browse the SEO glossary for definitions of related terms.

Check your site now: Run a free audit on the RankNibbler homepage to see how your page scores across 30+ SEO checks, including redirect analysis, canonical tags, and duplicate content signals.

Last updated: April 2026