Privacy

Privacy

Most privacy policies are written to cover every future possibility. This one describes what actually happens today, and it is short because almost nothing happens. When that changes, this page changes first — before the feature ships, not after.

Last updated 13 September 2026. Answermend is a product of AdModifier LLC, 30 N Gould St #40766, Sheridan, WY 82801, United States. AdModifier LLC is the data controller for anything described on this page. Questions about anything here: hello@answermend.com.

The short version

  • This site sets cookies only if you allow it. The only ones are Google Analytics’s; nothing we run ourselves sets one, and nothing is set until you answer the box at the bottom of the page. Change your answer.
  • This site runs two page-view counters, and both are ours by choice. (A third, injected by Cloudflare at its edge, ran here until 2 September 2026; what it was and why it is gone is below.) One is ours, served from our own server at analytics.answermend.com: it sets no cookie and leaves nothing on your device. The other is Google Analytics: it is Google’s, it sets cookies, and it sends a record of your visit to Google. We would rather say that in the first paragraph than bury it. What each one records, and how to stop either, is below.
  • The eight free generators, the crawler log analyzer, and the schema validator when you paste code into it run entirely inside your browser. What you type or paste into them is never sent anywhere, including to us.
  • The eight site checks are the opposite and we will not pretend otherwise: the address you type goes to our server, which fetches it. No record of it is kept.
  • We hold no account for you unless you sign in at app.answermend.com — the free tools never create one. If you do have one, what it holds, how sign-in works and how to export or delete it is set out below.

Every one of those is checkable rather than a promise: open your browser’s network panel and storage inspector while you use the tools.

The free tools

The FAQ, Organization, Product, Article and LocalBusiness schema generators, the robots.txt, llms.txt and hreflang generators, the AI Crawler Log Analyzer, and the Schema Markup Validator’s paste mode are ordinary JavaScript running on your own machine. Your questions, answers, business details, log files and pasted markup stay in the page. There is no request that carries them to a server, so there is nothing for us to store, log or lose.

If you copy the result and paste it into your own site, that is you publishing it. Nothing about that step involves us.

The eight site checks

The AI Crawler Checker, the AI Readiness Score, the Render Check, the llms.txt Checker, the AI Content Checker, the Open Graph Checker, the Canonical Tag Checker and the Schema Markup Validator’s URL mode work the other way round, and every one of their pages says so. They have to: a browser cannot read another domain’s robots.txt or raw HTML, because those files carry none of the headers that would let it. So the work happens on our server, and none of these eight can honestly be called private to your browser.

What your browser sends. The web address you typed, and nothing else from the page. It goes to api.answermend.com inside the body of a POST request — deliberately not in the URL, so it cannot be picked up by a log line or a referrer header on the way. No name, no email, no account, and no cookie from the check itself (Google Analytics sets its own, described under Analytics). Your IP address and your browser’s user-agent reach that server the same way they reach any server you send a request to.

What our server does with it. For the Crawler Checker, the Readiness Score and the Render Check, it fetches the address you gave and the robots.txt at its origin, following redirects and checking each hop. It reads the raw HTML and runs none of the JavaScript, which is the whole point — that is what a non-rendering AI crawler receives. It then asks for the same page again while identifying itself as a crawler, so the two answers can be compared; the Readiness Score repeats that once for each AI crawler it reports on, so a single readiness check makes roughly fourteen requests to the site being checked. All of them come from our server, not from you: the site sees our address in its logs, never yours.

The other five fetch less. The llms.txt Checker reads the /llms.txt at the address’s origin. The AI Content Checker and the Schema Markup Validator read the one page. The Open Graph and Canonical checkers read the page, the first 64 KB of its og:image (enough to read its size), and the status of up to three addresses its canonical tags name. The Render Check’s Googlebot mode sends its request with the user-agent string Google documents for Googlebot; it still comes from our server’s address, not Google’s.

What is kept: nothing. None of the eight checks writes a record of what you checked — not the address, not the result, not the fact that you ran it. There is no database row, no file and no queue behind them; the answer is built in memory, sent to you, and dropped. The only things this server writes to disk are the email list described below and, when the scan runs, a scan result. The one thing held past the request is a count of recent requests per IP address, kept in memory to enforce a rate limit of 30 requests per ten minutes, and lost whenever the service restarts.

