Does a free AI visibility report get re-opened, and by which door? 6 real checks, 12 report loads, all within 55 minutes of the check; 1 load through the report email, 1 through a return bar, and one checker came back from ChatGPT twice at 37 and 40 hours without opening it

The question and the instrument

Yesterday's read ended at the report: 6 lifetime checks, 6 reports opened, 4 opened more than once, 1 paid click. "Opened more than once" says nothing about when or how. A practitioner who sends a free report by email and offers a way back on the site wants to know whether anyone returns to the report after the session that produced it, and through which door: the email, a link on the site, a typed URL, a chat engine that remembered the page. This read answers that for every real check on our tape.

Counts are of real external persons, as our instrument defines them: our own identities, our own network egress, capture probes and two datacenter shapes are excluded, and every count below has a raw query beside it in the artifact. A "door" is the referrer and session of a report load: the report page rendered by the check itself, a load in the same session with no referrer, a load in a new session with no referrer, a mail app, or the return bar. The return bar is a "Your report" link on the home page for a browser that has already run a check, live since 2026-08-31.

Every report load on the 6 real checks, by door

12 loads, 0 after the first hour. The longest gap between a check and its last load is 55 minutes, on the one check that led to a checkout session (2026-07-13): that reader opened the report 4 times in two sessions inside an hour. The mail-app load is the 2026-09-14 phone checker opening the report email in the Gmail app 7 minutes after the check. The return-bar load is the 2026-08-28 checker, who went from the report to the home page and back through the bar 1 minute later; that click is the only real return-bar row the tape holds.

Per check

The email ledger began on 2026-07-18, so the first two checks have no email rows. For the four that do: 9 emails, 5 of them follow-ups at 48 and 120 hours (and one hand-written note at 141 hours), and 0 of the 5 follow-ups were followed by a report load. The two 2026-09-14 checks get their first follow-up today, after this read.

Returns to the site after the check

5 home-page loads by a checker after that checker's check, 2 persons. 3 were inside the check's own session (the 2026-08-28 checker's bar round-trip, and the 2026-09-14 checker 25 minutes after the check, still on the referrer that brought them). The other 2 are the same 2026-09-14 checker in two new sessions.

The two late returns are one person, 36.7 and 40.1 hours after their check, each a single home-page pageview with chatgpt.com as the referrer and nothing after it: no report load, no form touch, no click. The check itself had arrived from ChatGPT, through the guide on checking whether AI recommends a business, so the door back was the same conversation, or a new one that produced the same link.

What the site could not measure

• Whether the return bar was on the screen. The bar's "shown" event was queued before the analytics client had initialised and dropped, on every page load since 2026-08-31; the tape holds 0 real "shown" rows against 1 real click, which is the proof the bar rendered at least once. Fixed 2026-09-16 12:43Z (events fired before initialisation are now queued and flushed); 3 probe rows read back since. The two returns happened at 06:15Z and 09:39Z, before the fix.
• That the two returns were AI referrals. The detector's guard against double-counting was keyed on the browser tab, so a tab that had already produced one detector row on 2026-09-14 produced none on 2026-09-16 in two new sessions. Re-keyed on the session at 12:56Z today. Neither row is back-filled; the count stays 0 and the instrument labels the rows "same-tab return".
• Which emails were opened. Our sending provider's logs are closed to the keys we hold, so an email counts as a door only when a load carries a mail-app referrer. A report email opened in a desktop client that strips the referrer lands in the "no referrer" rows.

Reading

On this tape a free report is read in the session that produced it and not again. 4 of 6 "opened more than once" collapses to 6 extra loads inside 55 minutes. The follow-up emails, sent at two and five days, have 0 loads to show for 5 sends. The one person who came back days later came back through the chat engine that sent them, to the home page, and left without the report; the two things that would have told us what they saw on that page were both broken. The sample is 6 checks and one late returner; these are counts, not rates.

The next read, pre-registered

1. 1On 2026-09-30, the two 2026-09-14 checks will have had both follow-ups (48 h and 120 h). Statement: 0 or 1 of the 4 follow-up emails is followed by a report load. 2 or more and the follow-ups are a door after all.
2. 2On the same date, every home-page load by a known checker after 2026-09-16 12:43Z prints a "shown" and "clicked" cell from the fixed sensor. Statement: if any such return happens, the bar is shown on it; if the bar is shown and not clicked on every return, the bar is not the door.
3. 3On the same date, any new-session return from an AI engine by a known checker after 12:56Z carries a detector row. Statement: rows equal returns.

Either outside its statement is published as a falsification with the same script and a dated artifact.

Artifact

`content/news/report-reopen-cut-2026-09-16.json` holds every real check's loads with minutes and door, the lifecycle emails on each with loads after them, every later home-page return by a checker with its session, referrer and the sensor state at that instant, the return bar's rows lifetime with probe rows named, and 24 self-checks, each an instrument count against a raw query. The script is `content/news/report_reopen_cut.mjs`; this post is rendered from the artifact by `report_reopen_post.mjs`. No business names, addresses or locations are in either.