Define the public information that must be checked
Select one representative public page and list what makes it useful: its subject heading, service explanation, key conditions and next step. Use that list as the comparison target. Counting HTML bytes is not enough; a large response can contain scripts and decorative markup while omitting the information the visitor came to read.
Keep private dashboards and personalized account data outside this public-content test. The aim is to understand how a public page is delivered, not to move sensitive information into its response. Record the exact URL, language, login state and test time so another person can reproduce the observation.
Capture the response and the rendered document
Use the browser network panel to inspect the main document response, or save it with an HTTP client. Separately inspect the document after the page has loaded normally. The Elements panel shows the current document and can include changes made by scripts; it should not be mistaken for an untouched copy of the server response.
Compare the expected information section by section. Mark each item as present in the response, added during rendering or missing in both. Text buried inside a script data object is not the same evidence as readable content in the document body. Save short excerpts and screenshots where useful, keeping request credentials out of shared evidence.
Identify the dependency behind each gap
For content that appears only later, inspect the request or script that supplies it. Record failed responses, unexpected login requirements or console errors. Repeat from a fresh session to avoid mistaking locally cached data for content that every new visitor receives. Keep failures tied to the particular section they affect.
Google documents separate crawling, rendering and indexing stages and can process JavaScript-generated content. Therefore, missing text in the initial response alone is not proof that the page cannot be indexed. The finding establishes a rendering dependency; its reliability and Google's observed rendered output need their own evidence.
Worked example: a service page with an empty shell
Consider an illustrative service page whose initial response includes the header and a loading placeholder. After a public API request, the page displays the service scope, eligibility conditions and contact link. Your comparison has three rows for these meaningful items, each marked as added during rendering. It does not declare the whole website unindexable.
Suppose a fresh-session test reveals that the API unexpectedly requires a session cookie. The actionable task is to correct delivery of the intended public content. The team might render those public sections on the server or at build time while retaining interactive controls in the browser. This is a scoped implementation option, not a claim that every application needs the same architecture.
Validate the improvement without overstating it
After an implementation change, repeat the original comparison on the same URL and a second page using the same template. Check that the meaningful sections remain correct after scripts initialize and that the title and canonical address stay consistent. A successful initial response is not useful if the browser immediately replaces it with an error or a different page.
Save the before-and-after evidence and add unresolved dependencies to your website-audit action list. Where access allows, compare Google's rendered HTML separately and record its observation time. Report what was verified: public content delivery, browser rendering or an indexing observation. Do not convert a local rendering pass into a promise of ranking or immediate indexing.