CrawlCue – Broken Link & Image Auditor

No. Scans only run while an administrator explicitly starts or resumes one. The "audit overdue" message is calculated from the saved last-scan timestamp when an administrator views WordPress.

Yes. The crawler requests the rendered front-end HTML, so links and images output by Elementor, themes, menus, widgets, shortcodes, WooCommerce, and similar front-end systems can be discovered when they appear in the resulting HTML.

Yes. External URLs are checked with WordPress's safe HTTP functions. Each unique URL is checked once per audit and that result is reused for every occurrence found on the site. A check normally uses HEAD; when HEAD is unsuccessful, CrawlCue may make one small GET fallback before classifying the URL.

Open Details (or View all for grouped results). CrawlCue shows the rendered HTML attribute that exposed the URL, such as img[src], img[srcset], img[data-src], source[srcset], or a[href], plus a compact element locator and an expandable HTML clue. Hidden widgets, responsive/lazy markup, shared headers or footers, shortcode output, and page-builder templates can contain URLs that are not visibly displayed on the page. The clue identifies the rendered markup CrawlCue received from the front end. It may not identify the original PHP, shortcode, widget, or page-builder template that generated that markup.

Some sites, CDNs, firewalls, social networks, certificate chains, or anti-bot services respond differently to a WordPress server than they do to a visitor's browser. CrawlCue therefore treats most non-success responses as inconclusive unless the response strongly establishes that the resource is gone. HTTP 404 and 410 are confirmed broken; responses such as 403, 429, custom/non-standard 4xx codes, 5xx codes, timeouts, DNS failures, and TLS/SSL verification failures are shown under Needs Review instead. CrawlCue also retries a failed HEAD check with a small, browser-compatible GET request before classifying the URL, because some healthy sites do not handle HEAD requests the same way as normal page requests. The compatibility request still identifies itself as CrawlCue and does not solve JavaScript challenges, bypass CAPTCHAs, or use session-cookie tricks. If you open an inconclusive URL yourself and confirm that it works, use Mark as Working. CrawlCue stores that manual verification separately from Ignore and remembers it on future scans when the automated check remains inconclusive. A later confirmed failure such as HTTP 404 or 410 overrides the old manual verification.

Recheck preserves that workflow. It first checks whether the representative source page still contains the saved URL. If the reference was removed, CrawlCue verifies the other grouped source pages in small batches and clears the removed occurrences. If the reference is still present, CrawlCue retests the destination once and updates the whole group.

Version 1.0 focuses on HTML image sources (img src, srcset, and picture/source) and hyperlinks. External stylesheets and CSS background-image crawling are not included in the first release.