What Is a 301 Redirect? An SEO Implementation Guide

A 301 tells browsers and search engines that a URL has moved permanently, then points them to the replacement through the Location header. It can preserve access and help consolidate search signals, but only when the destination is relevant, the chain is short, and the new page works.

What does a 301 redirect actually do?

I have opened a supposedly migrated URL before and watched it pass through three redirects before reaching the page. The browser eventually showed the right content, but the path was slower and harder to troubleshoot than it needed to be.

When a URL moves permanently, the server can return 301 Moved Permanently. The replacement address appears in the Location response header. A browser follows that address, and search engines can associate the old URL with its replacement.

A 301 is not an SEO checkbox. It is an HTTP response used during domain migrations, HTTP-to-HTTPS changes, URL structure changes, and page renames. A careless rule can create a loop, a long chain, or a redirect to a page that does not match what the visitor expected.

The contents of a 301 response

RFC 9110 describes a 301 response as an indication that the target resource has been assigned a new permanent URI. A minimal response looks like this:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-address

The Location header does the practical work here. The client makes a new request to that address according to its redirect policy. MDN documents 301 as the status for permanent moves, although client behavior around methods and caching still needs attention.

Use 301 when the replacement URL is expected to remain in use for the long term.

301, 302, 307, and 308 are not interchangeable

301 and 302 describe permanence. 307 and 308 also make method-preservation behavior explicit. That distinction matters for POST requests, APIs, and forms.

Sending a payment form’s POST request through a 301 can cause some clients to repeat it as GET. For an ordinary page rename, 301 is usually the sensible choice. For an API request where the method and body must survive, 307 or 308 deserves a closer look.

The difference is not only about search engines. Browser caching, CDN behavior, client implementations, and submitted form data all affect the choice.

Choose the status from the request’s lifetime and behavior. Do not select it from an SEO recommendation alone.

Why 301 redirects matter for SEO

Google Search Central lists server-side redirects, including 301 and 308, as recommended methods for permanent moves. That gives search engines a strong signal, but it is not a promise that every ranking signal transfers immediately or perfectly.

A redirect is one piece of a URL migration. The new page should be a meaningful replacement for the old page. Its canonical tag should point to the new address, the XML sitemap should contain the new URL, and internal links should stop pointing at the old one.

Sending every old product or guide to the homepage is technically easy and usually unhelpful. The visitor expected a related page. Search engines can see that mismatch too.

For a domain migration, review the Change of Address process in Google Search Console. DNS records, TLS certificates, and mail services sit outside the redirect itself, but a domain migration can break any of them if they are ignored. If DNS is involved, the existing post What Is DNS_PROBE_FINISHED_NXDOMAIN Error? can help you review delegation and resolution.

Does a 301 automatically transfer SEO value?

No. A 301 says that a permanent change happened; it does not guarantee the result you want. The signal may be weaker when the content changes substantially, the destination returns an error, the redirect chain is long, or unrelated pages are grouped under one destination.

Check the page content, title tag, and canonical value together. The post What Is a Title Tag and Why Is It Important? covers the title checks I use during this review.

Map old URLs to their closest relevant destinations. A homepage should not become the default answer for an entire site.

Configuring 301 redirects in Apache and Nginx

An Apache .htaccess rule

With Apache, mod_rewrite can redirect one old path to a new address. The virtual host must allow the relevant .htaccess file, and the rewrite module must be available.

RewriteEngine On
RewriteRule ^old-page/?$ https://www.example.com/new-page [R=301,L]

R=301 sets the response status, while L stops processing the current rule set after a match. That last flag matters when later rules would otherwise change the result.

An Nginx server block

For an entire HTTP virtual host, Nginx can use a direct return directive:

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

    return 301 https://www.example.com$request_uri;
}

$request_uri preserves the requested path and query string. A request for /product?id=42 therefore moves to the new hostname without dropping that information.

Test the configuration before reloading it:

sudo nginx -t
sudo systemctl reload nginx

The first command checks the syntax. The second reloads the running Nginx process. If nginx -t fails, stop there.

I learned to treat that first command as a hard gate after preparing a redirect change on the wrong server. I had not typed the hostname first; the red prompt and a tab-completed hostname caught me before I pressed Enter. A few seconds of checking were cheaper than explaining a broken virtual host.

That habit came from an earlier mistake at the hosting company, and it has saved me more than once since. Identify the machine, then change the configuration.

Test before publishing. Verify the old and new hostnames separately, not just the page you happen to have open in a browser.

Using WordPress for redirect rules

WordPress can manage simple redirects through an SEO plugin, a dedicated redirect plugin, or the web server. At a busy site, handling a redirect in Nginx or Apache avoids starting PHP for a request that only needs a response header.

If you use a plugin, check the exact old path. Trailing slashes, case, URL encoding, and query parameters can change the result. Pick one canonical form and make the redirect behavior consistent.

Keep an export of the rules before a migration. Thousands of redirects stored only inside a plugin may not survive a move to another server. The existing post Best WordPress SEO Plugins to Boost Rankings is useful when separating plugin capabilities from the redirect design itself.

