Apache Redirect Guide: .htaccess Rules for Common SEO and Domain Changes

Overview

If you manage redirects on Apache, the goal is usually simple: send users and crawlers from an old URL to the correct new one with the fewest possible hops and the right HTTP status code. In practice, that means deciding whether a redirect is permanent or temporary, choosing where rules should live, and avoiding conflicts between server config, CMS plugins, CDN rules, and application-level routing.

For most SEO and domain change scenarios, a 301 redirect is the default choice when the old URL has permanently moved. A 302 redirect is more appropriate for temporary routing, testing, short-lived campaign changes, or controlled maintenance situations where the original URL is expected to return. If you need a refresher on status code choice, see 301 vs 302 vs 307 vs 308 Redirects: When to Use Each Status Code.

Apache supports redirects in more than one way. Two common approaches are:

• mod_alias directives such as Redirect and RedirectMatch, which are often straightforward for one-to-one moves.
• mod_rewrite rules using RewriteEngine, RewriteCond, and RewriteRule, which are more flexible for hostname changes, pattern matching, and conditional logic.

On many shared hosting setups, .htaccess is the practical place to implement rules. On managed servers or VPS environments, placing redirects in the main Apache virtual host config is often cleaner and faster because Apache does not need to re-read per-directory rules on every request. Still, .htaccess is widely used, so it is worth having a clear set of dependable patterns.

Before changing anything, keep four principles in view:

1. Prefer one hop. An old URL should ideally redirect directly to its final destination.
2. Be consistent. HTTP, HTTPS, www, non-www, trailing slash, and uppercase rules should not fight each other.
3. Map deliberately. Redirect old content to the closest relevant equivalent, not always the homepage.
4. Test with headers. Never assume a rule works because the browser eventually lands somewhere.

A simple Apache redirect from one old page to one new page might look like this:

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

A host-level move using mod_rewrite might look like this:

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

For HTTPS enforcement:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://www.example.co.uk/$1 [R=301,L]

For a preferred host, such as redirecting www to non-www:

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

These examples are intentionally simple. In production, your final ruleset should account for existing application routes, reverse proxies, CDN behaviour, and whether your SSL termination happens at Apache or upstream. If your setup already includes canonical host logic elsewhere, duplicate redirect logic may create a redirect loop or an unnecessary chain.

For closely related guidance, it is also worth reviewing HTTP to HTTPS Redirects: Best Practices, Common Mistakes, and Testing Steps and www vs non-www Redirects: How to Choose and Configure the Preferred Version.

Maintenance cycle

A good Apache redirect setup is not a one-time job. This section gives you a repeatable review cycle so your rules stay clean as content, infrastructure, and search signals change.

A practical maintenance rhythm for most sites looks like this:

Monthly checks

• Review recent 404 logs for new broken URLs that deserve a redirect.
• Spot-check key redirect rules with a header-based redirect checker.
• Confirm important protocol and host rules still resolve in one hop.
• Look for accidental temporary redirects where permanent redirects were intended.

Quarterly checks

• Audit your top landing pages, legacy URLs, and historically linked resources.
• Check for redirect chains introduced by CMS changes, plugin updates, or platform rewrites.
• Review whether old campaign URLs, QR destinations, or shortened links still resolve correctly.
• Prune obsolete rules that no longer serve a useful purpose.

Pre-release checks

• Before a redesign, migration, taxonomy change, or domain move, export current URLs and create a redirect mapping document.
• Test staging rules separately from production, especially if both environments share common config patterns.
• Identify whether redirects should live in Apache, the CDN, the app, or a mix of layers.

Post-release checks

• Crawl old URLs and verify they resolve to the expected new destination.
• Check that high-value backlinks and bookmarked URLs reach their best matching page.
• Monitor logs for unexpected request patterns, loops, and spikes in 404s.
• Confirm analytics and campaign parameters survive redirects where needed.

One useful habit is to separate your redirect rules into logical blocks with comments. For example:

# Force HTTPS
# Preferred host
# Legacy blog URL rules
# Product category migration
# Campaign shortlinks
# One-off retired pages

This makes future reviews faster and reduces the chance that one team member adds a rule which overrides another. It also helps you identify which rules are permanent site architecture decisions and which are short-term exceptions.

If your site changes frequently, keep a companion spreadsheet or version-controlled file with these fields:

• Old URL
• New URL
• Status code
• Reason for redirect
• Date added
• Owner
• Review date

That small discipline turns ad hoc htaccess redirect edits into governed redirect mapping. For migration planning, A Market-Research Approach to Redirect Planning for Site Migrations is a useful companion read.

Signals that require updates

You do not need to rewrite your Apache rules every week, but some signals should prompt a review. These are the common cases where redirect logic often goes stale.

1. A hosting or proxy change

If you move to a new host, put Cloudflare in front of Apache, add a load balancer, or terminate SSL before traffic reaches Apache, rules based on %{HTTPS} may behave differently. In these cases, you may need to inspect forwarded headers or move some redirect logic to the edge. A rule that worked on a single-server setup can become unreliable after an infrastructure change.

2. A domain or subdomain migration

Any move from one host to another should trigger a full review of domain forwarding logic. Common examples include:

• example.co.uk to www.example.co.uk
• oldbrand.co.uk to newbrand.co.uk
• blog.example.co.uk to example.co.uk/blog/

The main risk here is layered redirects. An old domain may redirect to an old host pattern, which then redirects to HTTPS, which then redirects to a trailing slash version. That is avoidable if you design the final target first and redirect directly to it.

3. URL structure changes inside the site

