Fix Structured Data Warnings in Search Console

JSON-LD warnings in Search Console — usually a missing recommended field, the wrong @type, a bad date, or a relative image URL. Here's the field-by-field fix.

Search Console’s structured-data reports flag warnings like Missing field "image", Invalid value in field "datePublished", or Either "author" or "publisher" must be specified. These almost never block indexing, but they do cost you rich results — no author byline, no review stars, no product price chip. On pages that would otherwise win an enhanced listing, that’s usually a 10-30% CTR hit.

Fastest fix: open the Rich Results Test, paste the live URL, and read the exact field name it flags. Then fix that one field at the source (your JSON-LD generator), redeploy, and click Validate fix in Search Console. Nine times out of ten the warning is one of: a relative image URL, a date without a timezone, author written as a bare string, or two conflicting @type values on one page.

One thing that changed in 2026: Google no longer lists any property as strictly “required” for Article — it now calls them all “recommended” (docs updated 2025-12-10). But you still won’t qualify for the Article rich result without headline, image, and datePublished, so treat those three as required in practice.

Which bucket are you in?

Warning text (Rich Results Test / Search Console)Most likely causeJump to
Missing field "image" or "author"Field absent, or present but emptyMissing field
Invalid value in field "datePublished"Wrong date format, or no timezoneDate format
Datetime ... is missing a timezoneDate is valid but has no offset (a notice, not a hard error)Date format
Missing field "priceCurrency" (Product)priceCurrency not at the offer levelMissing field
Parsing error / Unparsable structured dataTrailing comma or broken JSONSyntax
Two types detected, conflictArticle + BlogPosting on one pageWrong type
Image flagged as too small / not crawlableURL is relative, blocked, or under size limitsImage

Common causes

Google dropped the word “required” for Article in late 2025, but the rich result still needs certain fields. Here’s what each type needs in practice, as of June 2026:

TypeNeeded for the rich resultMost often omitted
Article / BlogPostingheadline, image, datePublished, authorimage, author
Product (merchant listing)name, image, offers with price + priceCurrency + availabilityoffers.priceCurrency
Recipename, image, recipeIngredient, recipeInstructionsrecipeInstructions
Eventname, startDate, locationlocation shape
FAQPagemainEntity[], each with name + acceptedAnswer.textsee note below

FAQPage note (important, 2026): Google deprecated the FAQ rich result — it stopped showing the expandable FAQ dropdown in Search on May 7, 2026, and the FAQ report plus Rich Results Test support are being removed in June 2026 (the Search Console API drops it in August 2026). Valid FAQPage markup still won’t error, and there’s no need to rip it out, but a warning on acceptedAnswer.text no longer affects any visible rich result. Don’t spend time chasing FAQ warnings; spend it on Article and Product.

How to confirm a missing field: the Rich Results Test prints every detected field and names the missing one exactly. Red = required-for-eligibility field absent or invalid; yellow = recommended field missing (page still qualifies).

2. Wrong type

Article is the base type; BlogPosting is for blog posts; NewsArticle is for news content eligible for Google News. Declaring two of them on the same page makes Google pick one and can produce a conflict warning. Rule of thumb:

  • News publisher pursuing Google News → NewsArticle
  • Personal or company blog post → BlogPosting
  • General technical guide / documentation → Article

Pick one and emit exactly one @type per page.

3. Date format

Google wants ISO 8601. Note the corrected last line — a missing timezone is a notice, not a hard failure:

"datePublished": "2026-05-21T10:00:00Z"      // best: with timezone (Z = UTC)
"datePublished": "2026-05-21T10:00:00+08:00" // best: explicit offset
"datePublished": "2026-05-21"                 // valid: date only
"datePublished": "2026/05/21"                 // invalid: slashes
"datePublished": "May 21, 2026"               // invalid: human text
"datePublished": "2026-05-21T10:00:00"        // warning: no timezone

For the last case, Google’s docs say it will default to Googlebot’s timezone if you omit the offset, so it won’t break the rich result — but the byline date can shift by a few hours from what you intended. The fix is to always emit the offset. new Date(...).toISOString() always appends Z, which solves this for free.

4. image field format