What does leave a trace. The ordinary web-server log line for the request itself: time, IP address, user-agent, and which endpoint was called. It does not contain the address you checked — the log format drops query strings, and the address travels in the request body, which is never logged. We have not set a deletion schedule for those log files, and we would rather write that down than quote you a retention period we do not keep to. When one is set it will be named here.

What we will not do with it. The domain you check is not published, not shared and not sold. It does not appear in a public page, a case study or any aggregate, and nothing from a check is used to train a model.

The email fields on this site

There are three email inputs on this site: one on the pricing page, one in the result panel of the AI Visibility Checker, and one that appears when you download a copy of a result from the app. All three are the same form doing the same job. The third asks after the result is already on your screen — the address buys the copy, never the answer, and a signed-in account is never asked because we already have it. They post to the same endpoint, store the same fields, and add you to the one list. If you tick the box and submit either of them, we keep your address. Here is exactly what that means.

What is stored: your email address, the page and form it came from, the words of the consent notice you were shown, and the times you gave consent and were added. Nothing else — no IP address, no browser user-agent, no referrer. Those columns do not exist in the record.

Where it is stored: in a Postgres database operated for us by Supabase, under access rules that keep one account’s records unreadable to another. It is not sent to a mailing-list provider, an analytics tool, or anyone else, and Supabase holds it on our instructions only. Until 2 September 2026 this was an append-only file on our own server in Manassas, Virginia; that file still exists as a rollback copy and nothing writes to it any more. We have not yet confirmed which region Supabase stores it in, and we would rather say so than name the wrong one — it will be named here once we have checked it in their console.

Why: so we can send you the one email both forms describe — when the plans go on sale. It is not a drip sequence and it is not shared or sold.

How to be removed: email hello@answermend.com from the address you signed up with, or from any address if you tell us which one to remove, and we will delete the record. No form, no account, no reason required. You can also ask what we hold about you and we will tell you.

If you do not tick the box, the address is not kept.

Server logs

Requesting a page leaves the ordinary record any web server keeps: IP address, time, the page requested, your browser’s user-agent string. The same is true of the separate server the three site checks run on. These are kept by the companies below as part of running the site, and we do not build profiles from them or combine them with anything else.

Who else touches a request

  • Cloudflare — DNS and CDN. Every request to this site, every request a site check makes to api.answermend.com, and every page-view message to analytics.answermend.com, passes through their network before reaching the origin.
  • Hostinger — the server these pages are hosted on.
  • Supabase — two jobs, and they are worth separating. It is the database holding the email list, every completed scan and every account record, since 2 September 2026. It is also our sign-in provider: your email address and the identity behind it live in its own store rather than in our tables, and it is what sends the sign-in link and code. They hold all of it on our instructions and for no purpose of their own; nothing there is used to train a model.
  • OpenAI, Google, Anthropic and Perplexity — the answer engines a scan questions: ChatGPT, Gemini, Claude and Perplexity. A scan sends them the questions derived from the page you gave us, which name the business being asked about. ChatGPT and Gemini are questioned on every plan; Claude is questioned on Pro scans only, which is the only difference between the plans on this point. They are the only engine vendors any scan reaches on any plan. None of the three is permitted to train on it — see above.
  • Resend — the service that delivers email we send from this product, such as a report of a scan you asked for. It is given the address and the message and nothing else, and it sends from send.answermend.com, a subdomain kept deliberately separate from our main one. Your sign-in link and code do not come from here — those are sent by Supabase, above. Anything else we ever send you goes out through this same provider rather than a new one, and if that changes it is named here first.
  • netcup — the server the site checks and the scan run on, in Manassas, Virginia, United States. The email list and the stored scans moved off it to Supabase on 2 September 2026; what runs here is the software, not the records. It is a separate machine from the one serving these pages, and it is ours to administer.

Every one of them acts on our instructions, and none is sent anything beyond what is needed to serve you the page, run the check you asked for, or deliver an email you asked for. That is the whole list. If one is added, it is named here before it is used, not after.