If category names, product slugs, date patterns, or language paths change, revisit broad pattern rules. A regular expression that once worked well may become too aggressive and send unrelated URLs to the wrong destination.

4. Search intent and content architecture shifts

Sometimes the issue is not technical but editorial. A legacy page may have been redirected to the nearest available category during a migration, but months later a better content match now exists. That is a good time to update the redirect target. Redirect relevance matters for users and for SEO.

5. Repeated 404s in logs or analytics

If the same retired URL keeps appearing in error logs, external links, campaign materials, PDFs, or printed QR codes may still be driving traffic there. Add a targeted redirect if there is a strong replacement. For fast-moving redirect governance, see Redirect Governance for Fast-Changing Content: Lessons from High-Velocity Data Systems.

6. Redirect behaviour differs across environments

If staging, QA, and production do not behave the same way, your rule set may depend on hostnames, rewrite base assumptions, or modules that are not enabled consistently. That is a signal to review the implementation method, not only the pattern itself.

Common issues

This section covers the Apache redirect problems teams hit most often, along with practical ways to prevent them.

Redirect chains

A redirect chain happens when one URL redirects to another redirect instead of the final page. For example:

http://example.co.uk/page
-> https://example.co.uk/page
-> https://www.example.co.uk/page/
-> https://www.example.co.uk/new-page/

This slows resolution, wastes crawl budget, and complicates debugging. The fix is usually to consolidate your logic so the first response points straight to the final canonical URL. For a fuller walkthrough, read How to Fix Redirect Chains and Redirect Loops on Live Websites.

Redirect loops

A loop happens when two or more rules keep sending the request back and forth. This often comes from overlapping HTTPS, host, and application rules. For example, Apache forces non-www while the CDN forces www. Browsers will eventually report too many redirects.

To reduce loop risk:

• Define one canonical protocol and host combination.
• Keep that decision consistent across Apache, CDN, CMS, and app layers.
• Test with curl -I or similar tools rather than relying on browser behaviour.

Using 302 instead of 301 by accident

Some redirect helpers or CMS plugins default to temporary redirects. If a move is permanent, update the status code explicitly. This is especially important for high-value pages, migration rules, and long-lived domain redirects.

Overbroad pattern matching

Rules based on loose regular expressions can catch more URLs than intended. A classic example is redirecting all requests containing a keyword rather than an exact folder or slug pattern. Test edge cases before deployment, including assets, query strings, and similarly named paths.

Homepage dumping

Redirecting every retired URL to the homepage is rarely the best user outcome. It can also make troubleshooting harder because all failed mappings look superficially successful. Where no relevant replacement exists, a clean 404 or 410 may be more honest than a generic homepage redirect.

Conflicts with WordPress or other applications

Apache rules may overlap with CMS-level redirects, permalink logic, or SEO plugin behaviour. In WordPress, for example, core and plugin routing can create extra hops if Apache is also rewriting the same requests. If your site uses both server-level and application-level redirects, decide which layer owns each use case. That approach is usually easier to maintain than mixing similar logic everywhere.

Forgetting query string behaviour

Campaign links often rely on UTM parameters or other tracking values. Some redirects should preserve query strings, while others may intentionally discard them. Review this carefully if links are used in email, QR, paid campaigns, or short links.

Editing .htaccess without rollback

Because .htaccess changes can affect the whole site immediately, keep a backup before each change and use comments with dates or ticket references. On larger teams, version control is better than direct manual edits.

For more advanced decision-making between redirects and canonicalisation, see How to Use Real-Time Insights to Decide Between 301, 302, and Canonical at Scale.

When to revisit

Use this section as an action list. If any of these events happen, revisit your Apache redirect rules rather than assuming the old configuration is still correct.

• After a domain change, rebrand, merger, or subdomain consolidation
• After enabling HTTPS, replacing certificates, or changing proxy/CDN behaviour
• After modifying permalink structure, category paths, or product URL rules
• After launching a new CMS, plugin stack, or routing framework
• When recurring 404s appear in logs, analytics, or support tickets
• When important legacy URLs still attract backlinks, direct visits, or campaign traffic
• On a scheduled quarterly review, even if nothing obvious has broken

A practical revisit workflow looks like this:

1. Export the current rules. Save the live .htaccess or vhost config before editing.
2. List canonical targets. Decide your final preferred protocol, host, and path pattern.
3. Test key scenarios. Check HTTP, HTTPS, www, non-www, trailing slash, legacy URL, and campaign URL behaviour.
4. Remove extra hops. Rewrite rules so each test URL reaches its final destination in one hop where possible.
5. Verify status codes. Make sure permanent moves use 301 and temporary cases use 302 or another appropriate code.
6. Check relevance. Update old target pages if a better destination now exists.
7. Document review dates. Add a note for the next maintenance cycle.

If you want a simple baseline to return to, keep a short internal checklist for every Apache redirect review:

• Is the preferred host correct?
• Is HTTPS enforced correctly?
• Are there any redirect chains or loops?
• Do legacy URLs map to the most relevant new pages?
• Are query strings handled as intended?
• Are there temporary redirects that should now be permanent?
• Are duplicate rules present across Apache, CDN, and app layers?

The value of an Apache redirect guide is not only in the code snippets. It is in having a repeatable method for keeping those snippets aligned with the site you actually run today. As infrastructure changes, migrations accumulate, and content grows, redirect logic drifts unless someone reviews it deliberately. Treat your apache rewrite rules as part of ongoing technical maintenance, and your site will be easier to crawl, easier to debug, and less likely to lose value during change.