How to Configure 301 Redirect in .htaccess: Complete Guide

Exact Commands, Real Examples, Zero Guesswork

How to Configure 301 Redirect in .htaccess: Complete Guide

Redirect misconfiguration is one of those technical errors that leaves no obvious trace — no warning in the browser, no alert in the dashboard, just a quiet and steady loss of rankings over days and weeks. This guide was put together to give developers and site owners the exact syntax and logic needed to implement server-level rules without making the mistakes that silently cost authority.

What’s Inside This Guide

1. How Server-Level Redirects Work — and Why the Method Matters.
2. Basic Syntax and Essential Commands for Common Scenarios.
3. Advanced Rules for Complex Redirect Structures.
4. Critical Mistakes and How to Verify Everything Is Working.
5. FAQ.

How Server-Level Redirects Work — and Why the Method Matters

When a URL changes — whether because a page was moved, a domain was migrated, or a site was restructured — the server needs to communicate that change to both browsers and search engine crawlers. Without that communication, the old URL becomes a dead end: users see a 404 error, and the authority accumulated by the old URL through links, citations, and engagement history is simply lost rather than transferred to the new destination.

A permanent redirect instruction signals to crawlers that the move is intentional and indefinite. The crawler should update its index to reflect the new URL and transfer the authority signals associated with the old one. This transfer is not instantaneous — it happens over a series of re-crawls that can take days to weeks depending on the crawl budget assigned to the site and how quickly the crawler processes the signal. The guide on Google Search Console covers how to monitor this process and verify that the new URLs are being indexed correctly after any redirect implementation.

The method used to implement the redirect matters significantly. PHP-level redirects, JavaScript redirects, and meta refresh redirects all work for browsers but are less reliable for crawlers — they add processing steps, can be missed entirely, or may be interpreted as soft redirects rather than genuine permanent moves. Server-level configuration, handled in the Apache configuration file, executes before any page code runs and is the most reliable, fastest, and most authoritative method for communicating permanent URL changes to search engines.

Basic Syntax and Essential Commands for Common Scenarios

The configuration file that controls Apache server behavior is a plain text file located at the root of the website — the same directory level as the index file. It processes rules from top to bottom, applying the first matching rule it encounters. This sequential processing behavior is critical to understand before writing any rules, because the order in which rules appear determines which one fires for any given request.

The most straightforward redirect scenario — redirecting a single old URL to a new destination — uses the Redirect directive. No module activation is required; this directive is available in any standard Apache installation:

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

The structure is: directive, status code, old path (relative to root, starting with /), new full URL (absolute, including protocol and domain). The status code 301 communicates permanence. Omitting the code defaults to a temporary 302 in some server configurations — always specify it explicitly to avoid ambiguity.

For scenarios involving multiple individual pages, the Redirect directive can be repeated on consecutive lines. Each line handles one source-to-destination mapping. This approach is straightforward but becomes unwieldy for large-scale migrations where dozens or hundreds of pages need individual rules. For those scenarios, the RewriteEngine approach — covered in the next section — is more appropriate:

Redirect 301 /services/ https://www.yourdomain.com/our-services/
Redirect 301 /about-us/ https://www.yourdomain.com/about/
Redirect 301 /contact/ https://www.yourdomain.com/contact-us/

The HTTP to HTTPS migration redirect is one of the most commonly needed configurations and one of the most frequently implemented incorrectly. The correct approach uses RewriteEngine, which requires the mod_rewrite module to be active on the server — standard on most Apache installations but worth confirming before implementing:

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

The RewriteCond line checks whether HTTPS is currently off — meaning the request arrived over HTTP. If that condition is met, the RewriteRule fires and redirects the full request URL to its HTTPS equivalent. The [L] flag tells the server this is the Last rule to apply — stop processing further rules after this one. The [R=301] flag specifies the response code. Both flags are required for correct behavior.

Advanced Rules for Complex Redirect Structures

The non-www to www canonicalization redirect is a configuration that many sites need but often implement in ways that create redirect chains — the old URL redirects to an intermediate URL which then redirects to the final destination. Each hop in a chain costs page load time and dilutes the authority transfer. The correct implementation handles both the protocol and subdomain canonicalization in a single rule block rather than two separate blocks that fire sequentially:

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

This single block handles both conditions simultaneously: if the request is not HTTPS OR the host does not start with www, redirect to the canonical HTTPS www version. The [OR] between the two RewriteCond lines means either condition alone triggers the rule. The [NC] flag on the host condition makes the match case-insensitive. The result is a single-hop redirect from any non-canonical version to the canonical one, regardless of which combination of HTTP/HTTPS and www/non-www the original request used.

Full domain migrations — moving all content from one domain to another — require the redirect rules to be placed on the old domain’s server. The rules capture the full path of every incoming request and append it to the new domain, preserving URL structure across the migration:

