Understand the Site Resources card

Read robots.txt, sitemap, llms.txt, favicon, and analytics status for one website.

Last checked 21 August 2026

The Site Resources card summarizes files and analytics coverage that apply across one website. Use it to see the latest observations and to queue a refresh. It is not the complete check report. Open Sitewide Checks for Good, Advisory, Warning, or Critical results and incident evidence.

Read each row

  • robots.txt shows the latest HTTP observation for /robots.txt. TechDash checks it hourly. A usable response is 2xx or 304; redirects are not followed.
  • Sitemap URLs shows the URL count from the last complete, usable sitemap baseline. TechDash starts from absolute Sitemap: declarations in the stored robots.txt text, or /sitemap.xml when none exist, then walks indexes and child files.
  • llms.txt shows the latest daily HTTP status for /llms.txt. A site that never published this experimental file does not fail merely because it is absent.
  • favicon.ico shows the latest daily HTTP status for /favicon.ico. This observation is separate from the website icon displayed elsewhere.
  • Analytics lists supported packages detected in stored snapshots for checked, enabled monitored pages. Each nested row gives that package's percentage coverage within those pages.

Before data exists, a row says Not checked yet. File rows can show labels such as 200 (OK), 301 (Redirect), 404 (Missing), 429 (Too many requests), or 0 (Failed). Sitemap URLs includes the unit, such as 1 URL or 118 URLs.

If checked pages contain no supported package, the card says No supported analytics detected. That is not proof that the whole website lacks analytics.

Distinguish observations from check results

The row is the latest observation. Sitewide Checks explains whether TechDash could safely evaluate that observation:

  • Good means a check passed or stored its first baseline. It does not always mean the resource returned 200. For example, a never-detected sitemap can remain quiet because no successful baseline exists.
  • Advisory can mean evaluation was skipped because required current evidence was unavailable or incomplete. A skipped result must not be read as a pass.
  • Warning or Critical means an actionable comparison failed. Open the incident for Expected, Current, affected URLs, crawler names, file locations, or before-and-after evidence.

An unavailable robots.txt fetch fails Robots.txt availability, but TechDash skips current policy evaluation for Robots.txt blocks monitored URLs and AI crawler access removed. If either policy check was already failing, TechDash preserves that failure instead of replacing it with Advisory or Good. This prevents a network error from creating a false recovery. The visible robots.txt row can therefore show an unavailable status while a prior blocking incident remains open.

A partial or failed sitemap walk also does not erase the last complete, usable sitemap count. The successful sitemap baseline is sticky. XML sitemap membership and Non-indexable URLs in sitemap are skipped until the walk is complete, so missing or invalid members are not inferred from a partial tree.

Understand timing and run a check

robots.txt is due hourly. Sitemaps, /llms.txt, and /favicon.ico are due daily. The scheduler reviews due work every minute while monitoring is running, but sleep, offline status, a Wi-Fi sign-in page, an unavailable license, paused monitoring, or queue pressure can delay the start. Analytics updates only when normal page checks finish.

Select Check now to validate connectivity and the license, then queue a full resource run. Site resources queued. confirms queueing, not completion. The single-worker Site resources queue fetches robots.txt, sitemaps, llms.txt, and favicon.ico, runs resource Custom Checks, and resumes eligible sitemap work. It does not run page checks, SSL, DNS, domain, Search Console, or analytics detection.

Act and verify

For benign changes, such as an intentional robots.txt edit, planned AI crawler restriction, deliberately absent llms.txt, or analytics exclusions on account pages, review the evidence and document the policy before resolving an incident. For unexpected failures, restore direct public access, correct the file or page state, then run the appropriate recheck.

Verification requires both layers: confirm the row has the expected current observation, then confirm the related result in Sitewide Checks. For analytics, rerun the affected monitored pages instead of selecting Check now.

Related articles