Analytics

We count how many people reach these pages and which ones they read, and it is done by two tools, which deserve different descriptions. We chose both. A third ran here until 2 September 2026; the next paragraph is its whole history, kept on this page rather than deleted along with it.

Cloudflare Web Analytics — the one we did not add, and no longer run. Until 2 September 2026 Cloudflare injected a script (static.cloudflareinsights.com/beacon.min.js) into pages as they left their network. It was never in our source code and did not appear if you fetched a page with a plain tool — it was added at the edge, for browsers, and it reported a page view to Cloudflare. In its final configuration it was not injected for visitors from the EU. Because it sat outside the script we control, it did not honour Do Not Track, and it was present even on this page and on our terms page, which carry none of our own counters. We found it on 1 September 2026 while auditing our own claims, having previously stated on this page that there were only two. That was wrong, and we corrected it here in public rather than quietly fixing the count. We then decided to keep it — and on 2 September 2026 we reversed that and turned the injection off. What changed our mind: the same beacon was being injected into our signed-in dashboard at app.answermend.com, where our Content-Security-Policy blocks every third-party script, so it was collecting nothing there in any case. That left two options — weaken the policy protecting the dashboard, or stop the injection — and the setting is account-wide, one switch covering every hostname, so switching it off for the dashboard switched it off here too. What that costs us, stated plainly: we no longer have loading, responsiveness and layout-shift figures from real visitors, which was the reason we had kept it, and neither remaining counter measures them. The two counters described above are now the only ones on this site, and both honour Do Not Track.

Ours — Umami. It runs on our own server in Manassas, Virginia, the same machine as the tools API, using Umami, an open-source program. It sets no cookie. It stores no IP address and no browser user-agent — those columns do not exist in the database. A visit is counted with a one-way hash that is re-salted every day, so yesterday’s visitor and today’s cannot be linked. Nothing it collects leaves that machine.

Google’s — Google Analytics 4. This one is a third-party script, it sets cookies on your device (_ga and a second one named for the property), and it sends a record of your visit to Google, who process it on their own infrastructure under their own terms. As of that same date it receives the same handful of on-page actions our own counter records, described under “What is kept” below — that the action happened, on which page, and where a button or link was involved, the words written on it. Never what you typed into a generator or a form. We have turned Google Signals off, which is the setting that would otherwise let Google join your visit to an advertising profile across sites and devices. We run no advertising pixel and no tag manager. But we are not going to pretend the rest of it is private: if you would rather Google did not see this visit, use a blocker — most block it, and we do not work around them.

Both honour Do Not Track. If your browser sends that signal, neither counter starts. It would be incoherent to respect it for our own cookieless counter and ignore it for Google’s.

Your choice about the Google cookie. Because Google Analytics is the only thing here that writes to your device, it now asks first. On your first page view a box appears at the bottom of the screen with two buttons of the same size — Allow the Google cookie and Do not allow the Google cookie — and until you press one, Google Analytics is not loaded, not configured and sends no request at all; there is no “you declined” ping either. Press no and nothing you can read or use changes: the two cookieless counters above keep counting the page view, and any _ga cookie left from a previous yes is expired on the spot. If your browser sends Do Not Track, that counts as a no and the box never appears — you have already answered. Your answer is kept in this browser’s local storage under am_cookie_choice; it is not a cookie, it is not sent to us or to anyone else, and clearing your site data clears it. You can change it whenever you like: change your cookie choice.

Nothing either one collects is sold, and nothing is used to train a model.

That is a claim worth being specific about, so here is the whole of it.

No cookie from Umami, and nothing left on your device. The Umami script sets no cookie and writes nothing to your browser’s storage. (Google Analytics, described above, is the one that does.) The one thing it reads is an opt-out flag, if you have set one. There is no identifier on your machine to delete, and nothing that could follow you to another site.

How a visit is counted without one. When a page loads, your browser sends a short message to analytics.answermend.com. Our server takes your IP address and your browser’s user-agent string, combines them with this site’s id and a secret value that changes every day, and puts the result through a one-way hash. That hash is the “visitor”. It cannot be turned back into your IP address, and tomorrow the same browser produces a different one. The IP address and the user-agent are used to compute it and are then gone: there is no IP address column and no user-agent column anywhere in the database. The message itself is not written to our web-server log either.

