1. Save the exact URL and response
Record the requested URL, final URL after redirects, time, language and whether you were signed in. Define the content you expected: a service description, eligibility condition, heading or destination link. “The page is missing content” is difficult to investigate; “the public workshop description is absent from this response” gives someone a reproducible starting point.
Ask a developer to inspect the main document request in the browser’s Network panel after a fresh navigation. Preserve its status, response headers and response body. A screenshot records appearance; the document response records what arrived before subsequent page updates. These are separate pieces of evidence.
An HTTP success status alone does not establish successful content delivery or indexing. Google documents different treatment for success, redirect and error responses. If you encounter a login page, challenge, error or unexpected redirect, record that result before investigating rendering. Google’s HTTP status documentation.
Do not copy authentication cookies, tokens or private customer information into a shared ticket. A short public-content excerpt and redacted request details are usually enough to explain the discrepancy.
2. Compare initial HTML with the rendered page
Choose one distinctive sentence and look for it in the document response. Then inspect the rendered page’s DOM, the browser’s current representation of its elements. Record whether the sentence is present as page text, appears only inside embedded data, arrives after JavaScript runs, or remains absent. Text found in a script payload should not automatically be treated as visible page content.
Google describes separate crawling, rendering and indexing stages, and uses rendered HTML when processing JavaScript pages. Its documentation also notes that not all bots execute JavaScript. Avoid extending Google’s capabilities to every search provider or assistant. JavaScript SEO basics.
Repeat the comparison with the same URL and conditions. If the result changes between visits, write down the difference instead of choosing the more reassuring result. Browser state, timing or a failed dependency may need investigation. Your immediate deliverable is a clear observation, with uncertainty preserved.
Suprara examines one public URL’s initial HTTP/HTML, robots.txt and one declared or default sitemap. It does not render JavaScript or crawl the whole website. “Not detected in the initial HTML” therefore remains a bounded finding. Save the scan PDF and its coverage alongside the separate browser evidence.
3. Check content, links and directives separately
Inspect the page’s main answer before adjusting its metadata. Does a visitor get the information needed to understand the offer? Can they follow a relevant next step? If the essential information arrives only after an interaction, include that interaction in the reproduction steps and ask the developer to assess the dependency.
Inspect important navigation links too. Google recommends anchor elements with an href pointing to a resolvable address; a click handler by itself is not a dependable substitute. A control can work for a person while still requiring a separate link-discovery review. Google’s link guidance.
Record indexing instructions separately from missing text. Check the response headers and HTML for the applicable directives rather than assuming that a content problem is an exclusion. Use the noindex and indexing guide to investigate the intended state. Never remove protections from private material merely to make an audit look cleaner.
4. Obtain search-engine evidence for the search question
When you have authorized access to the relevant Search Console property, compare its indexed information with a live URL inspection. Google explains that these views answer different questions; a successful live test does not guarantee indexing. Save the inspection date and clearly label which view each observation came from. URL Inspection documentation.
Google’s JavaScript troubleshooting guidance points to inspection tools for rendered HTML, resources and JavaScript errors. Ask the developer to connect a specific missing passage with the relevant error or blocked resource, if the evidence supports that connection. JavaScript troubleshooting.
If property access is unavailable, mark the indexed state as unverified. A browser screenshot and a public scan cannot fill that gap. Continue the public-page investigation without claiming that you have reproduced Google’s stored version.
5. Work through a hypothetical discrepancy
Imagine a fictional training studio with a public workshop page. Its audit response contains the page title and an empty application container. In a signed-out browser, the workshop description appears after a request to a public content endpoint. These observations are invented solely for this practice exercise; they describe no customer or measured outcome.
The record should say: “Workshop description absent from captured initial HTML; present in the rendered page after the content request. Search indexing unverified.” It should not say that the studio is invisible in AI search.
The developer could investigate delivering the essential description in the initial HTML or improving the existing rendering path. The suitable repair depends on the application. Define acceptance before implementation: the correct public description is available through the agreed path, navigation works, and private registration details remain protected. Keep search and business outcomes pending until separately observed.
6. Close the task with evidence
Use the checklist below to preserve the investigation.
After an authorized repair, repeat the original checks and test a second page using the same template. Preserve any remaining uncertainty. A higher scan score can accompany better initial HTML, but it does not establish more citations, visits or enquiries.
Use the website audit guide to prioritize the work, and the AI visibility evidence guide to plan separate outcome observations. Finish with a conclusion that names the verified change and the next unanswered question.
Your practical checklist
- Exact requested and final URL, language and timestamp
- Expected public passage or link
- Initial-response observation and rendered-page observation
- Relevant status, directive or resource error
- Search inspection status, including unavailable access
- Proposed change, owner, approval and repeatable test
Apply what you learned
Practice this topic in Academy, then use the worksheet to document the evidence and the change you plan to make.
Sources and further reading
A clearer website starts with evidence.
Get a real public-page scan and a personalized PDF, then use the free worksheet to prioritize your next changes.