JavaScript and Meta Refresh Redirects: What Google Does

Google follows both JavaScript redirects and meta refresh redirects, and it will usually consolidate the old URL into the new one. But it does so less directly than it follows a 301, and the difference matters. A server-side redirect is answered in the HTTP response before any page content exists. A client-side redirect is only discovered after the page has been fetched, parsed and, in the case of JavaScript, rendered. Google's own documentation treats server-side redirects as the preferred mechanism and describes the client-side kinds as something to use only when you cannot do better.

This guide is about that second situation. It covers what each client-side method actually is, how Google processes it, where the failures hide, and what to do when you genuinely have no access to the server configuration. It deliberately does not cover migration planning or crawl-error triage, which are server-side topics with their own posts.

The short version: a client-side redirect is a fallback, not a peer of the 301. It can work well enough to pass signals to the destination, but it is slower to be recognised, easier to break, and invisible to anything that does not execute your page.

The Three Kinds of Client-Side Redirect

A redirect that happens in the browser rather than on the server comes in a few forms, and they behave differently enough that lumping them together causes confusion.

The meta refresh is an HTML tag in the head of the document, such as a meta element with http-equiv set to refresh and a content value like "0; url=https://example.com/new-page/". The number is the delay in seconds before the browser jumps. The page must be downloaded and its head parsed before anything happens, but no script is needed. The JavaScript redirect sets a new location from code, usually by assigning to window.location.href, calling window.location.replace, or calling window.location.assign. It needs a browser (or a crawler) that executes scripts. The third form is the HTTP Refresh header, a response header that does the same job as the meta tag. It is rare, and it is set on the server, so if you can set it you could almost always set a proper 301 instead.

A fourth thing is often mistaken for a redirect: a page that loads normally and then swaps its content with JavaScript, or a link that navigates only after a click handler runs. Neither changes the URL a crawler fetched, and a crawler that does not click will never see the second page. Treat those as navigation features, not redirects.

The practical differences between the first two come down to dependency. A meta refresh needs only HTML, so any crawler that parses the head can read it. A JavaScript redirect depends on script execution, which for Google means the rendering stage rather than the initial crawl.

How Google Processes Each One

Google documents its handling of redirects in its guidance on redirects and Google Search. It lists meta refresh and JavaScript location changes as supported methods, alongside the server-side status codes, and says that it follows them.

For meta refresh, Google distinguishes by delay. An instant refresh, meaning a zero-second delay, is interpreted as a permanent redirect. A refresh with a delay is interpreted as a temporary one. That is a sensible reading of intent: a page that bounces the visitor immediately is clearly not meant to stay, while a page that shows a message for several seconds before moving is closer to a temporary notice.

For JavaScript redirects, Google has to render the page to see them. Googlebot fetches the HTML, queues the page for rendering, and executes the scripts in a headless Chromium-based renderer. Only then does the location change show up. The redirect target is then processed as a followed redirect, and Google's documentation says it will attempt to follow it. This is the same two-stage pipeline described in our post on how Google renders JavaScript sites, and everything that can go wrong there can go wrong with your redirect.

What Google does not promise is equivalence. Its documentation recommends server-side redirects wherever possible and says client-side methods are less reliable. You should not read that as "these are ignored". You should read it as "these depend on more moving parts, and we make no guarantee about speed or consistency". In practice that means the old URL may linger in the index longer, the destination may be discovered on a different schedule, and the signal consolidation you expect from a 301 arrives more slowly and less predictably.

Client-Side Redirects Compared With a 301

The clearest way to compare them is by what each one requires before the crawler learns about the move.

• Discovery. A 301 is known the moment the response headers arrive. A meta refresh is known after the HTML head is parsed. A JavaScript redirect is known only after rendering, which can trail the crawl.
• Crawl cost. With a 301 the crawler downloads almost nothing. With a client-side redirect it downloads the whole document, and for JavaScript also fetches and executes scripts. On a large site that is a real addition to the crawl budget spent on stale URLs.
• Permanence signal. A 301 says plainly that the move is permanent. An instant meta refresh is read as permanent by Google, but a JavaScript redirect carries no status code at all, so the permanence has to be inferred.
• Non-Google clients. Many crawlers, link checkers, social preview fetchers and AI retrieval tools do not execute JavaScript. They see the original page, not the destination. A 301 works for all of them.
• Failure mode. A 301 fails loudly with a visible status. A JavaScript redirect can fail silently: a blocked script, a runtime error or a timeout leaves the crawler looking at an empty or stub page.

Where Client-Side Redirects Break

Most redirect problems in practice are not a question of whether Google supports the method. They come from the conditions around it.