What is kept. Per visit: that hashed id, the page path, the query string if the address has one — including any utm_ campaign tags and advertising click ids such as gclid or fbclid that the address carries — the page title, the address of the page you arrived from, and the time. Worked out from the user-agent before it is discarded: browser, operating system, device type, screen size, language. Worked out from your IP address before it is discarded: country, and where they can be told, region and city — either from the country label Cloudflare has already attached to the request in passing, or on our own machine against a geolocation database file stored on it. No lookup service is asked, and the program cannot ask one. And for a few on-page actions — copying a generator’s output, downloading a file, submitting the email form — that the action happened, and on which page. Never what you typed into it. And a few on-page actions, recorded the same way: that you copied or downloaded something a generator made, that you submitted a form, and when a button or link is involved, the words written on it, cut at 60 characters. Never what you typed into a generator or a form — those stay in your browser and are described above. This sentence was added on 1 September 2026: these actions had been recorded since the counter went live and this page had not said so.

About that referring address. We would rather describe it exactly than round it off: the page you arrived from is stored in three parts — its domain, its path and its query string. That is the referring address minus the https://, not just the site it came from. Moving between two pages of this site records no domain at all.

What is never kept. Your IP address. Your user-agent string. Any name or email address — the one exception is the two email fields described above, whose records are separate and are not connected to this one. And nothing you enter into the six generators, which still run entirely inside your browser and still send nothing anywhere.

No session recording. Umami can record and replay a visitor’s screen. That feature is switched off, has never been switched on, and switching it on would be a material change that lands on this page before it lands on the site.

It does not talk to anyone. The analytics service on our server is blocked at the operating-system level from making any outbound network connection at all — it can reach its own database and nothing else. Its built-in usage reporting and update checks are both switched off as well. This is enforced by the machine, not by a setting we promise to leave alone.

How to switch it off. Any browser setting, extension or blocklist that blocks analytics.answermend.com stops all of it, and nothing on this site breaks when it is blocked. We also honour your browser’s “Do Not Track” setting: with it on, nothing is sent.

The scan, when it runs

The AI visibility scan went live on 1 September 2026. It processes the website address you give it, reads that page to work out what questions a customer of yours would ask, and puts those questions to ChatGPT and Gemini on our own servers — not in your browser. It records the address, the questions, what each engine said about you, and any competitor domains those answers named. That is customer data and it is treated as such: it will never appear in a public page, a case study or a shared dataset without explicit, separate permission — never bundled into a terms page — and nothing will be used to train a model. The scan has been running since 1 September 2026, and the detail above is that full description rather than a promise of one.

If you have an account

Sign-in went live before this page described it, and that is the wrong way round. This page’s own rule is that it changes first — before the feature ships, not after — and on accounts it did not. This section is the correction, written from what the code actually stores rather than from what an account might one day hold. The free tools and the three site checks still create no account, and nothing above this line changes because this section exists.

Signing in, and what it leaves on your device

There is no password. We do not set one, do not store one and never ask for one. You give an email address and get back a one-time sign-in link and a six-digit code; either signs you in, and both work once. The code exists because a link opens in whichever browser your mail app chooses, which is often not the one you started in.

How long the link and the code last is set by our sign-in provider, not by this server. They expire, they work once, and asking for a new one replaces the last. The same is true of everything else here that has a limit — a signed-in session, an invitation to join an account, a report link, the receipt that unlocks a report’s full list. Every one of those expires and every one is enforced, and this page deliberately publishes none of the durations. They are security settings we tune as we need to, not commitments we have made to you, and printing one here would turn it into a promise nobody agreed to keep. Where a date actually matters to you, you are shown that date rather than a rule: a report link carries its own expiry, in your own timezone, on the page it opens.

The session is kept in this tab, not on your device. It lives in your browser’s sessionStorage under am_session — not a cookie, and not local storage. Closing the tab ends it, so signing in does not survive a browser restart. That is deliberate and it is the narrower choice: the token can read your whole scan history, and we would rather you signed in again than left it lying about. If that is ever widened, this page changes in the same edit.

