bing-crawl-health

Installation
SKILL.md

Bing Crawl Health

Diagnose how Bing crawls, indexes and links a property, and produce an issue summary grouped by type with concrete fixes, the feed status, the most-linked URLs and recommendations. This is the Bing counterpart of the indexing-health skill; for Google's index run that one. The user's request may contain a property name or URL, a date range for the crawl trend, a focus hint (a path or section), or a list of fixed URLs to resubmit; use it to skip resolution or narrow the suspect set.

Workflow

  1. Resolve the property. If the user's request or the conversation names a property, use it. Site URLs use GSC formats: sc-domain:example.com or https://www.example.com/. Otherwise call list_sites and pick the obvious match. If several plausible properties exist, ask the user which one before continuing. Every property-scoped Bing tool takes that same GSC siteUrl and maps it to Bing's form itself (sc-domain:example.com becomes https://example.com/), echoing the result as bingSiteUrl.

  2. Confirm the Bing side. Call list_bing_sites (no arguments). A notConfigured: true answer means Bing Webmaster Tools is not connected for the property's Google account in the GSC Wizard app; tell the user to add it there, point them at the indexing-health skill for the Google side, and stop. Otherwise find the property in siteDetails and read isVerified: Bing serves data only for a verified site, an unverified one makes the property-scoped tools answer with a not-verified error that names the fix (a subfolder property has to be verified as its own site in Bing Webmaster Tools), and a property missing from sites has to be added there first.

  3. Crawl trend. Call get_bing_crawl_stats with startDate and endDate for the last 28 days unless the user set a range; omit both dates for everything Bing has, about 6 months of crawl data, when the user wants the long trend. daily[] rows (oldest first) carry crawledPages, inIndex, inLinks, code2xx, code301, code302, code4xx, code5xx, blockedByRobotsTxt, allOtherCodes, crawlErrors and containsMalware. A day Bing did not report is missing from the series, not a zero, so never read a gap as a crawl stop. Compare the first and last reported weeks: whether pages crawled and inIndex rise or fall, and the share of the crawl that hit a 4xx, a 5xx or a robots block (derived from the row sums; say so). An inIndex drop with a 5xx or robots rise on the same days is the pattern to flag first. Bing reports on its own calendar and carries no settledThrough or partialDays, so do not apply the Google reporting-lag rule here.

  4. Crawl issues. Call get_bing_crawl_issues; the limit default of 200 is fine, and raise it when rowCount equals the limit. issues[] rows carry url, httpCode, inLinks and issues, a list of decoded labels: "301 redirect", "302 redirect", "HTTP 4xx", "HTTP 5xx", "Blocked by robots.txt", "Important URL blocked by robots.txt", "Contains malware", "DNS error" and "Timeout error". Rows come most inbound links first, so the top of the list is the most damaging. Group by label (a URL with several labels counts under each), count the URLs per group, keep the two or three examples with the most inLinks, and narrow to the user's focus path when one was given. An emptyBecause answer means Bing reports no issues; say so rather than leaving the section blank. Any "Contains malware" row is urgent and goes first.

  5. Feeds. Call get_bing_feeds. feeds[] rows carry url, status (Pending, Success, Warning or Error), type (Sitemap, Sitemap index, Atom, RSS, Text or mRSS), lastCrawled, submitted, urlCount, fileSize and compressed; a date of 1601-01-01 is Bing's empty value, not a real date. Flag Error and Warning feeds, a lastCrawled well behind today, a urlCount of 0, and a property with no feeds at all (emptyBecause), which means Bing discovers pages only by crawling. For the Google sitemap view run the indexing-health skill rather than repeating it here.

  6. Most-linked URLs. Call get_bing_link_counts with page: 0 and limit: 50. Page 0 usually holds every linked URL, and totalPages is the number of linked URLs Bing reports, not a count of result pages, so do not page further; when truncated is true and the user wants the full list, raise limit instead. links[] rows carry url and count, most links first. Check each top URL against step 4 by exact URL: a most-linked URL that is also a 4xx, a redirect or a robots block wastes the links pointing at it and is the top fix, and a most-linked URL that redirects should have its links repointed at the final page.

  7. Submission quota. Call get_bing_url_submission_quota for dailyQuota and monthlyQuota (null when Bing did not report one). Report both as Bing's remaining URL submission allowance for the property, which is separate from IndexNow and is not spent by anything in this workflow.

Installs
2
First Seen
2 days ago