IndexNow on JavaScript sites: notify what users see

On a classic server-rendered site, "the page changed" and "the HTML changed" are close to the same thing. On a site that builds its content in the browser, they drift apart. A product price comes from an API call after the page loads; the HTML the server sends is the same empty shell every time. Meanwhile every deploy changes the script file names in that shell, so the HTML changes when nothing a reader sees has.

If your IndexNow notifications are driven by the HTML, a JavaScript-heavy site gets both failure modes at once: real changes are missed, and non-changes are announced. This post is about getting that decision right, and about the part IndexNow cannot help with.

First: IndexNow does not make a page renderable

An IndexNow notification asks participating engines to come and look. What they find depends on whether they can render the page.

Bing's crawler has rendered JavaScript with Microsoft Edge since 2019, when Bing committed "to regularly update our web page rendering engine to the most recent stable version of Microsoft Edge." Rendering is not the same as rendering everything reliably, though. The current Bing Webmaster Guidelines ask you to avoid "hiding critical content behind client-side rendering" and "excessive or unnecessary HTTP requests to render the content", and they are blunt about the consequence: "Content that cannot be reliably rendered may not be indexed or selected for grounding results."

So before tuning notifications, make sure the content you care about survives rendering:

• Titles, descriptions, canonical tags and the main text should be in the server response (server-side rendering or prerendering) wherever your framework allows it.
• Content that only appears after a click, a scroll or a consent banner is content a crawler may never see.
• Check what Bing actually sees with the URL Inspection tool in Bing Webmaster Tools.

A notification for a page that renders empty tells an engine, quickly, that there is nothing there.

Decide "changed" on the rendered page

For the notification itself, the question is the same as on any site: did something a reader would notice change? On a JavaScript site you can only answer that by looking at the page after it rendered, the way a browser shows it.

Concretely, that means loading the page in a real browser, waiting for it to settle, and comparing the rendered result with the previous one. The comparison should look at what matters:

• the title and meta description, which scripts sometimes set after load;
• the main content, including anything filled in from an API;
• structured data, which some frameworks inject at runtime;
• links and images in the main content.

And it should ignore what does not: script and stylesheet file names with build hashes, framework attributes and generated class names, hydration markers, analytics snippets.

Watch for changes that only exist in the browser

Some of the most important changes on JavaScript sites never show up in the server response at all:

• Client-side redirects. A route that now sends visitors elsewhere with location.replace() still answers 200 on the server.
• Client-side noindex. A script that adds <meta name="robots" content="noindex"> after load changes indexability without touching the HTML the server sent.
• Client-side canonical changes. The same goes for a canonical tag injected or rewritten at runtime.

All three change whether a page should be in an index. They are visible only after rendering, and they deserve a notification once they have held, just like their server-side equivalents.

Rendered output is noisier, so confirm before you submit

Rendering adds its own randomness. An API is slow once and the price block is missing. An A/B test serves a different headline. A personalization script greets someone by city. A carousel lands on a different slide. If one render differs from the last, that is a reason to look again, not yet a reason to notify.

A second render agreeing with the first removes most of this. For the rest, rotating blocks and personalized sections, exclude them from the comparison by CSS selector. The FAQ's warning about submitting "the same URL many times a day unless there are meaningful content changes" applies with extra force here, because a noisy rendered page can look changed on every check.

Rendering costs something; spend it where it matters

Rendering every page on every check is expensive, for you and for the site being rendered. Two habits help:

• Pages whose raw HTML already contains all of their content do not need the browser on every check. If the raw HTML yields the same content as last time, skip the render, and render again periodically to be safe.
• Pages that build their content in the browser need the render. That is the work worth paying for.

Checklist

1. Critical content, titles and canonicals are in the server response where possible.
2. Bing's URL Inspection shows the page with its content.
3. Change decisions are made on the rendered page, with build hashes and framework noise ignored.
4. Client-side redirects, noindex and canonical changes are treated as indexability changes.
5. A change is confirmed by a second render; rotating blocks are excluded by selector.
6. Notifications go out for confirmed changes only.

None of this decides how an engine treats your pages. It makes sure that when you say a JavaScript page changed, it did, and that when an engine comes to look, it can see why.

Sources

• Bing Webmaster Guidelines, checked October 19, 2026
• Bing Webmaster Blog: The new evergreen Bingbot simplifying SEO by leveraging Microsoft Edge (October 9, 2019), checked October 19, 2026
• IndexNow FAQ, checked October 19, 2026

A 200 or 202 from an IndexNow endpoint means the request was accepted, not that the URL is indexed. Google does not participate in IndexNow.

All posts