Bing Webmaster Tools and IndexNow solve different parts of a search launch. Bing Webmaster Tools establishes a verified property and provides sitemap, crawl, indexing, and URL-level diagnostic information. IndexNow sends participating search engines a prompt that a URL was added, updated, redirected, or removed.

Neither tool guarantees that a page will be crawled, indexed, ranked, or shown for a particular query. IndexNow's documentation is especially clear: an HTTP 200 response only means the search engine received the URL. A useful launch therefore needs three separate records:

  1. the website was ready for crawlers;
  2. the sitemap or IndexNow endpoint accepted the notification; and
  3. later evidence showed what the search engine did with the URL.

This guide owns that operational handoff. The SEO redesign and migration checklist owns coordinated site moves, the canonical URL guide owns the treatment of individual URL variants, and the post-launch measurement guide owns business reporting after release.

Define the launch outcome before opening either tool

"Submitted to Bing" is too vague to be an acceptance criterion. It can mean a sitemap address was entered, one URL was sent, an API returned a success code, or a page appeared in an index report. Those are different events.

For a new or substantially changed website, define the outcomes you need:

  • the business controls a verified Bing Webmaster Tools property for the correct public host;
  • approved users have the minimum access they need;
  • the canonical XML sitemap is publicly reachable and submitted;
  • important URLs return the intended production status, index directive, and canonical;
  • IndexNow key verification works for the URLs being submitted;
  • each release notification has a timestamped result;
  • rejected or rate-limited requests have an owner and retry state;
  • important URLs are inspected after search systems have had time to process them; and
  • reports distinguish receipt, discovery, crawl, indexing, impressions, and leads.

This definition prevents a green API response from becoming an unsupported marketing claim.

Prepare the website before notifying search engines

Do not use submission tools to compensate for a broken release. Test the public website first, from outside the development environment.

For every URL in the release set, verify:

  • the exact HTTPS hostname and path are final;
  • the response status matches the intended state;
  • redirects are direct and land on the approved destination;
  • successful pages declare the correct absolute canonical;
  • indexable pages do not carry noindex;
  • pages are not unintentionally blocked from crawling;
  • the primary content is present in the delivered page;
  • internal links use final canonical URLs;
  • structured data describes the visible page accurately;
  • the sitemap includes successful canonical URLs and excludes variants, errors, private pages, and redirects; and
  • the production server can handle ordinary crawler requests without failing.

A server returning the homepage with 200 OK for every unknown route is not ready. A page that canonicalizes to staging is not ready. A sitemap full of redirect sources is not ready. Fix the production truth before sending a notification about it.

For server-rendered and JavaScript applications, the crawlability guide explains how to validate initial responses, rendered content, links, metadata, and failure behaviour.

Establish durable Bing Webmaster Tools ownership

Add the exact production property in Bing Webmaster Tools. Bing documents multiple verification methods, and it also supports importing eligible properties from Google Search Console. Choose the method the business can maintain, not merely the fastest method available to one contractor today.

Record:

  • property URL and hostname;
  • verification method;
  • where the verification file, tag, or DNS record is managed;
  • primary business owner;
  • approved agency or contractor access;
  • recovery and offboarding owner; and
  • verification date.

If importing from Google Search Console, confirm the resulting Bing property is the intended one. An import is a setup convenience, not evidence that the site's Bing crawl or index state matches Google's.

Do not make an individual employee or temporary vendor the only administrator. Use Bing's user-management controls to give each approved person the access level their work requires. Review access after a vendor change, staff departure, security incident, or domain migration.

API credentials and OAuth tokens are different from the public IndexNow verification key. Keep Bing Webmaster API client secrets and tokens out of repositories, screenshots, tickets, analytics events, and command history. Store and rotate them through the organization's approved credential process.

Submit a canonical sitemap and inspect its processing state

Bing accepts XML sitemaps, sitemap indexes, RSS, Atom, and plain-text URL lists. For most business websites, a canonical XML sitemap is the clearest inventory because it can carry absolute locations and accurate modification dates.

Before submission, validate the live sitemap:

  • it returns 200;
  • its content type and XML are usable;
  • every location is an absolute URL on the intended public site;
  • entries use the preferred scheme, host, path, case, and slash convention;
  • listed pages are successful, indexable, and self-canonical;
  • redirect sources, error URLs, internal search, account pages, and tracking variants are absent;
  • lastmod reflects a meaningful page change when supplied; and
  • the file stays within the sitemap protocol's limits.

