How to manage tracking scripts across Webflow sites with one Webflow Cloud loader

A shared Next.js 15 application deployed through Webflow Cloud can centralize tracking-script management across multiple Webflow sites, replacing separate pasted vendor snippets with a single same-origin head-code reference to a configurable `/tracking/tag` loader. Each site uses the identical repository but supplies its own environment variables for a site label, JSON script registry, consent requirement, and mount path, allowing scripts and optional inline setup code to vary without code changes. A Route Handler builds the JavaScript loader, validates malformed configuration safely, exposes diagnostics through headers and a site identifier, and uses private, cookie-varying responses to prevent consent-sensitive caching issues. Middleware and a duplicate Route Handler check ensure vendor URLs are withheld unless a first-party `tracking_consent=granted` cookie is present, while a consent-banner callback can set the cookie and immediately load tracking after acceptance. The setup emphasizes Webflow Cloud-specific requirements, including npm, avoiding `basePath` and explicit Next.js Edge runtime declarations, retaining `middleware.ts` rather than upgrading to Next.js 16’s proxy convention, and correctly using the `/tracking` mount path. It also outlines testing, per-site deployment, common causes of 404s, failed builds, broken consent gates, and empty loaders, plus potential extensions for vendor setup snippets and complementary Webflow or analytics tools.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.