You'll Never See the Clone — But We'll Tell You Who Did

When a brand is cloned, the most unsettling part is rarely the copy itself. It is the silence around it. You learn that a fraudulent site exists, but you have no idea who reached it, who trusted it, or who handed over a password to it. The clone is something your customers see — and something you almost never do.

The Clonedown core platform already closes the loop on the clone itself: detection through takedown, end to end, automated by default and backed by a 24/7 disruption team, with 100% deindexing on verified URLs via the Google Trusted Copyright Removal Program. That removes the threat. But it does not, on its own, tell you who walked through the door before you shut it.

That is the gap the Clonedown SDK is built to close.

An optional add-on, not a default

The SDK is not part of the standard Clonedown plans. It is an optional add-on for teams that need more than takedown — specifically, teams that want to harden their pages and understand exactly who is interacting with them, including through unauthorized copies. If your priority is simply removing clones, the core platform stands on its own. The SDK is for when attribution and page-level defense matter.

Why clones lean on your real assets

Most clones are not careful reconstructions. Attackers copy what is fast to copy: your markup, your scripts, your images. Reusing your genuine assets is what makes a clone convincing — and it is also what makes it detectable. A page that was built to be yours can carry instructions that only behave correctly when it is served from where it belongs.

The SDK works from that principle. You embed a single script tag, on any stack, with negligible performance cost. From there it does three things.

What the snippet does

Anti-clone hardening. The SDK applies obfuscation, asset protection, and copy traps to the pages you choose to protect. This raises the cost and effort of cloning your site cleanly and makes lazy, asset-reusing copies less reliable for an attacker.

Unauthorized-origin detection. When a protected page loads from an origin that is not yours — a cloned domain reusing your code — the SDK recognizes it and alerts you. You find out that a copy is live from the behavior of your own page, not from a customer complaint days later.

Visitor-level attribution. This is the part that changes incident response. When a protected page is accessed, the SDK gives you attribution for that access — even when the page is being served from a clone. Instead of an abstract report that “a clone exists,” you see which users actually reached the protected page through it.

From “someone cloned us” to a list of names

The difference is operational. “Someone cloned us” is a problem you cannot act on with precision. A traceable list of the visits that hit the clone is something a security or fraud team can work immediately: reset the right credentials, contact the specific customers who were exposed, prioritize the accounts an attacker is most likely to target, and document the incident with real evidence rather than assumption.

For brands whose customers are deliberately targeted — high-value accounts, regulated relationships, audiences an attacker singles out — that specificity is the difference between a generic warning to everyone and a precise intervention for the few people who were actually at risk.

What it is, and what it is not

We want to be exact about this. The SDK is a brand-protection and incident-response tool. It tells you when your protected pages are being misused and who interacted with them in that context, so you can defend your brand and the people who trust it. It is not surveillance of the open web, it is not a tracker bolted onto unrelated browsing, and it does not promise to unmask every actor behind every clone. It does one thing well: it makes the abuse of your pages visible and attributable, at the level of individual visits, with a single lightweight snippet.

Used alongside the core platform, it means a clone is no longer just something that gets taken down. It becomes something you can see clearly while it is happening — and respond to on behalf of the customers it was built to deceive.

If page-level defense and visitor attribution map to how your team handles incidents, the SDK is available as an add-on, and we are glad to walk through what protecting a specific set of pages would look like.

Clonedown OÜ, Tallinn, Estonia.