image can be a URL or an ImageObject. Either way it must be absolute (full https://...), crawlable (not blocked by robots.txt), and large enough.

// Simple string form (accepted for Article)
"image": "https://yourdomain.com/cover.jpg"

// Full recommended form
"image": {
  "@type": "ImageObject",
  "url": "https://yourdomain.com/cover.jpg",
  "width": 1200,
  "height": 630
}

Size rules, as of June 2026:

  • Article images: width times height must be at least 50,000 pixels (e.g. 1200x630 is fine). Aspect ratios Google prefers: 16x9, 4x3, 1x1.
  • Product images: Google raised the minimum to 500x500 pixels — warnings began April 14, 2026 and become hard enforcement January 31, 2027. Ship product images at 500×500 or larger now.

A relative URL like /cover.jpg is the single most common image warning. It must start with https://.

5. author as a bare string

// Warning-prone
"author": "Jane Doe"

// Recommended
"author": {
  "@type": "Person",
  "name": "Jane Doe",
  "url": "https://yourdomain.com/about"
}

Put only the name in author.name — no job title, no “by”, no publisher name mixed in. The author.url should point to a page that uniquely identifies that author (an about/bio page), which Google now uses to attribute authorship.

6. JSON-LD syntax errors

JSON-LD must be valid JSON. A single trailing comma invalidates the whole block, and Search Console reports it under the Unparsable structured data report. The Schema.org validator and Rich Results Test both surface it as Parsing error. Common culprits: trailing commas, smart/curly quotes pasted from a doc, and unescaped quotes inside a string.

Shortest path to fix

Step 1: Get the exact error from the Rich Results Test

https://search.google.com/test/rich-results

Paste the live URL (or use Test code to paste raw JSON-LD). You’ll see:

  • which schema types were detected,
  • each field’s parsed value,
  • red items = required-for-eligibility field missing or invalid,
  • yellow items = recommended field missing (still eligible).

Write down the flagged field name verbatim — that’s what you fix.

Step 2: Cross-reference Schema.org and Google’s docs

For an Article image warning, check both:

https://schema.org/Article                                                     (Schema.org definition)
https://developers.google.com/search/docs/appearance/structured-data/article   (Google's extra requirements)

Schema.org tells you the field exists and its expected type; Google’s page tells you whether it’s needed for the rich result and any size/format constraints. They don’t always agree, and Google’s rules are the ones Search Console enforces.

Step 3: Generate JSON-LD from one helper

Hand-written JSON-LD is where warnings come from. Generate it from a single function so every page is consistent:

// src/lib/jsonld.js
export function articleJsonLd({ title, slug, image, publishedAt, modifiedAt, author }) {
  const url = `https://yourdomain.com/articles/${slug}/`;
  return {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "image": {
      "@type": "ImageObject",
      "url": image.startsWith("http") ? image : `https://yourdomain.com${image}`,
      "width": 1200,
      "height": 630
    },
    "datePublished": new Date(publishedAt).toISOString(),
    "dateModified": new Date(modifiedAt || publishedAt).toISOString(),
    "author": {
      "@type": "Person",
      "name": author?.name || "AI Productivity Guide Team",
      "url": author?.url || "https://yourdomain.com/about"
    },
    "publisher": {
      "@type": "Organization",
      "name": "Your Site",
      "logo": {
        "@type": "ImageObject",
        "url": "https://yourdomain.com/logo.png",
        "width": 600,
        "height": 60
      }
    },
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": url
    }
  };
}

This kills the three most common warnings at once: the image.startsWith("http") guard forces an absolute URL, new Date(...).toISOString() forces ISO 8601 with a Z offset, and author is always an object with a url.

In the layout, emit it as a script tag (note set:html so Astro doesn’t escape the JSON):

---
import { articleJsonLd } from "../lib/jsonld.js";
const ld = articleJsonLd(Astro.props);
---
<script type="application/ld+json" set:html={JSON.stringify(ld)} />

Step 4: Add CI validation so it never regresses

Parse every built page’s JSON-LD and fail the build on missing fields or broken JSON:

// scripts/check-jsonld.mjs
import fg from "fast-glob";
import fs from "node:fs";

