Usually because it went in the wrong place, ran before the thing it needed existed, or collided with something Webflow already loads. Custom code in Webflow is powerful and unforgiving. There is no build step to catch your mistake, so a stray tag can take down a page that worked five minutes earlier.
We inherit a lot of Webflow sites where custom code has quietly accumulated for years. A tracking script here, a slider library there, a fix for a bug nobody remembers. By the time we see it, nobody knows what any of it does, and half of it is loading on every page for a feature that exists on one.
None of that means you should avoid custom code. It means you need a small set of rules about where it goes and when it runs. Once you have those, custom code stops being scary and starts being the thing that lets Webflow do almost anything.
There are four places. Site settings, which applies to every page. Page settings, which applies to one page. The Code Embed element, which sits inside your layout at a specific point. And rich text fields in the CMS, for code that belongs to one collection item. Webflow names all four as custom code locations.
Site settings and page settings each give you two slots, one that goes inside the head and one that goes just before the closing body tag. That distinction is the single most important thing to understand, because it decides when your code runs relative to the page being built.
Head code runs before the page renders. That is right for things that must exist early, like a font preload, a meta tag, or a consent manager that has to block other scripts. It is wrong for anything that touches page elements, because those elements do not exist yet.
Body code runs after the HTML has been parsed. That is where almost everything else belongs. If your script needs to find a button, attach a click handler, or measure an element, it goes before the closing body tag. Putting it in the head is the most common reason a script silently does nothing.
Fifty thousand characters per field. Webflow's own product update states the limit is 50,000 characters across Site settings, Page settings, Code Embed elements, and CMS rich text fields. The same update confirms the raised limit is available on all paid sites and workspaces, so custom code is not a free plan feature.
Fifty thousand characters is generous for most work, and if you are approaching it you have a design problem rather than a limit problem. Inline code at that size is code that should live in a hosted file and be referenced by a single script tag.
The paid plan requirement catches people out on client projects. If a site is still on a free plan, custom code will not publish, and the failure is confusing because everything looks fine in the Designer. Plan limits shape more of Webflow than people expect, which we cover across the board in our guide to Webflow's plan limits.
Our rule is that anything longer than a few dozen lines gets hosted externally and pulled in by reference. That keeps the Webflow fields readable, gives you version control, and lets you update the script without republishing the site.
Because Webflow does not run it there by default. Custom code needs to be switched on for preview, and Webflow University's guidance on the Code Embed element tells you plainly that you may need to toggle Enable custom code, or publish to staging, before you can see the effect.
This trips up almost everyone the first time. You paste a script, nothing happens on the canvas, and you assume the script is broken. It is not. The Designer is deliberately not executing it, because running arbitrary scripts inside the editing environment would be a security and stability problem.
Webflow University also notes that how the code renders depends on its type. Markup and styles behave differently from scripts, so some embeds show something useful on the canvas while others show only a placeholder until the site is published or previewed with code enabled.
The practical workflow is to build against staging rather than the Designer whenever custom code is involved. Publish to the staging domain, test there, and treat the Designer canvas as a layout tool rather than a preview of behaviour.
Whenever the code belongs to one place on one page. A Code Embed sits inside your layout, so the markup lands exactly where you put it and the code travels with the component. Site-wide code should be reserved for things that genuinely need to run everywhere, which is a shorter list than most sites assume.
The test we use is simple. If removing the section would make the code pointless, the code belongs in that section. A custom form widget, an embedded map, a pricing calculator, a third party review badge. All of those are Code Embed cases, not site settings cases.
Webflow University describes the Code Embed as holding HTML snippets, iframe embeds, and small scripts and styles, and it is explicit that snippets meant for frameworks or server side setups will not run there. That last part matters. A Code Embed is not a place to paste React or PHP and hope.
The maintenance benefit is the real argument. Code that lives next to the thing it controls gets deleted when that thing gets deleted. Code that lives in site settings outlives everything, which is exactly how sites end up loading a slider library for a slider that was removed two redesigns ago.
As much as you let it, and third party code is the usual culprit rather than your own. The HTTP Archive Web Almanac 2025 third parties chapter found that over 90% of pages load third party resources, with a median of 83 third party requests on desktop and 79 on mobile.
Those numbers should give you pause, because most of those requests were added one at a time by someone who thought they were adding just one. The top 1,000 sites carry a median of 129 third party requests on desktop and 106 on mobile, and the Almanac notes the top 1,000 added about 15 more requests year over year compared to 2024.
Webflow itself is not the problem here. A clean Webflow build is fast out of the box. What slows it down is the accumulated layer of analytics, chat widgets, heatmaps, and marketing pixels that get pasted into site settings over time, each one loading on every page.
Across our own projects we hold an average PageSpeed score of 98, and honestly the biggest single factor is refusing scripts rather than optimising them. Every script we do not add is a script we never have to make fast. The wider case for that discipline is in our piece on how third-party scripts slow down your website.
Load them late, load them once, and load them only where they are needed. Anything that is not required to render the page belongs before the closing body tag rather than in the head, and anything that only serves one page belongs in that page's settings rather than site wide.
Deferring is the next lever. A script tag marked async or defer stops blocking the parser, which is the mechanism behind most script related slowdowns. The difference between a blocking script and a deferred one is often the difference between a good Largest Contentful Paint and a bad one, which we unpack in our guide to fixing render blocking resources.
Tag managers deserve a specific warning. Google Tag Manager is genuinely useful for marketing teams, and it is also a door that anyone with access can push more scripts through without a developer noticing. If your performance mysteriously degrades over months, check what has been added there before you check anything else.
The last rule is to audit on a schedule. Once a quarter, open the network tab, list every third party domain your homepage contacts, and ask what each one is for. Anything nobody can name gets removed. That single habit does more for Webflow performance than any amount of clever code.
Anything that fights the platform. Do not load a second copy of jQuery, because Webflow already loads one and a duplicate will break interactions. Do not override Webflow's own classes with sweeping global styles. Do not use custom code to rebuild something the Designer already does natively.
The jQuery conflict is the most common real breakage we see. Webflow's interactions depend on the version it ships. A tutorial from a WordPress context tells you to include jQuery, you paste it in, and suddenly every animation on the site stops working. The fix is to delete the include and use the version already present.
Sweeping style overrides cause a slower kind of damage. Global CSS in site settings applies to every page forever, including pages that do not exist yet. Six months later somebody builds a new page, an element looks wrong for no visible reason, and the cause is a rule written for a page that has since been deleted.
The last category is code that duplicates native features. Every time you script something the Designer can do, you have created a thing that no future editor can maintain and that will not survive a redesign. Native first is not purism. It is the difference between a site your client can update and one they cannot.
Open the browser console first. Most custom code failures announce themselves clearly there, usually as a message saying something is not defined or an element is null. Those two errors cover the large majority of cases, and both point at timing rather than at the code itself.
An element being null almost always means the script ran before the element existed, which means head code that should be body code. Something being undefined usually means a library did not load, or loaded after the code that needed it. Order is the answer to both.
Next, check whether the code is even reaching the page. View the published page source and search for a distinctive string from your snippet. If it is missing, the problem is upstream, and the usual causes are a free plan, an unpublished change, or code sitting in a page you are not looking at.
When you genuinely cannot find it, remove everything and add it back one piece at a time. It feels crude and it is reliably the fastest route. On a site with a decade of accumulated snippets it is often the only route, and it doubles as the audit you were going to have to do anyway.
Open your Webflow site settings and read what is in there. Most people have not looked in a year, and there is usually something loading on every page that should not be. Delete what nobody can explain, move page specific code into page settings, and move component code into Code Embeds.
Then publish to staging and check the console on three or four pages. A clean console is a reasonable definition of a healthy site, and errors you have been ignoring are often the reason something intermittently misbehaves.
If you have a Webflow site carrying years of custom code nobody understands, that is a very normal situation and a solvable one. We are happy to look through it with you and tell you what is safe to remove. Come find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.