Most migration playbooks are written with Google in mind. You map redirects, submit the new sitemap, watch Search Console for a couple of weeks, and call it done when impressions recover. Then someone notices that Bing traffic is still down 40 percent two months later, and nobody can say whether that is a real problem or just Bing being slow.
It is usually both. Bing behaves differently after a site move, and the differences are predictable enough to plan around. This checklist covers what to do before launch, on launch day, and across the eight weeks that follow, with Bing treated as its own workstream.
Why Bing takes longer to recover than Google
Two structural facts explain most of the lag. First, Bingbot crawls with a smaller budget than Googlebot on the typical mid-sized site. Where Google may hit a redirected URL within hours of launch and follow the chain the same day, Bing can take days or weeks to revisit a URL it already considers stable. Pages deep in your architecture, or pages that rarely changed before the migration, sit at the back of that queue.
Second, Bing’s index refreshes less frequently. Even once Bingbot has seen the redirect, the ranking signals attached to the old URL are consolidated onto the new one on a slower cycle. In practice this means you can see the new URL indexed, the old one marked as redirected, and the ranking still sitting with neither for a stretch. That gap is normal, but it is also where competitors pick up positions that are hard to win back.
The combined effect is a recovery curve that lags Google’s by two to six weeks on a clean migration, and much longer on a messy one. Because the delay is expected, the only way to tell a healthy recovery from a broken one is a baseline and a cadence. Everything below is built around that.
Pre-launch: capture a Bing baseline you can defend
You cannot measure loss without knowing where you started. Google Search Console gives you a partial history, and Bing Webmaster Tools gives you another, but neither is a clean position record for the keywords you actually care about, and neither shows competitors.
- Pick the keyword set now, not after launch. Choose the terms that drive real Bing traffic (Bing Webmaster Tools search performance report is the fastest source), plus a handful of head terms and a handful of long-tail pages you would hate to lose. Fifty to two hundred keywords is plenty for most sites; you are building a signal, not a census.
- Record positions for at least three consecutive weeks before launch. One snapshot is not a baseline. Bing positions fluctuate week to week, and you need to know what normal noise looks like so that a post-launch dip of three positions can be read correctly.
- Record the ranking URL, not just the position. After a migration the question is rarely “did we drop” but “which URL is ranking now.” If the old URL is still ranking at week four, redirects are not being processed. If a different new URL is ranking, canonicals or internal links are pointing somewhere unexpected.
- Segment by country if you serve more than one. Bing’s market share varies sharply by country, and its index behaves differently in each. A US-heavy site that also earns Bing traffic in the UK, Canada, or Germany should baseline each separately.
- Baseline the competitors too. Pick up to five domains that share your results pages. Their positions during your migration window are your control group: if they move up in lockstep as you move down, you are losing ground; if everyone shifts together, it is an algorithm or index change rather than your migration.
Pre-launch: redirect mapping rules that hold up on Bing
Redirect mapping is the same discipline for any search engine, but a few rules matter more for Bing because of the slower crawl.
- One hop, 301, no exceptions on the important pages. Chains that go old URL to interim URL to final URL cost Google a little; they cost Bing a full extra crawl cycle per hop. Flatten them before launch.
- Map to the closest equivalent, never the homepage. Bulk redirects to the root are treated as soft 404s by both engines, and Bing is slower to reassess once it has made that judgment.
- Keep the old XML sitemap live for a period after launch, listing the old URLs. This is counterintuitive but useful: it gives Bingbot a reason to recrawl the old URLs and discover the redirects instead of waiting for its own schedule.
- Preserve trailing slash, case, and query parameter behavior. If the old site served both versions and the new one only serves one, every variant needs an explicit rule. Bing has often indexed variants you forgot existed.
- Test the map against Bing’s own index, not just your crawl. Export the URLs Bing Webmaster Tools reports as indexed and run every one through your redirect test. The set is frequently different from what Google has indexed.
Launch day: tell Bing directly
Bing gives you more direct channels than Google does. Use all of them in the first hours.
IndexNow
IndexNow lets you push a list of changed URLs to Bing (and other participating engines) in one request. Submit the new URLs, and submit the old URLs as well, because a submission for a URL that now redirects prompts Bing to fetch it and discover the 301. Batch them in chunks and keep the API key file reachable on the new host.
Bing Webmaster Tools site move
If the migration involves a domain change, use the Site Move tool inside Bing Webmaster Tools. It exists specifically to tell Bing that signals from the old domain should transfer to the new one, and it is a separate action from adding the new site. For a same-domain restructure (new URL paths, new CMS) there is no site-move step; the redirect map and IndexNow carry the load.
URL inspection
Bing Webmaster Tools includes URL inspection. On launch day, inspect a sample of your highest-value old URLs and confirm Bing sees the redirect, then inspect the corresponding new URLs and confirm they are crawlable, return 200, and show the canonical you expect. Spot-check ten to twenty; if any of them show a blocked, noindex, or canonical-mismatch state, treat it as a launch defect rather than something to revisit later.
The first eight weeks: what to track and how often
A weekly check is the right cadence for Bing. Daily tracking produces noise that mostly reflects crawl timing, not real ranking change, and it tempts teams into reacting to movement that would have resolved itself. Weekly checks line up with how quickly Bing actually reprocesses a migrated site, which makes trend lines readable.
Set up a bing rank tracker against the same keyword list you baselined, with the same competitors and the same countries, and read it on the same day each week. The point is to compare like with like across the entire window. If your baseline was recorded weekly, weekly post-launch data is directly comparable without smoothing.
Here is what to look at each week, in order of priority.
- Share of keywords where the new URL is ranking. This is the single best indicator of migration health on Bing. It should climb steadily. If it plateaus below 80 percent by week four, something is blocking the transfer.
- Average position versus baseline, per country. Expect a dip in weeks one through three. Expect it to close by week six.
- Competitor position deltas on your top terms. If a competitor gains three positions while you lose three on the same keyword, that keyword is at risk of staying lost. Prioritize inspecting the exact URL involved.
- Keywords where the old URL still ranks. Any old URL still ranking at week five means Bing has not processed that redirect. Resubmit it via IndexNow and confirm the redirect is a single 301.
- Keywords that dropped out of the top 50 entirely. Separate these from keywords that merely fell. Complete disappearance is more often a crawl or indexation defect than a ranking one.
Common failure patterns on Bing
The same handful of mistakes show up in most Bing migration post-mortems. They are worth checking proactively in week one rather than discovering in week six.
Lost or wrong canonicals
New CMS templates frequently ship with a canonical tag pointing at a staging hostname, at the non-preferred protocol, or at a version of the URL with a trailing slash that does not match the redirect target. Google often picks the right URL anyway; Bing is far less forgiving. A canonical that disagrees with the redirect target can leave a page unranked on Bing for weeks. Crawl the new site and compare every canonical against the redirect map.
Blocked Bingbot
Firewalls, bot-management rules, and CDN security settings are commonly tuned during a migration, and Bingbot is a frequent casualty. Check server logs for Bingbot user agents returning 403 or 429, and check the crawl stats in Bing Webmaster Tools for a sudden drop in pages crawled per day. If Bing cannot fetch the redirects, nothing else in this checklist matters.
Changed titles and headings
Redesigns almost always touch page titles. Bing weights on-page relevance heavily, and a title rewritten from a descriptive phrase to a brand-first slogan can cost positions independently of the URL change. Diff old and new titles for your top 100 pages. Where the title changed, do not attribute the ranking drop to the migration until you have ruled out the rewrite.
When to escalate
Because Bing recovery is slow by design, the hard part is deciding when slow has become stuck. Use thresholds rather than instinct.
- Week two: if crawl volume in Bing Webmaster Tools has not returned to at least pre-launch levels, escalate to whoever owns the server and CDN configuration. This is almost always a blocking issue.
- Week four: if fewer than 70 percent of tracked keywords show the new URL ranking, escalate to the development team with a specific list of old URLs still ranking and their redirect status.
- Week six: if average position across the tracked set is still more than 20 percent below baseline in any country while competitors are flat, treat the migration as unresolved and schedule a full technical audit rather than continuing to wait.
- Any week: a competitor overtaking you on a head term that you held for the entire baseline period warrants same-week investigation of that specific URL.
These thresholds assume you have the weekly data to evaluate them. That is the practical reason to put tracking in place before launch rather than after: the tool matters less than the continuity. The tracker from Broken Link Checker runs weekly checks across 24 countries with up to five competitors per project, delivers verified results, and offers a free tier covering 10 keywords, enough to keep a small site’s head terms under watch through the migration window. It sits within the same SEO tool suite you will want for the broken-link cleanup that follows any URL restructure.
Bing will not recover on Google’s timeline. Treat it as a separate track with its own baseline, submission channels, and thresholds, and the recovery becomes something you manage rather than something you hope for.
