Legal

Privacy Policy

Rebilder is infrastructure for websites, so most of what we hold is about sites and software agents rather than about people. This page is specific about the places where that is not true: your Console account, the email address you give the scanner, and the hashed IP behind our rate limiter.

Draft last edited 2026-08-05. Not a review date.

Draft — not reviewed by counsel

This document is a working draft written by the Rebilder team for the owner and their lawyer to review. It has not been reviewed or approved by counsel, it is not yet a binding agreement, and passages marked TODO_OWNER are facts the owner still has to supply. Do not rely on it as legal terms until this banner is gone.

Who we are

Rebilder is operated by Rebilder LLC at TODO_OWNER: registered business address. For UK and EU data protection purposes, our representative (if one is required) is TODO_OWNER: UK/EU Article 27 representative, if required — confirm with counsel whether one is needed. Data protection questions and requests: privacy@rebilder.com.

For your Console account, your scan requests and your lead email, we are the controller. For the gateway events your install sends us and the content your site serves through it, we act on your instructions as a processor; your own privacy notice governs your visitors.

What we collect

Console account data

  • Your email address and authentication records, held by our authentication provider.
  • The organisation and store records you create, including the domains you register.
  • API keys — stored only as a hash. The key itself is shown once, at creation, and we cannot recover it.

Gateway events — what your install sends us

When an agent requests a page from a site running the gateway, your install records one event and posts it to us. An event contains: a store identifier, a timestamp, what kind of requester it was and which platform it identified as, whether that identity was cryptographically verified, the requested URL, the Accept header, the referrer, which response path ran, which of your sources answered, and how long the render took.

An event contains no IP address, no cookie, and no visitor identifier. That is a property of the event schema rather than a setting: the published event type has no field for one, and adding one would be a versioned, documented schema change. We therefore collect no consumer personal data beyond what you, the site operator, are already lawfully processing in your own logs.

A requested URL can carry personal data if your site puts it there. We do not strip query strings, because the URL is the thing being measured. Keep personal data out of URLs — for us and for everyone else who logs them.

Scan records

A scan produces a record of the target URL, the ARS version identifiers, the score and grade, and capture metadata: HTTP status codes, the redirect chain, response header names and values, byte counts, and a sha-256 hash of each response body.

We do not store third-party page bodies or prose excerpts. That is a copyright decision as much as a privacy one, and it is why re-scoring a page under a new ruleset re-fetches it instead of replaying a stored copy.

Scanner emails, and two separate consents

The score, the grade, every check with its evidence, the byte comparison and the permalink are ungated — you never give us an email to see what is wrong with your page. If you ask us to email you the written report, we store your address, the scan it belongs to, the time, and a hashed IP.

  • The report itself is transactional: you asked for it, we send it once.
  • Marketing email is a separate, unchecked box. We store the exact version of the consent wording you were shown and the moment you ticked it, so we can prove what you agreed to.
  • Declining marketing never withholds the report.
  • Every marketing email carries a one-click unsubscribe, and unsubscribing is honoured for the address, not for a campaign.

Hashed IPs, for rate limiting only

The scanner is a free service that fetches other people’s websites, so it has to be rate limited or it becomes a weapon. We hash the caller’s IP with a secret and a salt that rotates every UTC day, and store only the hash. The raw address never leaves the request that carried it and is never written to a database.

Because the salt rotates daily, yesterday’s hashes cannot be linked to today’s: the value is useful for a day of rate limiting and useless as a profile. Hashed IPs are used for rate limiting and abuse prevention, and for nothing else.

Under sustained load, or after repeated scans from one address, the scanner presents a bot challenge. That challenge is served by Cloudflare Turnstile, which collects browser signals and your IP address directly from your browser — see the sub-processor list.

Visits to rebilder.com

We run no third-party product-analytics tag, no advertising pixel, and no cross-site tracker on rebilder.com. Our hosting provider records standard request logs. Cookies are limited to what signing in requires.

Why we process it, and on what basis

To provide the service
Console accounts, event ingest, scan results, report delivery. Basis: performance of a contract with you.
To keep the service standing up
Rate limiting, bot challenges, abuse investigation, security logging. Basis: our legitimate interest in not being used to attack other people’s websites, balanced by hashing the identifier rather than keeping it.
To improve the product
Aggregate measurement of how sites and agents behave. Basis: legitimate interest. Published aggregates are additionally floored at 25 independent sites.
To send marketing
Basis: your consent, recorded with the wording you were shown, withdrawable in one click.
To comply with law
Tax records, responses to lawful process, copyright notices. Basis: legal obligation.

The data wall — what never crosses

We also operate MUMM, a consumer negotiation agent. People reasonably ask whether the site data we hold ends up on that side. It does not, and the answer is a database boundary rather than a policy paragraph.

  • Your per-site data never feeds a negotiation engine. Not your events, not your scans, not your score, not your traffic — at any granularity, for any customer, at any price.
  • The only figures that cross are aggregates computed over at least 25 independent sites, read through a dedicated read-only role that is granted access to the aggregate views and nothing else. An under-populated bucket is not visible to that role at all, so there is no query it can run that would identify you.
  • The floor of 25 is not a tunable. It is the same number in the code, in the SQL and on this page.
  • It runs the other way too: data whose subject is a MUMM buyer never crosses to the Rebilder side, at any level of aggregation, anonymised or not. "Agents could not find your shipping cost in 62% of attempts" describes a website and may cross. Anything describing people does not.
  • We never build a cross-site price or discount-depth data product, and we never sell negotiation clearing prices to sellers in any aggregation.
  • Every cross-boundary read is recorded with a structured log line and a best-effort audit row.

