What a redirect is
A redirect sends a browser or crawler that asked for one URL on to a different URL. The standard way is a server response with a 3xx status code and a Location header naming the new address. A page can also redirect itself with a meta refresh tag or with JavaScript.
Sites redirect when content moves, when they switch to HTTPS or a new domain, and when several URLs should lead to one canonical address. Applications also redirect after actions such as signing in or submitting a form.
Server-side redirects: a 3xx status plus Location
A server-side redirect happens before any page content is sent. The browser requests a URL, the server answers with a 3xx code and a Location header, and the browser requests the new URL automatically.
The rule can live in the web server, the CDN or the application, and the status code says what kind of move it is. 301 and 308 mean permanent; 302, 303 and 307 mean temporary.
Because no page is downloaded first, this is the fastest kind of redirect, and every HTTP client understands it, including crawlers, link checkers and API libraries. A permanent move of /pricing looks like this:
GET /pricing HTTP/1.1
Host: example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/plans
Content-Length: 0Meta refresh and JavaScript redirects
A meta refresh is an HTML tag that tells the browser to load another URL after a delay, such as <meta http-equiv="refresh" content="0; url=https://example.com/plans">. The server returns 200 and a normal page, and the browser follows the tag only after downloading and parsing it.
Google treats an instant meta refresh (a delay of 0) as a permanent redirect and a delayed one as temporary. A timed refresh can also move the page before a reader has finished with it, which is an accessibility problem.
A JavaScript redirect changes window.location, for example with location.replace("https://example.com/plans"). It runs only after the page and its script load, and only in clients that run JavaScript. Use replace() rather than assigning location.href, so the back button doesn't return to a page that redirects again.
Which kind of redirect to use
Use a server-side redirect whenever you can configure one. Google advises using JavaScript redirects only when server-side and meta refresh redirects aren't possible, because it sees them only if rendering the page succeeds.
- Server-side 3xx: moved or renamed pages, HTTP to HTTPS, www to non-www or the reverse, domain changes and old URLs after a migration.
- Meta refresh: static hosting that offers no redirect rules. Use a delay of 0 and put a normal link on the page as a fallback.
- JavaScript: decisions only the browser can make, such as routing inside a single-page app. Don't rely on it for permanent URL changes that search engines need to see.
- No redirect at all for a temporary outage. Return 503 with a Retry-After header on the original URLs instead of redirecting to a maintenance page.
What redirects cost users and crawlers
Each server-side redirect adds a full request and response before the real page starts loading. If the redirect crosses to another host, the browser may also need a new DNS lookup, TCP connection and TLS handshake. On a slow mobile network, that delay is easy to notice.
Crawlers pay the same cost per hop. Google's crawlers follow up to 10 redirect hops, and Google recommends redirecting straight to the final destination because chains add latency and not every client follows long ones.
Redirects can also fail in ways a working page can't. A loop never resolves, and a rule that drops the query string loses campaign tracking parameters. Sending removed pages to the homepage confuses visitors, and Google may treat it as a soft 404.
Keep internal links, canonical tags and sitemaps pointing at final URLs, so redirects only have to handle old bookmarks and external links.