If you suspect Google is missing content on a JavaScript page, look for the same paragraph or link in the initial response, a signed-out browser and Google's live render. The difference between those views tells you where to investigate.
Say your product page works perfectly while you're signed in, but a teammate opening the same link sees an empty comparison table. First make sure a new visitor can get the information. Then check whether Google can render it.
What should you compare?
- Initial HTML. Use View Source or the document response in your browser's Network panel. Search for a distinct phrase from the missing section. Its absence can be normal if JavaScript supplies the section later.
- Signed-out browser. Open the exact URL in a clean session. See whether the section appears without an account, stored settings or a click. Inspect the element and watch for failed data requests.
- Google's live test. Use URL Inspection and view the tested page. Search the tested HTML for the phrase and use the screenshot or resource information where available. Separately check the indexed report if your question is about what Google last recorded.
Google's JavaScript documentation describes crawling, rendering and indexing as separate steps. A successful live render helps narrow the diagnosis. It doesn't establish that the page is indexed.
What does a missing section tell you?
Consider a fictional integration directory. Its title loads immediately, but the descriptions appear only after a visitor opens a filter panel. The team wants someone to understand each integration from its own URL. A useful fix is to put the summary and ordinary links on stable pages that work on direct load.
If the section never appears in a signed-out browser, check for a session dependency or a failed request first. If the browser shows it but Google's live test doesn't, investigate blocked resources, render errors and interaction requirements. Avoid replatforming the whole site before you can reproduce the failure on one page.
How do you hand this to engineering?
Include the exact URL, the missing phrase, the conditions you tested and what each view showed. Give the fix a clear acceptance check, such as seeing the integration summary and a working documentation link on a signed-out direct visit and in the live tested HTML.
If blocked resources are involved, check which crawler and purpose the rules apply to before changing them. The crawler controls guide explains how to separate search access from training preferences.
How can a developer test the fix without waiting for a crawl?
Save the current response and reproduce the missing section before touching the page. Use an example that matters to someone making a decision. On a fictional integration page, that could be the sentence explaining which direction a sync runs and the link to the setup instructions.
- Load the exact page directly instead of clicking there from the homepage. That catches assumptions about state left over from a previous screen.
- Try the viewport or locale where the problem was reported, and record the conditions. A different layout may move the section without removing it.
- Look for the actual link destination in the rendered HTML. A label that looks clickable still needs a working path to the relevant resource.
- Repeat the same checks after deployment and on one similar page to see whether the fix affected the shared template.
There can be more than one reasonable implementation. A static summary can be enough when a live widget adds optional details. A server-rendered version may be worth the engineering work when the missing copy is central to the page. Keep both versions in sync if you use both. The acceptance test should describe the information a visitor can access, so the implementation can change later without changing the goal.
