Google's MathSolver JSON-LD validator is stricter than schema.org. I learned that the hard way over 4 rounds of fixes.

Chetan Sanghani — Thu, 02 Jul 2026 16:10:46 +0000

Last week, Google Search Console flagged 10 pages on my Indian tax calculator suite with structured-data errors:

Missing field usageInfo — 10 items
Invalid value in field itemtype — 10 items

The pages all had MathSolver JSON-LD blocks. I had 38 similar blocks across the site. The natural assumption: I made a schema mistake once, and it propagated to all 38 tools.

Four commits and 76 files later, I discovered the real problem — and it wasn't a schema mistake at all.

Here's the full journey, with commit hashes, so you can skip the six hours I spent.

Setup: what the schema looked like

For context, SmartTaxCalc.in is a suite of 38 free Indian tax calculators (HRA, Advance Tax, NRI residency, DTAA, RSU vesting, etc.). Every tool page had a MathSolver JSON-LD block that looked roughly like this:

{
  "@context": "https://schema.org",
  "@type": "MathSolver",
  "name": "Fixed Deposit (FD) Calculator",
  "url": "https://smarttaxcalc.in/tools/fd-calculator/",
  "mathExpression": "maturity = principal * (1 + rate/(4*100))^(4*tenure_years)",
  "isAccessibleForFree": true,
  "inLanguage": "en-IN",
  "mainEntityOfPage": "https://smarttaxcalc.in/tools/fd-calculator/",
  "publisher": {
    "@type": "Organization",
    "name": "SmartTaxCalc",
    "url": "https://smarttaxcalc.in"
  },
  "reviewedBy": {
    "@type": "Person",
    "name": "CA Ankitkumar Italiya",
    "identifier": "ICAI:644575",
    "url": "https://smarttaxcalc.in/reviewer/ankitkumar-italiya/"
  },
  "citation": {
    "@type": "Legislation",
    "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
    "legislationJurisdiction": {
      "@type": "Country",
      "name": "India"
    }
  },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Applicable Regime", "value": "Both regimes" },
    { "@type": "PropertyValue", "name": "Applicable AYs", "value": "All AYs" }
  ]
}

Every field maps to a valid schema.org property. citation on CreativeWork (which MathSolver inherits from) legitimately accepts Legislation or CreativeWork. additionalProperty is PropertyValue. spatialCoverage/legislationJurisdiction on Country — all valid per schema.org's own docs.

But Google's validator disagreed.

Round 1: Fix the obvious (commit `32d1a24`)

Hypothesis: The GSC error strings gave me two things to fix.

For "Missing field usageInfo" — Google's MathSolver docs mark usageInfo as required. I hadn't included it. Easy fix:

+  "usageInfo": "https://smarttaxcalc.in/methodology/",

