Citeworthy is a product of Alan Wizemann, LLC, a Delaware limited liability company ("we", "us"). We provide website audit services at citeworthy.io and app.citeworthy.io.
What we collect. Account data (your name, email and Google account identifier when you sign in with Google), the site URLs you add, crawl results from your public web pages, and — only if you connect Google Search Console — read-only search performance data for the properties you choose.
How we use it. To run the audits you request, show you results, and send service emails you opt into. We do not sell personal data, and we do not use your data to train AI models.
Google user data. Search Console access uses the read-only scope only. Refresh tokens are stored encrypted; data is fetched solely to display your analytics to you, retained only while the site remains connected, and deleted when you disconnect or delete the site. Our use of Google user data complies with the Google API Services User Data Policy, including the Limited Use requirements.
Storage & processors. Data is stored with Cloudflare (Workers, D1) in their global infrastructure. Payment processing is handled by our billing provider; we never see card numbers.
Analytics on our own site. We use Google Analytics to understand how our own website and app are used (pages visited, feature usage events). This applies to citeworthy.io and app.citeworthy.io only — we never place Google Analytics, or any third-party analytics tag, on a customer site. See Google's privacy policy for how Google processes this data; you can opt out with standard browser controls or Google's opt-out tools.
Edge telemetry on connected sites. If you switch on the managed edge, requests to your site pass through our proxy, and we keep three different things about them — a detailed row for a small subset, a count of all of them, and, for the ones we fetched from your server and served as a page, how long your server took to answer us.
The detailed row is written for AI-crawler and AI-assistant fetches, search-engine referrals, and requests served from the markdown lane. It contains: the requested path, the HTTP status we returned, which of those four categories it was, the crawler name we matched in the user-agent string (for example GPTBot), the hostname of the referring site (for example perplexity.ai), and which lane served the response. That is the whole row.
The count covers every request your site serves through our edge, grouped by day and by category. There are 9 categories and this is all of them: a page view arriving directly or unattributed, a page view from a search engine, a page view from an AI assistant, a page view from another website, an AI crawler, another bot, an asset, and two catch-alls — requests that are none of the above (redirects, errors, robots.txt and sitemap fetches) and requests we could not classify at all. A count is all it is: a number in a row that says “on this day, this site served this many requests of this kind”. The count row holds no path, no IP address, no user agent, no referrer and no cookie, and nothing about it survives the increment — the request adds one to an integer and then stops existing. There is no record of an individual counted request to retain, disclose, or hand over if somebody asks us for one.
How long your server took to answer. When our edge fetches a page from your server, we measure the time from sending that request to your server's first response byte, and add it to a running total for that page path, that day — plus one tick in one of eight speed ranges, so the page's typical and worst response times can be reported honestly rather than as an average that hides them. That is the whole row: a day, a path, a total, and eight counters. It is measured only for requests your server actually answered as a page; assets, redirects, errors, pages we served from our own cache, and our own robots are all excluded. It is a measurement of your server, not of your visitor. It contains nothing about who asked — no IP, no user agent, no referrer, no cookie and no query string — and it is not a browser measurement: it does not include the visitor's own network, and it is not a Core Web Vital. We set no cookie and run no script to obtain it, because it is timed on our side of the connection.
What neither contains. We do not store the visitor's IP address. We do not store the raw user-agent string — only the crawler token we matched in it, or nothing. We do not store the referrer's path, and in your analytics the referring hostname is the only part of the referrer we keep. We set no cookies and run no script on your site, so there is nothing to identify a returning visitor with. We do not attempt to identify individual people, and this data is shown only to the owner of that site. This is truer of the counts than of the rows, not less: the counting side stores strictly less, over strictly more traffic.
One measurement we take across all traffic. We are trying to answer a question nobody has published an answer to — which search and AI engines still include the user's query in the referrer they send. So when a request arrives with a referrer, we read the names of its query parameters (for example q, source) and count how often each engine sent a query string at all. The values are never read. Not stored, not truncated, not hashed — the code lists parameter names and has no way to reach a value, which is a property of how it is written rather than a promise about how we behave. What that produces is one row per day per engine per set of names, with no site, no path, no visitor and nothing that could be traced back to a person or to your account. It is not shown in your dashboard because it is not about your site; we keep it 90 days.
What we therefore cannot tell you. Because we set no cookie and run no script, we cannot count unique visitors, sessions or bounce rate — and we do not estimate them. What we report is requests and page views, both counted. We mention it here rather than only in the product because it is a limit on what exists, not a feature we have not built yet: there is no stored value anywhere from which those numbers could be reconstructed, by us or by anyone who compelled us.
Edge telemetry retention. Individual rows are kept for 7 days on every plan. Daily per-site totals — both the detailed rollups and the counts — are kept for 30 days on Free, 12 months on Pro and 24 months on Studio. Deleting the site deletes all of them.
Turning it off. The pass-through switch in your dashboard stops us modifying responses within about a minute, but it deliberately does not stop telemetry or counting — the switch exists for suspected serving problems, and quietly losing your analytics during one would be a second failure. To stop both specifically, ask us to set the per-site telemetry flag off — it silences the detailed rows and the counts together, so there is no second switch to find — or remove the DNS record, which removes us from the path entirely.
Deletion. Deleting a site permanently drops its audit database. Deleting your account removes all account and site data. Email hello@citeworthy.io for any data request.