Did the scan read the page you meant to audit?

Blockquote audits the HTML it receives. Before repairing a missing author, heading or answer, check that the response contains the page you intended to audit. A login screen or empty application shell can change the findings without changing your article.

Check the response before the recommendation

Start with the requested URL, final URL and relevant finding evidence in the original report. Compare them with the delivered page. Keep the scan time and coverage fields beside that record. The audit scope document explains why incomplete coverage can change a score.

Inspect the initial HTML response, as well as the page after browser scripts run. Use your browser's Network panel to inspect the document response. Do not infer the received content from a successful status code alone.

Follow this decision sequence:

1. If the request fails, diagnose access, routing or the reported network error first.
2. If the final destination is unexpected, inspect the redirect before changing the article.
3. If the destination is correct, look for the intended heading and a distinctive answer sentence in the received HTML.
4. If those passages are present, use the finding's evidence to choose the applicable content repair.

A consent banner alone does not establish that the article is blocked. Check whether the response also contains the article. A response consisting only of a consent wall requires a different diagnosis.

A real response specimen, with a limited conclusion

On 12 October 2026, a manual HTTP request inspected the public content guide. The request used Blockquote's user-agent string and requested HTML. It returned these fields:

• Final URL: https://blockquote.io/llm-friendly.
• Status: 200; content type: text/html.
• H1: “Write content that can be cited”.
• Canonical URL: https://blockquote.io/llm-friendly.
• Opening sentence: “State the answer, identify its source, and include the limits that make the claim accurate.”

This response contains the intended heading and opening. It is a manual response specimen, not a completed Blockquote scan. A matching user-agent string does not reproduce every condition of a production scan, including request signatures and network origin.

Now consider an illustrative variant, not an observed failure: an article URL redirects to /login, and the response contains “Sign in” instead of the answer. Adding Article markup to the article would not repair that response. First resolve the unintended redirect or provide the intended public route.

Distinguish an HTML shell from a browser-rendered page

If the browser displays the answer but the document response lacks it, check whether scripts insert the content after loading. Blockquote's client-side rendering check examines the raw HTML fetched for that scan.

Keep the claim specific to that response. Google's JavaScript documentation describes a separate rendering stage that executes JavaScript. A missing passage in Blockquote's fetched HTML does not establish that Google cannot render it. Other crawlers have different capabilities.

For a public article, server rendering or prerendering can put the answer into the initial response. Verify the delivered HTML after that change. Keep private account pages and authentication protected; do not expose private content to obtain an audit result.

Repair the barrier and verify the new response

Record the failure precisely. An HTTP 403 response, an unexpected login destination and a successful response without article text are different observations. None establishes that the intended article lacks an author or useful answer.

Check your own server or firewall logs when available. Identify the rule or route before changing it. Keep consent and security controls in place while fixing unintended access to a public page.

After your normal release, repeat the response inspection for the same URL. Record the final destination, heading and answer sentence. Then obtain a fresh scan. The developer documentation describes cached reports and the authenticated refresh option; a cached report cannot verify a newly delivered repair.

Compare the original coverage and affected finding with the new report. Use the content guide for the broader repair comparison. Report only what the new evidence establishes.

Google's HTTP guidance says a successful response does not guarantee indexing. Correctly delivered content and an improved audit finding also do not establish an observed AI citation. Verify those outcomes separately.