How to Redirect One Web Page to Another

hdply · 2026-08-15

You moved a page, renamed a site, or want a memorable short link that lands somewhere long and ugly. Whatever the reason, the mechanics differ depending on whether you control the server — and picking the wrong method costs you search rankings or leaves visitors on a dead URL. Here are all the options, in the order you should consider them.

First, understand the difference between 301 and 302

A proper redirect is an HTTP response with a status code, and the code carries meaning:

301 Moved Permanently — this page has a new home, forever. Search engines transfer the old page's accumulated ranking signals to the new URL and eventually replace it in their index. Browsers cache it aggressively.
302 Found (temporary) — the content is elsewhere for now. Search engines keep indexing the original URL.

Use 301 for a move you don't intend to reverse, 302 for a genuinely temporary detour like a maintenance page. Getting this backwards is a common and expensive mistake: a 302 on a permanent move means the new URL never inherits the old one's standing.

Note that 301s are cached hard by browsers. If you might change your mind, use 302 until you're sure — otherwise visitors who hit the old URL once will keep being sent to the old destination from their own cache.

Option 1: A server-level redirect (best when available)

Every serious host has a way to do this without touching your HTML.

Netlify, Cloudflare Pages and similar

A _redirects file at the root of your site:

/old-page    /new-page    301
/blog/*      /articles/:splat    301

Apache (.htaccess)

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

# whole site to a new domain
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

nginx

location = /old-page.html {
    return 301 https://example.com/new-page.html;
}

This is the right answer whenever you can use it: it's fast, invisible to the visitor, and unambiguous to search engines.

Option 2: Meta refresh (when you only control the HTML)

On a single-file host — hdply included — you can't set response headers, because you're publishing a document rather than configuring a server. The redirect has to live inside the page:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="refresh" content="0; url=https://example.com/new-page">
  <link rel="canonical" href="https://example.com/new-page">
  <title>Moved</title>
</head>
<body>
  <p>This page has moved to
     <a href="https://example.com/new-page">example.com/new-page</a>.</p>
</body>
</html>

The 0 means redirect immediately. Three details make this version work properly rather than merely function:

The canonical link reinforces to search engines which URL is authoritative. Google treats an immediate meta refresh much like a 301, and the canonical removes the ambiguity.
The visible link in the body is what a visitor sees if the refresh is blocked, or if they arrive with a slow connection.
Zero delay. A non-zero delay is treated as a soft redirect and passes signals less reliably — and any delay above zero is an accessibility problem, because content that moves on its own disorients screen reader and low-vision users.

Option 3: JavaScript redirect

<script>
  location.replace('https://example.com/new-page');
</script>

Use location.replace() rather than location.href: it swaps the current history entry instead of adding one, so the back button doesn't bounce the visitor straight back into the redirect.

The weakness is that it requires JavaScript, so crawlers and anyone with scripts disabled may not follow it. It's genuinely useful for a conditional redirect — sending visitors somewhere based on language, screen size or a query parameter — which the other methods can't express.

<script>
  // send Korean-preference visitors to the Korean page
  var lang = (navigator.language || '').toLowerCase();
  if (lang.indexOf('ko') === 0) location.replace('https://example.com/ko/');
</script>

Combine it with a meta refresh as the fallback and you cover both cases.

Which method to use

Method	Needs server access	Search-engine friendly	Works without JS	Use when
301 / 302 header	Yes	Best	Yes	You control the host
Meta refresh (0s)	No	Good	Yes	You only control the HTML
JavaScript	No	Unreliable	No	Conditional redirects
Link on a notice page	No	Poor	Yes	You want people to read something first

Moving a whole site without losing traffic

Map old URLs to new ones, one by one. Redirect every old page to its closest equivalent, not all of them to the homepage — a bulk redirect to the root is treated as a soft 404 and loses the value of every page.
Put the redirects in place before announcing the move.
Keep them for at least a year. Old links live in bookmarks, emails and other people's sites far longer than you'd expect.
Update Search Console — use the Change of Address tool if the domain changed, and submit the new sitemap.
Check your inbound links. For the handful of sites sending you the most traffic, ask them to update the URL directly. A redirect is a fallback, not a substitute.
Watch for a dip. A temporary drop after a migration is normal; a drop that hasn't recovered in a couple of months means something is misconfigured.

Common questions

Does a redirect lose ranking? A 301 passes essentially all of it. Chains lose more — a redirect to a redirect to a page is slower and leakier, so always point directly at the final destination.

Can I redirect to another domain? Yes, all of these methods work cross-domain.

How do I redirect just one old page while keeping the rest? On a single-file host, publish a separate small site at the old address containing only the meta refresh page above. It's a page whose whole purpose is to point elsewhere.

Why does my browser keep going to the old destination? A cached 301. Test in a private window, or clear the cache — and this is exactly why a 302 is safer while you're still deciding.