Guides

How Sitesfare keeps your website safe

What Sitesfare Shield does for every website, what you will see in Settings → Site capabilities, and how to prove a destination in two minutes. With a destination checker and the robot visitor’s timeline.

6 min read · updated

Interactive

Destination checker

Where does your page send what visitors type? Type the host and see what their browsers will do with it.

The robot visitor’s timeline

What happens. The robot opens the site like a visitor from a webmail link: scrolls, waits for timers, reads the page from a screenshot, types a one-off fake password into every form that asks for one, and follows where it goes.

What it can find. The fake password reaching a chat-bot or paste host, or a page on Google’s danger lists: a proof — offline within the visit. A brand it does not belong to, a redirect, a hidden frame asking for a password: signs — a review, and a warning page after two of them.

Nothing is ever deleted. A site taken offline is restored in a minute if a person finds it was a mistake, and the reporter and the owner both hear the outcome.

The short version

Every website on Sitesfare is protected by Sitesfare Shield, a set of safeguards no other website builder or host has together. You do not have to switch anything on. This guide explains what it does, what you will see in your dashboard, and the one thing you may be asked to do: prove you control the place a login or payment form sends to.

1. Your website can only do what it was seen doing

When you publish, Sitesfare reads your pages and notes every outside service they use — fonts, images, videos, maps, the API your code calls. Each page is then served with a policy that your visitors' own browsers enforce: the site may load from, connect to and post to those services and nothing else.

Why it matters: the most common trick on hosting platforms is to publish an innocent page, pass the checks, then swap in a page that sends visitors' data somewhere new. On Sitesfare the browser refuses the new destination, whoever changed the page.

What you will see: Settings → Site capabilities lists the services seen at publish. If your code later calls a service that was not there (an API called only after a click, say), visitors' browsers report the attempt and it shows under Blocked attempts with an Allow button. Allow it and the policy is updated within a minute.

Websites that existed before Shield spent their first week in watching mode — reported, not refused — and are enforced from 10 November 2026. New websites are enforced from their first publish.

2. Where visitors' secrets may go

If a page on your website asks a visitor for a password, a card number, a one-time code or a PIN, there is one more rule: what they type may only go to

  • your website itself and Sitesfare,
  • a short list of services nobody can read from (fonts, maps, captchas, video players, the payment providers' own checkout calls), and
  • destinations you have proved you control.

Everything else is held back by the browser until you prove it. A verified business unlocks every destination its files name.

Proving a destination (two minutes)

  1. Open Settings → Site capabilities. Under Where visitors' secrets may go, the destinations waiting for proof are listed — press Prove it is mine.
  2. Sitesfare shows a TXT record: a name like _sitesfare.api.yourdomain.com and a value starting sitesfare-proof=. Add it in your DNS (the same place you manage your domain). Putting it at _sitesfare.yourdomain.com instead proves every host of that domain at once.
  3. Press I added it — check now. DNS changes can take up to an hour to show; once the record is found, the browser allows the destination immediately.

The proof is re-read at every publish. If the record disappears, the destination waits again — so leave it in place.

Try the destination checker above: type any host and see what the browser will do with it, and the exact record to add.

If your API lives on a shared platform

Addresses like myapp.herokuapp.com, something.vercel.app or name.up.railway.app cannot carry your record: their DNS belongs to the platform, not to you. Put a domain you own in front (api.yourdomain.com pointing at it) and prove that — or verify your business.

Analytics and chat widgets

Analytics and error reporting keep working on a login page. A live-chat widget does not, where secrets are typed: a person on the other end could read what the page pushes into the conversation. Keep chat on your other pages, or verify your business.

3. A robot visits your website

An hour after every publish, then a day later (on a phone), a week later and weekly after that, a robot opens your website the way a visitor would, scrolls, waits, and — on every form that asks for a secret — types a one-off fake password and follows where it goes. A report about your site, or a sudden burst of visitors, brings a visit forward.

Three outcomes:

  • Clean — nothing to do; the screenshot is kept as the approved look of your site.
  • A review — something looked unusual (an unknown destination, a page that changed with no publish). A person looks; you will hear from us only if there is something to fix.
  • A proof — the fake password reached a chat-bot or paste service, or the page is on Google's danger lists. The site goes offline within the visit and the owner is emailed. Nothing is deleted; a mistake is undone in a minute from the admin's side.

Two independent unusual signs put a warning page in front of the site until a person has looked. Visitors can still continue to the site; nothing is deleted.

The timeline above shows what happens at each visit.

4. New accounts

For the first 24 hours after you join, your website reaches the standard services, proofs and extra destinations open the next day, you can make two websites a day, and search engines are asked to wait until the robot's first clean look (usually within an hour of publishing). Trust is earned by time and clean visits, not granted at sign-up.

5. What happens to scams

When a scam is proved, the person behind it — not just the page — is the unit: that account's other sites go offline, it cannot sign up or publish again, and its files are remembered so the same kit is refused at upload whoever uploads it. Accounts linked to it by a shared bot token or webhook are reviewed; a person decides before anyone else is suspended. Sharing a family computer or a mail provider with someone never links you to them.

6. Reporting, and the numbers

Anyone can report a website at sitesfare.com/report, gets a case id, and is told the outcome. Our response targets and the last 90 days' figures — reports, sites taken down, sites cleared, the median time to act, what the robot found — are public at sitesfare.com/trust.

Questions people ask

My login page broke after publishing. Open Settings → Site capabilities: the destination is waiting for proof. Add the TXT record and press Check; it is allowed at once.

A service shows under "Blocked attempts". Press Allow if your site needs it. If you did not expect it, something on the page is trying to reach somewhere it should not — write to support.

Does this slow my site down? No. The policy is one header; the robot visits a few times a week.

Can I turn it off? No — it is what lets every Sitesfare website share one trusted domain. You can allow any legitimate destination in a click, and prove any destination of your own in two minutes.