Page Objects Test
What is it?
Every page requests a set of resources alongside its HTML: images, scripts, stylesheets, fonts, and embedded media. When any of those requests fails, the page renders incorrectly, the console fills with errors, bandwidth is wasted on doomed responses, and the perception of quality that both users and search engines form on load takes a hit. This test verifies that every resource requested by the page you submit can be successfully retrieved, and reports the ones that fail.
Why broken resources hurt SEO and UX
A page that requests a 404 image still spends time waiting for the response and still displays the broken-image icon to the user. A missing stylesheet leaves the page unstyled until either the request times out or the browser gives up. A failed script can break interactive features that the rest of the page depends on. Every broken request is a small visible failure that erodes user trust, and the cumulative effect of many small failures pushes users back to the search results page.
Search engines crawl pages much like real browsers and notice the same failures. While a single broken image rarely affects ranking on its own, a pattern of broken assets across a site is a quality signal that contributes to overall trust and authority. Pages that consistently load every resource cleanly look better-maintained to both users and crawlers.
Common causes of broken resources
- Asset renamed or deleted without updating the references in templates and content.
- Stale references after a redesign, where leftover script or stylesheet tags still point at old paths.
- CORS or hot-link protection blocking external resources that used to be reachable.
- Mixed-content blocking on HTTPS pages, where a sub-resource still uses HTTP.
- CDN cache miss for a deleted file, where a purge is needed after replacement.
This test reports every resource on your page that fails to load. The fix guide below walks through diagnosing failed requests in browser DevTools, common causes of each failure type, and how to add a build-time link check or scheduled monitoring so future regressions are caught before users see them.
Pass rate:
-
Top 100 websites: 7%This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 11%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | N/A |
|---|---|
| 2022 | 6% |
| 2023 | 2% |
| 2024 | 7% |
100
75
50
25
0
How do I fix it?
This test fails when one or more resources requested by the page (images, scripts, stylesheets, fonts, or media) cannot be retrieved. Broken assets leave the page rendered incorrectly, trigger console errors, and damage how search engines perceive page quality. Fixing this issue means finding the failing requests and either restoring, removing, or correcting their URLs.
Where to make the change
- Open DevTools, Network tab: reload the page and filter by status to surface every 4xx and 5xx response. The Initiator column tells you which file requested the broken resource.
- Application code or templates: update the resource path, fix the file name, or remove the reference if the asset is no longer needed.
- CDN and storage: verify the file is published to the expected location and that the path is publicly readable.
Common causes and how to resolve them
- 404 on an asset that was renamed or deleted: update the reference to point at the new path or restore the file.
- Stale references after a redesign: a leftover script or stylesheet tag still points at an old build. Remove the obsolete tag.
- CORS or hot-link protection blocking external resources: host the asset yourself or configure the third-party server to allow your origin.
- Mixed-content blocking: on an HTTPS page, an HTTP resource is blocked silently in modern browsers. Update the URL to
https://. - CDN cache miss for a deleted file: purge the CDN cache after removing or replacing assets.
Best practices
- Run a build-time link check: tools such as html-validate or a custom CI step can catch broken asset references before they ship.
- Self-host critical assets: hosting your own JavaScript and CSS removes a class of third-party outages.
- Monitor with synthetic checks: a scheduled check that loads the homepage in a real browser flags broken assets even when no user reports them.
