Legal

Privacy policy

Last updated 13 September 2026

GetCited crawls the sites you add, tracks how they rank, checks how AI engines answer questions about them, and, if you install the snippet, records what visitors do on your pages. This page says exactly what is stored, for how long, and who else sees it.

It is written against the code that is running, not against a template. Where something is designed but not built yet, it says so instead of claiming it.

Two kinds of data, two different roles

Everything on this page falls into one of two buckets, and our legal role is different in each.

Account data is about you, our customer. We decide why and how it is processed, so under the GDPR we are the controller.
Visitor data is collected by the snippet on your site and is about your visitors. You choose to install it and you choose what it is used for, so you are the controller and we are your processor. We process it to run the service for you and for nothing else.

What we store about you

Account: your name, email address, whether that address is verified, and an avatar URL if you signed in with Google. If you signed up with a password, only a hash of it is stored.
Sign-in sessions: a session token, its expiry, and the IP address and user agent of the browser that signed in. This is the one place a raw IP address is written to our database, and it is yours, not your visitors'.
Organization: name, slug, members and their roles, and pending invitations with the email addresses they were sent to.
Projects: the domains you add, crawl results for them (URLs, status codes, titles, meta tags, headings and other on-page findings), tracked keywords, rank history, GEO prompts and the answers engines gave.
API keys: a SHA-256 hash of each key and its label. The key itself is shown once when you create it and cannot be recovered from us.
Usage counters: monthly counts per organization of pages crawled, keyword lookups, rank checks, GEO prompts, brain runs and sessions. They drive quotas and billing.
Billing: plan, subscription status, current period end, and the Polar customer and subscription ids.
Email records: every message we send you is recorded with its recipient, type and timestamp.

What the snippet collects about your visitors

The snippet is a single plain JavaScript file served from our domain and loaded on the pages you choose. It sends semantic events, not recordings. There are fourteen event types and this is all of them, with everything each one carries.

session_start: Referrer (up to 500 characters), landing URL (up to 1000 characters, including its query string and any UTM parameters), a coarse device bucket of mobile, tablet or desktop, viewport width and height, and whether the browser reported navigator.webdriver.
pageview: The page path and the document title.
scroll_depth: One of 25, 50, 75 or 100.
content_seen: A heading or section that stayed at least half visible for 500ms: its tag name, up to 140 characters of its text, and how long it was on screen. This is text from your page, not from the visitor.
click: Tag name, up to 80 characters of the element label, the href if the element is a link, and a short CSS selector built from the tag, id and first two class names.
rage_click: Three clicks inside 1000ms within 30 pixels: the same element reference plus the click count.
dead_click: A click that changed nothing on the page: the same element reference.
form_start, form_submit, form_abandon: The form id, name or action attribute, the number of fields in the form, and how many of them were touched. No field values.
copy: Up to 200 characters of copied text. Email addresses and runs of six or more digits are replaced with placeholders in the browser before the event leaves the page.
visibility_change: Whether the tab became visible or hidden, and milliseconds of foreground time so far.
exit: Foreground active milliseconds, the furthest scroll percentage, and an engaged flag.
error: Up to 200 characters of a JavaScript error message from your page.

Every event also carries a session id, a sequence number, a timestamp and the page path. URLs are reduced to their path before storage, so query strings and fragments are dropped. The exception is the landing URL and referrer on session_start, which are kept whole so the visit can be attributed to a channel.

Every visitor-controlled string is cleaned before it is stored: control characters and zero-width characters are removed, whitespace is collapsed, and the string is truncated to the limits above. The same strings are marked as untrusted wherever they are passed to a model or returned through our MCP tools.

What the snippet does not collect

No cookies. Nothing is written to document.cookie.
No session recording and no replay. There is no DOM capture, no mouse path, no video.
No keystrokes and no form field values. Form events count fields, they do not read them.
No raw IP address is stored. The IP is used in memory to derive a visitor id and is then discarded.
No cross-site or cross-customer tracking. A visitor id is scoped to one project and cannot be joined across your own sites, let alone across our customers.
No advertising. We do not sell visitor data, share it with ad networks, or build profiles for anyone but you.
No third-party scripts. The snippet loads nothing else and talks only to our collection endpoint.

The snippet does keep three short-lived keys in sessionStorage so a session survives page navigation. sessionStorage is cleared by the browser when the tab closes and is readable only by your own site.

One known exception, and we are fixing it

When a visitor clicks directly on an input or textarea, the snippet records that element label. For those two tags the label falls back to the field value, so up to 80 characters of what the visitor had typed can be stored on a click event. This is a bug, not a design decision.

Until it is fixed, treat click events on form fields as possibly containing typed text, and do not install the snippet on pages with sensitive forms. We will remove this note when the fix ships.

How visitor identity works

A visitor id is a SHA-256 hash of a server-side secret, the current UTC date, the project id, the IP address and the user agent, truncated to 32 hexadecimal characters. The IP address and user agent are used only to compute that hash during the request. Neither is written to the database.

