How Instant Read works

When you enter a URL, the server fetches that page like a crawler would, reads every signal it can observe from the response, scores four separate readings, and blends them by weight into one temperature. It takes a few seconds because it is a real fetch, not a lookup.

What actually happens when you press the button

Your URL is validated. Scheme, port, and hostname are checked, and every address the hostname resolves to is tested against private and reserved ranges. A URL that resolves anywhere non-public is refused before a connection is opened.
The page is fetched. Up to four redirects, followed one at a time so each hop gets the same validation as the first, with a nine second timeout and a 1.5 MB ceiling.
Three companion files are fetched. robots.txt, llms.txt or llm.txt, and sitemap.xml from the same origin. Several signals depend on them and none of them can be inferred from the page.
The document is read. Markup becomes text, JSON-LD is extracted and flattened so a nested graph is treated the same as a top-level node, and the visible words are counted.
Every signal is evaluated. Each returns pass or fail plus the evidence for that verdict.
Four readings are scored. Each one as a percentage of its own available weight.
One temperature is blended. Search Visibility and AI Discoverability are worth 30 percent each, Technical Accessibility and Content and Entity Strength 20 percent each.

Why four readings and not one number

Because a single pool of weights would have let one reading quietly outvote another. The readings do not hold the same number of signals, and the ones inside them are not the same size. Thrown into one pot, the reading with more entries wins arguments it should not win, and then the four sub-readings stop describing anything real. The signal registry shows the current counts and weights, generated from the engine itself.

Scoring each reading on its own scale first, then blending by an explicit weight, means a site can genuinely read hot for search and cold for AI. That combination is common and it is the most useful thing the tool finds. A site built carefully in 2019 frequently reads in the eighties for search and in the forties for AI retrieval, because nothing it does wrong was wrong when it was built.

What the free reading shows you, and what it does not

The free reading gives you the temperature, all four sub-readings, and the three heaviest signals you are passing alongside the three heaviest you are failing, each with the evidence behind it. That is deliberately enough to act on. The heaviest failing signal is usually the single most useful sentence anyone can hand you.

What it does not give you is the remedy for each failure, the full list of what else is failing, or anything about the pages you did not enter. That is the Visibility Diagnostic, and the line between them is enforced in the code rather than in a paywall: the remedies never leave the server, which is also why a shared reading link can never leak them.

The limits, stated plainly

One page, not the site. The homepage is not representative of the site and never has been.
Raw response, not the rendered page. If the content arrives by JavaScript, the thermometer will not see it. Neither will several of the systems it is modelling, which is the point of that signal rather than a shortcoming of the tool.
No ranking data. Nothing here knows your positions, your traffic or your links.
A snapshot. Response time moves, servers have bad afternoons, and a site can change between two readings taken an hour apart.

Reproducibility

The same page in the same state returns the same temperature, which is what makes comparison over time meaningful. Every published reading carries the date it was taken so you can retake it yourself and see whether anything moved. If your number disagrees with a published one, the published one is probably old, and a date is more useful than an argument.