How to Set Up 301 Redirects in Apache .htaccess

Overview

A 301 redirect tells browsers and search engines that a URL has moved permanently. In practical terms, it is the standard tool for sending traffic from an old page to a new one, consolidating duplicate URL versions, and guiding site migrations without leaving broken paths behind.

On Apache, many website owners implement redirects in the .htaccess file. This works well on shared hosting and on Apache setups where per-directory overrides are enabled. It is not always the only option; in some environments, redirects are better managed in the main virtual host configuration. But for many teams, .htaccess remains the fastest place to create and maintain redirect rules.

Before you edit anything, keep three principles in mind:

• Be exact about the destination. A redirect should point to the final preferred URL, not an intermediate step.
• Choose permanence intentionally. Use 301 only when the move is meant to last. If the change is temporary, a different status code may fit better. If you need a refresher, see 301 vs 302 vs 307 Redirects: When to Use Each for SEO and User Experience.
• Test every scenario. One working example does not prove the rule is safe. Check HTTP and HTTPS, with and without www, trailing slash variants, and common legacy URLs.

It also helps to know which Apache module your syntax depends on. Simple redirects can use mod_alias directives like Redirect 301. Pattern-based rules usually rely on mod_rewrite with RewriteEngine On, RewriteCond, and RewriteRule. In many hosting environments both are available, but your configuration may vary.

As a general rule, use the simplest directive that solves the problem. A single-page move does not need a complex regular expression. Fewer moving parts usually means fewer surprises later.

Checklist by scenario

Use this section as the working part of the guide. Pick the scenario closest to your need, apply the example carefully, and then test the exact URLs involved.

1. Redirect one old page to one new page

Use this when: a page has been renamed, moved, or replaced by a clear equivalent.

Checklist:

• Identify the exact old path and exact new path.
• Keep the redirect as direct as possible.
• Update internal links so users and crawlers stop relying on the old URL.

Example using mod_alias:

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

Notes: This is often the cleanest option for simple one-to-one moves. Use an absolute destination URL for clarity, especially when protocol or hostname may also be changing.

2. Redirect an entire directory to a new directory

Use this when: a section of the site has moved, such as /blog/ to /articles/.

Checklist:

• Confirm that the new directory structure matches the old one closely enough for pattern-based forwarding.
• Review exceptions before applying a broad rule.
• Check a sample of old URLs from the directory, not just one.

Example using mod_rewrite:

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

Notes: This keeps the remainder of the path and moves it to the new directory. If some pages no longer have direct replacements, do not force them all to the same generic page unless that is truly the best user outcome.

3. Redirect a page extension change

Use this when: URLs are changing from .php to extensionless versions, or from older file-based paths to cleaner URLs.

Example:

RewriteEngine On
RewriteRule ^products/(.*)\.php$ https://example.com/products/$1/ [R=301,L]

Checklist:

• Make sure the new URL format already resolves correctly.
• Check for collisions where two old filenames would map to the same new path.
• Confirm that canonical tags and internal navigation use the new version.

4. Force HTTP to HTTPS

Use this when: your site should only load over HTTPS.

Example:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Checklist:

• Install and validate the SSL certificate first.
• Make sure the destination hostname is the preferred one.
• Test assets, forms, and mixed content after launch.

For a broader migration workflow, see HTTP to HTTPS Redirect Checklist for Websites, Subdomains, and Legacy URLs.

5. Force non-www to www, or www to non-www

Use this when: you want one canonical hostname.

Example forcing non-www to www:

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

Example forcing www to non-www:

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

Checklist:

• Choose one host version and use it consistently.
• Combine this carefully with your HTTPS redirect logic.
• Update canonical tags, sitemap entries, and important backlinks where possible.

If you are deciding between hostnames, read WWW vs Non-WWW Redirect Strategy: Best Practices for Canonical Consistency.

6. Redirect an old domain to a new domain

Use this when: a brand, product, or site has moved domains permanently.

Example:

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

Checklist:

• Keep the old domain active long enough to serve redirects reliably.
• Map high-value legacy URLs to their closest matching new URLs.
• Avoid sending everything to the home page unless there is no relevant replacement.

For larger migrations, document your URL mapping before launch. That step matters more than clever rewrite syntax.

7. Redirect a retired URL to the closest relevant replacement

Use this when: a page no longer exists, but another page satisfies the same intent.

Checklist:

• Look at backlinks, traffic history, and internal references before choosing the target.
• Prefer relevance over convenience.
• If no meaningful replacement exists, a 404 or 410 may be more honest than a weak redirect.

This is especially useful when trying to fix broken backlinks without creating soft, confusing destinations.

8. Redirect with query string awareness

Use this when: old campaign or application URLs include parameters and the destination depends on them.

Example:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^ref=partnerA$
RewriteRule ^landing/$ https://example.com/partner-landing/? [R=301,L]