const issues = [];
for (const f of fg.sync("dist/**/*.html")) {
  const html = fs.readFileSync(f, "utf8");
  const blocks = [...html.matchAll(/<script[^>]+ld\+json[^>]*>([\s\S]+?)<\/script>/g)];
  if (blocks.length === 0) { issues.push(`NO JSON-LD: ${f}`); continue; }
  for (const [, body] of blocks) {
    try {
      const data = JSON.parse(body);
      if (!data["@type"]) issues.push(`MISSING @type: ${f}`);
      if (data["@type"] === "BlogPosting") {
        if (!data.headline) issues.push(`MISSING headline: ${f}`);
        if (!data.image) issues.push(`MISSING image: ${f}`);
        if (!data.datePublished) issues.push(`MISSING datePublished: ${f}`);
        if (!data.author) issues.push(`MISSING author: ${f}`);
      }
    } catch (e) {
      issues.push(`INVALID JSON: ${f} -- ${e.message}`);
    }
  }
}
if (issues.length) { console.error(issues.join("\n")); process.exit(1); }

This catches the regression before it ever reaches Google. For schema correctness beyond presence checks, the schema-dts types or a Schema.org validator API call can be layered on top.

Step 5: Validate fix in Search Console after deploy

Open the specific structured-data report under Enhancements in the left sidebar (it appears automatically once Google detects that type on your site), then click Validate fix. Google checks a sample immediately; if the field is fixed it starts a re-evaluation that typically takes 7-14 days to clear all affected URLs. If the sample still fails, validation stops and you’ll see why.

To speed up the most important pages, open URL Inspection for 5-10 top URLs and click Request indexing — that re-crawls and re-parses the JSON-LD sooner than waiting for the routine recrawl.

How to confirm it’s fixed

  1. Rich Results Test on the live URL → the previously flagged field now shows a value and no red item remains. This is the source of truth; if it’s green here, your markup is correct.
  2. URL Inspection → Test live URL → View tested page → More info → Structured data shows the fields Googlebot actually parsed on the live page (catches cases where JS injects the JSON-LD too late).
  3. Search Console enhancement report moves the URL from “Invalid” to “Valid” after the recrawl (the 7-14 day window). The Rich Results Test passing first is normal — the report lags the crawl.

If the Rich Results Test is green but Search Console still shows the warning after two weeks, request indexing on those URLs; the report is almost always just stale, not wrong.

FAQ

Do structured-data warnings hurt my rankings? No. They don’t affect crawling, indexing, or ranking. They only gate eligibility for rich results (stars, byline, price chip). The cost is lost CTR on pages that would otherwise get an enhanced listing, not lost rankings.

The Rich Results Test passes but Search Console still shows the warning. Why? The report reflects Google’s last crawl, not your latest deploy. Once the Rich Results Test on the live URL is green, the fix is in place; the report catches up after the recrawl (often 7-14 days). Use Request indexing on key URLs to nudge it.

Are FAQ schema warnings worth fixing in 2026? No. Google deprecated FAQ rich results — they stopped appearing in Search on May 7, 2026, and the FAQ report and Rich Results Test support are removed in June 2026. Existing FAQPage markup is harmless to leave in place, but fixing FAQ-only warnings won’t restore any rich result. Prioritize Article and Product.

Is a date without a timezone actually broken? Not broken — it’s a warning. Google defaults to Googlebot’s timezone when the offset is missing, so the rich result still works, but your byline date can drift a few hours. Emit ISO 8601 with an offset (new Date(x).toISOString() gives you a Z) and the warning goes away.

My image URL looks fine but still warns. What’s wrong? Three usual reasons: it’s relative (must start with https://), it’s blocked by robots.txt or returns a non-200, or it’s below the size floor (50,000 px for Article; 500×500 for Product as of April 2026). Open the image URL directly in a browser and confirm it loads and is large enough.

Where did the “required field” wording go for Article? Google’s Article docs (updated 2025-12-10) now say there are no strictly required properties, only recommended ones. In practice you still need headline, image, and datePublished to win the Article rich result, so treat them as required even though the docs soften the language.

Prevention

  • Generate all JSON-LD from one helper — never hand-write it per page.
  • One @type per page; never Article + BlogPosting together.
  • Dates always via new Date(...).toISOString() — no string concatenation, always a timezone.
  • Every URL field (image.url, author.url, publisher logo) absolute with https://.
  • Run the Rich Results Test before merging any schema change; require green.
  • CI parses every page’s JSON-LD and fails the build on missing required fields.

Tags: #SEO #Google #Search Console #Indexing