By Greg Nowak. Updated 24 September 2026.
Publishing a page is only the beginning of its operational life. Prices change, offices move, advice is corrected, products are withdrawn and campaign pages expire. If your IndexNow integration listens only for the first publish event, search systems may continue working from an outdated URL long after your CMS contains the right information.
IndexNow lets a website notify participating search engines when a URL is added, updated or deleted. It can accelerate discovery of the change, but it does not guarantee crawling, indexing, rankings or inclusion in an AI-generated answer. The useful business outcome is therefore not “IndexNow installed.” It is a dependable connection between every meaningful public change and a verifiable notification.
Freshness is now a wider business concern
Stale pages can misstate availability, pricing, compliance guidance or contact details. That was already a search and customer-service problem. It also matters when search engines use pages to support AI-generated answers.
Bing Webmaster Tools now reports page-level citation activity across supported AI experiences. That visibility can show which URLs are being referenced, but reporting cannot correct the underlying content. The source page, its HTTP response, canonical URL and discovery signals still need to agree.
For an expired offer, for example, publishing a replacement page is not enough. The old URL must also produce the intended outcome: a permanent redirect when a genuine successor exists, or a proper not-found response when it does not. The sitemap and IndexNow workflow should reflect that decision.
Trigger notifications from public outcomes
A generic CMS “save” event is a poor trigger. Editors save drafts, adjust internal metadata and preview unfinished work. Instead, determine what changed for the public URL after the CMS has completed the action.
| Editorial action | Required public outcome | IndexNow action | Acceptance check |
|---|---|---|---|
| First publication | New canonical URL is indexable | Submit the new URL | Check response, canonical and sitemap entry |
| Material correction | Same URL serves revised content | Submit the changed URL | Check rendered content and modification date |
| Slug or path change | Old URL redirects permanently to the new URL | Submit both affected URLs | Check redirect chain, destination and canonical |
| Unpublish or delete | URL returns the intended not-found response | Submit the removed URL | Confirm removal from the sitemap |
| Apply noindex | Page remains available but is excluded from indexing | Do not treat it as an indexable publication | Inspect rendered meta directives and HTTP headers |
This distinction also keeps previews, staging domains and internal hostnames out of the queue. Production should be the only environment submitting public URLs.
Build the integration as a small operational workflow
For a custom CMS, place eligible URLs in a queue after the public state has been committed. A worker can submit single URLs or batches to the global IndexNow endpoint. Batch requests may contain up to 10,000 URLs, although smaller batches are usually easier to retry and investigate.
Host the verification key file where the protocol expects it, and log the triggering event, submitted URL, time, response code and retry count. An HTTP 200 response means the service received the request; it does not mean the URL has been indexed.
Use bounded retries with backoff for temporary failures. Do not retry malformed URLs indefinitely. Repeated authentication, validation or rate-limit responses should create an actionable alert rather than an endlessly growing queue.
For every submission, validate these basics:
- The URL uses the real public scheme, hostname and path.
- The page, redirect or removal response is already live when submitted.
- The API key can be verified from the public host.
- Canonical tags, robots directives and HTTP headers match the intended state.
- The sitemap contains current canonical pages and excludes deleted or redirected URLs.
Keep IndexNow and XML sitemaps in separate roles
IndexNow is an event signal: this URL changed now. The XML sitemap is an inventory: these are the canonical URLs the site currently wants discovered. Neither replaces the other.
Reconcile them periodically. A new canonical page should normally enter the sitemap and the notification queue. A deleted or redirected URL should leave the sitemap, while its old address is submitted so participating engines can discover the changed response. A meaningful content update should refresh an accurate lastmod value—not merely the time when a sitemap generator last ran.
This comparison catches errors that plugin dashboards alone may miss: an internal hostname, an untranslated path, a deleted URL still listed in the sitemap or a content type that never triggers submission.
WordPress and Drupal still require acceptance testing
The official WordPress IndexNow plugin detects creation, updates and deletion, submits in the background and checks rendered noindex directives, X-Robots-Tag headers and the site-wide search visibility setting. It also offers exclusions, manual submission, recent results and retries.
Those features cover the standard route, not every bespoke publishing setup. Test custom post types, scheduled publishing, multilingual pages, bulk imports, slug changes and deletion through any external system that can modify WordPress.
Drupal’s Index Now module supports content events through entity-specific submodules and provides a service for additional URLs. It can replace the scheme and host for a headless frontend; if public and internal paths differ, the implementation needs a URL-alteration hook rather than a host override alone. Review the stable and development branches against your Drupal version before deployment.
Test the awkward cases before calling it finished
Run an acceptance script that publishes a page, corrects it, changes its slug, applies noindex, unpublishes it and deletes it. Repeat the sequence for translations, commerce entities and headless routes where relevant. At every step, inspect the live response, canonical, sitemap state, queued URL and submission result.
The final operational view can be modest: recent successes, outstanding retries, permanent failures and sitemap discrepancies. What matters is that an operations lead can see whether the workflow is healthy without reading application logs or waiting for somebody to notice a stale search result.
If your CMS integration currently stops at “page published,” Greg can help map the complete content lifecycle, test the edge cases and turn the agreed rules into maintainable hooks and monitoring. Talk to Greg about auditing your publishing workflow.
Related on GrN.dk
- Google’s 2026 AI Search Guidance: SEO Still Matters, but Reporting Has Changed
- AI Crawler Control for Business Websites: Protect Content Without Losing Search Visibility
- AI disclosure rules belong in your CMS, not a spreadsheet
Need help with this kind of work?
Audit your CMS publishing workflow Get in touch with Greg.