Notes: The trailing ? clears the original query string in this example. Be deliberate here. Some analytics parameters should be preserved; some legacy parameters should be dropped.

If redirected links are part of a campaign workflow, pair redirect governance with tracking discipline. Related reading: Real-Time Analytics for Website Owners: What to Log, What to Ignore, and What to Automate.

What to double-check

Once the rules are in place, the real work is verification. A redirect that appears correct in one browser tab can still fail under different host, protocol, or path conditions.

Check the status code

Make sure the server returns an actual 301 response. Do not assume a browser jump means the server sent the intended code. Use your preferred redirect checker, browser developer tools, or command-line requests to verify the chain and status code.

Check for chains

An old URL should go straight to the final URL in one step where possible. A common mistake is stacking rules so that a URL first moves from HTTP to HTTPS, then from non-www to www, then from an old path to a new path. That may still work, but it is inefficient and harder to maintain.

Where practical, consolidate logic so each old URL lands on the preferred final destination directly. For cleanup strategies, see How to Fix Redirect Chains and Loops Before They Hurt SEO and Speed.

Check for loops

Loops often happen when one rule rewrites a URL and another rule immediately sends it back. Test both the old and new versions of affected URLs. If the browser reports too many redirects, review hostname conditions, trailing slash behavior, and any application-level redirects that may conflict with Apache.

Check rule order

Apache processes rules in sequence. A broad rule placed too high can swallow traffic meant for a specific exception beneath it. Put your most specific redirects before wider catch-all patterns, and comment your logic so future edits do not break it accidentally.

Check trailing slash behavior

/page and /page/ may not behave the same way in every setup. Decide which format is canonical and test both. This matters more during migrations and CMS changes, where slash handling often shifts silently.

Check internal links and canonicals

Redirects are a safety net, not a substitute for internal cleanup. Update navigation, XML sitemaps, canonical tags, hreflang references if relevant, and structured references inside templates so they point to the destination URL directly.

Check application and platform conflicts

WordPress, CMS plugins, framework routing, CDN rules, and Cloudflare page rules can all add their own redirect behavior. If Apache and another layer are both trying to canonicalize the same URL, you can get duplication or loops. Keep a simple record of which system owns which redirect responsibility.

Common mistakes

Most redirect problems are not caused by complicated technology. They usually come from rushed changes, unclear ownership, or broad rules applied without enough testing.

Using 301 for a change that is not actually permanent

If the destination may change back soon, think carefully before using a permanent redirect. A 301 is best when the move is intended to last.

Redirecting all removed pages to the home page

This is one of the most common weak implementations. It may save time, but it often creates a poor experience for users who expected a specific answer. Whenever possible, redirect to the closest relevant page instead.

Mixing Redirect and RewriteRule without a plan

Both can be valid, but mixing them casually increases the chance of overlap. If you use both, document why and check the final execution path carefully.

Forgetting that .htaccess is context-sensitive

Rules in a root .htaccess file behave differently from rules in a subdirectory. Paths and patterns may need adjustment depending on where the file lives.

Writing patterns that are too broad

A regular expression meant to catch one class of URLs can unintentionally catch many more. Start with the narrowest match possible, then widen only if testing shows it is safe.

Ignoring case and hostname variants

Some requests may arrive with uppercase characters, alternate subdomains, or legacy aliases. If those variants matter, account for them explicitly.

Leaving temporary migration rules in place without review

Over time, one-off rules accumulate. That can slow troubleshooting and increase the risk of conflicts. Keep a change log and prune rules that no longer serve a purpose.

When to revisit

A redirect setup is never fully finished. The best time to revisit your Apache 301 rules is before a change, not after traffic drops or users start reporting dead links.

Revisit your rules when:

• You rename categories, products, or service pages.
• You change CMS permalink settings or URL patterns.
• You move from HTTP to HTTPS or change your preferred hostname.
• You migrate to a new domain or merge sites.
• You launch seasonal campaigns that create temporary landing pages you may retire later.
• You audit backlinks and discover old URLs still attracting authority or referrals.
• You add CDN, proxy, or application-level redirect logic that may overlap with Apache.

Use this maintenance checklist each time:

1. Export or list affected old URLs.
2. Map each old URL to the best final destination.
3. Write the simplest possible Apache rule.
4. Place specific rules before broad ones.
5. Test status codes, chains, loops, hostname variants, and protocol variants.
6. Update internal links, canonicals, and sitemaps.
7. Monitor logs, analytics, and crawl behavior after deployment.
8. Document what changed and why.

If your redirect rules are becoming difficult to reason about, that is usually a sign to simplify them, move some logic into server config, or review whether another platform layer should own part of the process. Good redirect management is not about collecting more rules. It is about preserving clarity as the site evolves.

Done well, an Apache 301 redirect setup becomes a dependable part of your technical SEO foundation: old links keep working, users reach the right content, and future changes become easier to manage instead of harder. Save this checklist and return to it whenever your URL structure, hostname strategy, or migration plan changes.