RewriteEngine On
RewriteRule ^(.*)$ https://www.newdomain.com/$1 [L,R=301]

The (.*) pattern captures everything after the domain in the original request — the full path, including any directories and file names — and the $1 appends that captured content to the new domain URL. A request for olddomain.com/services/plumbing/ becomes newdomain.com/services/plumbing/ automatically without needing individual rules for each page. Understanding how this type of migration connects to the broader technical picture — including sitemap updates and canonical tag adjustments — is covered in the guide on XML sitemaps and robots.txt configuration, which addresses the full set of technical files that need updating after any significant URL restructuring.

• ► Always place the HTTP to HTTPS rule before any other RewriteRules — protocol canonicalization should be the first thing processed
• ► Use the [L] flag on every rule that should terminate processing — without it, subsequent rules may fire and modify the already-redirected URL
• ► Test every new rule in a staging environment before deploying to production — a syntax error in the configuration file returns a 500 error for the entire site
• ► Back up the existing configuration file before making any changes — restoration from backup is faster than debugging a syntax error under production pressure
• ► Verify that mod_rewrite is enabled on the server before using RewriteEngine rules — on shared hosting, this is usually active by default but worth confirming

Critical Mistakes and How to Verify Everything Is Working

The most destructive mistake in redirect implementation is the redirect loop — a configuration where URL A redirects to URL B, which redirects back to URL A, creating an infinite loop that browsers and crawlers cannot escape. This produces a “too many redirects” error in browsers and causes crawlers to abandon the URL entirely. Loops typically occur when the rule condition is not specific enough: a rule intended to redirect HTTP to HTTPS that doesn’t check whether HTTPS is already active will fire repeatedly, redirecting HTTPS URLs back to themselves through the HTTP version.

The second most damaging mistake is placing a 301 redirect on a URL that shouldn’t be permanently redirected — using it for temporary changes, A/B testing destinations, or seasonal content that will return. A 301 communicates to crawlers that the old URL is permanently gone and should be removed from the index. Once cached in a crawler’s memory as permanent, reversing this decision takes significantly longer than if a temporary 302 had been used. Use 302 for anything that might revert within a year. Use 301 only when the old URL will never again serve its original content.

Verification should happen at three levels: the immediate HTTP response check (confirming the status code and destination), the crawl-level check (confirming the chain has no unnecessary hops), and the search index check (confirming that the old URL eventually disappears from results and the new URL takes its place with authority intact). The guide on how to check your website positions covers the tracking approach that reveals whether authority transferred correctly — position improvements for the new URL over the weeks following migration confirm the redirect is working as intended. Monitoring in Search Console specifically for the “Page Indexing” report shows how quickly the new URLs are being processed and whether any errors are preventing correct indexing after the configuration change.

Frequently Asked Questions

Does a permanent redirect pass 100% of authority to the new URL?

Not exactly. Google has stated that some signal dilution occurs even with correct permanent redirects — estimates range from 85–99% transfer. The loss is minor and unavoidable. What matters is avoiding chains, which compound the dilution at each hop.

My site is on Nginx, not Apache. Does any of this apply?

None of the syntax shown here applies to Nginx — it uses a completely different configuration format in server block files rather than directory-level config files. The underlying redirect logic is identical, but the implementation syntax is entirely different.

Nginx redirect rules go in the server block of the site configuration, typically in /etc/nginx/sites-available/. Mixing Apache syntax into an Nginx environment produces server errors, not redirects.

How long before Google recognizes a permanent redirect and updates its index?

Typically two to six weeks for most sites. High-crawl-budget sites may see index updates within days. Low-authority sites can take longer. Monitor the Coverage report in Search Console to track progress — the old URL should move to “Excluded” status as the new one gets indexed.

Can a syntax error in the config file take down the entire website?

Yes — a syntax error returns a 500 Internal Server Error for every page on the site. This is why backing up the existing file and testing in staging before deploying to production is non-negotiable, not optional.

Should I redirect www to non-www or non-www to www?

Either is technically correct — consistency is what matters. Pick one version, implement the redirect to enforce it, and set the same version as the preferred domain in Search Console. Whichever version has more existing external links should generally be the canonical target.

Is it safe to keep old redirect rules indefinitely or should they be cleaned up?

Old rules that still fire correctly cause no harm. But accumulated redirect rules from years of migrations slow the file processing marginally and create maintenance confusion. An annual audit to remove rules for URLs that no longer exist and consolidate redundant chains is worth the time investment.

We did a domain migration six months ago and rankings never recovered. Can redirects be the cause?

Possibly, but domain migrations also affect many other ranking signals simultaneously. Check whether the redirect rules are still active and returning 301 status for old URLs. Also verify that the new domain’s sitemap was submitted and that canonical tags on all pages point to the new domain.

If the rules are correct but rankings haven’t returned, the issue may be that the new domain’s authority profile is weaker than the old one, or that content quality signals didn’t transfer because the page content changed during migration.