Avoid using JavaScript for redirection purposes

JavaScript redirects — sending users to a different URL via a script rather than an HTTP header — technically work, but create problems that a proper 301 doesn't.

An HTTP 301 redirect happens at the server level, before the browser renders anything. Google processes it cleanly, follows it immediately, and passes link equity. A JavaScript redirect requires the browser to load the page, parse the script, execute the redirect, and then load the new destination. Google can follow most JavaScript redirects, but the processing is slower and less reliable, and it passes less link equity than a proper server-level 301.

In Webflow, you should never need a JavaScript redirect for moving a URL. Webflow's native redirect tool in Site Settings → Hosting → 301 Redirects handles permanent URL changes cleanly. If you find JavaScript redirects in your code, they're either legacy artifacts from a previous setup or workarounds that can be replaced.

How to find them: search your custom code for window.location and location.href. These are the most common JavaScript redirect patterns. Check Site Settings → Custom Code (both head and footer), and check any Embed elements on individual pages. If you find them, look at what they're doing. If the intent is to redirect one URL to another, replace with a Webflow 301 redirect and remove the script.

Common scenarios where these appear: an old A/B test that was never cleaned up, a seasonal landing page redirect running long past its purpose, or a tracking redirect added by a previous developer. None of these need a JavaScript redirect on a Webflow site.

One context where JavaScript routing is legitimate: single-page applications with client-side routing. But Webflow generates static pages with server-side rendering. If you're using Webflow as a standard marketing or content site, JavaScript URL manipulation should not be in your code.

Check this alongside your meta refresh and iFrame audits. All three are ways that redirect-like behavior ends up in custom code rather than in Webflow's proper tools. Cleaning them up before going live is faster than diagnosing crawl issues after the fact.