Monitor a site migration
A migration changes every URL at once. Your access log is the only record of what search bots find after the change. Log Hero shows you the crawl before launch, the redirects after it, and the day each URL flipped.
Time: 20 minutes before launch, then 10 minutes a day for two weeks · You need: a new sitemap and 14 days of data
Before the migration
Section titled “Before the migration”Take the baseline by hand. Log Hero has no export, no download and no copy button, so write the figures down:
- Crawl hits. Open Log Hero → Crawl Budget & Waste and set the bot to
Googlebot. Write down the Crawl hits tile for a 30-day range. This figure is exact. - The section table. Crawl by section gives one row per first path segment,
with
Hits,Paths,200,3xx,404,ParamsandAvg ms. Write down the sections that the migration touches. - Crawl Ratio. If a sitemap inventory is loaded, open Coverage and write down the Crawl Ratio · Googlebot tile. Without an inventory the whole Coverage page is an empty state instead.
On launch day, upload the new sitemap under Project settings ▸ Sitemap. Upload the file rather than entering its URL. See Add a sitemap.
1. Watch What Changed for the first two weeks
Section titled “1. Watch What Changed for the first two weeks”Log Hero → What Changed compares the last 7 complete days against the 7 before them. Three of its alerts matter during a migration:
- A status mix shift. A status class that moves by 1 point of share or more raises
an alert. The text reads
{class} error share {up|down} {x.x}pts ({a}% → {b}% of bot hits). - A section that starts 404ing. The threshold is 20 or more
404hits in the last week, with either none the week before or a rise to 1.5 times the week before. The text readsNew 404s spiking in {section} section ({before} → {now} hits). - A bot that crawls more or less. The threshold is a change of 50% or more, with at
least 100 hits in one of the two weeks. The text reads
{name} crawl down {x.x}% ({from} → {to} hits).
The date range decides whether the comparison runs at all. Set a range that ends
yesterday or earlier and that covers at least 14 days. The Last 7 days preset ends
today, so it always shows this message instead of alerts:
Select a range that ends yesterday or earlier and covers at least 14 days, so two full weeks can be compared.
The alerts always cover the same two weeks. The range length only decides whether the comparison is possible.
2. Make sure that old paths redirect once
Section titled “2. Make sure that old paths redirect once”A redirect costs the bot two requests, every time it follows one. Old paths in the crawl are normal for a few weeks after launch. Old paths that stay for months are not.
Crawl Budget & Waste ▸ Redirected paths still being crawled lists them. Each row
gives the path, the status served, the hit count, and the days hit as
{days}/{windowDays}.
Two rules for reading it:
- The list is a sample. This panel reads the top 5 000 URLs by hits. A redirect outside that sample is absent from the list.
- A path that stays in the list for weeks is still linked from somewhere. The redirect works. Something keeps sending bots to the old URL. Find that link and point it at the new URL.
3. Make sure that the new paths are crawled
Section titled “3. Make sure that the new paths are crawled”Open Coverage after the new sitemap is loaded.
- Crawl Ratio · Googlebot is the share of advertised pages that Googlebot fetched at least once in the window. It climbs over the weeks after launch. The panel How much of the sitemap the crawlers have reached plots the same share per day.
- Crawled by Googlebot, not advertised lists paths that Googlebot requests and the new sitemap does not advertise. After a migration the old paths fill this list. The list gets shorter as the old URLs drop out of the crawl.
- Advertised, not crawled by Googlebot is the other half. New URLs stay here until Googlebot reaches them.
If the migration also changed the hostname, open the Hostnames panel on Crawl Budget & Waste. See Find crawl on the wrong hostname.
4. Make sure that single URLs changed
Section titled “4. Make sure that single URLs changed”URL Drilldown answers for one exact path. Open it from any path row in the other reports, or paste the path into the search box.
The panel Status served, by day gives one cell per day, coloured by the code served
most often that day. A change of code is called out above the strip in the form
flipped {prev} → {next} on {YYYY-MM-DD}. That date is the day to look at.
A URL with a query string cannot be opened here. The page answers:
Parameter URLs can't be drilled down yet — hits are counted against the base path only.
Their hits count against the base path instead.
If the numbers do not move
Section titled “If the numbers do not move”- If no bot hits arrive at all, see No data arriving.
- If old paths answer
404instead of redirecting, see Find crawl errors. - If the crawl lands on a host you did not expect, see Find crawl on the wrong hostname.
What this cannot show
Section titled “What this cannot show”- The redirect target. The log records that a
301was served, not where it points. - Redirect chains and loops. Each hop is a separate row on a separate path. Log Hero cannot join them.
httpagainsthttps. The log carries no scheme. Both requests land in the same hostname row.- Hourly patterns. Every figure is a daily total. There is no time-of-day view.
- Bot verification before 2026-09-01. The verified against unverified split on Bot
Activity starts on that date. An earlier range shows
IP verification was not recorded for this date range.instead of the table.
