Meta Refresh and JavaScript Redirects: SEO Risks Explained

Short answer: A meta refresh is a tag in the page that sends the browser to another address, and a JavaScript redirect does the same with a script. Search engines can often follow both, but they are slower, less dependable and worse for visitors than a server-side 301 or 302 redirect. Use them only when you cannot change the server, and replace them with proper redirects when you can.

Three ways to redirect a visitor

A redirect sends a person or a crawler from one address to another. There are three common ways to do it.

Server-side redirect. The server answers the request with a status code such as 301 or 302 and the new address. The browser or crawler moves on before any page content is loaded. This is the standard method, explained in the article on choosing between 301 and 302.
Meta refresh. The old page loads, and a tag in its head tells the browser to go to a new address after a number of seconds, often zero.
JavaScript redirect. The old page loads, a script runs and it changes the location of the window.

The last two happen inside the page. The server has already said “here is a page”, so a crawler must read the page and interpret it before it learns that the content lives elsewhere.

What search engines do with them

Google has said that it can follow meta refresh and JavaScript redirects, but it prefers server-side redirects and describes the page-level methods as less reliable. For a meta refresh, Google reads the tag when it processes the page. For a JavaScript redirect, it has to render the page first, which happens in a second step that may come later, as covered in the guide to JavaScript SEO basics.

The consequences for you are practical:

The change may be recognised later than with a server redirect, so the old address can stay in results for longer.
If a script is blocked, fails, or the page cannot be rendered, the redirect may not be seen at all.
Other search engines and tools, such as social media link previews, may not run scripts and will treat the old page as the real one.
The signals that normally move from an old address to a new one may pass less cleanly.

None of this means that a page-level redirect will destroy your rankings, but it adds risk that a simple server rule avoids.

Problems for visitors

Redirects in the page are not only a search matter. Visitors notice them too.

A flash of the old page. The old page is shown briefly before the new one appears. Slow connections make this obvious.
The back button trap. After a redirect, pressing back returns to the old page, which immediately redirects again. People feel stuck and leave.
Delayed refresh and accessibility. A page that changes after a few seconds can disturb people who use screen readers or who need more time. Accessibility guidelines advise against automatic timed changes without a way to control them. The topic is related to the guide on accessibility and SEO.
Extra load time. The browser downloads and processes the old page before it can start on the new one, which adds to the total delay.

When they are acceptable

Sometimes you have no choice. A hosted website builder may not give access to server settings. A page on a platform that you do not control may allow only a tag or a script. In such cases:

Prefer a meta refresh with a delay of zero seconds over a long delay, because it is closer to a normal redirect.
Add a visible link to the new address inside the old page, so that visitors and crawlers can follow it if the automatic redirect does not run.
Set a canonical tag on the old page that points to the new address, as described in the article on canonical tags.
Keep the page quick and the text short.
Plan to replace it with a server redirect as soon as the platform allows.

JavaScript redirects are also used legitimately for tasks that depend on the visitor, such as sending people to a language version after login. Avoid using them for permanent address changes.

How to replace them with proper redirects

On most sites this is a quick job for someone with access to the server or the CMS.

Apache. Add rules to the configuration or the .htaccess file that return a 301 status for the old address.
Nginx. Add a return or rewrite rule in the server block.
WordPress. Use a redirect plugin or the redirect feature of your SEO plugin, which creates server-side redirects for individual pages.
CDN or edge rules. Many CDN services can redirect addresses before requests reach your server.
Hosting panel. Many hosts offer a redirect tool that writes the rule for you.

Use 301 for permanent moves and 302 for temporary ones. Redirect each old address to the most relevant new page, not to the home page for everything, and avoid chains of several redirects in a row, as explained in the guide to redirect chains and loops.

How to find page-level redirects on your site

View the source of suspicious pages and search for “refresh” in the head, and for “location” in scripts.
Crawl your site with a tool that reports redirect types. Many crawlers list meta refresh separately from server status codes.
Check Search Console for pages reported with redirects, as explained in the article on Page with redirect.
Open old marketing addresses, printed addresses and old links from other sites, and see where they land and how.
Ask your developer or agency whether any landing pages use scripts to forward visitors.

Remember that some malware injects sneaky redirects through scripts, which send visitors from search to another site. If a page redirects in a way that you did not create, treat it as a security problem and read the article on cloaking and sneaky redirects.

How to test a redirect after you change it

Never assume that a redirect works because the rule looks right. A short test routine catches most errors before visitors or search engines meet them.

Test the exact old address. Type or paste it, with and without the trailing slash and with both the www and non-www forms. Each version should end on the same new page.
Read the status code. In the network tab, the first response for the old address should be 301 or 302 with a location header. The final response should be 200.
Count the steps. One redirect is ideal. If the visitor passes through three steps, merge them into a single rule.
Check on a phone. Mobile networks and some in-app browsers behave differently from a desktop computer.
Test with scripts off. If the new address only works because a script runs, a crawler that does not run scripts will not follow it. A server redirect works either way.
Inspect in Search Console. Use the URL inspection tool on the old address to see what Google found, then request indexing of the new page if needed.
Update the sitemap. It should list only the final addresses, never the ones that redirect.

Repeat the test after any change to the server, the CDN or a caching plugin. Redirect rules are among the first things to break when someone moves a site, changes the server software or restores an old backup, and the damage often goes unnoticed for weeks because the home page still looks fine.

Common mistakes

Using a long delay. A refresh after five or ten seconds is confusing and treated as less certain by search engines.
Redirecting everything to the home page. Visitors lose the content they expected, and search engines may treat it as a soft 404.
Combining several methods. A server redirect, a meta tag and a script together can create loops.
Forgetting to update internal links. Link to the new address directly, not through the redirect.
Leaving temporary redirects for years. A 302 that is meant to be permanent gives a mixed signal. Review them during a migration, as described in the site migration checklist.

How Site AI Audit helps

Site AI Audit follows the links of your site and reports redirects and broken links among the SEO findings, together with titles, descriptions, headings, the sitemap, robots.txt and noindex settings. It can help you see which addresses redirect before you decide how to fix them. The first check is free, covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring and alerts.

The bottom line

Use server-side redirects whenever you can. Treat meta refresh and JavaScript redirects as temporary workarounds, make them instant, add a visible link and a canonical tag, and replace them as soon as you get access to the server.

FAQ

Does Google follow a meta refresh redirect?

Often yes, but server-side redirects are more reliable and are the recommended method. Use a meta refresh only when nothing else is possible.

Are JavaScript redirects bad for SEO?

They can work, but they depend on rendering and are slower to be recognised. Avoid them for permanent address changes.

What is better than a meta refresh?

A 301 redirect for permanent moves or a 302 for temporary ones, set on the server, in the CMS or at a CDN.

Can a meta refresh cause a loop?

Yes, if it points back to a page that redirects again. Test each redirect from start to finish after a change.

How can I tell which type of redirect a page uses?

Check the response status in the browser’s network tab. A 301 or 302 means a server redirect. A normal 200 response followed by a jump points to a tag or a script.