iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To add a redirect in WordPress, edit the .htaccess file in the WordPress directory on an Apache server, place a narrowly matched RewriteRule before the generated WordPress block, test it as a temporary redirect, and change it to R=301 only after the old and new URLs work without loops. This guide shows the exact layout, common migration patterns, and recovery steps for 404s, ignored rules, and redirect loops.
First confirm that .htaccess is the right tool
.htaccess is Apache’s per-directory configuration file. Apache reads it for requests in that directory and its child directories; it is not processed by Nginx. If the site runs Nginx, put equivalent directives in the relevant Nginx server-block configuration instead of creating or changing .htaccess.
- Ask the host which web server handles the public request, especially when a reverse proxy, CDN, or managed WordPress platform is involved.
- On Apache, verify that
mod_rewriteis loaded. WordPress uses this module for pretty permalinks and URL rewriting. If it is unavailable, the host must enable it. - Locate the file in the document root or in the directory where WordPress is installed. A file in one directory does not automatically govern requests outside that directory.
- Confirm that the host allows per-directory overrides. Apache can be configured to ignore
.htaccessdirectives even when the file exists; only the host can change that policy.
These checks prevent a common false diagnosis: editing a perfectly valid rule on a server that never reads the file.
Back up the file and understand WordPress’s managed block
Download a copy of the current .htaccess file before making any change. Keep the backup outside the web root and retain the previous version until the redirect has been verified. A malformed directive can make the site return a server error, and the backup is the fastest recovery.
#1 Best Overall
A typical root-level WordPress installation has this generated block:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressThe last rule sends requests that are not existing files or directories to index.php, where WordPress resolves the permalink. The exact generated lines can differ for a subdirectory installation or a different permalink setup, so do not replace a working block with the root example blindly.
WordPress may rewrite everything between # BEGIN WordPress and # END WordPress. Keep hand-written redirects and security directives outside those markers. This preserves them when WordPress regenerates its rules.
Regenerate or restore the baseline rewrite rules
- Sign in to WordPress administration.
- Open Settings > Permalinks.
- Leave the intended permalink structure selected and click Save Changes.
Saving this screen causes WordPress to regenerate its rewrite configuration when it can write the file. The screen also displays the lines associated with the selected structure. If WordPress reports that .htaccess is not writable, copy the displayed rules into the file manually, preserving any custom rules outside the marked block.
Add one exact old-URL-to-new-URL redirect
For a site installed at the domain root, put a custom rule above the WordPress block:
# Custom redirects
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=302,L]
</IfModule>
# BEGIN WordPress
...generated WordPress rules...
# END WordPressReplace both paths and the hostname with the real values. The pattern is evaluated without the leading slash in a per-directory .htaccess file, so ^old-page/?$ matches /old-page and /old-page/, but not /old-page/extra. The optional slash is deliberate; remove it if only one form should match.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →R=302 is useful while testing because it is temporary. After you have checked the behavior from a clean browser session and confirmed that the destination is correct, change it to R=301 for a permanent redirect:
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]L means “last” for the current rewrite pass, so Apache stops evaluating later rules after this match. It does not prevent the browser from making the new request; the destination must still be able to load normally.
Rank #3
- Used Book in Good Condition
Use a path-relative destination, such as /new-page/, when the redirect remains on the same host. Use an absolute URL when changing hosts, schemes, or domains. Escape regular-expression characters in the pattern: a literal dot is written as . in Apache syntax, and characters such as ?, +, (, and ) have special meanings unless escaped.
Place rules in the right order
Apache evaluates rewrite rules in sequence. A broad front-controller rule can consume a request before a later custom redirect gets a chance to match it. Keep specific redirects first:
# Specific custom redirects come first
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-section/old-article/?$ /new-section/new-article/ [R=301,L]
RewriteRule ^old-section/?$ /new-section/ [R=301,L]
</IfModule>
# BEGIN WordPress
...generated WordPress rules...
# END WordPressOrder the most specific patterns before broader ones. A rule for ^old-section/?$ should not appear before a rule intended for a deeper path if both could match. Never put a destination in a pattern that can redirect to itself; that is a common cause of loops.
Common redirect jobs
| Job | Example pattern | Destination and cautions |
|---|---|---|
| Old slug to new slug | RewriteRule ^old-slug/?$ /new-slug/ [R=301,L] |
Use an exact path and keep the destination outside the match. |
| Several legacy paths | RewriteRule ^legacy/(one|two)/?$ /current/ [R=301,L] |
Parentheses and the pipe are regular-expression operators; test every alternative. |
| File extension change | RewriteRule ^old-file.html$ /new-file/ [R=301,L] |
Escape the dot and decide whether a trailing slash should be accepted. |
| HTTP to HTTPS | Host-specific HTTPS redirect | Use the host’s documented rule and account for reverse-proxy SSL termination; do not assume Apache can see the original scheme. |
| Root URL to a subdirectory | Rule matching the empty root path | Adapt the domain and directory names to the installation and test assets, admin URLs, and canonical links. |
| Domain migration | Old-host path to new-host path | Coordinate the redirect with WordPress Address, Site Address, DNS, HTTPS, and the new permalink structure. |
For a host-wide HTTP-to-HTTPS rule, use the provider’s documented approach when a load balancer or reverse proxy sits in front of Apache. If WordPress believes the request is HTTP while the proxy has already terminated TLS, WordPress can issue HTTPS redirects repeatedly and create an infinite loop. The fix is to configure the proxy’s forwarded-protocol handling and WordPress’s HTTPS awareness together, not to add more copies of the redirect.
Migrate a site, hostname, or installation directory safely
Changing the domain
When moving from one hostname to another, first make a complete backup, then update the WordPress Address and Site Address to the intended values. Keep the old host available long enough to serve redirects. Add host-specific rules so requests for the old domain go to the corresponding path on the new domain, and verify that the new site does not redirect back to the old host.
Moving WordPress into or out of a subdirectory
A subdirectory changes the per-directory context and often changes RewriteBase, the front-controller path, and the location of the file itself. Regenerate the rules from Settings > Permalinks after the move rather than copying a root-install block unchanged. Test the homepage, a post, a page, media files, login, and the administrator area.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Changing trailing-slash policy
Choose one canonical form and ensure that WordPress’s permalink settings, any canonicalization rule, and internal links agree. A rule that adds a slash must not redirect a URL that another rule immediately removes the slash; alternating policies produce a loop.
Changing HTTPS termination
If TLS is terminated at a proxy, the connection from the proxy to Apache may be HTTP even though the visitor used HTTPS. Confirm which forwarded headers the host supports and how WordPress is told to trust them. Test both direct HTTP and public HTTPS requests before making the redirect permanent.
Best Value
Test before committing a 301
- Save the original file and deploy the custom rule with
R=302. - Request the old URL in a private browser window or with a client that does not reuse cached redirects.
- Confirm the response points to exactly the intended destination and that the destination returns the expected success status.
- Check the old URL with and without a trailing slash, plus a nearby path that must not match.
- Check query strings, language prefixes, and case variants if your site uses them; decide explicitly which should redirect.
- Inspect the redirect chain for a second hop back to the old URL, a repeated scheme change, or an unexpected hostname.
- Only after the results are stable, change
R=302toR=301and repeat the test.
Browsers and intermediaries can cache a 301 aggressively. During troubleshooting, use a private session, a different client, or a command-line HTTP client and account for cached responses before concluding that a corrected rule is still failing.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Fix 404s, ignored rules, loops, and server errors
The rule appears to do nothing
- Confirm the request is reaching Apache, not Nginx or a proxy with its own routing rules.
- Verify that
mod_rewriteis loaded and that the host permits overrides in this directory. - Check that the file is named exactly
.htaccess, is in the active document root or WordPress directory, and is readable by the web server. - Resave Settings > Permalinks to restore the baseline and then reinsert the custom rule above the generated block.
The old URL returns a 404
Check the per-directory pattern first. In .htaccess, do not include the leading slash in the RewriteRule pattern. Remove an accidental directory prefix, correct the spelling and case, and ensure that a broader rule has not sent the request somewhere else. If the old URL is supposed to be handled by WordPress rather than redirected, verify that the baseline front-controller rules and mod_rewrite are functioning.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThe browser reports too many redirects
Draw the complete chain: scheme, hostname, path, and slash form at every hop. Make sure the destination cannot satisfy the old rule, that HTTP-to-HTTPS logic agrees with the proxy, and that slash or www/non-www canonicalization is not split between conflicting layers. Temporarily disable one custom rule at a time, test with a fresh client, and restore the known-good backup if the site remains trapped in a loop.
The site returns a 500 error after editing
Restore the backup immediately, then validate the syntax before trying again. Typical causes include an unsupported directive, a missing closing tag in an optional module block, malformed regular-expression punctuation, or a flag written incorrectly. Make one small change at a time so the offending line is identifiable.
WordPress rules keep disappearing
Move custom redirects and security rules outside the # BEGIN WordPress and # END WordPress markers. WordPress is allowed to regenerate the marked section when permalink settings are saved or rewrite rules are flushed.
Security and long-term maintenance
Rewrite rules can protect sensitive files or block unwanted request patterns, but they are not a substitute for authentication, file permissions, or application-level security. Keep such directives outside the generated WordPress block and review them for Multisite behavior before deployment; a rule safe for one site can interfere with network paths or administrative endpoints in a Multisite installation.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Keep a dated backup whenever the permalink structure, domain, HTTPS setup, or installation directory changes.
- Document the purpose and owner of each custom rule, especially temporary migration rules.
- Prefer one precise rule over a broad catch-all. Broad expressions are harder to audit and more likely to capture the destination or unrelated content.
- Remove temporary redirects after the migration window, but retain a record of the old mapping.
- After plugin, host, or proxy changes, retest representative old URLs and the canonical destination.
Choose the right redirect layer
| Layer | Best fit | Control and risks |
|---|---|---|
Apache .htaccess |
Exact path redirects and migrations on Apache shared hosting | Works before WordPress loads, but depends on Apache, mod_rewrite, override permissions, correct ordering, and careful syntax. |
| WordPress or a redirect plugin | Editors who need a dashboard-managed list and application-aware conditions | Easier to manage from WordPress, but the request must reach PHP; a broken WordPress bootstrap cannot process the redirect. |
| Nginx server block | Sites served by Nginx or a reverse proxy configured at the web-server layer | Centralized and efficient, but requires server configuration access and Nginx-specific syntax; .htaccess changes will not apply. |
| Hosting-platform rules | Managed environments that expose canonical redirects in their control panel | Operationally convenient, but precedence and syntax are platform-specific; document which layer owns each redirect. |
For a handful of stable path mappings on Apache, a narrowly scoped rule outside the WordPress markers is usually the most direct solution. Use another layer when the server does not read .htaccess, when nontechnical editors must maintain many mappings, or when redirects depend on application data.
Quick Recap
A practical pre-deployment checklist
- Apache is confirmed, or the Nginx/server-block alternative is being used.
mod_rewriteis available and overrides are permitted.- The current
.htaccessis backed up. - The WordPress-generated markers and baseline rules remain intact.
- Custom rules are outside the markers and above the broad WordPress front-controller rule.
- Each pattern matches only the intended old URL and cannot match its destination.
- Testing used a temporary redirect, a clean client, both slash forms where relevant, and a nearby nonmatching URL.
- WordPress Address, Site Address, hostname, HTTPS termination, subdirectory, and trailing-slash choices agree.
- The final permanent redirect is changed to
R=301only after verification, with a rollback copy retained.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
