Redirect Types & Concepts
What is a soft redirect?
A soft redirect is an informal term for any technique that sends visitors from one URL to another without issuing a proper HTTP redirect status code, specifically without returning a 3xx status code in the server response. Instead of the server responding with a 301, 302, or other redirect code that browsers and search engines understand natively, a soft redirect uses an alternative mechanism, typically a meta refresh tag, JavaScript navigation, or a page that visually suggests visiting a different URL, to move visitors without the server ever issuing a redirect response.
The original URL returns a 200 OK, the status code for a successful page load, rather than a redirect status code. From the server’s perspective the page loaded successfully. From the browser’s perspective the visitor was moved somewhere else. From the search engine’s perspective the situation is ambiguous: the URL returned success, but the content suggests the visitor should be elsewhere.
The term “soft” in soft redirect contrasts with the “hard” redirect of a proper server-side HTTP redirect, a definitive, unambiguous instruction issued at the HTTP level. A soft redirect is a gentler, less definitive mechanism that achieves a similar outcome for human visitors but communicates far less clearly to browsers, crawlers, and search engines about what is actually happening.
How a soft redirect works
Soft redirects take several forms, all sharing the characteristic that the original URL returns a 200 OK rather than a redirect status code.
Meta refresh redirect: an HTML meta tag in the page head that instructs the browser to navigate to a new URL after a specified delay:
The server returns the page with a 200 OK. The browser loads the HTML, parses the meta tag, and navigates to the destination. From the HTTP response perspective this is a successful page load; the redirect happens at the HTML parsing level, not the HTTP response level.
JavaScript redirect: JavaScript code that executes in the browser and navigates to a new URL:
Again the server returns a 200 OK with the page content. The JavaScript executes in the browser after the page loads and initiates navigation. The HTTP response contains no redirect instruction, only the page content that triggers client-side navigation.
“Page has moved” content without redirect: a page that displays a message telling visitors the content has moved, “This page has moved to [link]”, but returns a 200 OK rather than a redirect. The visitor must click the link manually rather than being redirected automatically. This is the most passive form of soft redirect; it communicates the move to human visitors through on-page content rather than through any automated redirect mechanism.
Canonical tag without redirect: a page that returns a 200 OK but includes a canonical tag pointing to a different URL as the preferred version. This is not technically a redirect at all, no visitor is moved anywhere, but it is sometimes described as a soft redirect because it signals to search engines that the canonical URL is elsewhere without actually redirecting visitors.
Soft redirect vs hard redirect
The distinction between soft redirects and hard redirects maps cleanly onto the difference between client-side and server-side redirects, with one addition: the “page has moved” content approach that does not automatically redirect at all.
A hard redirect: the correct term for a proper server-side HTTP redirect, issues a 3xx status code and Location header before any content is delivered. The browser is definitively instructed to go to a new URL. The instruction is unambiguous, standardised, and processed by every browser and crawler identically. The original URL returns a redirect code, not a 200.
A soft redirect returns a 200 OK and uses some other mechanism, HTML, JavaScript, or on-page content, to suggest, encourage, or force the visitor to a new URL. The instruction is less authoritative, less standardised, and processed differently by different browsers and crawlers. The original URL appears to be a live, successful page from the HTTP response perspective.
For human visitors the practical difference is often invisible; both result in the visitor ending up at the destination. For search engines the difference is significant: a hard redirect carries clear permanent or temporary signals and passes SEO equity according to standardised rules. A soft redirect is ambiguous; the search engine must infer intent from non-standard signals.
Why soft redirects exist
Soft redirects are almost always a workaround: a solution chosen because the correct approach was unavailable, unknown, or inconvenient rather than because it was the best tool for the job.
No server access: the most legitimate reason for using a soft redirect. Some hosting environments, basic HTML-only hosts, certain static site platforms, CMS environments with no redirect configuration capability, provide no way to configure server-side redirects. A meta refresh or JavaScript redirect is the only available mechanism for moving visitors from one URL to another. This is a genuine constraint that justifies a soft redirect as a temporary measure while proper hosting is arranged.
CMS limitations: some content management systems do not expose server-side redirect configuration to content editors. A CMS that allows authors to add meta refresh tags to page templates but not to configure HTTP redirects produces soft redirects by default. The correct solution is to implement proper redirect management at the server or CDN level, but soft redirects may be the only option within the CMS interface.
Unfamiliarity with proper redirects: many soft redirects exist simply because the person implementing them was not aware of the correct approach. A developer who knows how to add a meta refresh tag to a page but does not know how to configure a server-side redirect may implement a soft redirect without realising the difference matters.
Fear of permanent changes: some developers use soft redirects when they are uncertain about the permanence of a URL change. A meta refresh feels less definitive than a 301 redirect because it can be removed from the page without any server configuration change. This reasoning is understandable but incorrect; the correct approach for uncertain permanence is a 302 temporary redirect, not a soft redirect.
Soft redirects and SEO
The SEO implications of soft redirects are consistently worse than proper server-side redirects and are the primary reason to avoid them for any URL that matters for search visibility.
Ambiguous status code: a soft redirect returns a 200 OK on the original URL. Search engines receive a success signal rather than a redirect signal. They must determine from the page content, the meta refresh tag or JavaScript code, that a redirect is intended. This inference is less reliable than a definitive 3xx status code.
Uncertain SEO equity transfer: Google has stated it attempts to follow meta refresh redirects and pass link juice through them, but the transfer is less reliable than through a 301 redirect. For JavaScript redirects specifically the equity transfer is even less reliable because the redirect is discovered in a second rendering wave rather than the initial crawl. For URLs with significant backlink profiles, using soft redirects risks losing equity that a proper 301 would have transferred.
Duplicate content risk: because the original URL returns a 200 OK, search engines may index it as a standalone page separate from the destination. If both the original and destination contain similar content, duplicate content issues arise that a hard redirect would have prevented by making the original URL inaccessible.
Index update delays: a proper 301 redirect is a clear signal for search engines to update their index: replace the old URL with the new one. A soft redirect is ambiguous; search engines are less certain what to do with a 200 OK page that appears to redirect visitors. Index updates for soft redirects are slower and less predictable than for hard redirects.
Crawl budget inefficiency: a soft redirect using JavaScript requires Googlebot to process the page in two waves: the initial HTML crawl and a subsequent JavaScript rendering pass. The destination URL is discovered in the rendering wave, which may occur significantly later than the initial crawl. This two-wave process consumes more crawl budget per redirect than a hard redirect that resolves in a single request.
Soft redirects in MediaWiki and Wikipedia
One specific context where “soft redirect” has a formalised meaning is in MediaWiki, the software that powers Wikipedia. In this context a soft redirect is a legitimate, intentional feature rather than a workaround.
A MediaWiki soft redirect is a short page that informs visitors the content they are looking for is at a different page, typically on a different wiki or in a different namespace, and provides a link to it. Unlike a hard redirect which automatically moves the visitor to the destination, a MediaWiki soft redirect displays the “this page is a redirect to” message and lets the visitor choose to follow it.
This is used specifically in cases where automatic redirection would be inappropriate: redirecting between different wikis, redirecting to pages that should be visited intentionally, or handling special cases where the automatic redirect behaviour would cause confusion. In this context the soft redirect is a deliberate editorial choice, not a workaround for missing functionality.
This MediaWiki-specific meaning of soft redirect is distinct from the broader web development meaning discussed throughout this article. The term is used consistently across both contexts but refers to different things: the MediaWiki soft redirect is an intentional editorial tool, while the general web development soft redirect is typically an imperfect substitute for a proper HTTP redirect.
Soft redirects in e-commerce
E-commerce platforms are a common source of soft redirects, particularly for out-of-stock products, discontinued items, and category reorganisations.
Out-of-stock product pages: a product that is temporarily out of stock may display a page encouraging visitors to browse related products rather than returning a 404 error or hard redirect. This page returns a 200 OK with soft redirect content, effectively a “page has moved” experience without an actual redirect. For temporary out-of-stock situations this may be appropriate. For permanently discontinued products a 410 Gone or 301 redirect to the most relevant alternative is better.
Category page reorganisation: when product categories are reorganised, a CMS may create pages at old category URLs that display a message directing visitors to the new category rather than configuring server-side redirects. These soft redirects accumulate over time and create duplicate content and crawl budget issues if not addressed.
Pagination and filter URLs: some e-commerce platforms serve near-identical content at multiple paginated or filtered URLs and use canonical tags as a form of soft redirect to indicate the preferred version. This is a legitimate use of canonical tags for canonicalisation but should be supplemented with proper URL management to avoid crawl waste on filtered URLs.
Detecting soft redirects
Soft redirects are detectable through the same tools used for any redirect analysis.
curl: curl -I https://example.com/old-page returns only the response headers. A soft redirect returns 200 OK rather than a 3xx status code. The 200 response where a redirect was expected is the primary indicator.
Viewing page source: a soft redirect via meta refresh is visible in the page source as a <meta http-equiv="refresh"> tag in the head. A JavaScript redirect is visible as window.location code in a script block.
Browser developer tools: a URL that shows a 200 OK in the Network tab but causes the browser to navigate to a different URL is using a client-side redirect, either meta refresh or JavaScript. The navigation event after the initial 200 response is the soft redirect in action.
Google Search Console: the Coverage report may surface URLs that are returning 200 OK but show signs of being redirect intermediaries: pages with thin or templated content, high crawl frequency with low indexing value, or URLs that Googlebot has flagged as soft 404s.
Replacing soft redirects with proper redirects
Wherever a soft redirect exists and server access is available, replacing it with a proper server-side redirect is straightforward and always the right decision.
Identify the source URL: the page containing the soft redirect. Identify the destination: the URL the meta refresh, JavaScript, or on-page content is pointing to. Determine the appropriate HTTP status code: 301 for permanent moves, 302 for temporary. Configure the redirect at the server level: .htaccess file, Nginx config, CDN rule, or redirect management platform. Remove the soft redirect mechanism from the source page. Verify using curl or browser developer tools that the URL now returns a 3xx status code rather than a 200.
For soft redirects on platforms where server-side configuration is not accessible, the correct long-term solution is to migrate to a hosting environment or redirect management platform that supports proper HTTP redirects. In the interim, a meta refresh with a zero-second delay is the least bad soft redirect option; it is processed more reliably by search engines than JavaScript and does not require JavaScript to be enabled.