Because the UTC date is part of the input, the id for the same person changes at midnight UTC and yesterday's ids cannot be matched against today's. There is no way to follow a person across days, across your sites, or across our customers. Sessions are closed on the server after 30 minutes of inactivity.

The honest limit: the server-side secret is a long-lived environment value, not a salt that is generated and destroyed each day. Someone holding that secret together with a candidate IP and user agent could test whether a given id belongs to that pair on a given day. We treat the secret as a credential. Rotating it daily is on the roadmap and is not in place yet.

How long data is kept

Raw behavior events: the design is 90 days. The job that deletes them is specified and not yet implemented. Until it ships, raw events stay in the database until you ask us to delete them or you delete the project. We would rather write that down than imply a deletion that is not running.
Behavior sessions: the design target is 400 days, under the same caveat as raw events.
Aggregates such as daily page rollups, keyword rollups and insights: kept for the life of the project. They hold counts and paths, never visitor identifiers.
Crawl results, rank history and GEO answers: kept for the life of the project so history charts work.
Account, organization and billing records: kept while the account exists, and after that only where we have to keep them, such as invoice records Polar holds for tax purposes.
Dashboard sign-in sessions: deleted when they expire.

Our backup policy is not finalised. Once it is, this section will state how long a deleted record can survive in a backup.

Sub-processors

These are the third parties that can see data as part of running the service.

Anthropic: Runs the hosted brain that turns your site data into the prioritised action queue. It receives aggregate metrics, page paths, crawl findings, keywords and rank history for the project being analysed. Individual visitor events are not sent to it. Used only when the brain is configured with Claude.
DataForSEO: Keyword volumes, SERP positions and AI engine answers. It receives your domain, the keywords you track and the GEO prompts you add. No visitor data.
Polar: Subscriptions, checkout, invoices and sales tax. Polar is the merchant of record and receives your name, email and payment details directly. We store only your Polar customer id, subscription id, plan and status. We never see or store card numbers.
Resend: Transactional and weekly digest email. It receives the recipient address and the message contents, which include a summary of your site findings. Used only when an email API key is configured; otherwise emails are logged and never sent.
Google: Google sign-in, if you choose it. Google receives the sign-in request and returns your name, email address and avatar URL. A Google Search Console connection is in our plans and is not built yet; when it ships, connecting it will send your Search Console query and page data to us, and this list will be updated first.

The production host for the application and its Postgres database is not finalised. This page will name that provider before the service is generally available.

We do not offer a signed data processing agreement today, and we have not completed standard contractual clauses or a transfer impact assessment for these transfers. Most of these sub-processors are based in the United States. If your use requires a DPA, email us and we will tell you where that stands rather than send you a document we cannot stand behind.

Legal bases

Account data: performing our contract with you, our legitimate interest in security and abuse prevention, and legal obligation for tax records.
Visitor data: you choose the basis, because you are the controller for it.

On consent banners: the snippet sets no cookies, but it does use sessionStorage, and sessionStorage is storage on the visitor's device. Regulators differ on whether cookieless analytics of this kind is exempt from the consent requirement in Article 5(3) of the ePrivacy Directive. We are not lawyers and this is not legal advice for your site. You decide whether your site needs a banner or a notice, and that decision is yours to make.

Your rights and how to delete data

You can ask for a copy of your account data, a correction, an export, or deletion. Email us from the address on the account.
There is no self-serve delete button in the dashboard yet. Deletion is a manual request today. We will acknowledge within five business days and complete it within 30 days.
Deleting a project deletes its crawls, keywords, ranks, GEO answers, behavior sessions and raw events. Deleting the organization deletes all of that plus members, invitations and API keys.
If you are in the EU, the UK, California or another place with equivalent law, the rights you already have apply here. You can also complain to your supervisory authority.

Rights of your visitors

If one of your visitors asks about the data the snippet collected, you are their point of contact and we will help you answer. Be aware that because the visitor id is a daily hash of inputs we do not keep, we usually cannot tell which rows belong to a specific person from an email address or an IP address. Article 11 of the GDPR covers exactly this situation: we are not required to collect more data just so we can identify someone.

What we can do is delete a project's data, a date range of it, or everything tied to a session id the visitor is able to give you.

Security

All traffic runs over HTTPS. Passwords are hashed. API keys are stored only as SHA-256 hashes.
Every domain table carries an organization id and every query is scoped to it. MCP tools resolve the project through an ownership check before touching any data.
Visitor-supplied strings are treated as untrusted input everywhere, including in the fields handed to the model.
We hold no SOC 2, ISO 27001 or equivalent certification, and we have not had a third-party penetration test. We will say so here until that changes.

Report a vulnerability to [email protected]. Please do not open a public issue for it.

Children

The dashboard is for site owners and is not intended for anyone under 16. We do not knowingly collect account data from children.

Changes to this policy

We update this page when the product changes, and the date at the top with it. Material changes are emailed to account owners before they take effect.

Contact

Privacy questions go to [email protected]. Everything else goes to [email protected]. The source for the snippet and the rest of the platform is at github.com/bapierre/vanpelt-seo, so you can check any claim on this page against the code.