Build1 publisher3 min readPublished
Verifying Search Console at the bare domain summed four hosts into one 17% error rate
The 77 failed crawl requests that looked like an app problem all went to an apex with no address record. The per-host table further down the same report is the only place a count can be attributed to one host.
The Engineer · Build desk
What happened
- Google had indexed none of WatchNext, and the crawl stats report showed 453 requests over the month with 17% of them ending in a DNS error.
- Search Console had been verified as a domain property for leyu.studio, so every figure in the report is the sum of every subdomain under it.
- The hosts table splits that total across four hosts: an online shop, its checkout, the WatchNext app, and the bare domain, with WatchNext a little under a third of requests.
- The bare domain had no page, no server and no DNS address record, and it accounted for 77 of the property's 81 failed requests; the remaining four were ordinary 404s.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint One verification covers every subdomain, and the report adds those subdomains together, so every chart above the hosts table describes a population the site owner did not choose.
- decision A team reading only the overview would spend the sprint on the app's rendering, when the change that removes 95% of the property's failures is a DNS record.
- contradiction Two equally tidy matches turned up in one diagnosis, and only the one a resolution failure forces holds, so any per-host figure derived from a property-wide percentage in this report has to be treated as unusable.
A hostname with no address record cannot get past DNS, so every request to it fails at that one stage and no other [9]. 17.00% of 453 is 77.01, and the bare domain received 77 requests [3][7][1]. The daily export agrees: over the last five days of the period, every request recorded no bytes downloaded and a response time of zero [10]. "The count is the consequence of the cause," the WatchNext post said [18].
453 requests minus 77 leaves 376, and the only failures left in that set are the four 404s, which is about 1.1% [3]. The rate that started the diagnosis was 81 failures across the whole property, or 17.9% [2].
The same summing nearly produced a finding in the other direction. The file-type table puts HTML at 8.17% of requests, and WatchNext received 134 of the 453 [12], which is 29.6% of the property [6]. Multiply 134 by 8.17% and you get 10.95 page fetches [5], against a coverage report listing exactly 11 pages as crawled and not indexed [2]. The post threw the result out. The 8.17% is the HTML share across all four hosts, and applying it to WatchNext alone assumes a Next.js app and a Shopify storefront request the same mix of JavaScript, images, stylesheets and pages [13]. The multiplication "borrows a ratio from a population it doesn't describe, and the tidy answer it produces is a coincidence," the post said [14].
The same problem sits one section later. The busiest day in the report is 113 requests on 14 August, three days before the commit that gave these pages server-rendered content [16]. That would date Google's opinion of the site to the broken version, except the chart covers the whole property and does not say which host the 113 requests went to [16].
The hosts table has one column that does not fit: all four hosts carry a status of "No problems", including the one that could not resolve, so whatever it checks is not the fate of individual requests, and the post did not lean on it [11].
Verifying at the domain is still the choice I would make, because one verification covering every subdomain is worth having [4]. Host attribution then lives only in that table, and on this property the cheapest available fix was an address record for the bare domain [6].
Inspecting a single post showed Google had found it through a link from another site, crawled it on 20 August, after the fix, fetched it successfully and read the canonical URL as declared, and still had not indexed it [17]. Property-wide, 99.56% of requests were refreshes of URLs Google already knew about and 0.44% were discovery [15]. Applied to 453 requests, that is roughly two discovery requests in the month [7], against 200 URLs the coverage report lists as discovered and never fetched [2].
What to watch
- Next month's export: if the apex gets an address record, the property's DNS error rate should fall to zero.
- Whether the post crawled on 20 August is indexed on a later inspection, now that the fetch and the canonical both check out.
- Whether the 0.44% discovery share moves once Google stops spending requests on a host that cannot answer.