How to Redirect a Page to Another Page or Website Using .htaccess

When a page on your website moves or is retired, sending visitors and search engines to the replacement URL is far better than leaving a 404 Not Found behind. On Apache hosting you do this with a .htaccess file placed in your website's document root. This guide shows you how to redirect a single page, a directory, or an entire site to a new location, which of the two Apache methods to use, and the mistakes that quietly break redirects.

Last reviewed: 27 July 2026, against Apache HTTP Server 2.4 (current stable series). This guide is written for Noiz hosting and is kept current against Apache. It complements, and does not replace, the official Apache documentation linked below.

Official Documentation Reference

• Apache HTTP Server Tutorial: .htaccess files
• mod_alias: the Redirect directive
• mod_alias: the RedirectMatch directive
• mod_rewrite directive reference
• Apache rewrite guide: redirecting and remapping URLs

Prerequisites

• A hosting account served by Apache. All Noiz shared and reseller hosting serves sites through Apache, so .htaccess directives are honoured.
• Access to your website files, either through the File Manager in your control panel, or over SFTP/FTP.
• The exact old URL path you want to redirect, and the exact destination URL.

Where the .htaccess File Belongs

The file must sit in the document root of the site (or in the subdirectory you want the rules to apply to). The document root folder name depends on the control panel your hosting uses:

• Plesk: httpdocs
• cPanel and DirectAdmin: public_html
• ISPConfig: web

The filename is exactly .htaccess, with a leading dot and no extension. It is a hidden file, so switch on Show hidden files (or dotfiles) in your File Manager or FTP client before you go looking for it. If no .htaccess exists yet, create one; an empty document root is perfectly normal for a fresh site.

Always download a copy of the existing file before you edit it. A single mistyped directive takes the whole site offline with a 500 Internal Server Error, and having the original to restore turns a crisis into a thirty second fix.

Redirect a Single Page

The simplest and most readable method uses the Redirect directive, provided by Apache's mod_alias module. Add this to .htaccess:

# Send one retired page to its replacement on the same site
Redirect 301 /oldpage.html /newpage.html

Now a request for https://yourdomain.com/oldpage.html arrives at https://yourdomain.com/newpage.html, and the 301 tells search engines the move is permanent so ranking signals follow the new URL.

Replace yourdomain.com, oldpage.html and newpage.html with your own values throughout this guide; they are examples only.

The Rules for Writing the Two Arguments

