Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In one Search Console investigation, most of the apparent crawl trouble came from a hostname that had no address record—not from the site the team was trying to diagnose. The report was for a domain property covering four hosts, so its totals mixed activity from several sites. The case shows why you should check report scope and failure type before treating an aggregate crawl error as a problem with one application.
Why did Search Console show DNS errors?
Eugen Taranowski described the investigation in a WatchNext blog post republished on DEV Community on September 14, 2026. WatchNext ran at watchnext.leyu.studio, but the team had configured a Google Search Console domain property for leyu.studio. That property combined data from four hosts:
| Host | Crawl requests reported |
|---|---|
shop.leyu.studio |
234 |
watchnext.leyu.studio |
134 |
leyu.studio |
77 |
checkout.leyu.studio |
8 |
Across the property, the author reported 453 crawl requests during the month and a 17% DNS-error share. The apex hostname, leyu.studio, had no page, server, or DNS address record; the www variant did not exist either. In the account, all 77 requests to the apex were DNS errors. The author’s explanation is that a hostname without a resolvable address cannot connect to an HTTP server, so those requests fail before a server can return a page.
The report showed 81 failed requests overall: the 77 DNS failures and four ordinary HTTP 404s. Those are different failure stages. A DNS error means the crawler could not resolve the hostname to reach a server; a 404 means it reached a server, which responded that the requested resource was not found. These counts and the proposed explanation are Taranowski’s account of this property, not an independently verified crawl log or a general rate for Google crawling.
#1 Best Overall
Were the errors from WatchNext or another subdomain?
The host breakdown makes the central issue visible: the domain-property totals included 234 requests for shop.leyu.studio, 134 for WatchNext, and activity from two other hosts. A domain property can be useful when you want coverage across subdomains, but an aggregate number is not automatically specific to the application you are investigating.
- Check the property’s scope. Confirm whether the report covers a domain and its subdomains or only a particular URL prefix.
- Inspect the host-level breakdown. Identify which host generated the requests and errors before assigning them to a site.
- Separate DNS failures from HTTP responses. A missing hostname and a missing page call for different diagnoses.
In this case, the 77 apex requests and 77 reported DNS errors had a plausible mechanism behind their matching counts: the hostname lacked an address record. That makes them different from a numerical match that appears only after applying a percentage to an unrelated subset.
Rank #2
Why the HTML percentage did not explain WatchNext’s unindexed pages
Taranowski also reported that 8.17% of requests across the entire property were HTML. Applying that percentage to WatchNext’s 134 requests produces roughly 11—the same number as the pages reported as crawled but not indexed. The author cautioned against treating that match as an explanation: 8.17% represented all four hosts, not WatchNext alone. Their request mixes could differ, so the property-wide ratio did not establish WatchNext’s HTML share.
This is a useful check whenever two counts line up: ask whether the percentage describes the same population as the number you are trying to explain. A precise-looking calculation can be coincidental when its numerator and denominator come from a broader group than the subset under discussion.
Rank #3
What happened to the crawled page that was not indexed?
After setting aside the apex DNS errors, the account says 99.56% of requests were refreshes of known URLs and 0.44% were discovery. One WatchNext post had been found through an external link, fetched successfully after a server-rendering fix, and carried the declared canonical URL, yet it still was not indexed.
The account treats that as evidence that the indexing question was separate from the DNS noise, but it does not establish why Google chose not to index that page. The figures and URL inspection are described by the author; the underlying export and configuration are not independently available in the account.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the team changed—and what remains unknown
The team reports adding a page at leyu.studio, redirecting www.leyu.studio to the apex, and creating a separate URL-prefix Search Console property for each site. These changes were intended to make the apex resolve and to keep WatchNext reporting specific to WatchNext.
At the time of the post, post-change Search Console figures were not available; the author said reports could take weeks to reflect the changes. The account therefore does not show whether the DNS-error rate fell, whether indexing improved, or whether the separate property changed the indexing outcome. Cleaner reporting and successful indexing are distinct outcomes: fixing report scope or DNS does not, by itself, get pages indexed.
How to tell a cause from a coincidence
When counts appear to match, test the explanation rather than relying on the arithmetic alone:
- Look for a mechanism. A hostname that cannot resolve cannot reach its server, which gives a plausible reason for DNS-stage failures.
- Check the population. A domain-wide percentage cannot be assumed to describe one subdomain without host-specific evidence.
- Keep outcomes separate. Resolving a DNS or reporting problem does not demonstrate that a page will be indexed.
The figures here are case-specific measurements reported by Eugen Taranowski in 2026. They are useful for understanding the investigation, not for estimating how often Google encounters these problems across sites.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