Submit the sitemap under the matching verified property. Bing's Sitemaps tool reports discovered, submitted, imported, and processing information and can expose warnings or errors for a particular sitemap. Record the submitted sitemap URL, submission date, last processing state, URLs discovered, and any corrective action.

A sitemap is a discovery aid. Inclusion does not compel indexing, and omission does not reliably keep a reachable linked page out of search. Use page-level index controls, authentication, correct status codes, and coherent internal linking for their respective jobs.

Reference the canonical sitemap in robots.txt when appropriate:

text Sitemap: https://www.example.ca/sitemap.xml

Then fetch both files publicly. A source-code review cannot prove that a CDN, reverse proxy, deployment, or hostname rule serves the intended result.

Use URL Inspection as a diagnostic record

Bing describes its URL Inspection tool as a place to review crawling, indexing, SEO, and markup information for URLs in the selected property. Use it to investigate an important page, not as a ritual applied to every sitemap entry.

For a newly launched service page or resource, capture:

  • inspected canonical URL;
  • inspection date;
  • crawl and index state shown by the tool;
  • reported errors or exclusions;
  • markup or SEO findings that require action;
  • the production evidence checked independently; and
  • next review date.

If the tool says a URL is not shown or has not been crawled, inspect the website before resubmitting:

  1. Can an unauthenticated client fetch the URL?
  2. What is the initial status and redirect chain?
  3. Does the final page allow indexing?
  4. Does its canonical point to itself?
  5. Is the page linked from relevant canonical pages?
  6. Is it present in the correct sitemap?
  7. Is the visible content substantial and distinct?
  8. Are the hostname and property aligned?
  9. Are recent server or CDN errors interfering with crawlers?

Repeated submission does not repair a contradictory canonical, a blocked page, a soft error, or an inaccessible server.

Understand the IndexNow verification model

IndexNow uses a key to establish that a submitter controls the host or a portion of it. The key is not a conventional private API secret: the protocol expects a UTF-8 text file containing the key to be publicly retrievable at the declared key location.

That distinction matters:

  • the IndexNow verification file is intentionally public;
  • server login credentials, environment files, deployment keys, Bing API tokens, and OAuth secrets are not;
  • the application should still control who or what can trigger submissions; and
  • logs should record results without dumping unrelated credentials or private environment values.

The simplest model is to place the verification file at the host root. IndexNow also supports another location on the same host when keyLocation is supplied. A key file below a directory can authorize only the matching URL scope described by the protocol, so root placement is recommended when the whole host is managed together.

Validate key ownership before automating:

  • the key file is reachable over the intended public scheme and host;
  • the response body contains the exact key and no HTML wrapper;
  • the declared keyLocation matches that file when used;
  • URLs belong to the declared host and permitted path;
  • the key and location are stable across deployments; and
  • rotation has an owner and a coordinated cutover plan.

Never paste the site's real operational values into a public tutorial, support post, or test fixture. Use obvious example domains and values in documentation.

Send only URLs that actually changed

IndexNow is an update notification protocol, not a recurring full-site ping. Notify participating search engines when a public URL is added, materially updated, redirected, or removed.

A release change set can include:

| Change type | URL to notify | Preflight evidence | | --- | --- | --- | | New page | New canonical URL | 200, indexable, self-canonical, internally linked, sitemap state | | Material update | Existing canonical URL | 200, visible change deployed, metadata and canonical verified | | Permanent move | Old URL and final replacement | Old status and direct destination; target 200, indexable, self-canonical | | Removal without replacement | Removed URL | Public 404 or 410, links and sitemap updated | | Canonical consolidation | Affected source and preferred URL | Source treatment and target state agree with the approved URL decision |

IndexNow's FAQ specifically includes redirects and URLs returning 404 or 410 among the changes that should be submitted. That lets search systems learn that an old address changed; it does not mean an error URL belongs in the canonical sitemap.

Do not submit:

  • staging or preview URLs;
  • private account or administrative pages;
  • parameter combinations that have no intended search value;
  • URLs on another host under the wrong key;
  • redirect destinations that are still failing;
  • pages marked noindex unless the notification is part of an approved removal change;
  • unchanged URLs merely to inflate a submission count; or
  • speculative routes that have not been deployed.

