This test fails when the browser encounters JavaScript runtime errors as the page loads. Unhandled errors can break interactive features, leave content unrendered, and signal poor code quality, all of which hurt the user experience that search engines factor into rankings. Fixing this issue means identifying the offending script, reproducing the error in DevTools, and shipping a patch that handles the failure cleanly.

Where to make the change

• Open browser DevTools: the Console tab lists every error with the file, line number, and stack trace. Reproduce the issue locally and use sourcemaps to map back to the original code.
• Application code: wrap risky operations in try / catch, validate external data before using it, and provide fallbacks when DOM elements or APIs are missing.
• Third-party scripts: check whether the error originates in an analytics, advertising, or chat-widget script. If yes, contact the vendor or load the script with defer so it does not block the rest of the page.

Common causes and how to resolve them

• Calling a method on null or undefined: guard with optional chaining (?.) or check the value exists before calling.
• Race condition between the DOM and the script: wait for DOMContentLoaded or place the script tag at the end of <body> with defer.
• Missing or 404 script file: a typo in the src attribute or a deleted asset triggers a load error. Fix the path or remove the tag.
• Unsupported syntax in older browsers: if you support legacy browsers, transpile modern JavaScript with a tool such as Babel and serve appropriate polyfills.
• CORS error blocking a fetch: the API must include the correct Access-Control-Allow-Origin header. Either configure the API or proxy the request through your own backend.

Best practices

• Add error monitoring: a service such as Sentry, Bugsnag, or Datadog RUM captures errors from real users and groups them by frequency, so you fix what hurts most first.
• Fail loudly in development, gracefully in production: log unexpected errors but never let them break the rendered page. Show a fallback UI instead of a blank screen.
• Treat errors as bugs in the build: add lint rules and unit tests for the most common error paths so they cannot ship again.
• Defer non-critical scripts: using defer or async on third-party scripts limits the blast radius when one of them throws.

This test fails when images are served in legacy formats such as JPEG and PNG instead of modern alternatives like WebP or AVIF. Modern formats compress significantly better at equivalent visual quality, which means smaller transfers, faster page loads, and lower data usage for visitors on metered connections. Fixing this issue means generating modern variants and serving them to browsers that support them.

Example

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Marathon runners at sunrise" width="1600" height="900">
</picture>

Where to make the change

• Raw HTML: use the <picture> element with multiple <source> entries so the browser picks the best supported format.
• WordPress: WordPress 6.x and later supports WebP natively. Use a media optimization plugin to convert existing JPEGs and PNGs and serve modern formats automatically.
• Shopify: Shopify's image CDN can serve WebP automatically; using the image_url filter with format parameter or the image_tag helper handles negotiation.
• Wix or Squarespace: both platforms convert and serve WebP automatically when supported by the visitor's browser.
• Headless or framework sites: components like next/image and astro:assets generate AVIF and WebP variants at build time and serve the best format per request.

Common causes and how to resolve them

• Only legacy formats published: add a build step or image CDN that generates WebP and AVIF alongside the original.
• Single-format <img> tag: wrap the image in <picture> with <source> entries for AVIF and WebP, falling back to the JPEG.
• Image CDN not negotiating format: enable automatic format conversion or pass a format=auto query parameter (depends on provider).
• SVG used where a raster image would be smaller (or vice versa): illustrations and icons should be SVG; photos should be raster in a modern format. Mixing them up wastes bytes.

Best practices

• AVIF first, WebP fallback, JPEG last: AVIF compresses best, WebP is widely supported, JPEG remains the universal fallback.
• Match quality to use case: hero images can use higher quality settings; thumbnails can drop quality without visible loss.
• Use an image CDN: services like Cloudflare Images, Cloudinary, or Imgix handle resizing, format conversion, and caching in one step.

This test fails when JavaScript or CSS resources block the browser from rendering visible content. Each render-blocking file delays the first paint, and on slower networks the cumulative impact can be severe. Fixing this issue means inlining the truly critical CSS, deferring or asynchronously loading non-essential scripts, and removing unused code.

Example

<head>
  <!-- Inline only above-the-fold critical CSS -->
  <style>/* critical styles here */</style>

  <!-- Load full stylesheet asynchronously -->
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">

  <!-- Defer non-critical scripts -->
  <script src="/scripts/app.js" defer></script>
</head>

Where to make the change

• Application code or templates: identify the CSS and JavaScript needed for the initial render and load only those synchronously. Defer the rest.
• Build pipeline: use a critical CSS extractor (such as critical or penthouse) to generate the above-the-fold styles automatically.
• WordPress: performance plugins offer "delay JS execution" and "load CSS asynchronously" options that handle most of this without code changes.
• Headless or framework sites: use the framework's preload and code-splitting hints to control what blocks rendering.

Common causes and how to resolve them

• Single large stylesheet blocking render: inline critical CSS for the first viewport, load the full stylesheet asynchronously.
• Synchronous third-party scripts in the head: add defer or async, or move them to the end of the body.
• Web fonts blocking text rendering: add font-display: swap in @font-face rules so the fallback font shows immediately.
• Render-blocking @import in CSS: replace with separate <link rel="stylesheet"> tags so the browser can fetch them in parallel.

Best practices

• Use defer for scripts that need the DOM: they execute after parsing but before DOMContentLoaded.
• Use async for fully independent scripts: they execute as soon as they download, in any order.
• Preload the critical request chain: tell the browser early about fonts and key assets with <link rel="preload">.
• Audit with Lighthouse: the Render-blocking resources audit lists every offending file with the estimated time saved by deferring it.

The ads.txt file is a public list of the advertising vendors authorized to sell your inventory programmatically. A correctly formatted ads.txt protects against domain spoofing in the ad supply chain and is required for inclusion in many premium advertising marketplaces. Fixing this issue means publishing a valid ads.txt at the site root with current authorized seller entries.

Example

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
example-ssp.com, 12345, RESELLER
contact=ads@example.com

Where to make the change

• Raw HTML or static site: upload ads.txt to the site root so it is served at https://example.com/ads.txt.
• WordPress: use a small plugin or upload the file via FTP. Some advertising plugins manage it automatically based on connected accounts.
• Shopify: upload the file through the theme code editor as an asset, then expose it at the root via a route configuration.
• Cloudflare or similar CDN: serve ads.txt from a worker if you do not have file-system access at the origin.

Common causes and how to resolve them

• File missing: create one with at least your direct advertising relationships.
• File at the wrong path: ads.txt must be at the domain root, not in a subdirectory.
• Wrong relationship value: use DIRECT for direct seller relationships, RESELLER for authorized resellers. Other values are invalid.
• Stale entries: partners change; remove relationships you no longer have so spoofers cannot exploit them.
• Returning HTML instead of plain text: the file must be served as text/plain. A page that returns HTML or a 404 fails validation.

Best practices

• Audit quarterly: stale entries are the main source of ads.txt vulnerabilities.
• Mirror app-ads.txt for mobile inventory: apps use a parallel app-ads.txt file with the same syntax.
• Add a contact line: include a contact=email@example.com line so vendors can reach the right person about ad-quality issues.