Blocked resources. If the script that performs the redirect lives in a file that robots.txt disallows, the renderer never runs it. The crawler sees the source page, which may be a nearly empty shell, and indexes that instead. Check that the scripts involved are crawlable, the same way you would for any rendering-dependent content.

Redirects gated on user behaviour. Code that redirects only after a click, a scroll, a cookie check or a timer longer than the renderer will wait is unreliable. Googlebot does not interact with a page the way a person does. A redirect that depends on a 'Continue' button is not a redirect a crawler will follow.

Conditional redirects by device, language or location. Sending visitors to a different URL based on browser language or IP address, through JavaScript, means the crawler sees only the version its own profile triggers. The other versions can become undiscoverable. Offer a visible link or selector and let the user choose instead of forcing a jump.

Redirect chains and loops. Mixing a server 301 with a meta refresh and then a JavaScript hop adds latency at every step, and the processing of each step is separate. Keep it to one hop. A loop, where two pages each redirect to the other, simply never resolves.

Redirecting to an error or an unrelated page. A JavaScript redirect from a removed product to the home page, or to a generic error page that returns a 200 status, is read the way a soft 404 would be. Google may decide that the destination is not a true replacement and decline to transfer the old page's signals to it.

Content that still exists. If the old page keeps substantial content and the redirect fires after a delay, the crawler may index the old page on its own merits. Whether you want that is a decision you should make deliberately.

When You Have No Server Access

The honest reason client-side redirects still exist is that many sites cannot do anything else. Hosted website builders, some e-commerce platforms, managed landing page tools and locked-down enterprise CMS installs may give you a template editor and nothing more. There is no .htaccess, no server configuration, and no place to set a status code. In those cases a client-side redirect is a legitimate tool, provided you use it carefully.

Before you accept that limitation, check the options in order of preference, because the server layer is sometimes reachable from places people forget.

• Platform redirect manager. Many hosted platforms include a URL redirect setting that issues genuine 301 responses. Look in the site settings or SEO section before you write any code.
• CDN or edge rules. If the domain sits behind a content delivery network or an edge provider, redirect rules can usually be configured there and respond with a proper status code, without touching the origin.
• DNS and registrar forwarding. For whole-domain moves, a registrar's forwarding service may offer a permanent redirect. Verify the status code it returns, because some of these services use a frame or a meta refresh instead.
• The hosting support ticket. A request to the host to add a redirect rule is often cheaper than a workaround, and it produces the correct response.
• Client-side as the last resort. If none of the above is possible, use the most robust client-side combination available.

A Defensive Setup When Client-Side Is All You Have

When a client-side redirect is unavoidable, build it so that every layer confirms the same intent. No single piece is authoritative, but together they give Google consistent evidence.

Use an instant meta refresh rather than a delayed one, since Google reads a zero-second refresh as permanent. Put it in the head, high, so it parses early. Add a JavaScript redirect using location.replace as well, which keeps the old URL out of the browser history so the back button does not trap the visitor. Include a plain visible link to the new URL in the body for people and crawlers that run neither.

On the old page, add a rel canonical link element pointing at the destination. Canonicals are a hint rather than a command, but it is a consistent, crawlable statement of which URL should represent the content. Keep the page itself minimal and make sure it returns a 200, not a server error, so the redirect code can actually be delivered.

Then update everything you control that points at the old address: internal links, your XML sitemap, navigation and any structured data. A crawler that never meets the old URL has no redirect to process. Replace the old URLs in the sitemap with the new ones, rather than listing both.

Finally, keep the redirects in place for as long as the old URLs still receive links or visits. Google's own advice for permanent server-side moves is to keep them in place for at least a year, and a fallback mechanism deserves at least that patience.

Testing What Google Really Sees

Do not assume the redirect works because it works in your browser. Your browser has a warm cache, your cookies and no robots.txt.

Use the URL Inspection tool in Search Console and run a live test on the old URL. Look at the rendered HTML and the screenshot. If you see the destination page, rendering followed the redirect. If you see the stub, something blocked it. Check the list of page resources for scripts that could not load, and read the console messages if the tool reports any.

Then fetch the old page with a client that does not run JavaScript, for instance curl, and read the raw HTML. You are checking that the meta refresh and the fallback link are present in the delivered source rather than injected by a script. That is a fair approximation of what simpler crawlers will see.

Finally, watch the outcome, not just the mechanism. Search the site: operator for the old URL after a few weeks, check the Page indexing report for the old and new paths, and compare indexing status. If the old URL persists and the new one is not picked up, the client-side route is not converting and a server-level solution, however inconvenient to obtain, becomes worth the effort.