Adding a site to Bing is easy; knowing whether Bing can actually crawl, understand, and select its pages is the useful part. I think of Webmaster Tools as a diagnostic relationship, not a one-time submission form. Verification proves control, a sitemap describes the durable URL set, and IndexNow reports timely changes.

Before opening Webmaster Tools

  • Choose the canonical HTTPS hostname you actually serve, including the intended www or non-www form.

  • Confirm important pages return HTTP 200 without login, geoblocking, or an accidental noindex directive.

  • Publish a sitemap containing canonical, indexable URLs rather than redirects, errors, or duplicate variants.

  • Make sure robots.txt does not block pages or resources Bing needs to crawl.

Any machine with network accessbash
curl -I https://example.com/
curl -fsS https://example.com/robots.txt
curl -fsS https://example.com/sitemap.xml | head
HTTP/2 200
user-agent: *
Sitemap: https://example.com/sitemap.xml

What this preflight proves

  • curl -I checks the homepage status and redirect behavior without downloading its body.

  • robots.txt is public crawl policy, not access control for confidential content.

  • A Sitemap: directive helps crawlers discover the sitemap independently of the dashboard.

  • The sample domain is a placeholder; use the exact verified property URL.

Add the site: import or manual verification

Open Bing Webmaster Tools and sign in. If the property is already verified in Google Search Console, import is the shortest path: Microsoft imports selected properties, permissions, and known sitemaps, then periodically revalidates ownership. Otherwise choose Add a Site and enter the canonical URL.

Four supported ownership methods

  • DNS auto verification: uses Domain Connect when the DNS provider supports it.

  • XML file: place Bing’s unique BingSiteAuth.xml file at the registered site root.

  • Meta tag: keep Bing’s unique verification tag in the homepage <head>.

  • DNS CNAME: publish the exact host and target Bing displays in the verification screen.

Meta-tag verification in a rendered page

Rendered homepage headhtml
<head>
  <meta name="msvalidate.01" content="YOUR_BING_VERIFICATION_CODE" />
  <title>Example site</title>
</head>

Use the unique content value shown by Bing, not this placeholder.

Where verification implementations fail

  • The tag must appear in the server-rendered homepage <head>, not only after client-side JavaScript runs.

  • The content value is site-specific and must be copied exactly.

  • Verify against the same hostname and protocol registered in Bing.

  • Caching and deployment promotion can leave Bing seeing an older homepage.

Any machine with network accessbash
curl -fsS https://example.com/ | grep -o 'msvalidate\.01[^>]*'
msvalidate.01" content="YOUR_BING_VERIFICATION_CODE" /

Check what Bing can fetch

  • This test reads the delivered HTML rather than the local source template.

  • No result means the tag is missing, injected too late, or served on another host.

  • A successful grep does not prove the token matches the property; complete verification in the dashboard.

  • The command is read-only.

Submit the sitemap

After verification, open Sitemaps for the selected property and submit the absolute sitemap URL. Bing accepts XML sitemaps and indexes, RSS, Atom, and plain-text URL lists. A sitemap describes URLs for discovery; it does not override robots rules, canonicalization, redirects, quality evaluation, or indexability.

robots.txttext
User-agent: *
Allow: /
 
Sitemap: https://example.com/sitemap.xml

A small directive with useful reach

  • The sitemap value is absolute and uses the canonical HTTPS hostname.

  • Allow: / is shown for clarity; it does not undo a more specific applicable disallow rule.

  • Submitting in Webmaster Tools provides processing status and per-sitemap diagnostics.

  • Keep lastmod accurate; invented freshness dates waste crawl signals.

Use IndexNow for changed URLs

Microsoft now recommends IndexNow for most real-time URL notifications. It complements the sitemap: the sitemap supplies the durable inventory, while IndexNow tells participating engines that a URL was created, meaningfully updated, or deleted.

indexnow-payload.jsonjson
{
  "host": "example.com",
  "key": "YOUR_INDEXNOW_KEY",
  "keyLocation": "https://example.com/YOUR_INDEXNOW_KEY.txt",
  "urlList": [
    "https://example.com/new-page/",
    "https://example.com/updated-page/"
  ]
}

Batch submission structure; the key must also be verifiable on the host.

Notifications are not indexing commands

  • Every submitted URL must belong to the declared host and use its canonical form.

  • The key file proves authority to notify for that host.

  • Submit meaningful publication, update, or deletion events—not every request or unchanged build.

  • An accepted notification requests discovery; search engines still decide crawling and indexing.

Publishing systembash
curl -i -X POST 'https://api.indexnow.org/indexnow' \
+  -H 'Content-Type: application/json; charset=utf-8' \
+  --data-binary @indexnow-payload.json
HTTP/2 200

Interpret the response narrowly

  • HTTP 200 means the request was accepted, not that every URL entered the index.

  • --data-binary sends the saved JSON without shell interpolation.

  • Do not expose private URLs merely to test the endpoint.

  • Many CMS and CDN products implement IndexNow already; avoid duplicate notification pipelines.

Verify discovery and diagnose indexing

  • Open URL Inspection for a canonical page and review crawl permission, response, discovered source, and indexing state.

  • Use Site Explorer to find crawled URLs and server or robots problems across sections.

  • Check sitemap processing details rather than repeatedly resubmitting an unchanged file.

  • Expect dashboard analytics to take up to roughly 48 hours after verification.

  • Use site:example.com only as a rough search check; Webmaster Tools diagnostics are more specific.

Why a submitted page may remain absent

  • Blocked crawling: robots rules, authentication, firewall policy, or repeated server errors prevent retrieval.

  • Explicit noindex: a robots meta tag or X-Robots-Tag excludes the page.

  • Canonical mismatch: the page identifies another URL as canonical or redirects elsewhere.

  • Thin or duplicate value: discovery does not require Bing to select the URL for its index.

  • Soft 404: an HTTP 200 page behaves like missing or empty content.

  • Rendering failure: essential content or links are unavailable to the crawler.

Primary Microsoft references