A permanent redirect tells browsers and search engines that a resource has moved to a new URL and that the new destination should become the long-term location. For SEO-focused site moves, Google currently recommends server-side permanent redirects whenever possible.
The two principal permanent HTTP status codes are 301 Moved Permanently and 308 Permanent Redirect. Google treats both as permanent redirect signals and may use the destination as the canonical URL.
For ordinary page navigation, both can serve the same broad SEO purpose: a permanent move. The technical distinction matters more when non-GET requests are involved. A 308 is defined to preserve the request method and body. Some older clients have historically changed a POST request to GET after certain 301 responses, which is why 308 can be useful when method preservation matters.
For a typical content-page URL change on an Apache/PHP site, a 301 remains a widely used and appropriate choice.
A persistent myth is that every 301 automatically loses a fixed percentage of ranking value. Google's current site-move documentation states that 301 and other permanent redirects do not cause a loss of PageRank. That does not mean a migration is risk-free: rankings can still fluctuate while Google recrawls URLs, processes canonical signals, and reassesses changed content.
A temporary redirect is appropriate when the original URL is expected to return as the primary location. Google follows temporary redirects but generally does not use the redirect itself as a signal that the destination should replace the source as canonical.
Common temporary HTTP redirects include 302 Found, 303 See Other, and 307 Temporary Redirect.
Both communicate a temporary move, but 307 is defined to preserve the request method and body. That difference can matter for forms, APIs, and other non-GET requests. For a conventional temporary page redirect, 302 is still common.
Do not select 302 merely because it feels safer. If the move is permanent, use a permanent redirect so your technical signals match your actual intent.
Meta refresh redirects are implemented in HTML with a refresh instruction. Google's current guidance distinguishes between an instant meta refresh and a delayed meta refresh.
Even though Google can understand meta refresh redirects, it recommends server-side redirects when possible. A server response communicates the move before the browser has to load and process an HTML document, which is generally cleaner for users, crawlers, and performance.
Google can process JavaScript redirects after rendering, but it recommends using them only when server-side or appropriate meta-refresh options are not available. A JavaScript redirect depends on rendering, and rendering can fail or be delayed.
For a normal URL migration, prefer a server-side 301 or 308. Use client-side methods as fallbacks rather than making them the default architecture.
A redirect chain occurs when the browser or crawler must follow multiple redirects before reaching the final page, for example:
/old-page → /intermediate-page → /new-page
Each extra hop creates another request and adds latency. Long chains also make migrations harder to understand and maintain.
Google says Googlebot can follow up to 10 redirect hops in a chain, but its site-move guidance recommends redirecting directly to the final destination. If a chain cannot be avoided, Google advises keeping it low, ideally no more than three hops and fewer than five.
Do not redirect large groups of unrelated retired URLs to one generic destination such as the home page. Google warns that irrelevant redirects can confuse users and may be treated as soft 404s. If several older pages were genuinely consolidated into one relevant replacement, that is a different and legitimate case.
A redirect requires an additional request before the final page can begin loading. One necessary redirect is usually not a problem, but unnecessary chains multiply that cost. This is especially noticeable on slower mobile networks or when several cross-domain handoffs occur.
Permanent redirects can remain in place for old bookmarks and external links, but your own site should not repeatedly route users through them. Update navigation, canonical tags, structured references, campaign destinations, and frequently used internal links to point directly at the final URL.
A redirect sends users and crawlers to another URL. A canonical tag can signal which URL you prefer among duplicate or very similar pages while leaving the current URL accessible. They are not interchangeable. If a page has truly moved and users should no longer use the old URL, a permanent redirect is normally the clearer solution.
Not every removed page needs a redirect. If there is no relevant replacement and the content is genuinely gone, returning an appropriate 404 or 410 can be better than redirecting visitors to an unrelated page.
Redirect SEO in 2026 is less about memorizing a single status code and more about matching the redirect to the real intent of the move. Use 301 or 308 for permanent moves, 302/303/307 for temporary ones, and server-side redirects whenever practical. Meta refresh and JavaScript redirects can be understood by Google, but they are better treated as fallback techniques for ordinary migrations.
For permanent site changes, map URLs carefully, redirect to relevant final destinations, eliminate unnecessary chains, update internal links and canonical signals, monitor Search Console, and keep the redirects active long enough for users and search engines to adapt.
Want to understand how referral redirects, source keys, and destination links can work together in a tracking workflow? Read the Cymtrack referral-link tracking guide.