Kick Scraper

Scrapers copy content off published pages, bot traffic inflates analytics, and automated clicks spend real ad budget. Webflow serves a published page from its CDN with no built-in bot filtering, so a live site accepts whatever traffic arrives.

Kick Scraper was a third-party bot-detection snippet for Webflow sites. As of August 2026 its vendor domain resolves in DNS but accepts no HTTP or HTTPS connection, and its Webflow app listing returns a 404, so there is no account to sign into and no snippet to copy. The Webflow half of the setup is still very much alive, and it is the half worth knowing: custom code fields, the Custom Code API, and the MCP server all let you install a third-party bot-filtering script and take it back out on your own terms.

That makes this page useful to two readers. One found Kick Scraper in an app directory and wants to know whether it is safe to install. The other needs the same protection from a provider that is still running, and needs the Webflow-side mechanics either way.

How to integrate Kick Scraper with Webflow

What is Kick Scraper? Kick Scraper is a bot-detection product for Webflow sites, sold as a JavaScript snippet you add through custom code. Despite the name it does not scrape anything and it touches no third-party platform: it was built to kick scrapers off a site and keep their traffic out of the analytics. The only surviving public description of it is FlowFav's app listing, a third-party affiliate directory whose own footer states it is not affiliated with Webflow.

Two checks decide whether any of this is installable today, and both come back negative. The vendor's domain, kickscraper.com, resolves through Cloudflare DNS to a host that answers on neither port 80 nor port 443, from four separate networks and from a real browser. No bot challenge to work around, and no error page either. The Webflow app listing that the directory's install button redirects to returns a 404, while a known-good listing on the same path pattern returns 200, so that 404 is a real absence and not a broken checker. Treat Kick Scraper as unavailable, and read the rest of this page as the mechanics for whichever provider you choose instead.

Three routes put a third-party snippet on a Webflow site. The Webflow MCP server reads and writes site-level and page-level custom code and manages registered scripts from a prompt in your AI client. Custom code fields in Site settings and Page settings, along with Code Embed elements, hold the snippet with no development work at all. The Custom Code API registers a script once and applies it across many sites, which is also how an app removes its own code when a customer uninstalls. Most sites need only the custom code fields; agencies running many client sites reach for the API.

Manage the snippet with the Webflow MCP server

The Webflow MCP server exposes Webflow's APIs as tools an agent can call, and its design and build group covers reading and writing freeform site-level and page-level custom code plus managing registered scripts. You can ask an agent to put a snippet in the head of one page, list what is already registered on a site, or take a script back out, without opening Site settings.

That matters more than convenience when the code comes from a third party. Every agent works inside your existing Webflow permissions and roles, the changes it makes land in the site's activity log, and per-site Agent Instructions let you write the guardrail down in advance, such as no third-party scripts on checkout pages.

The MCP server also reads the traffic side of the job. Its analyze tools report sessions, users, and pageviews over a chosen window, rank top pages, break traffic down by country, browser and source, surface engagement events, and measure average time on page, so you can compare a period before and after a filtering script goes live. Those readings depend on Webflow Analyze, a paid add-on, not on the MCP server alone. The MCP server itself is listed on the free Starter Site plan, so connecting it costs nothing.

Add the snippet through custom code

Custom code fields are where a snippet like this normally lives, and they are also the fastest thing to undo. Adding code to a site or a page requires a Core, Growth, Agency, or Freelancer Workspace, or an active Site plan. Only HTML, CSS, and JavaScript run in them: as Webflow's custom code documentation puts it, "You can't integrate server-side languages (such as Perl, PHP, Python, or Ruby) in any code section."

To install a snippet across every page:

1. In Webflow, go to Site settings > Custom code.
2. Paste the snippet into the Head code or Footer code section, preferring the footer for scripts so the page content loads first.
3. Click Save changes.
4. Publish the site.

Page settings carry the same two fields for a single page, Inside <head> tag and Before </body> tag, which is the right scope for testing before a site-wide rollout. Four limits shape what fits:

• Site-wide caps: The Head code and Footer code sections in Site settings hold up to 50,000 characters each.
• Page-level caps: The head and closing-body fields in Page settings hold up to 50,000 characters each as well.
• No server-side code: There is nowhere to run a server-side language, so anything beyond HTML, CSS, and JavaScript has to live off-site.
• Publishing gates it: Custom code takes effect in preview and comment modes, but nothing reaches visitors until you publish the site.

