# [Privacy Policy](https://rebilder.com/legal/privacy)

> What Rebilder collects, why, who processes it, how long we keep it, what never crosses to the negotiation side of the business, and how to get it all deleted.

- **Updated:** 2026-08-20
- **Author:** Rebilder LLC
- **Description:** What Rebilder collects, why, who processes it, how long we keep it, what never crosses to the negotiation side of the business, and how to get it all deleted.
- **Section:** Legal
- **Publisher:** Rebilder LLC

## Summary

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.

## Who we are

Rebilder is operated by Rebilder LLC, a company established in the United States, which is the data controller for the personal data described in this policy. Data protection questions, access requests and deletion requests: privacy@rebilder.com. We answer from a monitored address rather than a form, and a request sent there is a valid request under the GDPR, the UK GDPR and the CCPA.

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.

## What we collect — 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.

## What we collect — The Rebilder Tag, pageviews from your own site

The Rebilder Tag is a script a merchant can add to their own site to count pageviews, visitors referred by AI assistants, and automated browsers that declare themselves. It is installed by the merchant, on the merchant’s site, and we process what it sends on the merchant’s behalf as a processor; the merchant’s own privacy notice governs their visitors. Each pageview beacon carries three things: the path of the page with any query string removed, the referrer when it comes from another site, and whether the browser declared itself automated. Our server adds the time from its own clock; the tag sends no timestamp.

- No query string is ever stored. The tag sends the path alone, the endpoint strips any query that reaches it anyway, and the database refuses a path that carries one, so search terms, tokens and tracking parameters never enter the table.
- A pageview row carries no IP address and no IP hash. Rate limiting for the beacon endpoint uses the same daily-salted hashing described below, in separate short-lived rows, and nothing joins a pageview to a network address.
- No raw User-Agent is stored. The referrer is classified into a platform name on our server and only the classification is kept.
- The tag sets no cookie, uses no browser storage, and creates no visitor identifier, session identifier or fingerprint. Rows are pageviews, not people, and any visitor figure derived from them is an estimate labelled as one.
- The tag honours Do Not Track and Global Privacy Control: when either signal is on, it sends nothing at all.
- The tag never runs on rebilder.com itself, so everything this page says about visits to rebilder.com is unchanged by it.
- Beacons go to a single fixed Rebilder address with no override, so no other script on a page can redirect a merchant’s events elsewhere.

## What we collect — 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.

## What we collect — Scanner emails, and two separate consents

The score, the grade, every check with its evidence, the byte comparison, the permalink, and the written fix for the single check costing the most points are ungated. You never give us an email to see what is wrong with your page. The full fix list opens in your browser and we do not email it. If you give us an address to receive it, we store that address, the scan it belongs to, the time, and a hashed IP.

- We are not sending the report by email today. We keep the address so we can send it if you ask, and so we can reach you about the scan you ran.
- 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. It opens on screen either way.
- Every marketing email carries a one-click unsubscribe, and unsubscribing is honoured for the address, not for a campaign.

## What we collect — 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.

## What we collect — Visits to rebilder.com

Our public pages run one third-party analytics tag: Ahrefs Web Analytics, which tells us which pages people read and where they arrived from. It sets no cookie, writes nothing to your browser storage, and assigns you no identifier that follows you between visits or between sites. It is not an advertising pixel and it does not build a profile of you.

Per Ahrefs, the tag reports the URL you viewed, the page that referred you, your browser and operating system from the user-agent string, your language preferences, and a location no more precise than a city, which is derived from your IP address and then discarded rather than stored. We receive these as aggregate counts; we cannot single you out in them, and we do not try to.

It runs on the pages anyone can read. It is deliberately absent from the Console, from our internal operator pages, and from the sign-in and sign-up screens, because those URLs can carry things a marketing tag has no business seeing. Our hosting provider separately records standard request logs.

If you would rather not be counted at all, any content blocker that blocks analytics.ahrefs.com stops the script loading, and nothing on this site behaves differently when it is blocked. We do not detect blockers and we do not ask you to turn one off.

## What we collect — Cookies, and why you are not asked to consent to them

Every cookie this site sets is strictly necessary for something you asked it to do. There are no analytics, advertising, personalisation, or cross-site tracking cookies, so there is nothing here to consent to and we do not show you a consent banner. A banner over necessary-only cookies would be theatre, and it would train you to dismiss the ones that matter elsewhere.

- Session cookies, set when you sign in to the Console, which keep you signed in and let the server tell your requests apart from anyone else’s. They are set by our authentication provider (Supabase) on our own domain, and signing out clears them. Without them the Console cannot work at all.
- A bot-check cookie may be set by Cloudflare Turnstile on the public scanner at /scan, solely to tell a person from an automated script before we spend a scan on the request. It is a security control, not a profile, and it is not used to identify you across sites.
- One entry in your browser’s local storage, named rb-guide-offer, set when you close or complete the small guide offer in the corner of a marketing page. It holds the single word "closed" or "done", it is never sent to us, and its only purpose is to stop the offer asking you again. Clearing your site data brings the offer back.

Marketing pages you can read without signing in set no cookie of ours at all. That remains true now that we run an analytics tag, because the tag we chose is cookieless: Ahrefs Web Analytics stores nothing in your browser and gives you no persistent identifier, which is the reason there is still nothing here to consent to. Had we picked a tag that sets one, that cookie would not have been strictly necessary, and this section would have said so, with a consent prompt, before it was switched on.

The rule has not moved: if we ever add cookies that are not strictly necessary, we would ask for your consent before setting them, and this page would say so first. See “Visits to rebilder.com” above for what the analytics tag does record.

## 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 may use a scan result as the basis for marketing contact with the business it describes, an email about that site’s own results, sent to a business address we hold or that is published for that purpose. We do this only for business contacts, never for a natural person’s personal address; every message identifies us, states why you received it, and carries a one-click unsubscribe we honour permanently. Unsubscribing is independent of removal: leaving our mailing list does not remove an index entry, and removing an index entry does not require you to be on it.

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.
- **Tag pageviews** — Held for the same window as gateway events, never longer than 13 months, and 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 personal data is transferred there under the Standard Contractual Clauses adopted by the European Commission, together with the UK International Data Transfer Addendum where the UK GDPR applies. Each sub-processor we use is engaged under those clauses or an equivalent approved mechanism, and the sub-processor list names the country of processing for every one of them.

## 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.