For "Invalid value in field itemtype" — I assumed the citation.@type: Legislation was the problem. Legislation is more specific than CreativeWork; maybe Google's rich-result validator only accepts the broader type in citation slots.

   "citation": {
-    "@type": "Legislation",
+    "@type": "CreativeWork",
     "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
-    "legislationJurisdiction": {
+    "spatialCoverage": {
       "@type": "Country",
       "name": "India"
     }
   }

Applied to all 38 razor files + 38 static HTML mirrors. 76 files, one commit. Deployed. Rich Results Test result: still "1 invalid item detected."

Reasonable step, wrong root cause. Time to peel the next layer.

Round 2: Strip the "obviously invalid on MathSolver" properties (commit `6311067`)

Second hypothesis: some of the fields I kept aren't valid on MathSolver at all, even though they were valid schema.org somewhere.

additionalProperty — checking schema.org more carefully — is defined on Place, Product, QualitativeValue, QuantitativeValue, and StatisticalPopulation. Not CreativeWork. So MathSolver (which extends CreativeWork) shouldn't have additionalProperty even if I want it there.

citation.spatialCoverage: Country — the Country subtype felt exotic; Google's stricter validator might reject it in favor of the plain Place type.

-  "additionalProperty": [
-    { "@type": "PropertyValue", "name": "Applicable Regime", "value": "Both regimes" },
-    { "@type": "PropertyValue", "name": "Applicable AYs", "value": "All AYs" }
-  ]

   "citation": {
     "@type": "CreativeWork",
     "name": "...",
-    "spatialCoverage": {
-      "@type": "Country",
-      "name": "India"
-    }
   }

76 files again. Deploy. Rich Results Test result: still "1 invalid item detected."

At this point I was staring at a MathSolver block with only publisher.Organization, reviewedBy.Person, and citation.CreativeWork as nested types. The same page had a WebApplication block validating fine with Organization + Offer nested. So Organization/Person clearly weren't the problem.

By elimination, the offender had to be CreativeWork in citation. Or the MathSolver @type itself. But I hadn't proven the latter yet.

Round 3: Make citation a plain text string (commit `e642939`)

Third hypothesis: any nested @type at all inside MathSolver's citation gets rejected. schema.org allows citation to accept Text OR CreativeWork — switching to Text kills the last nested @type without losing information.

-  "citation": {
-    "@type": "CreativeWork",
-    "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
-    "alternateName": "..."
-  }
+  "citation": "Section 80C and Section 194A of the Income Tax Act, 1961"

Deploy. Rich Results Test. Same error. "Invalid value in field itemtype."

Now the parsed MathSolver had only publisher.Organization + reviewedBy.Person as nested types — both of which validated fine on the same page's WebApplication block, and both of which are standard CreativeWork-inherited properties.

If a completely spec-clean MathSolver with only unambiguous nested types still fails validation, the problem isn't the schema. It's the MathSolver type itself in this context.

Round 4: Remove MathSolver entirely (commit `64a86db`)

I re-read Google's MathSolver documentation with fresh eyes. The doc opens with:

"Math solver structured data helps users find math solver services in Google Search results."

And later:

"Math solvers help users solve math problems by generating step-by-step solutions..."

Google MathSolver is a feature-gated schema. It's for Wolfram Alpha, Photomath, Symbolab — educational platforms that solve math problems.

A tax calculator suite is not a math solver, no matter how many equations we run.

Google's validator wasn't rejecting a specific field. It was rejecting the eligibility of the entire schema for our use case. The "Invalid value in field itemtype" error was Google's way of saying "this schema doesn't apply here, please stop." I was fighting a feature gate, not a validation bug.

Removed the MathSolver block from all 38 tool razors and 38 static mirrors. 1,861 lines deleted across 76 files.

Rich Results Test result: 0 MathSolver items detected. No error. WebApplication + BreadcrumbList + HowTo all still valid, still eligible for their respective rich results.

The GSC error will clear as Google re-crawls the pages over the next 3-7 days.

The lesson that would have saved me 6 hours

Read the target audience paragraph of any Google structured-data doc before rolling it out at scale.

Google's structured-data docs almost always open with a "who this is for" statement. For MathSolver:

"Math solver structured data helps users find math solver services in Google Search results."

Not "math-related content." Not "sites that display formulas." Math solver services.

I skipped that sentence because I was building tax calculators — of course they involve math. Six hours later I learned that Google's definition of "math solver" is narrower than mine, and its validator enforces the definition rigidly.

Two practical takeaways

1. Feature-gated schemas exist. Detect them early.

Not every schema Google documents is available to every publisher. MathSolver, EmployerAggregateRating, JobPosting, DatasetProperty — these get feature-gated to specific verticals. Even a valid schema fails validation if you're the wrong publisher.

Look for these signals BEFORE implementing:

Docs open with "helps users find [specific type of service]"
Named examples in the docs are all one narrow vertical
Google's rich result gallery for that type shows only 3-5 major players

If any of those signal apply, validate ONE page in Rich Results Test before rolling out the schema to your entire site.

2. "Invalid value in field itemtype" is Google's catch-all rejection.

The error name suggests something specific — a particular @type value in a particular slot. In practice, Google throws this error whenever anything about your schema doesn't match its narrower-than-schema.org expectation.

If you see this error and you're SURE your schema is spec-clean, the answer isn't more schema polish. The answer is: are you using this schema type in a context Google intended it for?

Post-mortem: what I'd change

Locked into a guideline doc (docs/guidelines/content-and-integrity.md in my repo) — never add MathSolver JSON-LD on this site again. Also captured the anti-pattern for future contributors: validate ONE test page in Rich Results Test before rolling any new schema type across all 38 tools.

If you're implementing structured data for a niche use case, budget the "test one page first" step. It's the difference between one file changed and 76 files changed four times in a row.

I'm Chetan Sanghani, building SmartTaxCalc.in — 38 free Indian tax calculators, editorially reviewed by CA Ankitkumar Italiya (ICAI M-644575). Feedback welcome — especially if you've hit similar feature-gate walls with other Google structured data types.

DEV Community: Chetan Sanghani