Console errors include any unhandled JavaScript exceptions, network request failures, security warnings, or deprecation notices the browser emits while loading the page. Fixing this issue means resolving the underlying problem each error reports rather than suppressing the message. Even errors that do not visibly break the page can degrade performance, leak data, or trip Core Web Vitals.

Where to make the change

• Open DevTools, Console tab: expand each entry to see the file, line, and stack trace. Right-click an entry to filter, save, or jump to the source.
• Application code: patch the offending script (see js-errors). For network failures, fix the failing endpoint or remove the stale request.
• Third-party tags: if the error originates in an analytics, ad, or widget script, update the snippet, switch to the vendor's current loader, or remove unused tags.

Common causes and how to resolve them

• JavaScript runtime errors: see the JS Error Test fix; the same approach applies.
• Failed network requests (404 or 5xx): remove the dead request or fix the endpoint. Stale tracking pixels and removed assets are common culprits.
• Mixed content warnings: the page is HTTPS but loads an HTTP resource. Update the resource URL to https://.
• CORS or CSP violations: tighten or expand the policy as appropriate. CSP errors usually require allowlisting the offending origin in the response header.
• Deprecation warnings: update the call site to use the recommended API. These do not break the page today but will when the deprecation cycle completes.

Best practices

• Treat the console as a build artifact: a clean console is a sign of a healthy page. Aim for zero errors and zero warnings on production routes.
• Use error monitoring in production: real users hit edge cases your local environment will never reproduce. A monitoring service surfaces them with frequency data.
• Defer or remove unused third-party scripts: every removed script is one fewer source of console noise.

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.

Structured data is a standardized way to label the entities and relationships on a page so search engines and AI answer engines can understand them. Adding the right schema helps unlock rich result features in SERPs (star ratings, FAQs, product cards, recipes, events) and gives AI answer engines precise facts to extract when generating responses. Fixing this issue means picking the schema types that match your content and embedding them as JSON-LD inside the page <head>. See the Google Search Central structured data guide for the full type catalog.

Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose marathon running shoes",
  "author": { "@type": "Person", "name": "Jane Doe" },
  "datePublished": "2026-04-15",
  "image": "https://example.com/images/hero.jpg"
}
</script>

Where to make the change

• Raw HTML: embed a JSON-LD block inside the <head>. JSON-LD is Google's preferred format because it does not interleave with visible content.
• WordPress: a dedicated SEO plugin generates JSON-LD for articles, products, breadcrumbs, and FAQ blocks automatically. Customize the templates for non-standard content.
• Shopify: Shopify themes emit Product schema by default. Extend with custom types via theme code edits.
• Wix or Squarespace: built-in blocks for FAQ, recipe, and event content emit schema automatically.
• Headless or framework sites: generate JSON-LD from your content data in the layout component so every page ships consistent schema.

Common causes and how to resolve them

• No structured data at all: add at minimum the @type that matches the page (Article for blog posts, Product for product pages, Organization for the homepage).
• Wrong schema type for the content: using Product schema on an article page misleads search engines. Pick the type that matches what the page actually is.
• Required properties missing: each schema type has required fields. Validate with the Rich Results Test to surface missing properties.
• Markup does not match visible content: Google penalizes structured data that asserts facts the page does not show. Reflect what is actually on the page.
• Multiple conflicting blocks: a theme and an SEO plugin both emit schema for the same entity. Pick one source of truth.

Best practices

• Validate before shipping: Google's Rich Results Test and Schema Markup Validator catch syntax errors and missing required fields.
• Use JSON-LD: easier to maintain than Microdata or RDFa and Google's preferred format.
• Cover the obvious wins: Article, Product, BreadcrumbList, Organization, and FAQPage are the highest-impact types for most sites.
• Keep schema accurate: wrong or exaggerated schema can lead to Google removing rich result eligibility for the entire site.

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.