Why Biotree needed Crossdeck Trust — and how we stopped the SEO spam farms

Why are link-in-bio sites targeted by spam?

Every link-in-bio account is a small public web page, and Google indexes it. That is the entire value for a real creator — and the entire attraction for an abuser. If you can programmatically create thousands of pages on a reputable domain and pack them with links, you have built yourself a free backlink farm on someone else’s SEO reputation. Others do worse: phishing, malware redirects, scam funnels, all wearing the domain’s credibility as a disguise.

Biotree hit exactly this. Automated signups arrived in volume, each spinning up a profile whose only purpose was to plant links or scams. Individually, each fake account is trivial. In aggregate, they are a reputation attack on the whole platform.

The real stakes: your domain’s reputation, not your signup count

Here is the part that makes this urgent rather than annoying. Search engines judge a domain, not just a page. Let a domain fill with spam profiles and you do not merely host junk — you teach Google that the domain is junk. The penalty then lands on everyone, including the legitimate creators who did nothing wrong. Their pages rank worse because they share an address with a spam farm.

So for a link-in-bio product, stopping abusive signups is not a trust-and-safety chore bolted on the side. It is protecting the core asset: the domain reputation that makes a real user’s page worth having in the first place.

Why the obvious defences backfire

The two reflexes both fail, in opposite directions.

• Wall everyone with CAPTCHA. You tax every real signup with friction, hurting the conversion you actually want — and modern spam operations solve CAPTCHAs at scale anyway. You have punished humans and inconvenienced nobody who matters.
• Auto-ban anything suspicious. Now a machine is the judge, and it is wrong a meaningful fraction of the time. Every false positive is a real creator turned away at the door — and if your ban deleted their account, there is nothing to restore when you realise the mistake.

You cannot make a binary machine the judge of who is a person. So we did not.

What is a signup firewall?

A signup firewall scores every new signup on risk signals, but blocks only on explicit owner rules grounded in facts — enforced at the write layer, where the attacker actually acts — and a block refuses or signs the account out rather than deleting anything. That sentence is the whole design, and each clause is load-bearing:

• Score everything, auto-block nothing. Crossdeck Trust produces a signal on every signup. That signal surfaces risk; it does not pass sentence. The machine is a witness, not a judge.
• Block on facts and owner rules, not on a vibe. Biotree’s own rules decide what gets refused, based on facts rather than a fuzzy score. The owner sets policy; Trust supplies the evidence.
• Enforce at the write layer. Bots do not admire your interface — they write. So the gate lives on the write path, server-side, fail-closed. Guarding the button an attacker never clicks is theatre; guarding the write they must make is defence.
• A block refuses or signs out. It never deletes. A rule will occasionally catch a real person. If block meant delete, that mistake would be permanent. Refusing is fully recoverable — the honest human gets back in; the bot simply does not get through.
• A human triages the middle. Ambiguous cases land in a review lane where a person makes the call. Marking someone safe dismisses the alert; it never quietly loosens the gate for everyone else.

Bank-grade, and boring on purpose

One more deliberate choice: Trust uses named, explainable methods — a scorecard, champion-versus-challenger evaluation — not an inscrutable black box. That is not a limitation; it is the point. When you flag or refuse a signup you should be able to say why, in terms a human can audit and a court could accept.

A security layer you cannot explain is one you cannot trust, and trust is in the name. No cleverness for its own sake; just methods that hold up when someone asks how they work.

What it did for Biotree

The spam farms met a wall that real creators never felt. Abusive signups were refused at the write layer before a spam page could exist, so the profiles were never created, never indexed, and never had a chance to erode the domain. Legitimate signups passed straight through — no CAPTCHA tax, no false-positive bans.

And because Biotree ran this in a genuinely hostile, real-world environment, it did something no test suite could: it hardened Crossdeck Trust under live fire. That is the dogfood dividend. Every Crossdeck customer now inherits a fraud firewall that was not proven in a demo — it was proven by spammers trying, and failing, to farm Biotree.

What we learned

• Public, indexed, user-generated pages are a spam-farm target by construction. If you build one, assume the farms are coming, and defend the domain from day one.
• Let the machine be the witness, not the judge. Score to surface risk; leave the verdict to explicit, fact-based rules and, in the grey zone, to a human.
• Enforce where the attacker acts. Bots write, so gate the write — server-side, fail-closed — not the interface they skip.
• Refuse, do not delete. Design every block to be recoverable, because you will occasionally catch someone real.
• Explainability is part of trust. If you cannot say why you blocked someone, you do not have a trust layer. You have a liability.