SEO JavaScript: check what Google can actually read

9 min read

SEO JavaScript consists of verifying that useful content and links on a page remain accessible to Google, not just visible in your browser. To check this, compare the HTML response from the server, the DOM after execution and the HTML rendered in URL inspection. This comparison allows you to locate an access defect, a click dependency or a rendering error before modifying the architecture.

Google knows how to execute JavaScript, but this does not guarantee the presence of each content in the rendering nor its indexing. Control characteristics, link destinations and indexing guidelines on a single URL.

Read three documents, without confusing their roles

The response HTML is the document sent by the server. You view it with “Show source code” or in the main query response. The DOM is the current structure of the page, observable in the Elements tab of the development tools. JavaScript can add, delete or replace content.

Google distinguishes between exploration, rendering and indexing. It can run JavaScript with Chromium when its resources allow; the result is therefore not necessarily immediate.^[28] A page containing only empty structure in its initial response is more dependent on this execution than a page whose text is already delivered.

Your browser does not constitute proof of rendering Google: it may benefit from a session, local storage or interaction. The decisive document for this control remains the HTML rendered in the Google tool. Content missing from the rendered HTML used for indexing cannot be indexed as page content.^[28] Its absence during a live test does not prove its absence from the indexed version, however, because the two states may differ.^[23]

Finally, distinguish between readability and indexing. Seeing text in this rendering confirms its presence at the time of testing, not its inclusion in the index.

Prepare a reproducible SEO JavaScript check

Before opening Search Console, define exactly what you want to read. “The sheet is displayed” is too vague: remember the name of the product, a distinctive characteristic and the link to another sheet.

Record in your statement:

• the full URL, the template concerned and the version deployed;
• the expected text, its location and its origin: HTML or API;
• the URLs of the scripts and the request which provides the characteristics;
• the necessary interactions, the existence of a session and the access rules;
• status HTTP, directives robots and the declared canonicality.

The order of control proposed here is: URL access, initial response, indexing directives, resources, content insertion, links, then inspection Google.

First open the URL directly in a new session, without clicking or scrolling. Then separately observe the interactions that change the content. Keep each state with its date and context; otherwise you will compare different situations without knowing it.

Compare a form: the completed diagnostic table

Let's take an entirely fictitious catalog, without reference to a customer of 4SYSTEM. The sheet /catalogue/lampe-atelier provides its title as HTML. The characteristics come from a API called when opening the “Characteristics” tab. Navigation maps use buttons with onclick.

The table is a completed template for this scenario. The inspection column sets the inspection to be carried out; it does not report any real tests. The DOM described corresponds to the state after opening the tab.

The title can be readable without the entire file being readable. Reuse the same elements in all three views. After correction, archive a new check from a new session, without deleting the initial observation.

Replace destinations hidden behind onclick

A card that opens a file with an event JavaScript is not automatically an exploitable link. Google indicates that it cannot reliably extract anchor URLs without href nor other elements simulating links by script events.^[17]

In the fictional catalog, replace the navigation with a real item: <a href="/catalogue/lampe-orientable">Lampe orientable</a>. The script can still improve the transition, but the destination exists independently of the click handler. A button retains its place for an action, such as opening a panel, rather than for pointing to another page.

Check three points: the presence of the anchor in the rendered HTML, a real destination and an understandable label. Then open the destination directly: the server must provide the expected form, not just an application envelope that works after internal navigation.

Links added by JavaScript are also usable if they respect this markup.^[17] Correct the navigation component, then check its variations in categories and recommendations.

Isolate dependency on API and triggering

Start with the query that provides the missing text. In the Network tab, note its trigger, its status and the content of the response. A correct JSON response is not enough: also identify the step that transforms this data into text in the DOM.

If the query expects a click, suggest loading the essential characteristics as soon as the form is opened. If it leaves automatically but fails, review API access, origin checks, required cookies, and script errors. Do not make a private API public to resolve a SEO problem: only provide data intended for the public record.

Google does not render JavaScript of blocked files or blocked pages.^[28] Check the exploration restrictions for useful resources. Live inspection also requires a page accessible on the Internet without a connection.^[23]

Do not set a supposedly universal rendering deadline. To isolate a dependency, test a variation that directly delivers the essential text, then compare the rendering. This method distinguishes a data acquisition problem from an insertion problem.

Query Search Console without overinterpreting the test

URL inspection first presents the known version information of Google, not a current state of your deployment.^[23] Note the crawl date displayed before interpreting a difference. Then run the live test on the exact same URL.

View details of the tested page, its rendered HTML, and reported resources. Find the distinctive text retained, then href expected. Visual capture helps to understand the state of the page, but it does not replace this research: a visible button may remain without a link.

Also check the original answer. If it contains noindex while the form must be indexable, don't count on JavaScript to remove this directive: Google may abort rendering when it encounters it.^[28] Correct the directive at its origin, without removing legitimate exclusions from other pages.

A valid direct test does not guarantee indexing. It also does not predict the canonicality that Google will retain.^[23] If the content is rendered correctly but the page remains missing, continue with the diagnosis of an unindexed page instead of treating JavaScript as the sole cause.

Choose the patch and define its validation

Decide according to the gap observed. Content absent from the initial response but present in the Google rendering: the dependency on JavaScript exists, with no demonstrated readability defect. Content present only after click: modify the trigger. Content lost after execution: Examine the component that replaces HTML. Links without a destination: fix the markup.

Server rendering or prerendering can provide the text upon response HTML and reduce dependency on rendering JavaScript; not all robots know how to perform the latter.^[28] This is an architectural option, not an obligation or a promise of indexing. In particular, evaluate the availability of data on the server side and the risk of discrepancy between versions.

To close the ticket, log the change, version tested, and control documents: initial response, no-interact DOM, direct test HTML, and verified link. The proposed criterion is concrete: the expected content and its destination are present without prior action, with coherent directives.

Finally check another sheet using the same component. Keep separate track of indexing status; the technical validation of the patch is not its proof.

Frequently asked questions

Is the content of a component with shadow DOM invisible?

Not necessarily. Google supports web components and brings together shadow DOM and light DOM content when rendering.^[28] For a form whose characteristics are encapsulated, find their text in the HTML inspection rendering. The mere presence of the component in the source code does not validate the presence of its data.

Why does a redirected URL appear to pass the test?

The live test tracks redirects, but its report does not indicate that a redirect was followed or the final URL tested.^[23] So check the redirection chain in network tools and inspect the expected destination separately. Otherwise, you could validate the content of a page different from the record you are trying to correct.

How to check if Google is using an old script?

Google specifies that its rendering service may use old JavaScript or CSS resources because of its cache.^[28] Compare the files referenced by the page with those in the deployment, then check their version in the available test items. A versioned file name strategy helps with diagnosis, without proving a refresh on its own.

Conclusion: open a verifiable ticket

Start with a representative profile and distinctive content. Complete the comparison, correct the first established discrepancy, then repeat the test without interaction. Provide the developer with observations and evidence, not just a screenshot. To frame the diagnosis and fixes, consult the web services and SEO of 4SYSTEM and present your URL with this statement.

Sources

• SEO Link Best Practices for Google | Google Search Central | Documentation | Google for Developers (accessed 2026-10-08)
• URL Inspection tool - Search Console Help (accessed 2026-10-08)
• Understand JavaScript SEO Basics | Google Search Central | Documentation | Google for Developers (accessed 2026-10-08)