Search engine tools are easy to postpone. A site can be live, fast, and technically correct while its owner still has no reliable answer to basic questions:

I recently configured Google Search Console and Bing Webmaster Tools for two small sites: MarginDeck, the site for the macOS app I make, and SwingCodeLab, this independent developer site. This guide records the setup I would repeat for another small product site, including the confusing states I encountered along the way.

Configure both tools, but do not treat either dashboard as a ranking control panel. They help you verify discovery, diagnose crawling and indexing, and measure what happened. They do not guarantee that a submitted page will be indexed or ranked.

What each tool is responsible for

Google Search Console reports how a verified property performs in Google Search. It also provides page indexing, sitemap, URL inspection, security, and experience reports.

Bing Webmaster Tools provides similar crawl, indexing, and search-performance information for Bing. It also includes Site Explorer, Site Scan, IndexNow reporting, and AI Performance for supported Microsoft and partner AI experiences.

Use both even if Google is your main source of search traffic. The setup cost is small, the crawlers can fail differently, and Bing now exposes citation data that is not the same as a conventional click report.

Step 1: decide the canonical host before adding properties

A site may be reachable through several URLs:

Pick one production URL and redirect every alternative to it. Then make the same choice in page canonicals, internal links, structured data, the sitemap, and the URLs you submit for inspection.

For these two sites, the intended hosts are different by design:

Site Canonical homepage Redirected alternative
MarginDeck https://www.margindeck.app/ https://margindeck.app/
SwingCodeLab https://swingcodelab.com/ https://www.swingcodelab.com/

Use the chosen host in redirects, canonicals, internal links, and the sitemap. Google's canonicalization guidance treats redirects and rel="canonical" as strong signals, while sitemap inclusion is a weaker supporting signal.

Before continuing, check the production site rather than a local or preview deployment:

  1. The canonical homepage returns 200.
  2. Each alternative host and HTTP URL permanently redirects to the canonical HTTPS URL.
  3. The final HTML contains a self-referencing canonical link.
  4. robots.txt and sitemap.xml are public without authentication.
  5. Pages intended for search do not contain noindex.

Step 2: add and verify the Google Search Console property

Search Console offers two website property types:

For a small product site where you control DNS, I prefer a Domain property such as margindeck.app or swingcodelab.com. It avoids splitting data between HTTP, HTTPS, apex, www, and any future subdomain. Google's own property documentation generally recommends the Domain option when it is appropriate.

A URL-prefix property is still useful when you cannot edit DNS or when you deliberately need a separate view for one host or directory. If you use it, enter the exact canonical prefix, including https:// and the final slash.

After verification:

  1. Open Settings → Ownership verification and confirm that the durable method is still valid.
  2. Check Pages for indexing states, but expect little or no data at first.
  3. Open Sitemaps and submit the production sitemap URL.
  4. Inspect the canonical homepage and one representative content page.

Do not remove the DNS record or verification file after the green check appears. Ownership is checked again over time.

Step 3: add Bing Webmaster Tools—or import from Google

Bing supports manual verification, but importing a verified Search Console property is faster. Its add and verify documentation says the import can bring in the property and its sitemaps, automatically verify the selected site, and periodically revalidate access.

The practical flow is:

  1. Sign in to Bing Webmaster Tools.
  2. Choose Import from Google Search Console.
  3. Grant read access and select only the sites you intend to manage.
  4. Confirm that Bing selected the correct canonical site rather than an old HTTP or alternate-host property.
  5. Open Sitemaps and confirm that the production sitemap is present and processable.

Importing saves configuration work; it does not copy Google rankings or historical performance into Bing. Bing says new analytics normally need time to be collected and processed, so an empty Search Performance report immediately after setup is not a fault.

If you later disconnect Search Console under Bing's profile settings, make sure the Bing property retains a valid independent verification method.

Step 4: submit one clean sitemap

For a small site, the sitemap should be boring. Put it at a stable production URL such as:

https://example.com/sitemap.xml

Include only absolute canonical URLs that you want to appear in search. Exclude redirects, preview deployments, duplicate hostnames, account-only pages, noindex pages, and utility files that are public only for verification or downloads.

Google's sitemap guidelines recommend absolute URLs and canonical versions. Bing accepts XML sitemaps as well as several feed and text formats, as described in its Sitemaps documentation.

How to make the tools read the sitemap again

When a sitemap is generated dynamically, publishing a new article should update the file automatically. Search engines will revisit it, so normal content publishing does not require deleting and recreating the sitemap entry.

If you changed the sitemap itself or need to recover from a fetch error:

  1. Open the sitemap URL in a private browser window and confirm it returns 200 without login.
  2. Confirm the new canonical URL is present and the XML is valid.
  3. In Search Console, open Sitemaps and submit the same sitemap URL again. The report records the new fetch and processing state; it does not upload a file to Google.
  4. In Bing Webmaster Tools, open Sitemaps, select Submit sitemap, and submit the production URL again if its status is stale or failed.
  5. Wait for processing before changing the site again. A successful sitemap fetch means the file was read, not that every listed URL was indexed.

Do not increment fake lastmod dates every day. Update the date when the page's meaningful content changes.

Step 5: understand indexed data versus a live test