• The first argument is a URL path, never a full URL. Apache is explicit that it is a path beginning with a forward slash and that a relative path is not allowed, so write /oldpage.html and not https://yourdomain.com/oldpage.html. Get this wrong and the redirect will not fire; an invalid directive in .htaccess can take the site down with a 500 Internal Server Error instead.
• The second argument may be either a path on the same site (/newpage.html) or a complete URL on any site (https://example.com/newpage.html).
• Any query string on the incoming request is carried across automatically, so /oldpage.html?ref=news lands on /newpage.html?ref=news.

Redirect a Page to Another Website

To send a page to a different domain, give the full destination URL, and use https:// rather than http://:

# Send one page to an external site
Redirect 301 /mypage.html https://example.com/

Pointing a redirect at http:// is a common legacy habit worth breaking. The destination site will almost certainly bounce the visitor again from HTTP to HTTPS, which costs an extra round trip, loses the referrer in some browsers, and briefly exposes the request over plain text. Write the final HTTPS URL and be done in one hop.

Redirect an Entire Site to a New Domain

When you have moved a whole site and the page paths are unchanged, you want every URL to carry its path across, not to dump every visitor on the new homepage:

# Move the whole site, preserving the path of every request
RedirectMatch 301 ^/(.*)$ https://newdomain.com/$1

A request for /about/team.html then lands on https://newdomain.com/about/team.html.

Never point a whole-site redirect back at the same hostname. A rule such as Redirect 301 / https://yourdomain.com/ matches its own destination and the browser loops until it gives up with a "too many redirects" error. The old domain and the new domain must be genuinely different hostnames.

The Directory Matching Gotcha

Redirect matches the beginning of the path rather than the whole of it, and it appends whatever remains to the destination. That behaviour is useful for moving a directory:

# Move a whole directory; /old/guide.html becomes /new/guide.html
Redirect 301 /old /new

It is also the single most common surprise in this article, because that one line does not move only /old. Everything beneath it travels too, so /old/guide.html and /old/2019/archive.html are redirected as well. Matching is done on complete path segments, which is the saving grace here: a sibling file such as /oldsitemap.xml is left alone, and a rule written with a trailing slash as Redirect 301 /old/ /new/ will not catch a bare request for /old. When you want one URL and one URL only, use RedirectMatch with a regular expression anchored at both ends:

# Match this exact path and nothing else
RedirectMatch 301 ^/old$ /new

The ^ anchors the match to the start of the path and the $ to the end, so nothing longer can match. Note that in RedirectMatch the pattern is a regular expression, so a literal dot should be escaped: ^/oldpage\.html$.

When to Use mod_rewrite Instead

Older guides very often show RewriteEngine on immediately above a Redirect 301 line. That combination is harmless but meaningless: RewriteEngine belongs to the mod_rewrite module and has no effect whatsoever on mod_alias directives such as Redirect and RedirectMatch. Use one module or the other, and do not mix them in a single rule.

Reach for mod_rewrite when the redirect depends on something other than the path alone, such as the hostname, the query string, the request method, or whether a file exists. The equivalent of the first example looks like this:

RewriteEngine On

# Same redirect, expressed with mod_rewrite
RewriteRule ^oldpage\.html$ /newpage.html [R=301,L]

Two differences catch people out. First, inside .htaccess the leading slash is stripped from the path before matching, so the pattern is ^oldpage\.html$ and not ^/oldpage\.html$. Second, the flags do real work: R=301 issues a permanent redirect rather than an invisible internal rewrite, and L stops processing so later rules cannot fire as well.

Redirect All Traffic to HTTPS

This is the classic case that genuinely needs mod_rewrite, because the decision depends on the protocol rather than the path:

RewriteEngine On

# Force every request onto HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Only add this once a valid SSL certificate is issued and working for the domain, otherwise you redirect every visitor into a certificate warning.

Where to Place Rules in the File

Apache reads .htaccess from the top down, and the first redirect that matches wins. Two placement rules save a lot of confusion:

• Put your redirects above any application block. WordPress, Joomla and similar systems install a front controller block that routes anything not found on disk into the application. A redirect placed below it can be swallowed before it is ever reached.
• Never edit inside the managed markers. Anything between # BEGIN WordPress and # END WordPress is regenerated by the application and your changes will vanish on the next permalink save or plugin update. Add your rules above the # BEGIN line.

Test the Redirect Properly

Browsers cache 301 responses aggressively and often for a very long time, which is exactly why a wrong permanent redirect is so painful to undo. Test in a way the cache cannot fool you:

1. Check the raw response from the command line, which ignores browser caching entirely:

   curl -I https://yourdomain.com/oldpage.html

   Look for HTTP/2 301 (or HTTP/1.1 301 Moved Permanently) and a Location: header holding the destination you expect.
2. Confirm the destination returns 200 OK, not another redirect. Chains of redirects are slow and search engines discount them.
3. Only then test in a browser, using a private or incognito window.

If you are still experimenting, use 302 instead of 301 while you work. A 302 is temporary, is not cached in the same aggressive way, and can be changed freely. Switch it to 301 once the destination is confirmed correct.

Troubleshooting

Symptom: the whole site returns 500 Internal Server Error straight after saving. The file contains a syntax error or a directive the server does not permit in .htaccess. Restore your backup to bring the site straight back up, then reintroduce the rules one line at a time until the culprit shows itself.

Symptom: nothing happens at all and the old page still loads. The most likely causes are a first argument that is not a path beginning with a slash, the file saved with a trailing extension such as .htaccess.txt by a text editor, or the file sitting one directory above or below the real document root.

Symptom: the browser reports "too many redirects" or ERR_TOO_MANY_REDIRECTS. The destination matches the same rule that produced it. Check for a whole-site redirect pointing at its own hostname, or two rules that send traffic back and forth between each other.

Symptom: pages below the one you meant to move are redirecting as well. This is the directory matching behaviour described above, where Redirect carries everything under the path across with it. Swap Redirect for an anchored RedirectMatch when a single URL is all you want.

Symptom: the redirect works, but the browser keeps going to the old destination after you corrected the rule. The earlier 301 is cached. Verify the fix with curl -I first, then clear the browser cache or test in a private window.

Symptom: the rules disappeared by themselves. They were written inside an application-managed block. Move them above the # BEGIN marker.

Getting Help

If a redirect will not behave and the checks above have not found it, open a ticket from the Noiz client area with the domain name, the exact old and new URLs, and the .htaccess block you added. Noiz support can read the Apache error log for your site, which records the precise line that failed, and confirm whether the rule is being reached at all. On managed plans Noiz will apply and test the redirect for you.