On this page
A page can have a thin initial HTTP response, display complete content in a browser and have an older saved health result in a workspace. Those observations can all be valid because they answer different questions at different times.
Before deciding which result to trust, identify what each method actually inspected. A browser-style user-agent string does not make an HTTP request execute JavaScript. Opening a saved workspace result does not rerun its original check.
Define the question before choosing a tool
Use an HTTP check to inspect the response returned for a particular request profile. Use a browser to inspect the page after the browser has loaded and processed it. Use saved workspace evidence to understand recorded checks, activity or answer observations in their original scope.
| Method | Useful question | Limit to preserve |
|---|---|---|
| HTTP response | What did this request receive? | Does not by itself show a JavaScript-executed page |
| Browser observation | What content or interaction is available in this browser state? | Does not establish every crawler's behavior |
| Saved workspace evidence | What was recorded for this site and time? | May be older, summarized or incomplete |
Choose a specific requirement, such as whether the article body is present. “Is the site good for AI?” is too broad for any one of these checks.
A dated comparison on a public PB page
Historical example: these observations predate the September 7 marketing-site release. They describe the earlier site, not its current server-rendered article delivery.
On September 5, 2026, we inspected the public mentions, citations and recommendations article using separate HTTP and browser observations.
The standard HTTP request returned status 200. After excluding scripts, styles and navigation-related elements, our simple text extraction contained the site title and no article body. A later HTTP request using a Googlebot user-agent profile also returned 200, but its extracted text contained the article content.
In Chrome, the first observation showed a loading state. A subsequent observation at 12:13:36 UTC showed the article heading and opening paragraphs. The standard HTTP request started at 12:13:31 UTC; the Googlebot-profile request started at 12:13:43 UTC. These were separate requests, not a simultaneous experiment.
The supported conclusion is narrow: the article appeared in the loaded browser and the tested crawler-profile response, while it was absent from our standard-response text extraction. We did not verify Google's indexing, inspect an actual Googlebot request or run an authenticated PB workspace check for this example.
Record enough method to explain a disagreement
For each observation, keep the URL, request profile or browser state, capture time, result and the specific content tested. If using text extraction, record its exclusions. An extractor's word count is not an exact measure of everything a response contains.
A changed user agent can produce different delivery, but the label alone does not establish who made the request. Our Googlebot-profile fetch was a diagnostic request made by our tool, not proof of a visit from Google's infrastructure.
Similarly, a browser observation after loading does not establish that every interaction works. Testing whether text appears is different from submitting a form, following a checkout or checking a mobile workflow.
Add saved evidence without changing its date
A workspace record can add useful history: an earlier page check, an incident, crawler activity or a summary of AI answers. Retain the recorded event date separately from the time the assistant retrieved it.
If a saved check predates a deployment, it may describe the old release accurately. If the summary omits a response body, do not fill the gap by assuming it matches today's browser page. Open the underlying evidence when available or identify the missing detail.
Prerender Buddy's reviewed public MCP tools perform HTTP diagnostics. Its workspace tools provide bounded saved summaries where access is available; they do not supply a browser renderer or full provider-answer bodies. Use the developer tools overview to choose the appropriate evidence path.
Turn a disagreement into one next check
If HTTP extraction lacks the article but the browser shows it, inspect the relevant crawler-facing response before declaring a rendering defect. If both methods show outdated text, compare them with the approved release. If only a saved record looks wrong, check its date and original scope first.
Keep unknowns explicit. A request failure is not evidence of an empty page. A rendering comparison marked unavailable is not a passed rendering check. A result from one route cannot certify every page using the same website.
Start with the smallest next observation that distinguishes the plausible explanations. Broaden the audit only when the evidence points to a shared failure.
Write a conclusion tied to the method
A useful audit note says which content was observed, through which method and at what time. It then states the remaining question. Avoid converting “text present in this browser” into “all bots can read it,” or “saved check clear” into “the current release is verified.”
The methods complement each other when their boundaries remain visible. HTTP evidence describes a response, browser evidence describes a loaded state, and saved evidence adds history. Together they can support a precise repair or a decision that no repair is yet justified.