How to Create a 301 Redirect in WordPress Using .htaccess

A 301 redirect sends visitors and search engines from an old URL to a permanent replacement. On Apache-based WordPress hosting, you can create one in .htaccess before WordPress handles the request. This is fast and useful for migrations, but a syntax error can affect the entire site, so every change needs a backup and a precise target.

The examples below assume Apache with mod_rewrite or mod_alias available. Nginx does not read .htaccess, and managed hosts or reverse proxies may provide a different redirect layer.

What is a 301 redirect?

An HTTP 301 response tells a client that a resource has moved permanently. The response includes a Location header containing the destination. Browsers follow it, and search engines can consolidate indexing signals toward the new URL over time.

Use a 301 when the old address should not return: a renamed page, a permanent domain migration, an HTTP-to-HTTPS move, or one canonical hostname. The destination should be the closest relevant replacement. Redirecting every deleted URL to the homepage is rarely helpful.

301 vs 302 redirect

Status	Meaning	Typical use
301	Permanent move	Retired URL, canonical hostname, permanent migration
302	Temporary move	Short test, maintenance route, temporary campaign

Choose based on intent. If the original URL will return, a temporary response is more accurate. If the move is permanent, use 301 and update internal links so visitors do not rely on the redirect indefinitely.

Where is the WordPress .htaccess file?

On a typical Apache installation, .htaccess is in the WordPress root—the directory containing wp-admin, wp-content, and wp-config.php. Files beginning with a dot may be hidden, so enable “show hidden files” in the hosting file manager or SFTP client.

A subdirectory installation can have a different rewrite context. Multisite and managed hosting can also use specialized rules. If the file does not exist or the host says it is not supported, do not create rules blindly; consult the platform documentation.

Back up .htaccess before making changes

1. Download a copy of the current .htaccess file.
2. Keep the hosting file manager or SFTP connection open.
3. Make one small change at a time.
4. Test the old URL in a private browser window and inspect the final address.
5. Restore the backup immediately if the site returns a 500 error.

Do not edit the lines between # BEGIN WordPress and # END WordPress for custom rules. WordPress can regenerate that block when permalink settings change.

Need a redirect rule?

Choose the redirect type and enter the source and destination in the free WPToolix generator. Review the generated hostname and path before adding the rule to your server.

Redirect one WordPress page to another

For a simple path-to-URL redirect, Apache’s Redirect directive is readable and does not require a regular expression:

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

Replace example.com with your real destination domain. The source is a URL path, not a filesystem path. Be careful with broad prefixes because Redirect can match additional path information. For exact matching or conditional logic, use RewriteRule:

RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

In per-directory .htaccess context, the pattern does not begin with a slash. The optional /? accepts the path with or without a trailing slash, and L stops later rules from handling that request.

Redirect HTTP to HTTPS

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

This preserves the current hostname, path, and query string while changing the scheme. Confirm that a valid TLS certificate is already active before enabling it. If WordPress sits behind Cloudflare, a load balancer, or another reverse proxy, Apache may not see the visitor’s original HTTPS state. Use the host’s documented HTTPS redirect instead of adding a rule that creates a loop.

Redirect www to non-www

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

This runs only when the hostname begins with www. and redirects to the captured hostname without that prefix. Use the opposite rule if www is your preferred canonical hostname. Ensure both hostnames resolve to the server and are covered by the TLS certificate.

Redirect an old domain to a new domain

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(?:www\.)?oldsite\.com$ [NC]
RewriteRule ^ https://newsite.com%{REQUEST_URI} [R=301,L,NE]

Replace both example domains. Escaping the dot in the old hostname makes it a literal dot rather than a regular-expression wildcard. The condition limits the rule to the old domain, while REQUEST_URI preserves the path. Query strings are preserved by default when the destination does not introduce a new query string.

Test representative URLs before a full migration. A preserved path only helps when equivalent pages exist on the new domain. Create explicit mappings for changed paths and avoid redirect chains from old HTTP to old HTTPS to the new host.

Generate .htaccess redirect rules automatically

The WPToolix .htaccess Redirect Generator creates rules for common page, HTTPS, hostname, and domain scenarios. Enter real paths and domains, copy the output, and compare it with existing conditions before saving.

A generator reduces typing mistakes but cannot know your proxy, multisite, subdirectory, or hosting-specific configuration. Keep the backup and test the response in the actual environment.

Where should custom redirects go in WordPress .htaccess?

Custom redirects are commonly placed before the standard WordPress rewrite block so they run before WordPress’s catch-all rule. Keep them outside the generated markers:

# Custom redirects
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

# BEGIN WordPress
# WordPress-generated rules remain here
# END WordPress

Placement can depend on inherited server configuration, other applications, and the type of directive used. Existing security, cache, or hosting rules may need to remain first. Preserve their order and follow provider documentation when it differs.

What to do if .htaccess causes a 500 error

1. Restore the known-good backup through SFTP or the hosting file manager.
2. Check the server error log for the rejected directive or syntax error.
3. Look for missing spaces, unmatched characters, unsupported flags, or directives unavailable on the host.
4. Reapply one rule at a time.
5. Ask the host whether Apache overrides and mod_rewrite are enabled.

If removing your custom block does not resolve the error, do not replace the standard WordPress rules casually. The problem may be elsewhere in the server or PHP configuration.

Test redirects without hiding problems

Browsers cache permanent redirects aggressively. During setup, test with a private window, a command-line HTTP client, or developer tools with caching disabled. Check the response headers rather than judging only by the page that eventually appears.

Test the exact old URL, trailing-slash variants, query parameters, uppercase paths where relevant, and unrelated pages that should remain untouched. Also check for chains and loops. A request should normally reach its final destination in one redirect. After verification, update WordPress menus, page content, canonical references, and sitemaps to use the final URL directly. Redirects are a safety net for old links, not a replacement for maintaining current internal links.

Frequently asked questions

Do .htaccess redirects work on Nginx?

No. Nginx ignores .htaccess. Add redirects to the appropriate Nginx server configuration or use the control provided by your managed host.

Does a 301 redirect pass the query string?

Apache rewrite rules normally preserve the original query string when the substitution does not define a new one. Test URLs containing parameters because other rules or applications can alter the result.

Can I redirect several old pages?

Yes. Use a separate exact mapping for each page when destinations differ. A carefully designed pattern can cover predictable groups, but broad regular expressions are easier to get wrong.

Will changing .htaccess affect WordPress permalinks?

It can. A rule that matches too broadly may intercept requests before WordPress receives them. Keep custom rules outside the generated block and test posts, pages, archives, feeds, and the admin area.

How do I verify a 301?

Open the old URL in a private window and inspect the network response with browser developer tools or an HTTP header checker. Confirm the first response is 301, the Location is correct, and the destination returns a successful status without a chain.