Skip to main content
SEOLens Evidence

Privacy

What this tool collects, and what it does not

The short version: there is no account or advertising profile, audit reports are not stored in an application database, and page-view URLs exclude the query containing your submitted audit target. The exact storage boundaries and analytics fields are below.

Last updated

No accounts or analytics cookies
There is no sign-up. Vercel Web Analytics records anonymous, aggregated page views without third-party cookies or a profile that follows you across sites. No custom interaction events are sent.
What anonymous analytics receives
A page view can include the page path and route, time, referrer, approximate location, browser, operating system and device type. New audits navigate to /analyze with an opaque one-time id, so the target URL is not put in the result page address, browser history, analytics event URL or referrer. This application also removes every query string and fragment from analytics event URLs. Legacy target-bearing links never start an audit automatically, require confirmation and receive a no-referrer policy.
Your history stays in your browser
An audit request is kept briefly in this tab’s sessionStorage under an opaque id and deleted before the audit starts, so copying the id cannot repeat the request. After a standard audit returns, one byte-limited recovery copy of its complete report can remain under that opaque id in this browser-managed tab session. It is accepted for restoration for up to 12 hours and is then removed while this site is active or the next time it is read. Browsers normally isolate sessionStorage by top-level tab, but may clone it into a duplicated or opener-created tab and may retain it for session restore. This lets refresh restore the report without fetching the website or an external performance provider again. By default, the selected theme, recent audit summaries, comparison snapshots and the selected baseline are kept in this browser’s localStorage. Snapshots include page titles, descriptions, headings, URLs and measured SEO signals. Select “Private / no-save run” to skip the recovery report, history, snapshots and baseline updates for that run. The “Clear all local audit data” control removes retained history, snapshots, the baseline and refresh-recovery report from the current tab; clearing this site’s browser data also removes local copies.
Internal link observations and local suggestions
Deep audits return bounded link destinations, anchor text, HTML selectors, short source-text excerpts, discovery provenance and eligibility evidence from pages already fetched. A browser worker derives internal link opportunities from those observations without requesting audited pages or sending content to an AI service. Search queries, pages you mark as important during a session, source excerpts and suggestions are not sent to analytics or application logs. The detailed graph and excerpts stay in report memory and, for a standard audit, its short-lived browser-managed tab-session recovery copy; they do not enter localStorage history or comparison snapshots. They are included when you deliberately export the full JSON report or print it; an opportunities CSV contains the filtered suggestions. Treat those files as copies of the inspected page content and share them deliberately.
No application database of reports
Reports are generated per request and returned to the browser. The application does not write reports or submitted target URLs to its own database. Audit targets and internal-link status crawl seeds are sent in bounded POST request bodies, not placed in the tool page URL. Link-status exports are created from the in-memory report in the browser and do not repeat the crawl. Hosting infrastructure still processes requests and may retain access or function logs under its own configuration and policies.
What the server logs
Application request logs include the route, a generated request id, audited hostname, score, timing and sanitized error details. Full client addresses are omitted; URLs in diagnostics are redacted to remove paths, queries and credentials. Rate limiting uses the trusted client address in memory or, when configured, a shared Redis store with expiring counters. Hosting providers may keep their own access logs under their policies.
Temporary performance reuse
A server instance can reuse successful Google performance measurements for up to five minutes and combine concurrent lookups for the same URL and device. The bounded memory cache uses a hash of the request identity and holds measurements, without storing the target URL or page HTML in its entries. Reused results are labeled with timestamps, and the explicit Refresh performance action requests a new lookup. Reloading a restored audit does not request one automatically. This cache is separate from browser history and expires automatically.
What gets fetched on your behalf
The URL you submit is fetched from the server, so the target site sees the server’s request rather than yours. The internal-link status crawler can request up to the selected 10–200 same-origin URL budget; its recursive mode reads served HTML and respects robots.txt, while external links are listed without being fetched. Only publicly reachable HTTP and HTTPS pages are permitted; private networks and loopback addresses are rejected before any connection is made. Redirects are followed from the server as well, and every redirect target passes the same checks before it is requested. JavaScript rendering is disabled by default. A deployment operator can enable it only after providing a separate runtime-isolation boundary for hostile page code; the serverless browser does not provide Chromium’s operating-system sandbox. When enabled and requested, the page’s own scripts, stylesheets and data requests are fetched from the server through the same address checks, while images, media and fonts are not loaded. Only a summary of the rendered page’s search signals is returned, and the rendered HTML is not stored.
Third parties
Vercel hosts the application, operates the edge that serves it, applies platform-level logging and processes the anonymous page-view data described above. By default, the submitted URL is sent to Google’s PageSpeed Insights API for performance evidence. A separately configured Chrome UX Report API lookup also requests URL-level data and may request origin-level data when the URL has no usable record. PageSpeed can use a key or an unauthenticated request; the direct Chrome UX Report lookup requires a key. Select “Skip external performance providers” before starting when you do not want the target sent to these Google services; performance evidence is then marked unavailable for that run.

Questions about any of this go to the contact page. The terms of use cover what you may analyze with it.