How to Audit Third-Party Scripts in Webflow Without Breaking Functionality

To audit third-party scripts in Webflow safely, list every script and where it lives, confirm what each one does and who still needs it, then remove or change one script at a time on the staging domain. Test the features each script touches after every change. Most breakage comes from deleting several tags at once without knowing what depended on them.

Why scripts pile up

Scripts get added over time: analytics at launch, a chat widget for sales, a heatmap for one research sprint, an ad pixel for a campaign that ended long ago. Nobody removes them because nobody is sure what they do. The result is extra JavaScript that hurts INP and sometimes LCP, tracking that fires twice, and forgotten vendors that can break.

Step 1: Build a script inventory

Do not remove anything yet. Check every place code can live in Webflow:

• Site settings > Custom code (head and footer)
• Page settings > Custom code on static pages
• Page settings on each CMS Collection template
• Code Embed elements on pages, in components and in rich text
• Integrations in Site settings, such as a Google Analytics ID
• Your tag manager container and any installed apps

Then check what actually loads. Open the published site in Chrome DevTools, go to Network, filter by JS and reload. Anything not from your domain or Webflow's CDN is third-party. Repeat on a few page types.

For each script, record the vendor, purpose, where it is installed, which pages need it, who owns it, and a decision: keep, move, defer or remove.

Example: a 300-page SaaS blog with GA4 in Site settings, GA4 again in GTM, a site-wide chat widget, a scheduling embed on one page and a pixel from a former agency. That list alone shows where to start.

Step 2: Find duplicates

• GA4 set up in Webflow's integration and also in GTM
• The same pixel in site head code and in page code
• jQuery loaded manually even though Webflow already loads it

In GTM Preview or GA4 DebugView, two page_view events on one load confirm a GA4 duplicate.

Step 3: Limit scripts to the pages that need them

A booking widget only needs the booking page. Move that code from Site settings to Page settings > Custom code on the pages that use it, or to a Collection template's settings for CMS pages. In GTM, use a trigger condition such as Page Path contains /contact.

Step 4: Fix how scripts load

A script in the head without async or defer blocks rendering. Most marketing tools do not need that.

<!-- Blocks rendering -->
<script src="https://vendor.example/w.js"></script>
<!-- Runs after HTML is parsed, keeps order -->
<script src="https://vendor.example/w.js" defer></script>
<!-- Runs when it arrives, no order -->
<script src="https://vendor.example/w.js" async></script>

Use defer when a script depends on another script or the DOM, and async for independent tags. Keep a script blocking only when the vendor says it must run first, like some consent or A/B testing tools. For chat widgets, check whether the vendor offers an official delayed-load option.

Step 5: Remove one script at a time

1. Save the exact code in your inventory so you can restore it.
2. Remove it and publish to the webflow.io staging domain only.
3. Run the checks below and watch the console for new errors.
4. If all is fine, publish to production and move on.

What to test after each change:

• Forms submit and show the success state
• Navigation, dropdowns, tabs and sliders work
• Webflow Interactions still run
• The consent banner works
• GA4 key events still arrive in DebugView

Before removing a library, search your custom code for its global name, such as fbq, to find hidden dependencies.

Step 6: Measure before and after

Run PageSpeed Insights on the same URLs before and after. Compare JavaScript size, blocking time and the third-party code diagnostic. Field data for LCP, INP and CLS uses a 28-day window, so it moves slowly. See web.dev on third-party JavaScript.

FAQ

Is it safe to delete code from Site settings?

Yes, if you save a copy first and test on staging. Restoring a full site backup undoes every other change too, so a saved snippet is the quickest rollback.

Should every script go into GTM?

Marketing and analytics tags usually should. Code the page needs to work, like a form handler, is better kept in Webflow.

How do I know if a script is still used?

Ask who logs in to the vendor account. If nobody can name an owner or purpose, it is a removal candidate.

Dealing with this on a live Webflow site? It is the kind of work I do in a Webflow audit. Send me your site and I will tell you what I would fix first.