If an implementation runs longer than the cap, host the file elsewhere and reference it from a short script tag instead.

Embed with a Code Embed element

A Code Embed element places the snippet inside a specific layout on the canvas, which suits protection that should travel with a component rather than sit in a page setting.

To embed the snippet:

1. Copy the snippet to your clipboard.
2. Open the Add panel and add a Code Embed element to the canvas.
3. Paste the snippet into the element.
4. Click Save and close, then publish the site.

Custom code in a Code Embed element cannot exceed 50,000 characters either, and the code runs on the published site rather than on the canvas.

One thing is worth saying plainly about any client-side bot script, this one included: it cannot stop a scraper from reading your HTML. Webflow serves a published page from its CDN before any script executes, so a crawler that never runs JavaScript already has the markup. A snippet can challenge real browsers and clean up its own analytics, but blocking at the network edge is a different job, and a reverse proxy such as Cloudflare is where that work belongs. For form spam specifically, reCAPTCHA is the narrower and better-supported answer.

Deploy and remove the snippet with the Custom Code API

The Custom Code API registers a script against a site and then applies it site-wide or to one page, which is how an app installs its own code and how it cleans up afterwards. It accepts OAuth tokens from a Webflow App only: site tokens and Workspace tokens cannot call these endpoints. Requests need the custom_code:read and custom_code:write scopes, plus sites:read, sites:write, pages:read, and pages:write.

Deployment follows a register, apply, publish sequence:

1. Register the script. POST /v2/sites/{site_id}/registered_scripts/hosted takes an externally hosted file and requires hostedLocation, integrityHash, a SemVer version, and a displayName of 1 to 50 alphanumeric characters. The inline script endpoint takes sourceCode instead and caps it at 2,000 characters.
2. Apply the script with PUT /v2/sites/{site_id}/custom_code for the whole site, or PUT /v2/pages/{page_id}/custom_code for one page. These endpoints use desired-state semantics: every script the site needs goes in each request body, and leaving one out is how you remove it.
3. Publish with POST /v2/sites/{site_id}/publish. The body must include at least one of customDomains or publishToWebflowSubdomain, and the endpoint allows one successful publish queue per minute.

A few constraints govern the whole lifecycle rather than any single call:

• Versions are immutable: You cannot overwrite a registered script, so shipping a change means registering a new version and applying that.
• Scripts are capped per site: A site holds a maximum of 800 registered scripts, which is generous but not infinite across a long-lived agency account.
• Nothing lands without a publish: Applying, updating, or removing a script only takes effect when the site publishes, via the Sites publish endpoint or a human hitting Publish.
• Deployments are auditable: Webflow webhooks deliver a site_publish event you can log to keep a record of what went out and when.

Uninstall is the step most teams skip, and it is the one that matters here. If you already authorized a Webflow App for a bot-filtering tool that has since gone quiet, revoke it: per Webflow's Data API FAQ, "There is no way to refresh the App's access token or add scopes to it", so revocation is the only way to end an abandoned app's access to your CMS data, forms, assets, and publishing. View and remove it under Site settings > Integrations > Authorized apps.

What you can build with the Kick Scraper Webflow integration

With the vendor offline, none of this is buildable through Kick Scraper right now. What follows is the shape of the work once a bot-filtering snippet and Webflow's custom code tooling are put together, and it holds for whichever provider you end up using.

• SEO content protection: A high-traffic content site runs verification on its article and landing pages, so casual copy tools meet a challenge instead of clean markup.
• Human-only client reporting: An agency filters automated sessions out before building a monthly report, then reads the traffic figures back through an agent rather than a dashboard.
• Ad-spend protection on ecommerce: A marketing team points paid campaigns at a launch page where automated clicks get challenged, so visit and conversion counts track closer to real buyers.
• Selective verification on high-value pages: A page-level install puts a challenge on a pricing page or a gated resource library and leaves the rest of the site untouched.

If you are deploying across more than one client site, learn to apply custom code programmatically first. Then connect the MCP server so you can audit and remove those scripts by prompt.