How do I check whether JavaScript content is indexed?

`curl -s https://example.com/page` returns exactly the bytes the server produced, with no script execution.

If the content you care about is not in that output, it does not exist for anything that does not render — social platform crawlers, many smaller search engines, feed readers, monitoring checks.

Check specifically for the title, the meta description, the canonical tag, the Open Graph tags and the links. These matter more than body text, because consumers that do not render still rely on them.

Piping through `grep -o '<title>[^<]*</title>'` and `grep -c '<a '` answers the two questions fastest.

Open the page and use the element inspector, which shows the live DOM rather than the source. The difference between this and view one is exactly what depends on JavaScript.

Disable JavaScript in the browser and reload. What survives is roughly what a non-rendering consumer receives, and it is usually a more honest picture than the source view.

Pay attention to navigation. A menu built from click handlers rather than anchor elements with `href` attributes contributes no links at all to a crawler that does not render, and weak ones to one that does.

Check whether the page sets its own title or canonical from a script. Both are honoured when rendered and absent otherwise.

URL Inspection in Search Console has a live test that returns the rendered HTML, a screenshot, and the console messages from the render.

This is the authoritative view for Google specifically, and it is the only one that can tell you a resource was blocked or a script failed on their side.

The console output is the part people skip and is frequently where the answer is: a script blocked by robots.txt, an API call that failed, a timeout.

The screenshot shows what the renderer saw, which makes a blank area obvious in a way a DOM dump does not.

Content in all three views: nothing to investigate.

In views two and three but not one: it works for Google and does not exist for consumers that do not render. Whether that matters depends on whether you care about link previews, feeds and non-Google crawlers.

In view two but not three: Google's renderer did not produce it. Read the console messages before anything else.

In none of them: it is not a rendering question at all, and the content is genuinely absent.

Google documents that rendering happens in a second pass with a delay that varies, so a very recently published page may legitimately show view-three content that lags.

Resources blocked by robots.txt. A script or an API endpoint the page needs, disallowed in robots.txt, cannot be fetched by the renderer and the content never appears.

Content that requires an interaction — a click, a scroll, a tab change. The renderer does not interact, so anything behind an interaction is not rendered.

Soft 404s: a client-side router rendering a not-found view under a 200 status. The status is decided on the server and the router cannot change it.

Long or failing requests, where the renderer moves on before the content arrives.

Metadata set by scripts, which social platform crawlers never see because they do not execute JavaScript at all.

VeriFixScan reads the HTML the server sends, which is view one, and reports what is present in it.

That is the correct measure for every consumer that does not render, and an incomplete one for those that do — the two have to be read together rather than one being treated as the truth.

`structure.html_quality` and `performance.javascript` report the shape of the document and the weight of the scripts behind it.

When the scan reports a missing title or canonical on a page that plainly has one in the browser, the gap between view one and view two is the finding, not an error in the scan.