Interpret Google fetch, crawl-recency, and canonical incidents

Investigate URL Inspection findings using Google's stored evidence.

Last checked 21 August 2026

URL Inspection incidents use Google's stored index evidence, not a live Googlebot request or page test.

An incident can report an earlier Google crawl after TechDash shows the problem fixed. Start with the evidence date, then decide whether the finding is current, relevant, or benign old data.

Read the result before acting

Each check records a pass or fail result. A failure can open an incident at its assigned severity:

Google cannot fetch the page is Critical because access denial can prevent crawling and indexing.
Google hit server errors is a Warning because failures can interrupt crawling or remove URLs from the index.
Google crawling as desktop is Advisory and calls for a mobile-parity review.
Google chose a different canonical is a Warning because Google may consolidate indexing signals onto another URL.
Abnormal Google crawl staleness is a Warning because delay can indicate weaker discovery, access, or page value.

A pass means stored evidence did not meet the failure condition. It does not guarantee indexing, rankings, traffic, or live access.

Google cannot fetch the page

This critical incident opens when Google reports an access-denied or access-forbidden fetch for inspected URLs.

Check:

Whether the last crawl time predates a fix.
Current HTTP status and availability in TechDash.
robots.txt, CDN, WAF, authentication, geoblocking, and firewall rules.
Server logs around Google's last crawl time, verifying genuine Googlebot if possible.

A successful browser request does not disprove the incident because bot policies differ. If the denial is old and current checks are healthy, verify before changing rules.

Access denial takes precedence over server errors. If a successful inspection batch contains both access-denied or access-forbidden URLs and server or redirect errors, TechDash publishes Google cannot fetch the page, not Google hit server errors, for that batch. Investigate denied rows first. A later batch without them can expose a remaining server-error incident.

Google hit server errors

This warning covers server and redirect errors: 5xx responses, redirect loops, invalid destinations, intermittent origin failures, and CDN-to-origin errors.

Compare the last crawl time with server logs. An error before deployment or outage recovery may now be benign.

Google crawling as desktop

This advisory prompts a mobile-parity review. It is not proof of a ranking problem.

Compare mobile and desktop content, links, structured data, canonical tags, robots directives, and status codes. Check the evidence date and any unusual mobile handling.

Google chose a different canonical

This warning means Google's selected canonical differs from the canonical declared for the page.

Incident evidence includes the checked URL, on-page canonical, and Google-selected canonical. Review duplication, internal links, sitemap entries, redirects, raw and rendered canonical tags, hreflang, structured-data URLs, and whether the intended canonical is indexable.

Google is allowed to choose a different canonical. The practical repercussion is that indexing and ranking signals may be consolidated onto Google's choice. The incident means your signals and Google's selection disagree, not that Google ignored a guaranteed directive.

Abnormal Google crawl staleness

This warning is relative to each URL's own history. TechDash requires at least three unique, valid prior crawl times that occurred before the latest reported crawl. It sorts those times, calculates the gaps between consecutive crawls, then uses the conventional median gap. With an even number of gaps, the median is the average of the two middle values.

The typical gap has a one-day minimum. The check fails only when the age of the latest Google crawl is strictly greater than three times that typical gap. An age exactly equal to three times the gap still passes.

A page that is normally crawled every two days can alert sooner than a page normally crawled monthly. Check internal links, sitemap membership, indexability, content value, server reliability, and whether Google has consolidated the URL elsewhere.

Last-crawl time does not guarantee indexing, ranking, or freshness. A slower cadence can be normal. Look for falling impressions, removal from the index, weaker links, or access changes before assuming a technical fix is needed.

Work with incident evidence

Open Incidents and review the affected URLs, result, severity, and evidence.
Compare the inspection request time and Google's last crawl time with TechDash's latest result.
Confirm current behavior with Search Console URL Inspection and its live test where available.
If old evidence is now benign, avoid speculative changes and record why.
If the problem remains, fix the relevant access, server, canonical, mobile, or discovery issue. Request validation or recrawling where available.
Keep TechDash running. Verify that current behavior is healthy and a later stored inspection passes or shows updated evidence.

Quota, authorization, rate-limit, and network failures do not become these SEO incidents. A URL without a successful inspection is omitted rather than failed. Missing new evidence is therefore different from evidence that Google could not fetch a page.