Broken images, stylesheets or scripts
broken_resourceShort answer
An image, CSS file or script referenced by your pages does not load (404/410, domain gone, or 5xx twice). Visitors see a broken image or a page without its styles; Googlebot renders pages with their CSS and JavaScript, so a missing file can change what Google indexes. Restore the file, point the page at its new address, or remove the reference.
Why it matters
Google renders pages like a browser; a stylesheet that 404s can hide content, shift layout (CLS) or make text invisible, and a missing script can leave content unrendered. A broken logo or hero image is visible to every visitor. Broken resources usually come from a theme update, a CDN change, or a plugin removed without cleaning its references.
How Glimana detects it
Resources seen in the last 30 days are checked; each broken resource is reported once, with the number of pages that reference it and a representative page, so one dead logo on 500 pages is one finding, not 500. If more than 20 resources on the same host fail at once, they are collapsed into a single "possible CDN or server outage" finding.
How to fix it
- Find the affected pages in Glimana. Open Issues › Broken images, stylesheets or scripts. This is a site-level check, so the single row carries the full evidence: the URLs, values or days involved. The task under Tasks shows the same list and the expected gain.
-
Apply the fix on your platform.
Open the evidence: it lists each broken URL, its status and how many pages use it.
404 under
wp-content/: the theme or plugin that owned the file was changed; update the reference in the theme'sfunctions.phpenqueue or in the page builder's global settings, or re-upload the file. Image 404s in content: re-upload and update the post, or run a search-and-replace for the old upload path.Assets under
cdn.shopify.comgo missing when a theme file is deleted; re-add it in the theme editor. External embeds (fonts, widgets) that fail: self-host or remove.Use fingerprinted asset URLs produced by your build so references cannot go stale; purge CDN caches after deploys.
-
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when they return 200 or are no longer referenced. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
The affected resources are re-fetched after you mark the task done; the task closes when they return 200 or are no longer referenced.