A WordPress redirect loop behind a proxy

If WordPress runs behind HTTPS while Nginx sits behind a reverse proxy, the application may not know that the original connection was HTTPS. WordPress redirects to HTTP, the proxy redirects back to HTTPS, and the browser eventually reports ERR_TOO_MANY_REDIRECTS.

The proxy must set X-Forwarded-Proto correctly, and WordPress must trust that information only from the expected proxy. Do not blindly trust a client-supplied header from the public internet.

After adding a rule, test the login page, administration panel, images, forms, and canonical tags. A working homepage proves very little.

Moving from HTTP to HTTPS

For an HTTPS migration, the HTTP virtual host on port 80 normally redirects to the HTTPS virtual host on port 443 while retaining the path. Prepare the certificate, certificate chain, virtual host, and application URLs first. Redirecting before the certificate is ready only sends visitors toward a TLS error.

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

    return 301 https://www.example.com$request_uri;
}

Choose one preferred hostname, either www or the bare domain, in the HTTPS configuration. If both hostnames serve different content, the canonical and redirect plan becomes fragmented.

HSTS tells browsers to use HTTPS without making a future HTTP request. That is useful once the setup is stable, but a wrong policy can make rollback painful. Test the certificate, redirects, and subdomains before adding includeSubDomains.

I once investigated an expired Let’s Encrypt certificate on a bayram morning because a renewal job had stopped quietly. The redirect was working perfectly; the certificate was not. That is why I treat TLS renewal monitoring as part of an HTTPS migration, not as a separate chore.

The existing post How to Install an SSL Certificate on a VPS with Let’s Encrypt covers certificate renewal and virtual host checks.

Do not add HSTS as a bandage. First make sure every hostname and certificate path works.

Finding redirect chains and loops

A redirect chain occurs when an old URL first points to another old URL and only then reaches the final destination. A to B to C may work, but every extra request adds latency and another place for a failure. A should point directly to C.

A loop is worse: two or more URLs keep sending the request back to one another. HTTP-to-HTTPS rules and reverse proxies are frequent causes.

Inspect the response headers from the command line:

curl -I http://example.com/old-page
curl -IL --max-redirs 10 http://example.com/old-page

-I requests headers only. -L follows redirects, and --max-redirs 10 prevents curl from following an unlimited path. The Location: lines show each hop.

For a single response with headers included in the output, use:

curl -sS -D - -o /dev/null https://example.com/old-page

Browser and CDN caches can make a test look cleaner than the server really is. Try another client or a clean browser profile, and test from an appropriate network location when a proxy or CDN is involved.

I use curl before opening a browser because the intermediate responses are visible immediately. The browser shows me the destination; curl shows me how it got there.

One old URL should reach one final, relevant, indexable page through one direct 301.

Checks after applying a 301

Do not call a migration finished because three pages opened successfully. Review the old URL list, access logs, sitemap, canonical values, and Search Console reports together.

• Check that old URLs return 301.
• Confirm that the final URLs return 200.
• Verify that no chain or loop remains.
• Update internal links, canonical tags, and the XML sitemap.
• Test image, CSS, JavaScript, and form paths separately.
• Watch for unexpected 404, 5xx, and redirect spikes in the logs.
• Confirm that migrated pages are not marked noindex.

The expected sequence is simple: an old URL returns 301, the new URL returns 200, and the final page remains indexable. If the redirect ends at an error page, the existing post What Is a 404 Error and How to Fix It? provides a useful status-code checklist.

Log volume is worth watching. A broad regular expression can catch image paths, administration URLs, or API endpoints by accident, and the access log usually reveals that before a user reports it.

301 mistakes I still check for

The most common mistake is sending every old page to the homepage. A visitor following an old product or article link expects related content, not a generic front page.

Another is allowing redirect rules to grow into an unreviewed list. Adding one rule takes a minute; finding a chain created by six old rules takes longer. Connect each old address directly to its final destination.

A 301 is also the wrong choice for a temporary campaign, an A/B test, or a short maintenance window. Use 302, 307, or an application-specific approach when the original URL is expected to return.

Query strings need care. Removing every parameter can break campaign tracking or application sessions. Do not treat utm_source and an application-critical parameter such as id as the same thing.

Finally, test the configuration before reloading production. I know this sounds obvious; I have still been the person grateful for a syntax check stopping a bad change.

Keep temporary behavior temporary, preserve required parameters, and replace broad rules with explicit mappings when you can.

Before You Publish a 301 Redirect

• List every old URL that needs a destination.
• Choose the closest relevant new page for each URL.
• Use 301 only for a genuinely permanent move.
• Test Apache or Nginx syntax before reloading the service.
• Inspect HTTP headers and the complete redirect path with curl.
• Update canonical tags, internal links, and the XML sitemap.
• Monitor logs, Search Console, 404 responses, and 5xx responses after release.

Frequently Asked Questions

Sources

• RFC 9110 – HTTP Semantics — rfc-editor.org
• MDN – 301 Moved Permanently — developer.mozilla.org
• Google Search Central – Redirects — developers.google.com
• NGINX – Rewrite Module — nginx.org