Publication and removal

  • Nothing about a named third party is published on a Rebilder index, ranking or badge without a verified opt-in from the domain owner.
  • Nothing derived from an authenticated, merchant-supplied or locally-run scan is ever published.
  • A scan result for a domain that has not opted in is private to the person who ran it, carries no social card, and is excluded from search indexing.
  • Removal is free, self-serve and permanent, and it is never purchasable.
  • We never make outbound sales contact on the basis of a score.

If a person’s name is their domain — a sole trader, a freelancer, a personal site — the opt-in requirement is the whole protection, and it applies to them exactly as it applies to a chain. To remove an entry, write to privacy@rebilder.com from the domain; suppression happens while we verify, not after.

Our crawler, and how to block it

The ARS probe identifies itself as rebilder-ars on every request and points at /bots, which documents what it fetches, how often, and how to stop it. In short: robots.txt first and nothing else until it resolves; the target URL twice, once preferring a machine representation and once preferring HTML; and per origin, /llms.txt and /.well-known/ucp. Nothing else is guessed at, no JavaScript is executed, no subresources are requested, and no cookies are sent or stored.

Naming rebilder-ars in a robots.txt group and disallowing it stops us. Anything that produces a published or permanent artifact obeys robots.txt in full. A blanket disallow addressed to every user-agent deliberately does not count as a refusal of the scanner, because blanket disallows are usually accidental and we would rather you decide than your misconfiguration decide.

We never send a User-Agent belonging to another operator. We imitate agent intent, never agent identity, so every request we make is honestly attributable to us.

Who else sees it

  • Sub-processors, listed with their purpose and data category at /legal/subprocessors. We update that page before adding a vendor.
  • Law enforcement or a court, on valid legal process, and we will tell you unless we are forbidden to.
  • A buyer of the business, under the same commitments — including the data wall and the publication rules, which are conditions of any sale, not preferences.
  • Never a data broker, an advertising network, or a list buyer. We do not sell personal information and we do not share it for cross-context behavioural advertising.

How long we keep it

Gateway events
Retained for the window shown for your plan on /pricing, and in no case longer than 13 months. Deleted sooner on request.
Scan records
For a domain that has not opted into the public index: 90 days from the scan. For an opted-in domain: the most recent scan for as long as the entry is published, deleted immediately on removal.
Scanner leads
Unsubscribing soft-deletes the row and keeps the consent record, because the evidence of what you agreed to is the thing that protects you. An erasure request hard-deletes it. Otherwise the record is kept for 24 months from the last contact.
Rate-limit rows
Hashed buckets are disposable and expire within about 7 days. They are unlinkable across days by construction.
Console accounts
For as long as the account is open, then 30 days, then deleted — less any billing records we are required to keep for tax purposes.

Being honest about the state of this: some of these windows are enforced today by a scheduled job and some are not — the cleanup automation is being built alongside the scanner. Where automation is not yet in place, deletion happens on request, and finishing the jobs is a launch blocker rather than a follow-up.

Your rights, and the route to exercising them

  • Access — a copy of what we hold about you.
  • Correction — fix anything wrong.
  • Deletion — erasure, subject only to records we are legally required to keep.
  • Portability — an export in a machine-readable format.
  • Objection and restriction — including to any processing we base on legitimate interest.
  • Withdraw consent — one click in any marketing email, or by writing to us.
  • Complain to a supervisory authority. We would rather you told us first, but that is your right, not our permission.

Send any of these to privacy@rebilder.com with enough detail to find the records — the address you used, the domain, or the scan link. We acknowledge within 5 working days and complete within 30 days, and we will tell you if a request will take longer and why. We do not charge for this and we do not treat you differently for asking.

Security

  • Everything is served over TLS.
  • API keys are stored hashed; secrets live in environment configuration and never in the repository.
  • The scanner refuses to fetch private, loopback, link-local and cloud-metadata addresses, re-checking on every redirect hop, so it cannot be pointed at an internal network.
  • Database access is split by role: the Rebilder service role cannot read the MUMM schema, and the benchmark reader can see only aggregate views.
  • Report a vulnerability to security@rebilder.com. We will not pursue anyone who reports in good faith and does not exfiltrate data.

Where it is processed

Our infrastructure is hosted in the United States. If you are in the UK or the EEA, your data is transferred there under the appropriate safeguards — TODO_OWNER: transfer mechanism — Standard Contractual Clauses / UK Addendum, to be confirmed and referenced with counsel. The sub-processor list names the country of processing for each vendor.

Children

Rebilder is a service for people who operate websites and is not directed at children. We do not knowingly collect data from anyone under 18. If you think we have, write to privacy@rebilder.com and we will delete it.

Changes to this policy

We post revisions here and email account holders about material changes at least 14 days before they take effect. Adding a sub-processor is announced on the sub-processor page before the vendor starts processing.

Contact

privacy@rebilder.com for anything on this page, including access, deletion, export and complaints. legal@rebilder.com for the Terms. security@rebilder.com for vulnerabilities. support@rebilder.com for everything else.

Other policies: Terms of Service · Privacy Policy · Sub-processors · Acceptable Use · Copyright and DMCA · Our scanner and crawler