What an account holds

This is the list, taken from the database itself rather than described in general terms:

  • The account — its name and when it was created.
  • Who is on it, and at what role — owner, admin or member.
  • The brands and locations you track — name, domain, and a location label if you gave one.
  • Every scan the account has run — the brand and domain, which engines were asked, when, and the summary.
  • The questions each scan asked, the competitor domains those answers named, and the sources the answers cited.
  • What each engine answered, question by question — the verdict, how many runs it rests on, and which model produced it.
  • Fixes you told us you had applied, and which questions each was aimed at.
  • What the account pays for — plan, status and period end — and the payment provider’s event ledger.
  • Invitations you sent that nobody has accepted — the address, the role and the expiry.
  • Report links minted for your scans — stored as hashes, never as the link itself, alongside the scan they point at.
  • A re-scan schedule, if one is set — the address to send to, the domain being watched, and the frozen set of questions.

Your email address is not in those tables. The login itself — the address and the identity behind it — is held by Supabase, our sign-in provider, in its own store. This service reads it to know who you are and which account you belong to. That distinction matters for deletion and is picked up below rather than glossed over.

The fix files are not stored at all. The FAQ schema, Organization schema, robots.txt and llms.txt a scan produces are rebuilt from the stored scan each time you ask for them. There is no table of them. That is written down rather than left as an empty heading, because an empty heading reads as “we found none”.

Your scans are confidential, and nothing trains on them

A scan record is a brand, its competitors, and where that brand is losing. It is treated as what it is.

It will never appear in a public page, a case study or a shared dataset without your explicit, separate permission — asked for in plain words, on its own, and never bundled into a terms page or a cookie box. A consent collected that way is not a consent. There is no switch in the product to turn this on, which is why you will not find it in your settings: a switch implies a value that could be set.

Nothing from a scan is used to train any model. Not by us, and not by anyone we send it to. This is worth stating as a commitment rather than a policy, because it has already been tested: on 2 September 2026 an API provider offered this account a substantial daily allowance of free credits in exchange for permission to train on the traffic we send them — which is your scan data. It was declined in writing the same day. Nothing changed as a result, which is the point of saying it here.

Getting a copy of it, and getting it deleted

There is a page for both, and you do not have to write to us. Sign in and open the Your data section of your Account page. It hands you the whole of it as one JSON file, and deletes the account. Two limits, because they are real: the export is available to admins and owners, since the file contains billing rows and the addresses of people invited who never joined; the deletion is the owner’s alone, sits behind a three-step confirmation, and cannot be undone. If that page cannot run one of them it says so and says why, rather than appearing to work.

An export is all of it or none of it. If any part of your record cannot be read, no file is sent at all. A bundle handed over as “everything we hold” with a section quietly missing is the one failure this refuses to risk.

What a deletion does not reach. This is the honest half, and it is the reason the paragraph above is not the whole answer:

  • Your login. It lives with our sign-in provider and this service has no way to delete it. After the account is gone you can still sign in — to nothing. Saying “your data is deleted” without saying that would be false in the one place you could check for yourself.
  • Encrypted backup archives taken before the deletion still contain the rows, until those archives expire. Deleting a live record does not reach into a backup and we are not going to pretend it does.
  • A re-scan schedule. It is keyed on an address and a domain and carries no account id, so the only way to match it to an account is by domain — and two accounts can watch the same domain. Matching on that could hand one customer another customer’s subscription, so a deletion counts it and names it and touches neither. To end one, use the unsubscribe link on the email or write to us.
  • Billing records are kept and unlinked from the account rather than destroyed.
  • The pricing-page email list is a separate thing with a separate request, so a deletion leaves it alone unless you ask for it in the same breath — there is a box on the request for exactly that.
  • Report links are revoked, which kills them. The index they live in is append-only, so an earlier line still names the scan. That residue is reported back to you in the receipt rather than described as gone.

Every export and every deletion is written to a journal before it is reported as done, and an admin or owner can read that account’s own entries on the same page — what was asked for, when, and by whom. Correcting something rather than deleting it has no button: write to hello@answermend.com and a person will do it.