Choose single-URL or batch submission

The IndexNow protocol supports a GET request for one URL and a JSON POST for a set of URLs. A batch payload identifies the host, key, optional key location, and URL list.

An illustrative payload is:

json { "host": "www.example.ca", "key": "example-verification-key", "keyLocation": "https://www.example.ca/example-verification-key.txt", "urlList": [ "https://www.example.ca/services/example", "https://www.example.ca/resources/example-guide" ] }

Use Content-Type: application/json; charset=utf-8, send only URLs authorized by the key, and follow the current protocol limits. Generate the batch from the approved release change set rather than from an unreviewed crawl.

For a small editorial release, one controlled batch can be easier to audit than many individual requests. For a system publishing frequent inventory or user-generated updates, queue and deduplicate notifications so ordinary application traffic cannot create an uncontrolled flood.

An automation should be safe to retry. Give each release a stable identifier, prevent concurrent workers from sending the same change set repeatedly, and store a hash or ordered list of the submitted URLs. If a job fails midway, retry only what the evidence says is unresolved.

Interpret every response conservatively

IndexNow documents these response codes:

| HTTP response | Protocol meaning | Operational action | | --- | --- | --- | | 200 OK | URL submission received successfully | Log receipt; do not call the URL indexed | | 202 Accepted | URL received; key validation is pending | Log pending validation and recheck the key setup | | 400 Bad Request | Invalid request format | Correct the payload, headers, or request construction | | 403 Forbidden | Key was not valid or could not be verified | Check the public key file, exact key, host, and location | | 422 Unprocessable Entity | URLs do not belong to the host or the key does not match protocol rules | Rebuild the scoped change set and verify scheme, host, and key | | 429 Too Many Requests | Request volume was treated as excessive | Stop immediate retries, respect backoff, deduplicate, and investigate the trigger |

Store the endpoint, timestamp, release identifier, URL count, response code, and retry decision. Do not log the contents of private environment files or authorization headers.

Treat 200 and 202 as transport or validation milestones. Later evidence comes from Bing Webmaster Tools, server logs where lawfully retained, index reports, search performance, and the public results themselves. Even a page that enters an index may receive no impressions because indexing and ranking are separate decisions.

Create an IndexNow acceptance register

The following Nexxen acceptance register is an original operational framework. It is not a claim about an unverified customer, ranking, or search-engine result.

| Field | Required record | | --- | --- | | Release ID | Commit, deployment, or approved change-set identifier | | URL | Exact public address submitted | | Change type | New, updated, redirected, removed, or canonicalized | | Preflight | Status, final URL, robots directive, canonical, and visible content | | Discovery | Internal-link and sitemap state | | Verification | Key URL, successful retrieval time, and authorized scope | | Submission | Endpoint, batch ID, timestamp, and URL count | | Response | HTTP code and sanitized response detail | | Retry | No retry, pending validation, corrected request, or backoff schedule | | Bing follow-up | Inspection date, crawl/index state, and reported issue | | Outcome | Discovered, crawled, indexed, excluded, or unresolved | | Owner | Person or system accountable for the next action |

The register separates facts that often get collapsed into one word:

text deployed -> publicly validated -> submitted -> received -> discovered -> crawled -> indexed -> shown -> visited -> converted

Not every URL will pass through every state, and later states are not promised by earlier ones.

Build a release workflow that can fail safely

Use this order for a normal website release:

  1. Approve the canonical URL change set.
  2. Deploy the exact reviewed revision.
  3. Fetch every changed public URL and record its status, redirects, canonical, robots directive, and primary content.
  4. Validate internal links, sitemap, and structured data.
  5. Confirm the IndexNow verification file from the public internet.
  6. Submit the approved changed URLs.
  7. Record the response without exposing credentials.
  8. Correct malformed, unauthorized, or rate-limited requests before retrying.
  9. Inspect priority URLs in Bing Webmaster Tools after processing time.
  10. Monitor crawl, index, performance, and business outcomes separately.

If public validation fails, stop before submission. If submission fails, leave the website live if the website itself passed—IndexNow is a notification layer, not the serving layer—but report the precise failure and keep the change set for a controlled retry.

For a migration, preserve the complete old-to-new URL map and validate redirects before notifying the old and new URLs. For ongoing publishing, connect the submission job to successful production releases rather than draft saves or staging builds.

