Why Your Ruunly Site Stays Online (Trust & Safety)

Every multi-tenant platform has the same problem. If signup is fast — and ours is — bad actors notice. The same five-minute onboarding that lets a lawn-care operator in Cape Coral go live by lunch is what a phishing crew in Lagos uses to spin up a fake locksmith site by dinner. Wix has dealt with this for fifteen years. Squarespace too. So has every email service ever launched.

Most operators reading this never think about it. The reason is that we do — quietly, automatically, before the bad neighbors ever go live next door to your professional website. This post is the short version of how.

Why bother explaining? Because the question comes up. Sometimes from a careful buyer who has been burned by a hosting provider that let their site sit next to a scam page. Sometimes from a Stripe risk reviewer doing a 12-month look-back on our connected accounts. Sometimes from a chain customer evaluating us for five locations. The honest answer is: yes, we screen everything. And here is roughly how.

Why this matters for you, not just for us

You signed up to run a service business. You did not sign up to share a hosting platform with a fake-checkout phishing page.

Three things happen when bad sites get into a platform's IP space:

1. Email reputation tanks. Mail servers downstream of a compromised platform start junk-foldering everything from that platform — including your invoice receipts and review-request emails to real customers.
2. Browser warnings spill over. When Google Safe Browsing or Microsoft SmartScreen flags a tenant site, neighboring subdomains sometimes get caught in the dragnet for hours before the false positive clears. Your customer clicks the link in your booking confirmation and sees a red "deceptive site ahead" screen.
3. Search rankings collapse. Google does not love hosts that look like they harbor abuse. The shared subdomain you live under, the shared IPs, and the shared registrar reputation all get downgraded together.

In other words: if we let scam sites in, you lose deliverability, you lose customer trust, and you lose Google. So we don't.

The layers (general shape, not the recipe)

We talk about trial-abuse defense in terms of layers because no single check catches everything, but a few cheap checks stacked together catch almost everything. Here is the general shape, with deliberate vagueness on the thresholds. (Publishing the specific numbers is a roadmap for attackers — see the section at the end.)

Layer 1: Velocity checks on signup

The first thing an abuse crew does is automate signups. Hundreds of accounts from the same IP block, the same browser fingerprint, the same disposable-email provider, in the same fifteen-minute window.

We watch for that pattern in real time. The signup endpoint is rate-limited per IP and per email-provider domain. Disposable email services that abuse crews love (and that real lawn-care operators have no reason to use) are tracked and treated with extra suspicion. None of this is visible to a real operator signing up from a coffee shop on their phone — it only fires when the pattern is obviously inhuman.

Layer 2: Content scanning at publish time

When a tenant publishes a page on a Ruunly site, two automated checks run in parallel:

• Text moderation sends the rendered page text through OpenAI's moderation API, which flags content categories like phishing-style fake-checkout language, content involving minors, hate speech, and content promoting violence.
• Link reputation takes every external link on the page (capped per scan) and checks each URL against Google Web Risk for known malware, social engineering, and unwanted-software threats.

Both run in the background. Your page goes live; the scan happens in parallel and only surfaces when something trips. If you are running a normal service business, you will never see any of this. We wrote up the user-facing version of the same process on the Content Safety page if you want the longer detail.

Layer 3: Public abuse-report channel

Even with scans, sometimes something gets through. The third layer is letting any visitor on the internet report a suspicious Ruunly-hosted page in three clicks. The report-abuse form drops directly into the same triage queue our trust and safety team works from. Reports get a real human review, usually within one business day.

This is not a vanity feature. It is the catch-net for whatever the scans miss. The combination of scan-at-publish + public-report + human-review covers what no single check can.

Layer 4: The off-switch

When all of the above turns up a confirmed bad actor — the kind of clear evidence that ends an account — there is a final step. We can take the site offline immediately, return a clean response to anyone visiting the URL, and start the legal and Stripe processes that follow. The mechanism is deliberately not described here in detail because describing it would help the next bad actor probe around it.

What honest operators need to know is the same as it ever was: if your site is honest, none of this touches you.

What we deliberately don't publish

There is a real tension between trust-marketing and security-by-obscurity. Every numeric threshold we publish is a number an attacker can stay under. Every signal name we publish is a signal an attacker can avoid sending. So:

• We do not publish the specific velocity numbers. Not the per-IP-per-hour limit, not the per-email-domain limit, not the look-back window.
• We do not publish the scoring weights inside the velocity heuristics.
• We do not publish the exact off-switch mechanics.

What we will tell you, publicly: the system exists, it runs continuously, it is layered, and it has caught what it has caught. The trust and safety team reviews the queue daily.

How to tell, as a buyer, whether a platform takes this seriously

If you are comparing service-business platforms and the question of trust matters to you (it should — your customer's first impression of you is the website you put in front of them), three quick checks tell you almost everything:

1. Is there a public abuse-report form? If a platform makes it hard to report scam content, they are signaling something about their priorities. Ours is at /report-abuse and takes three fields.
2. Is the security posture documented somewhere a real human wrote? Boilerplate "we take security seriously" is meaningless. Specifics — what gets scanned, what the response looks like, who reviews — are not. Our Security page and Content Safety page are deliberately specific.
3. Is the signup fast enough that abuse is plausible? If a platform makes signup deliberately slow to slow abusers, they are also slowing honest operators. The right answer is fast signup + layered scanning, not slow signup as a wall.

The point

Your customers will not read this post. The buyer at the chain considering you for five locations might. The Stripe reviewer doing a quarterly check definitely will. The honest operator who got burned by a competitor sharing IP space with a fake-locksmith ring will absolutely find it on Google.

That is who this post is for. And the answer for all of them is the same: the Ruunly site is a deliberately defended place to put your business on the internet. Honest operators get a fast, reliable home. The other kind do not get to stay.

If you are running a service business and want to start, the 14-day free trial is free, no credit card to begin. The screening described above kicks in the moment you publish — quietly, in the background, where it belongs.