Docs
How change detection works
IndexNow is for new and changed pages, and engines rate-limit sites that resubmit unchanged ones. So every check runs the same deterministic pipeline, and a page is only submitted when the evidence says something a reader would notice has changed.
What counts as a change
- Title and meta description. Bing names these as updates worth notifying.
- Main content: the page's
<main>, a single<article>, or the body without navigation, header and footer; headings, paragraphs, list items, table rows, link targets and image sources. - Structured data (JSON-LD), such as a product's price or availability, minus engagement counters.
- Indexability: a page that is removed (404 or 410), redirects, gets
noindexor declares another canonical URL. These are reported once they have lasted 12 hours on consecutive checks, so a deploy or short outage never triggers a submission.
What never counts
- Dates and times, relative times ("3 minutes ago"), view and like counters, greetings and session or personalization fragments.
- Nonces, cache-busting query strings and tokens in links.
- Markup changes: reordered attributes, wrapper elements, class names and inline styles.
- Anything you exclude: up to 20 CSS selectors and 20 text patterns per site, for a rotating banner or a testimonial carousel.
How a check decides
| Compared with the last check | Result |
|---|---|
| Same fingerprint | Nothing to do. Most checks end here. |
| Different fingerprint | The page is rendered a second time. Only if the second render agrees is the change submitted, so render timing and flaky scripts never count. |
| First check of a site | A silent baseline: existing pages are recorded, not submitted. |
| A page that appears later | Submitted as new. |
| Our detection improved | Every page is recorded again under the new version without submitting it, so an upgrade on our side never floods IndexNow. The current version is v5. |
| The fetch or render failed | The stored state is kept and the page is checked again next time. A failed submission keeps its evidence and is retried with backoff. |
Every check fetches the raw HTML; the browser render runs when it is needed. A page whose last render matched its raw HTML is server-rendered: while the raw HTML yields exactly the same content, it skips the render, and it is still fully rendered at least once a day, at a time of day fixed per URL so a large site's daily renders spread over the day. A page whose content is built with JavaScript is rendered on every check. A render also follows when the raw HTML changed or could not be compared, when our detection or your ignore rules changed, and while a possible removal waits for confirmation. Renders draw on your account's daily render budget; when it is used up, the render waits for a later check and nothing changes in the meantime. Each check, how it was decided and whether the page needs JavaScript is visible per URL in the dashboard.
Example
A pricing page is checked twice. Between the checks, a "Last updated 2 minutes ago" line changed, the visitor counter went up, and the price of the page's Team plan went from $40 to $45.
- The relative time and the counter are removed during normalization, so they alone would leave the fingerprint unchanged.
- The price is in the main content and in the JSON-LD offer, so the fingerprint differs. A second render agrees, and the page is submitted with the reason Content changed.
Limits, honestly
- A fingerprint shows that the content changed, not which words. We do not keep your pages, so we cannot show a diff.
- Content that only appears after a click, behind a login or in a cross-origin frame is not seen.
- Text outside the main content area (for example a sidebar) does not count when the page has a clear
<main>or article. - Changes are noticed at your check interval, not instantly: as often as every 12 hours on Pro (6 hours on Agency, coming soon) and every 24 hours on Solo. A deploy hook starts a check right after a release.
- Removals wait 12 hours on purpose.
- Each plan renders a bounded number of pages per day; pages over the budget are checked on a later run.
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.