Diagnose common launch failures

The verified property does not match the public host

The site may be verified as one hostname while canonical pages use another. Normalize the public host, add or verify the property required for reporting, and ensure sitemaps and inspections use the intended identity.

The sitemap was accepted but pages remain unresolved

Check the sitemap's processing details, then inspect representative URLs. Confirm success status, indexability, self-canonicalization, internal discovery, useful content, and server reliability. Sitemap acceptance is not page acceptance.

IndexNow returns 403

Fetch the exact keyLocation publicly. Check that the body contains the exact key, the file is on the correct host, no redirect or access rule interferes, and the submitted URLs fall within its authorized scope.

IndexNow returns 422

Compare every URL's scheme and host with the payload's host and the key's scope. Split mixed-host releases into independently authorized submissions.

IndexNow returns 429

Stop tight retries. Deduplicate the queue, find the event that created the volume, apply backoff, and submit only genuine changes. A scheduled job should not resend the full canonical inventory simply because the timer fired.

A URL was received but not indexed

Receipt is not an indexing decision. Use URL Inspection and public checks to investigate crawl access, status, canonical alignment, content usefulness, duplication, internal discovery, and time since release. Do not manufacture a fresh timestamp or trivial wording change merely to resubmit.

An old URL remains visible

Confirm the old URL now returns the approved direct redirect, 404, or 410; remove it from internal links and the canonical sitemap; notify the change; and monitor subsequent processing. Search results can lag behind a correct production change.

Run launch acceptance checks

Bing Webmaster Tools

  • [ ] Correct HTTPS property is verified.
  • [ ] Durable business owner and approved users are recorded.
  • [ ] Temporary vendor access is limited and reviewable.
  • [ ] Canonical sitemap is submitted under the matching property.
  • [ ] Sitemap processing details have been reviewed.
  • [ ] Priority URLs have an inspection record and next action.
  • [ ] Private API credentials and OAuth tokens are not exposed.

Public website

  • [ ] Changed pages return the approved status.
  • [ ] Redirects are direct and targets are healthy.
  • [ ] Indexable pages have one correct self-canonical.
  • [ ] Robots directives match the URL decision.
  • [ ] Primary content and structured data are present.
  • [ ] Internal links point to canonical destinations.
  • [ ] The sitemap lists successful canonical pages only.
  • [ ] Staging and private pages are excluded.

IndexNow

  • [ ] Verification file is publicly reachable at the declared location.
  • [ ] Key scope covers every URL in the change set.
  • [ ] Only added, updated, redirected, removed, or consolidated URLs are included.
  • [ ] Host, headers, and JSON are valid.
  • [ ] Submission timestamp, endpoint, count, and response are recorded.
  • [ ] 200 or 202 is described as receipt, not indexing.
  • [ ] 400, 403, 422, and 429 each have a controlled response.
  • [ ] Retries are deduplicated and rate-aware.
  • [ ] Follow-up inspection is assigned.

Keep the system maintained

Review the setup when the domain, canonical host, framework, CMS, CDN, sitemap generator, release pipeline, or agency relationship changes. Key files can disappear during a platform migration. Verification tags can be removed by a template rewrite. Old users can retain access. A submission hook can quietly stop firing or begin sending every URL repeatedly.

Include these checks in ongoing website maintenance:

  • property ownership and user access;
  • public verification artifacts;
  • sitemap freshness and processing errors;
  • release-to-submission job health;
  • rejected and rate-limited requests;
  • important URL inspection outcomes;
  • canonical and redirect drift; and
  • the difference between search visibility and business performance.

For Canadian businesses that need technical SEO implementation, crawl and index diagnostics, release validation, and accountable follow-up tied to a maintained website, Nexxen's SEO services are the commercial owner for this resource.

Make every claim match the evidence

A defensible Bing launch is not "we pressed submit." It is a chain of evidence.

Verify the property. Publish a clean canonical inventory. Validate the production responses. Notify only URLs that changed. Record the endpoint's actual result. Inspect priority URLs after processing. Then report discovery, crawl, indexing, visibility, visits, and conversions as separate outcomes.

That discipline makes Bing Webmaster Tools and IndexNow useful. It also prevents an accepted notification from being misrepresented as a ranking result the tools never promised.