Find crawl on the wrong hostname

A bot spends the same budget on staging.example.com as it spends on your live site. Log Hero records the hostname of every request, so a second host is visible as soon as a bot reaches it. This is how to find one and name it.

Time: about 10 minutes · You need: a working integration and at least 7 days of data

1. Look for the hostname selector

The hostname selector sits in the top bar, next to the date range, on every Log Hero report. Its first option is All hosts. It lists up to 50 hostnames, ordered by bot hits.

The selector appears only when two or more hostnames got bot hits inside the selected window. If it is absent, bots reached one host only in that window. Widen the date range before you conclude that there is one host.

The selector scopes the reports, with one exception that the next step names. If a change of date range drops the host you picked, the selector resets to All hosts.

2. Read the Hostnames panel on Crawl Budget & Waste

Log Hero → Crawl Budget & Waste, panel Hostnames. Its sub-line reads:

Crawl split across hosts (www vs non-www, staging, http).

The panel is a bar list of hostname, hits and share, for the bot selected at the top of the page. Under it comes one of two sentences:

All crawl lands on one hostname — no www/non-www or staging leakage for this bot.

{x}% of this bot's requests hit hosts other than {primary}.

This panel deliberately ignores the hostname selector. It always shows every host, even when you filtered the rest of the page down to one.

3. Name the variant

Each shape in the list means something different:

What the list shows	What it means	The fix
`example.com` next to `www.example.com`	Both spellings answer, so bots crawl the site twice	Redirect one spelling to the other with a `301`
`staging.example.com`, `preview.example.com`	A non-production host is reachable and indexable	Block bots in its `robots.txt`, or put authentication in front of it
`example.com:8080`	Requests arrive on a port other than 80 or 443	Fix the links that point at the port, then redirect the port to the canonical host
`Example.com` next to `example.com`	Mixed case, because the hostname is stored as it was sent	Redirect to the lower-case spelling
`web-01.internal`, an origin or load-balancer name	Bots reach the origin directly, past the CDN	Fix the DNS record, or accept traffic at the origin only from the CDN

Act on share, not on presence. A host with 0.1% of the crawl is noise. A host with 30% of the crawl is a budget problem and a duplicate-content problem at the same time.

4. Make sure that the fix works

A redirect or a block stops new hits. It does not remove the hits that Log Hero already recorded, so the old host stays visible until the date range moves past those days.

Make sure of two things after the window has moved on:

The host is gone from the hostname selector in the top bar.
The Hostnames panel shows its single-host sentence again:

All crawl lands on one hostname — no www/non-www or staging leakage for this bot.

If the host is still there after a full window, the bots still reach it. Open URL Drilldown for one of its paths and read Status served, by day. A redirect shows as a flip to 301.

Why hostnames look different per integration

The hostname is stored as it was sent. Case and port survive. Two spellings of one host are two rows.
Azure Front Door is the exception. It lower-cases the hostname and drops the port before the record reaches Log Hero. See Azure Front Door.
Coverage collapses variants, the logs do not. The sitemap join lower-cases the hostname and strips one leading www. on both sides. So www.example.com and example.com count as one host on Coverage, and as two rows in the selector and in the Hostnames panel.

If the host does not appear at all

An origin integration misses cached requests. A staging host behind a CDN is invisible to it. See Choose your integration.
A host with no bot hits is not listed. The selector and the panel both count bot hits only.
No data at all is a setup problem. See No data arriving.