Run and troubleshoot site-resource checks

Queue an immediate resource run and investigate stale or failed results.

Last checked 21 August 2026

Open the website and select Check now in Site Resources when you need fresh robots.txt, sitemap, llms.txt, and favicon observations. This is useful after a server correction, resource-file deployment, or unexpected incident.

The button first checks two prerequisites:

  • An active TechDash license
  • Working connectivity without a Wi-Fi sign-in page

If either check fails, TechDash shows a specific error. If both pass, the app says Site resources queued. and places the website in the single-worker Site resources queue. This confirms queueing, not completion.

Know what Check now runs

A manual resource run forces /robots.txt, the discovered XML sitemap walk, /llms.txt, /favicon.ico, and Custom Checks targeting robots.txt or sitemap XML. It evaluates related built-in checks when enough evidence is available.

It does not run monitored page checks, analytics detection, SSL, RDAP or WHOIS, DNS, Search Console, weekly screenshots, or displayed-icon enrichment.

Use an incident's Check & Verify for SSL, domain, or DNS because that action routes to the relevant lookup. Use a page row's Run now for analytics and other page-derived evidence.

Understand automatic timing

robots.txt is due hourly. Sitemap, llms.txt, and favicon are due daily. The scheduler reviews due resources every minute while monitoring is running and after the computer resumes.

A sitemap walk with saved unfinished work remains due. It can resume without waiting another full day, provided the enabled monitored-page set has not changed.

TechDash being closed, sleep, an offline network, a Wi-Fi sign-in page, an unavailable license, paused monitoring, or another website in Site resources can delay the start. Page checks use a separate queue.

Read results without mistaking skipped for fixed

The Site Resources rows show current observations. Sitewide Checks shows check results:

  • Good means a check passed or established its first successful baseline.
  • Advisory can mean a check was skipped because current evidence was unavailable or incomplete.
  • Warning and Critical identify failed checks whose evidence should be reviewed.

If robots.txt is unavailable, Robots.txt availability fails, while monitored-path and AI crawler policy evaluation is skipped. TechDash preserves any prior failure for Robots.txt blocks monitored URLs or AI crawler access removed. It cannot create a false recovery when the current policy is unreadable.

Sitemap behavior is similarly conservative. A failed or unfinished walk keeps the last complete, usable sitemap baseline. XML sitemap membership and Non-indexable URLs in sitemap are skipped until the complete tree is available. An old successful count on the card can therefore coexist with an unavailable or catching-up current walk.

Diagnose a row that does not update

  1. Confirm the website is not Paused.
  2. Inspect the Site resources lane in Queue Status.
  3. Keep the computer online and wait for the single worker to finish.
  4. Compare the updated rows with Sitewide Checks.

If the queue is empty but data remains old, reopen TechDash, then queue one manual run. If the button reports a license or connectivity error, resolve that error first.

Diagnose HTTP failures

Resource requests do not follow redirects. Serve robots.txt, sitemap files, and llms.txt directly at their expected URLs.

Other common results include:

  • 401 or 403: authentication, firewall, CDN, or bot policy
  • 404 or 410: wrong path or removed file
  • 429: rate limit
  • 5xx: origin or gateway failure
  • 0 (Failed): timeout or network-level error

Test the exact origin from the same computer. Check DNS, VPN, proxy, CDN, authentication, bot policy, and server logs.

Diagnose sitemap walks and retries

TechDash queues sitemap children, waits between files, and saves progress after each file. A failed child is retained for retry. If a prior complete walk exists, the displayed count stays on that successful baseline rather than changing to an incomplete partial count.

Membership and member validity are judged only after a complete walk. Until then, XML sitemap membership and Non-indexable URLs in sitemap are skipped as Advisory. Fix the failing child, then let the checkpoint resume.

Exactly 50,000 URLs in one sitemap file is permitted. More than 50,000 fails Sitemap limits exceeded, as does crossing 50 MB. For a URL-count failure, incident evidence includes the specific sitemap file URL and observed count. Large trees can also stop at the child-file boundary or job deadline. Split oversized files and remove dead or circular references.

After a complete walk, Non-indexable URLs in sitemap fails for monitored members that are noindex or outside 2xx and 304. Evidence lists each URL and reason. Fix the page or remove it from the sitemap if exclusion is intentional.

Read observations and incidents correctly

Incidents apply baseline and severity rules, so a visible non-200 row does not always mean a new incident. llms.txt absence stays quiet until a successful file has existed. A sitemap that has never been usable also stays quiet, while loss of a previously usable sitemap is a Warning.

Benign cases include an intentionally absent llms.txt, a reviewed robots.txt policy change, or a monitored account page intentionally excluded from a sitemap. Resolve or acknowledge only after confirming the evidence matches your policy.

After a correction, run one appropriate recheck. Confirm the row, queue completion, and related Sitewide Checks result. For analytics coverage, run the affected monitored pages because the percentage comes only from completed page snapshots.

Related articles