Both tools can show two different realities for the same URL:

This distinction explained two confusing results during my setup.

An old structured-data price does not prove the live page is wrong

Bing's indexed view for the MarginDeck homepage showed JSON-LD with an older price value after the live site had changed. That was evidence of a stale crawl snapshot, not automatically a production bug.

The correct sequence is:

  1. Check the live page source or run the tool's Live URL test.
  2. Confirm the canonical, status code, rendered content, and structured data are current.
  3. If the live result is correct, request indexing once and allow time for recrawling.
  4. If the live result is also wrong, fix the deployment or cache before requesting indexing.

Google describes the same distinction in its URL Inspection documentation: the main report describes Google's indexed version, while the live test checks whether the current page appears indexable.

A historical DNS error is not always a current DNS outage

Bing initially showed SwingCodeLab as “discovered but not crawled” with a DNS connection error. The useful follow-up was not to repeatedly press Request indexing. It was to inspect the canonical HTTPS URL under Live URL and independently confirm DNS resolution, the redirect chain, TLS, and the final 200 response.

If the live fetch succeeds, the stored error can remain visible until Bing processes a later crawl. If the live fetch fails, check DNS records and nameservers, IPv4 and IPv6 consistency, CDN or firewall rules, and whether Bingbot is being blocked.

Bing's URL Inspection guide documents the Index view, Markup view, and Live URL test separately. Treat the timestamp and selected tab as part of the result.

Request indexing is a notification, not a queue-jumping guarantee. Use it for a small number of important new or materially updated pages. For many URLs, maintain the sitemap instead.

Step 6: add IndexNow after the canonical setup is stable

IndexNow lets a site notify participating search engines when a URL is added, updated, or deleted. It complements discovery through links and sitemaps; it does not guarantee crawling, indexing, ranking, or citation.

A reliable implementation has four parts:

  1. Generate a key between 8 and 128 allowed characters.
  2. Publish a UTF-8 text file containing that exact key, ideally at the root of the canonical host.
  3. Verify that the key URL returns 200 and plain text after the production deployment.
  4. Submit the exact canonical URLs that changed after the deployment succeeds.

Example placeholders:

https://example.com/YOUR_INDEXNOW_KEY.txt
https://example.com/articles/new-article

The IndexNow protocol documentation recommends automated notifications as content is added, updated, or deleted. A successful 200 response means the submission was received; 202 means the URL was received while key validation is pending. Neither response says the page has been indexed.

I keep a separate key for each host. It is not required for secrecy—the verification file is public—but it limits operational mistakes and makes rotation easier.

Submit only URLs on the declared canonical host. Do not send preview URLs, redirected www variants, tracking parameters, or the entire historical sitemap on every release. For Google, continue using Search Console's sitemap and URL Inspection flows; IndexNow is a separate protocol for participating engines.

Step 7: read empty performance reports correctly

Search Performance and AI Performance can both be visible before they contain data.

For a newly configured site, an empty report usually means one of three things:

Google notes that a newly added property can take up to a week to generate data, and a lack of performance data may simply mean the site has not received search activity. Bing says Search Performance may take a few days after a site is added and does not provide backdated data from before collection began.

Do not create content just to make the dashboards non-empty. First confirm that the canonical pages are crawlable and indexable. Then publish material that answers a specific question with evidence or first-hand experience.

What to monitor in Search Performance

In both Google and Bing, use a consistent date range and review:

Google recommends focusing more on trends in impressions and clicks than on average position alone. Its Performance report guide also shows how to investigate high-impression, low-CTR pages and compare query or page changes. Bing's Search Performance documentation explains its source, query, page, crawl, and indexing metrics.

What Bing AI Performance does—and does not—show

Bing's AI Performance report covers supported Microsoft Copilot, Bing AI summary, and partner experiences. It reports cited pages, citation trends, and sampled grounding queries. These are source references in AI answers, not conventional rankings or visits.

If the report is empty, no data is available for the selected property and period. Check the selected filters and the provider's reporting guidance before drawing a conclusion. Once data appears, use it to identify:

Bing's AI Performance announcement cautions that citation counts do not indicate ranking, authority, placement, or a page's role within an answer.

A maintenance cadence for a small product site

SEO remains ongoing, but not because you must chase a different keyword every morning. The site changes, competitors publish, search demand shifts, crawlers revisit old versions, and performance data reveals questions you did not predict.

A lightweight routine is enough:

When Action
After each production content release Verify the canonical URL, sitemap entry, metadata, and structured data; then submit that changed URL through IndexNow.
Weekly for the first month Check indexing, crawl errors, sitemap processing, impressions, and unexpected queries.
Monthly once stable Export query and page data, compare a fixed period, and choose one evidence-backed improvement.
After domain, hosting, or redirect changes Recheck DNS, HTTPS, canonical tags, redirects, properties, sitemap, robots rules, and live URL inspection.
Quarterly Review ownership access, verification methods, stale content, broken links, and whether old URLs should redirect or be removed.

Use performance data as a research source, not a content factory. A promising query is one where your product or experience can contribute a better answer. A large keyword list with no connection to the site is only a backlog of possible distractions.

The checklist I would reuse

Official reference documents

Google

Bing and IndexNow