The service page looks complete in your browser
Imagine a commercial maintenance company's service page. Its opening definition appears immediately, but the proof block and case-study link arrive after you open a panel. A marketing owner checks the page, sees everything and approves the release. Later, Google's tested HTML contains the definition but neither the proof nor the link.
This hypothetical composite illustrates an audit question. Can the content supporting your offer reach Google's rendered page without someone operating the interface? The example is invented. It makes no claim about a client incident or observed Search Console result.
A JavaScript SEO audit names the missing text or destination, preserves evidence and gives a developer a repeatable pass condition. The business can then prioritise the defect by its commercial importance. Any effect on rankings needs separate evidence.
What rendering establishes for Google Search
Google's JavaScript SEO basics describe crawling, rendering and indexing. Google retrieves the response, executes JavaScript during rendering and processes the resulting content for indexing. Copy missing from the initial response may still appear after rendering. Its absence from server HTML starts an investigation.
The connection to Google AI Overviews and AI Mode is eligibility. Google's requirements for AI feature supporting links require a page to be indexed and eligible for a Search snippet. Standard SEO requirements apply, and eligibility doesn't guarantee inclusion. Google's generative AI optimisation guidance also directs JavaScript sites towards established technical practices.
A passing rendering check establishes that the required content appeared in a recorded test. Indexing and AI citation outcomes remain separate. If rendering is healthy and supporting links remain absent, investigate citation selection before commissioning a technical rebuild.
Choose the pages and content the audit must protect
Start with templates that carry buying decisions. Include the affected service page, another page using the same template and an unaffected control where one is available. A redesign review should sample each commercially important template rather than treating the homepage as evidence for the entire site.
The marketing owner needs to specify what must survive rendering. If the offer or proof is unclear to begin with, first structure the service content and proof. Marketing owns the meaning. The technical test checks whether the agreed content appears.
Before testing, record the following for each sampled page.
- The full URL, template name and deployed release identifier.
- The exact service definition and proof text that must be present.
- The required destination URLs, including the case-study link's actual
href. - The tester, environment, timestamp and timezone for every capture.
- Inspection access, existing crawl or indexing exclusions and the intended canonical URL.
If a firewall challenge or blocked dependency prevents retrieval, resolve crawler and infrastructure access. If exclusion is deliberate, review the publisher inclusion decision with its owner before changing anything. Keep those decisions in the audit record so developers aren't asked to undo an intentional policy.
Compare what each page view can establish
Capture each view separately. The server response is the HTML returned before browser JavaScript changes it. The browser DOM is the document after scripts run. Google's inspection evidence adds another environment and may describe an earlier crawl. These observations answer different questions, so a comparison needs to retain their dates and limits.
| View | Evidence | Limit |
|---|---|---|
| Server response | Status, headers, HTML, directives, canonical | Precedes JavaScript changes |
| Browser DOM | Text and link destinations before interaction | Shows your session only |
| Indexed inspection | Crawl details, selected canonical, available HTML | May be older or incomplete |
| Live inspection | Tested HTML, screenshot, resource details | Indexing and canonical selection remain pending |
Retrieve the initial response with your browser's network tools or an HTTP client. Search the response and DOM for the agreed phrases and inspect the links as anchors with destination URLs. Confirm that each required link uses an anchor with an href, including where a button triggers navigation.
In Search Console, inspect the exact URL. Google's URL Inspection documentation distinguishes indexed information from a live test. Use View crawled page where available for indexed evidence and View tested page after a live test. Save the available HTML, screenshot and resource information. Record unavailable evidence explicitly rather than treating it as a failed test.
Keep the indexed crawl time beside its evidence and the live test time beside the current result. Comparing an old crawl with today's browser can reveal a release difference. It doesn't, by itself, establish a rendering defect in today's code.
Trace the missing content to a reproducible cause
Return to the composite maintenance page. The agreed proof text is “Our maintenance team supplies a written completion record after each scheduled visit.” The required anchor points to /case-studies/maintenance-handover. These are invented example requirements, not claims about an actual business.
In the hypothetical audit, the initial response contains the service definition. A fresh browser session also lacks the proof until the panel opens. The developer observes that opening the panel initiates the request supplying both the proof and its case-study anchor. Google's live tested HTML lacks both items. Record those observations as separate captures with their actual test times when applying this method to a real page.
That combination supports an interaction-dependent loading hypothesis. Google's lazy-loading guidance says content loading shouldn't depend on actions such as scrolling or clicking because Google Search doesn't interact with the page. Check whether the text is already in the document behind a disclosure. A collapsed panel containing existing HTML is a different implementation from a panel that fetches its content only when opened.
For the composite, reproduce the request trigger and change it in a test environment. If the proof and anchor then appear without opening the panel, the developer has stronger evidence that the loading condition caused the gap. Save that reproduction with the original captures.
Other pages need different hypotheses. A failed content request, blocked script or JavaScript exception might interrupt the required block. Google's Search-related JavaScript troubleshooting guidance supports examining rendered HTML, loading problems and JavaScript errors. Connect each error to the missing content before assigning it priority. Prioritise errors with a reproducible connection to the missing content.
Also compare directives and canonical declarations before and after rendering. Google's JavaScript guidance advises keeping canonical values consistent. Record a conflict as a separate finding requiring investigation. Investigate indexing exclusions on their own evidence.
Give each repair an owner and a pass condition
For the composite, marketing owns the required proof wording and commercial priority. The developer owns the loading behaviour and anchor implementation. The SEO owner interprets the inspection evidence and follows up on Google's indexed state. One named person should keep the finding open until its remaining checks are resolved.
The repair record should identify the URL, template, release and exact required copy or destination. Link the captures with their environment, timestamp and timezone, then state the suspected cause and reproduction. Mark unresolved hypotheses explicitly. Name the implementation owner, content approver and indexed follow-up owner. Give the live pass condition and indexed review date separate fields.
The composite's live pass condition is precise. The agreed proof sentence and an anchor with href="/case-studies/maintenance-handover" must appear in Google's live rendered HTML without opening the panel. The content owner also checks that the proof remains readable and the link works for visitors.
Choose the smallest repair supported by the reproduction. Loading the block during initial rendering may resolve this example. Consider server rendering or prerendering where the diagnosed delivery constraint warrants it.
If missing commercial content spans important templates and the cause remains uncertain, use the collected evidence to scope a technical SEO diagnosis. Once a shared implementation defect is confirmed, the same record can define the work to repair the affected website templates.
Verify the release and return to the indexed evidence
Validate the release now, then return to indexed evidence after Google reprocesses the page.
- Repeat the response, DOM and live-inspection checks on the affected URL, another URL sharing its template and the control. Record the deployed release and fresh timestamps.
- Save before-and-after evidence for the exact text and anchor. Check status, directives and declared canonical for unintended changes.
- Mark live validation passed only when its content-level conditions are met. Request indexing where appropriate through Search Console.
- Revisit indexed information after Google reprocesses the page. Compare the recorded crawl time, available content evidence and Google-selected canonical with the intended result.
If the indexed evidence still describes the old release, leave indexed verification pending. If relevant HTML is unavailable, record that limitation and what the available indexing information establishes.
Hand over the finding with its evidence links, accepted live result, unresolved indexed checks and named follow-up owner. Before closing the release review, put an actual next review date in the record. At that review, either attach newer indexed evidence or retain the pending state with another dated check.