Three things now expire on a schedule, and a job on our own server enforces it daily. This paragraph named no period until 5 September 2026, because until that day nothing ran.

  • The answer text from a scan — redacted after 90 days, not deleted. The words an engine returned, the sources it cited, the searches it ran, and how it described you are all dropped together. The description goes with the words on purpose: it was an inference drawn from prose we are deleting, and a verdict about you that you can no longer check against anything is not something to keep. What stays is the measurement: how many runs of how many named your brand, so your own history does not develop a hole where a scan used to be. A redacted check says so; it never reads as a zero, a drop, or a neutral opinion.
  • Crawler hits — deleted after 90 days. The records of which AI crawler fetched which of your pages, if you installed the collector.
  • The receipts for those hits — deleted after 400 days. Longer than the hits themselves on purpose: a receipt that attests to a record has to outlive it, and the job refuses to run at all if that ordering is ever inverted.
  • The answers you write yourself — no time limit, and that is deliberate. When a scan finds a question your brand was missing from, the draft page we hand you leaves the answer blank: filling it would mean inventing your position on your own business. If you type that answer into the app, we store it word for word and keep it until you delete it or close the account. It is not an engine’s output about you, which is why the 90-day clock above does not apply to it — it is your writing, and you may still be publishing from it a year later. Deleting it on our measurement schedule would destroy your work rather than protect you.

Everything else on this page is kept until you ask us to delete it, or until the account is closed. An unset period means KEEP here — it never silently means zero days.

Your rights

You can ask what we hold about you, ask for it to be corrected, or ask for it to be deleted. Today the honest answer to the first question is almost always “nothing”. Write to hello@answermend.com and you will get a real answer rather than a form.

If you are in California

AdModifier LLC is a United States company and this site is built for a US market, so the law that applies here is California’s (the CCPA, as amended by the CPRA) rather than the GDPR. Under it you may ask us to tell you what categories of personal information we collected about you and why, to hand you a copy, to correct it, or to delete it. You may also ask which categories we disclosed to anyone else.

Two of the usual CCPA answers are unusually short here, and both are checkable rather than promised.

  • We do not sell your personal information, and we do not share it for cross-context behavioural advertising. There is no “Do Not Sell or Share My Personal Information” link on this site because there is nothing for it to switch off. If that ever changes, the link appears here and on every page before it changes, not after.
  • There is no financial incentive attached to giving us anything, so there is nothing you would lose by exercising any of these rights. We will not treat you differently for asking.

What we actually hold is set out above, section by section: an email address if you typed one into the pricing form, server logs, a cookieless page count, and — if you ran the scan — the address you asked about and what the engines said about it. That is the whole list.

To make a request, write to hello@answermend.com. We will confirm we got it, and answer within 45 days; if it needs longer we will tell you why before that runs out. We will ask you to confirm the email address the request concerns, because it is the only identifier we have — there is no account to log in to. Someone may act on your behalf if you say so in writing.

You may also ask us not to keep an email address you gave us, and we will remove it rather than suppress it.

Changes to this page

13 September 2026. This page counted four generators and three site checks, and by this date there were eight and five. The llms.txt Checker and the AI Content Checker had gone live without being named here. Both are added above, with the three checks about to be switched on — the Open Graph and Canonical checkers and the Schema Markup Validator’s URL mode — written down before any of them is. None of the eight keeps a record of what you checked.

3 September 2026. This page had no accounts section, and sign-in had been open for a day. It described the free tools and the email list in detail and said nothing about what an account holds, how signing in works, or how to get a copy of it or have it deleted — on a page whose stated rule is that it changes before the feature ships. Three processors were missing from the list below it for the same reason: the sign-in half of Supabase, the answer engines a scan actually queries, and the service that delivers our email. Both are fixed above. Nothing in the new section describes a control that does not exist today — where something is not built, or does not reach as far as it sounds like it should, it says so.

The date at the top is the only version marker. The page-view counter described above is the change this version records, and it was written down here before it was switched on anywhere. If something material changes again — session recording, the email list connected to a sending provider, the scan storing results — the change lands here first and the date moves with it.