DEV Community: Chetan Sanghani

The Indian Income Tax notice cascade, as a state machine: CPC Supreme Court (walkthrough for salaried filers)

Chetan Sanghani — Fri, 31 Jul 2026 15:18:07 +0000

The Income Tax Department has been issuing lakhs of Section 80GGC (political-party donation) scrutiny notices to salaried filers for AYs 2019-20 through 2022-23. If you claimed 80GGC in any of those years, there's a nonzero chance the notice arrives — and the single worst thing you can do is ignore it.

This post frames the Indian tax-scrutiny process the way a developer would find useful: as a state machine. 8 states, strict deadlines at every transition, and missing one edge type forfeits your appeal at that level.

The specific example is Section 80GGC because that's the current notice wave, but the cascade shape applies to any Chapter VI-A dispute.

The state machine

┌──────────────────────────┐
│  1. ITR Filed            │
└──────────┬───────────────┘
           ▼
┌──────────────────────────┐
│  2. CPC processing       │  Section 143(1) intimation
│     (9 months)           │  → arithmetic reconciliation
└──────────┬───────────────┘
           │
     ┌─────┴─────┐
     ▼           ▼
[No issues]  [Adjustment]  ─────┐
                                │  Rectify under Sec 154
                                │  within 4 years
┌──────────────────────────┐    │
│  3. Scrutiny selection   │◄───┘
│  Section 143(2) notice   │
│  (dept's 3-month deadline)
└──────────┬───────────────┘
           ▼
┌──────────────────────────┐
│  4. AO assessment        │  Section 142(1) requisitions
│  (12 months from AY end) │  + Section 143(3) order
└──────────┬───────────────┘
           │
    ┌──────┴──────┐
    ▼             ▼
[Accepted]    [Addition]  ────┐  30 days to appeal
                              │
┌──────────────────────────┐  │
│  5. CIT(A) — Form 35     │◄─┘
│  (12-24 months)          │
└──────────┬───────────────┘   60 days to next
           ▼
┌──────────────────────────┐
│  6. ITAT — Form 36       │  Quasi-judicial
│  (12-36 months)          │
└──────────┬───────────────┘   120 days
           ▼
┌──────────────────────────┐
│  7. High Court           │  Substantial law question only
│  (1-4 years)             │
└──────────┬───────────────┘   90 days
           ▼
┌──────────────────────────┐
│  8. Supreme Court        │  SLP under Article 136
│  (3-8 years, <5% admit)  │
└──────────────────────────┘

State 1 → 2: filing to CPC

Automated arithmetic check by the Centralised Processing Centre in Bengaluru. Timeline: within 9 months from end of the FY in which the return was filed.

Outcomes:

No adjustment → refund / no-demand intimation
Adjustment → intimation under Section 143(1) with a demand or reduced refund

80GGC-specific triggers at this stage:

Claim on a New Regime ITR → auto-disallowed (New Regime disables Chapter VI-A except 80CCD(2)/80CCH/80JJAA)
Claim above your reported gross income → auto-disallowed
Missing Chapter VI-A schedule entries where the claim is present

If CPC disallows and you disagree, file rectification under Section 154 within 4 years from end of the FY the order was passed. That's a soft transition — NOT scrutiny.

State 2 → 3: the department's deadline

The critical fact: the Section 143(2) scrutiny notice must be served within 3 months from the end of the FY in which the return was filed. If they miss it, they cannot open scrutiny for that AY — only reassess later under Section 148.

Selection triggers specific to 80GGC:

Donation quantum inconsistent with reported income (₹1L donation on ₹6L salary)
Party PAN linked to earlier bogus-registration flags
Donation date bunched with hundreds of other salaried donors on the same day (agent-driven manufactured donations)
No prior donation history + sudden ₹50,000+ donation
Reversal patterns (donation debited then credited back after a lag)

State 3 → 4: the AO back-and-forth

The AO issues specific requisitions under Section 142(1) — numbered lists of documents. You upload responses via e-Proceedings. The AO may issue follow-ups. Personal / video hearing is available.

Timeline for the AO to complete assessment: 12 months from the end of the AY. Extensions for TP / abroad / DRP references.

What the AO looks for in 80GGC cases:

Genuineness of the political party (registered under Section 29A of RPA 1951? still-active registration?)
Genuineness of the donation (bank trail matching receipt; no offsetting refund flow)
Source of funds (donor's own income vs borrowed / gifted funds)
Whether the donation aligns with donor's declared affiliation / activity pattern

If the order goes against you, the assessment order under Section 143(3) is issued. 30 days from date of service to file appeal to CIT(A).

The appellate deadlines — memorise these

Transition	Form	Deadline	Filing fee
AO → CIT(A)	Form 35	30 days from AO order	₹250-₹1,000
CIT(A) → ITAT	Form 36	60 days from CIT(A) order	₹500-₹10,000
ITAT → High Court	Reference/appeal	120 days from ITAT order	₹1,00,000+ (advocate cost)
HC → Supreme Court	SLP under Article 136	90 days from HC order	₹5,00,000-₹25,00,000+

Miss any deadline, forfeit right to appeal at that level. The state machine has no "retry" edge from missed deadlines.

The "20% rule" at CIT(A)

At CIT(A) stage, to prevent the department from initiating recovery while your appeal is pending, you must:

Pay 20% of disputed demand, OR
Obtain a stay-of-recovery order

This is procedural. A CA can help with the stay application if you don't want to lock up 20% of the disputed amount for 12-24 months of pendency.

What NOT to do (the anti-pattern list)

❌ Ignore the notice. Non-response converts the state machine into best-judgment ex-parte assessment under Section 144 — full disallowance + interest + penalty. Ignoring is the single worst state transition.
❌ Concede a genuine claim to close the file. Weakens your position for future AYs with the same donation pattern.
❌ Engage "tax notice resolvers" who promise settlement without asking to see your documents. They file a bad response, then disappear.
❌ Respond emotionally on e-Proceedings. Every response is on record — used against you at appeal.
❌ File frivolous appeals for delay. ITAT + HC can impose cost orders under their inherent powers.

What TO do (the correct-transition list)

✅ Respond within stated timelines. Even a short "acknowledged, working on documents, please grant 14 more days" filing preserves your position.
✅ Keep every donation-related document for at least 10 years. Section 148 reassessment can reach that far for escaped income above ₹50 lakh in asset form.
✅ Consult a qualified CA or tax advocate if disputed tax exceeds ~₹2 lakh.
✅ Request a personal or video hearing. Written submissions alone are less persuasive.
✅ If the claim was a genuine mistake (e.g. 80GGC on New Regime), accept the demand + interest, move on. Fighting a losing case escalates costs.
✅ Revised return under Section 139(5) if the mistake is caught before the department flags it — reduces penalty exposure.

The bogus-party defence

A specific 80GGC angle worth calling out: what if the party you donated to was later flagged as bogus by the Income Tax Department?

Not automatic disallowance. Courts have repeatedly held that:

The donor's obligation is to verify the party was registered under Section 29A of RPA 1951 at the time of donation, AND
Make the payment via non-cash mode with a valid receipt

If both are documented, post-donation events at the party (deregistration, later fraud finding) do NOT automatically vitiate the donor's deduction. You will still need to demonstrate the reasonable due diligence you exercised at the time — bank trail, receipt with party's PAN + registration proof, ECI website snapshot from that date.

When to just pay and move on

For an individual salaried assessee, the practical materiality thresholds:

Below ~₹50,000 in disputed tax: pay + move on. Legal + advocate costs at ITAT alone exceed the amount.
₹50K to ₹2L in disputed tax: fight at CIT(A) with a CA. Don't escalate to ITAT unless CIT(A) affirms.
Above ₹2L in disputed tax: worth full CA + advocate representation through the cascade.
Above ₹10L in disputed tax: usually worth appealing to ITAT even if CIT(A) affirms.

Over 99% of individual 80GGC cases settle at CIT(A) or ITAT. The Supreme Court is not the realistic exit route for an individual assessee.

Why I'm framing this as a state machine

The Indian tax appellate structure looks intimidating in prose form. But it's a finite state machine with clear transitions, strict deadlines, and specific document requirements at each state. Once you internalise the shape, drafting the response becomes tractable engineering work — enumerate the documents, hit the deadline, request the hearing.

Full statutory framing + timeline table + do/don't lists + FAQ + case-law framing: smarttaxcalc.in/blog/80ggc-notice-process/ — CA-reviewed by ICAI 644575.

Disclaimer: this is a general legal-process explainer, NOT legal advice for any specific case. If you have received an 80GGC notice or any tax scrutiny notice, consult a qualified CA or tax advocate before drafting a response.

The author builds SmartTaxCalc.in — free browser-based Indian tax calculator suite. Blazor WebAssembly, CA-reviewed, no signup, no backend. Previously wrote about the perquisites that survive the New Regime and Blazor WASM trim mode surprises.

The 4 Indian salary perquisites that survive the New Tax Regime (what your HR probably won't volunteer)

Chetan Sanghani — Fri, 31 Jul 2026 15:18:01 +0000

If you're a salaried developer in India, this is money left on the table because nobody frames it right.

The FY 2026-27 conventional wisdom: on the New Regime you can only claim the ₹75,000 standard deduction + employer NPS. Everything else — HRA, LTA, 80C, 80D — is disabled. Which is why so many mid-senior developers who took the New Regime for the higher ₹12L Section 87A rebate think their tax bill is just: gross minus standard deduction, slab math, done.

That framing misses four employer-provided benefits that stay exempt in BOTH regimes because they aren't Section 10 exemptions — they're Rule 3 perquisite valuations. The New Regime dropped Section 10; it did NOT touch Rule 3.

Combined tax savings at 30% + 4% cess bracket: typically ₹36,000 to ₹1,20,000/year depending on which your employer offers.

The rule that survived: Rule 3

Section 10 of the Income Tax Act defines which benefits are exempt from income. Rule 3 of the Income Tax Rules 1962 defines how much of an employer-provided benefit is taxable. These are different things.

The Budget 2020 New Regime (Section 115BAC) removed most Section 10 exemptions — HRA, LTA, most 10(14) allowances. It did not modify Rule 3. So any perquisite whose taxability is defined by a Rule 3 sub-rule is valued identically in both regimes.

Four Rule 3 sub-rules matter for the salaried developer:

1. Rule 3(7)(iii) — meal coupons

Cap: ₹26,400/year (₹50/meal × 2 meals × ~22 working days × 12 months).

Sodexo, Zeta, Zaggle. Your employer issues vouchers OR pays a food-court vendor directly. Fully exempt within cap.

What's NOT covered: a cash "meal allowance" in your salary. Fully taxable regardless of what you spend it on. The exemption is conditional on the payment mechanism, not the intent.

Tax saved at 30% + cess: ~₹8,240/year at full utilisation. Most tech companies already have this on their CTC menu — check your CTC statement for a "meal card" or "food coupon" line.

2. Rule 3(7)(iv) — gift voucher

Cap: ₹5,000/year cumulative across ALL employer gifts in that FY.

The full-or-nothing trap: if aggregate gift-card issuance in the FY crosses ₹5,000 (₹3,000 Diwali + ₹3,000 work anniversary = ₹6,000), CBDT interpretation is the entire amount becomes taxable, not just the ₹1,000 excess. Track this cumulatively.

Tax saved: ~₹1,560/year at full utilisation.

3. Rule 3(7)(ix) — telephone + internet reimbursement

Cap: NO monetary cap. Actual reimbursement against bills is fully exempt.

Conditions:

Bills must be in the employee's name
Employer actually pays or reimburses (not a cash allowance)
Mixed personal + official use is fine — no split proof required

What's NOT covered: a lump-sum "telephone allowance" paid as cash. Fully taxable regardless of your actual bills. The distinction between reimbursement-against-bills vs cash-allowance is the entire game.

Practical example: mobile ₹1,500 + broadband ₹2,500 = ₹4,000/month = ₹48,000/year reimbursed = ~₹14,976/year tax saved at 30% bracket. High-earning devs with premium ISP plans routinely see ₹75,000+ reimbursement = ~₹23,400 in savings.

This one is heavily under-used because tech companies default to "we pay you cash for phone" instead of "you submit bills, we reimburse." Ask HR to restructure — no cost to the employer, direct saving to you.

4. Rule 3(2) — company car (fuel + maintenance + driver)

The biggest lever, most under-used.

For a car provided by the employer used for both office and personal purposes, the taxable perquisite is a fixed monthly amount regardless of what the car actually costs the company.

Component	Small engine (≤1,600cc)	Large engine (>1,600cc)
Fuel + maintenance + insurance	₹1,800/month = ₹21,600/year	₹2,400/month = ₹28,800/year
Driver (if provided)	+₹900/month = +₹10,800/year	+₹900/month = +₹10,800/year

Numeric example: employer's actual outgoing on a 1,500cc car ≈ ₹60,000/year in fuel + insurance + maintenance. Employee's taxable perquisite = ₹21,600/year. Effective tax-free portion = ₹38,400/year. Tax saved at 30% + cess ≈ ₹11,981/year.

What's NOT Rule 3(2):

Cash fuel/petrol allowance (fully taxable)
Personal car with fuel reimbursement (fully taxable — different Section 10(14) framework, rare post-2018)
Car used ONLY for personal purposes (full running cost taxable)
Car used ONLY for office purposes (no perquisite; no benefit)

The sweet spot is "mixed use" — the reality for most senior devs commuting + weekend usage.

Combined example — ₹25 lakh CTC dev

Salary ₹25 lakh, marginal 30% + 4% cess, all four levers utilised:

Perquisite	Amount exempt	Tax saved
Meal coupons	₹26,400	~₹8,240
Gift voucher (Diwali)	₹5,000	~₹1,560
Telephone + internet (bills)	₹48,000	~₹14,976
Company car 1,500cc	employer cost ~₹60K → only ₹21,600 taxable	~₹11,981
Total		~₹36,757/year

On top of standard deduction, 80C, and everything else. And this stays the same in the New Regime.

Why HR usually doesn't volunteer this

Two reasons:

Legacy CTC templates. Older CTC structures encode a "cash phone allowance" as a taxable component because it was easier to run in payroll. Switching to reimbursement-against-bills is a payroll config change that requires HR's finance team to be aware — many aren't.
The 5,000 gift trap is easy to trip. HR issues a Diwali gift + a work-anniversary voucher without tracking cumulative → the employee ends up taxed on the full amount. Some companies just skip the exemption path and pay it as taxable.

How to actually get these

The framing that works with HR:

"I'd like to restructure a portion of my fixed CTC into (a) meal coupons up to ₹26,400/year, (b) telephone + internet reimbursement against actual bills, and (c) if the company offers a car benefit, I'd like to opt into that. These are all standard perquisite structures — no incremental cost to the company, but they lower my taxable perquisite value."

Most large employers have these on their CTC menu. Smaller firms may need walking through the Rule 3 framework — the CTC restructuring itself is standard HR practice, so it's not a novel ask.

Common misconceptions

❌ "My cash fuel allowance is exempt because Rule 3(2) exists." No. Cash allowances are fully taxable. Rule 3(2) applies to actual company-provided car benefits.
❌ "I'll claim ₹10,000/month telephone reimbursement even though my bill is ₹1,500." No. Only actual bills up to the amount reimbursed count.
❌ "Gift card exemption is per gift, not per year." No. Cumulative ₹5,000 across all employer gifts in the FY.
❌ "These deductions are Old-Regime only, like 80C." No. Rule 3(x) perquisite valuations survive the New Regime — they're computational rules, not Section 10 exemptions.

Why I built a calculator for this

I built SmartTaxCalc — a browser-based Indian tax calculator — because tools that let you enter these perquisite values and see the exempt-vs-taxable split are rare. Most calculators just take gross salary and apply slab math. The homepage calculator now accepts all four of these perquisite categories individually and shows the New-Regime vs Old-Regime impact side by side.

Full statutory framing + numeric examples + FAQ + HR-friendly script: smarttaxcalc.in/blog/ctc-exempt-allowances-fy-2026-27/ — CA-reviewed.

If you're on the New Regime and have never asked HR about restructuring these categories, that's the highest-ROI 15-minute conversation of your year.

The author builds SmartTaxCalc.in — free browser-based Indian tax calculator suite. Blazor WebAssembly, CA-reviewed by ICAI 644575, no signup, no backend. Previously wrote about Blazor WASM trim mode surprises and a PowerShell backlink rel verifier.

The 4 static-mirror drift classes hiding in your Blazor WASM SEO (and the audit script that finds them)

Chetan Sanghani — Sun, 26 Jul 2026 07:07:21 +0000

I run a Blazor WebAssembly tax calculator site. To feed Google's crawler before the SPA hydrates, every @page route also has a hand-maintained static HTML mirror at wwwroot/<route>/index.html. That works — the crawler indexes real content, users get instant-paint before Blazor boots.

But this weekend I ran a grep audit across those 100 mirror files. It found 4 distinct drift classes, silently degrading SEO signals for months. If your Blazor WASM site uses the same pattern, you probably have some of these too.

The setup, if you don't already have it

The .razor file is the source of truth. Blazor renders it after hydration. The static HTML mirror is a snapshot of what the page should look like on first paint, for the crawler + for the ~1-2 seconds users wait for WASM to boot. In practice this means every content-page razor has a paired wwwroot/<same-path>/index.html, and every razor edit is supposed to also update the mirror.

Supposed to.

The problem: razor edits happen in normal development flow, mirror edits require you to remember. Over 6 months and ~40 pages, drift accumulates. And it's invisible to dotnet build because the mirror is just static HTML — the compiler doesn't check it.

Here's what my Saturday audit found.

Drift class #1 — missing BreadcrumbList JSON-LD

Discovery: grep -L '"BreadcrumbList"' wwwroot/blog/*/index.html returned 7 files.

BreadcrumbList JSON-LD is what makes Google render "Home › Blog › Article Title" as a visible breadcrumb in the search snippet. Without it in the mirror, the crawler sees no breadcrumb at first index. My <SeoSchema> component in each razor emits it correctly at hydration — but the crawler reads the mirror before hydration. That schema was invisible to Google for 7 blog posts.

Fix: 7 additive <script type="application/ld+json"> blocks injected before </head>, matching the exact 3-level pattern (Home → Blog → Article Title) that my razors emit at runtime. Pattern was copy-paste from an already-working mirror.

Drift class #2 — missing FAQPage JSON-LD despite razor having FaqItems

Discovery: grep -L '"FAQPage"' wwwroot/blog/*/index.html returned 16 files. But when I cross-checked which of those razors had a FaqItems=@(new List<SeoSchema.FaqItem> { ... }) param on the <SeoSchema> component, 6 of the 16 did.

Those 6 razors are actively emitting FAQPage schema at hydration. Their mirrors have zero FAQPage schema. Users get the schema after WASM boots; Google's initial crawl doesn't. FAQPage is one of Google's most-visible SERP features (the expandable Q&A dropdown), and I was leaving CTR on the floor across 6 blogs for months.

Fix: I wrote a Node script that regex-extracted the new("Question", "Answer") tuples from each razor's FaqItems= block, JSON.stringify()'d them into the SIMPLE FAQPage schema format (matching what my already-working mirrors used), and injected before </head>. 38 Q&A pairs baked in across 6 files. All validated via JSON.parse post-write.

The 10 razors without FaqItems= are a separate content-authoring problem — they need FAQ Q&A written from scratch + reviewer signoff on YMYL claims. Different scope, deferred.

Drift class #3 — asymmetric hreflang cluster

Discovery: my sitemap.xml declares 4 hreflang alternates for my old-vs-new-regime cluster:

<xhtml:link rel="alternate" hreflang="en-IN" href=".../blog/old-vs-new-regime/"/>
<xhtml:link rel="alternate" hreflang="hi-IN" href=".../blog/hi/old-vs-new-regime/"/>
<xhtml:link rel="alternate" hreflang="gu-IN" href=".../blog/gu/old-vs-new-regime/"/>
<xhtml:link rel="alternate" hreflang="x-default" href=".../blog/old-vs-new-regime/"/>

But the page HTML on 2 of the 3 language variants (English + Hindi mirrors) had only 3 <link rel="alternate"> tags — missing gu-IN. The Gujarati mirror correctly had all 4. This is an asymmetric hreflang cluster: the sitemap says GU exists, English + Hindi pages don't reference it back. Google's algorithm for hreflang requires bidirectional references to trust the cluster.

Impact: the Gujarati variant may lose SERP visibility in gu-IN searches (no reciprocal reference from English/Hindi means weaker language-cluster signal). Small volume for my site but a real signal loss.

Fix: 2 additive <link rel="alternate" hreflang="gu-IN"> tags. All 3 mirrors now show 4-alternate symmetric cluster.

Drift class #4 — meta keywords copy-paste template

Discovery: I noticed during the FAQPage injection that 5 blog mirrors shared identical <meta name="keywords"> content — the generic homepage keywords like "income tax calculator india fy 2026-27, free tax calculator india no signup..." — even though the blogs were about wildly different topics (NPS 80CCD(1B), PPF vs ELSS, RSU tax, home loan interest, Form 10E).

Cross-checked: the razors had topical keywords. The mirrors had the generic homepage boilerplate. Classic mirror-drift on a low-priority attribute nobody remembered to sync.

Google mostly ignores <meta name="keywords"> since 2009. But:

Bing still uses it (per Bing Webmaster docs)
Yandex uses it
Some AI content classifiers use it
Human quality-raters see it — 5 topically-different blog pages sharing identical keywords looks like template-duplicate spam

Fix: extracted each razor's keywords content via regex, wrote it back into the corresponding mirror. 5 files, 5 topical keyword strings replacing 5 identical-homepage-boilerplate strings.

The audit script

This is the one-liner that started the whole weekend:

# Which blog mirrors are missing BreadcrumbList?
grep -L '"BreadcrumbList"' wwwroot/blog/*/index.html

# Which are missing FAQPage?
grep -L '"FAQPage"' wwwroot/blog/*/index.html

# Which are missing Article?
grep -L '"@type":"Article"' wwwroot/blog/*/index.html

# Cross-check razors: which razors HAVE FaqItems but mirrors DON'T have FAQPage?
# (this is where the "shippable parity fix" list comes from — the razor already
#  has the data, the mirror just needs to be synced)

If you have static mirrors for a Blazor WASM SPA and haven't grep'd them for schema completeness in a while, run these three grep commands. I'd bet money you find at least one drift class.

Why this happens

Static mirrors are a duplication. The DRY-in-code violation is what makes them work — the mirror is deliberately a copy, not generated, because generating them at build time (via prerendering) requires either running Blazor in server mode (defeats the point of static WASM) or shipping a whole SSG pipeline (heavier than the drift risk).

My repo made the pragmatic call: hand-maintain the mirror, add a lint that catches divergence for a growing list of known bad patterns.

The lint I have (scripts/lint-mirror-integrity.ps1) catches YMYL content drift — like a mirror saying "80CCD(1B) is allowed in the New Regime" when the razor correctly says it's disallowed (that class of drift once shipped a real integrity issue to production for weeks).

But schema-presence isn't in the lint. Neither is meta-keywords drift, or hreflang symmetry. My Saturday audit was manual grep-driven. I'll add these classes to the lint next.

Prescription

If you have this architecture:

grep -L schema audits are cheap enough to run monthly. Add them as CI checks if you can.
Cross-check razor source-of-truth against mirror — the FaqItems= vs <script>"FAQPage"</script> mismatch was the highest-signal finding.
Sitemap ↔ page HTML hreflang symmetry — if you have multilingual variants, verify both sides declare each other.
Meta keywords is deprecated but not zero-signal — copy-paste template duplication reads as low-effort content to human reviewers, even if Google's algo ignores the tag itself.

Static mirrors solve a real problem (crawler + first-paint UX). They introduce a real risk (drift you don't see). The audit script + lint list keeps that risk bounded.

One more thing

My audit found all 4 classes on a Saturday morning. Shipping the fixes across 13 mirror files took a Node script + a couple of hours. The impact: 6 blog pages became eligible for Google FAQ rich results, 7 became eligible for breadcrumb SERP renders, 2 got proper Article JSON-LD, 5 got topical keywords instead of homepage template.

If you have static mirrors and haven't audited them recently, do it. The scripts above are literally the whole thing.

I build client-side Indian tax calculators at smarttaxcalc.in — Blazor WASM, no backend, all client-side. This weekend's shipping arc: IsTrimmable=false is not enough was article #7 in this series.

IsTrimmable=false is not enough: how one WASM setting silently broke my Blazor app for 4 days

Chetan Sanghani — Thu, 23 Jul 2026 14:32:17 +0000

Last Sunday I split a Blazor WebAssembly app into a shared class library and a Web project. dotnet build: clean. dotnet publish: clean. Cloudflare Pages deployed. All my local smoke tests passed.

Four days later a user emailed: "The Calculate button doesn't work." Every calculator on the site was throwing this in the browser console:

Error: DeserializeNoConstructor, JsonConstructorAttribute,
TaxPlanner.Core.Models.TaxRulesConfiguration
Path: $ | LineNumber: 0 | BytePositionInLine: 1

This post is what I learned. If you have <PublishTrimmed>true</PublishTrimmed> in a Blazor WASM app and you use reflection-based System.Text.Json — HttpClient.GetFromJsonAsync<T>, JsonSerializer.Deserialize<T>, or [JsonSerializable] NOT declared — this could hit you too.

Update after publishing: a reader pushed me to properly instrument the "fix #1 didn't work" mystery instead of hand-waving it. The corrected analysis is in What actually happened at fix #1 below. Short version: reflection was never disabled (TrimMode=partial keeps the JSON reflection switch on — confirmed via runtimeconfig.json), and the IsTrimmable=false build was probably a valid fix that a caching layer masked. Source generation is still the right answer. Kept the original narrative intact so the correction is honest.

The setup

Blazor WASM app, .NET 10. Two projects:

TaxPlanner.Web — Blazor pages, services, <PublishTrimmed>true</PublishTrimmed> + <TrimMode>partial</TrimMode> (default for optimized WASM builds).
TaxPlanner.Core — data models. The refactor I shipped extracted the record types into this new library.

The Core project's csproj had this one line I didn't think twice about:

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <IsTrimmable>true</IsTrimmable>
</PropertyGroup>

Every guide on optimizing Blazor WASM output size tells you to mark your app assemblies as trimmable. It sounds like the disciplined choice. The Core assembly is small — models + a couple of helpers — and shrinking the payload matters when you're serving to phones.

The data models are all like this:

public sealed record TaxRulesConfiguration
{
    [JsonPropertyName("version")]
    public string Version { get; init; } = "";

    [JsonPropertyName("financialYears")]
    public IReadOnlyList<FinancialYear> FinancialYears { get; init; } = [];
}

Loaded once at startup:

_rulesConfig = await _httpClient.GetFromJsonAsync<TaxRulesConfiguration>(
    "data/tax-rules.json",
    new JsonSerializerOptions { PropertyNameCaseInsensitive = true });

Standard stuff. Works fine in development. Passes every build.

What the trimmer actually did

TrimMode=partial means: only aggressively trim assemblies marked IsTrimmable=true. TaxPlanner.Core was the only such app assembly.

The trimmer's job is to remove unreachable IL. It does a static reachability analysis: it walks from every entry point (Program.Main, exposed public APIs, etc.), traces which types and members are called, and deletes everything not reached.

Here's what it saw: TaxRulesConfiguration is a sealed record with only { get; init; } properties. The compiler-generated parameterless constructor was public. But nothing in the codebase calls new TaxRulesConfiguration(). The only "caller" is HttpClient.GetFromJsonAsync<T>, which uses reflection at runtime to look up and invoke that constructor.

Reflection is invisible to the trimmer. From its perspective, the constructor was unreachable. It got deleted.

System.Text.Json's reflection path then tried to construct the object at runtime, found no public parameterless constructor, no [JsonConstructor] attribute, no custom converter, and threw:

DeserializeNoConstructor, JsonConstructorAttribute,
TaxPlanner.Core.Models.TaxRulesConfiguration

dotnet build? Green. dotnet publish? Green. The trimmer doesn't warn on this class of stripping because from its perspective it correctly identified unreachable code. The bug only exists at runtime, only in the browser, only when the deserialization path fires.

Fix attempt #1: turn trim off for the assembly

Obvious first move:

<IsTrimmable>false</IsTrimmable>

I pushed it. Cloudflare rebuilt. I checked bundle size — Core.wasm went from 12 KB to 49 KB, matching exactly the type metadata + constructor IL the trimmer had been eating. That's a great debugging signal on its own: a ~4× jump means "trim was doing real work here"; near-identical size means "trim was doing nothing and might have been silently breaking reflection targets."

Restarted. Loaded the site. Clicked Calculate.

Same error.

This is where I lost an hour. My mental model said: opting the assembly out of trim should restore its type metadata, which should be enough for System.Text.Json's reflection to find the constructor. It wasn't.

What actually happened at fix #1 (updated after a reader's diagnostic)

The original version of this post threw up its hands here — "something about PublishTrimmed=true breaks reflection regardless of IsTrimmable." A sharp commenter pushed me to actually instrument it. Two findings changed the story.

First: reflection was never disabled. I'd half-assumed PublishTrimmed=true had flipped System.Text.Json's reflection feature switch off — which it does under full trimming. But this app uses TrimMode=partial, and I confirmed the switch's real value by reading the published TaxPlanner.Web.runtimeconfig.json:

"System.Text.Json.JsonSerializer.IsReflectionEnabledByDefault": true

So the reflection deserializer was available the whole time. That rules out the feature switch and pins the root cause firmly on the trimmed constructor described above — exactly what the DeserializeNoConstructor error says on the tin. If you want to check your own build, that one line in runtimeconfig.json tells you whether reflection-based JSON is even on.

Second: the IsTrimmable=false build was probably correct — the browser just wasn't running it. Recall the bundle jumped 12 KB → 49 KB when I flipped the flag, i.e. the constructor metadata was restored in the published artifact. If the deployed bundle has the ctor and reflection is on, that build should work. The most likely reason it still threw the identical error: stale cached assets. Cloudflare Pages serves the fingerprinted _framework/*.wasm files with immutable cache headers, and the Blazor PWA service worker (if you ship it) keeps its own asset cache that only updates after every tab is closed. The click that "still failed" was very likely executing the previous trimmed bundle, not the fixed one.

I can't prove that 100% after the fact — the clean confirmation is to compare the served asset's integrity hash against the fresh build's at the time, which I didn't capture. But it fits every observable: green build, restored metadata, byte-identical runtime error, a CDN + service worker between me and the browser. The honest correction: IsTrimmable=false likely was a valid code-level fix, and a caching layer made it look useless.

The pragmatic lesson stands, just for a sharper reason: IsTrimmable=false is a fragile defense — it depends on the trimmer's reachability analysis and your cache invalidation both cooperating. Source generation depends on neither: the deserializer is ordinary reachable IL, so no reflection switch, no trim heuristic, and (once the new bundle is actually served) no ambiguity.

Fix attempt #2: source-generation (the real answer)

Microsoft's official recommendation for trim-safe and AOT-safe JSON is System.Text.Json source generation. Instead of runtime reflection walking your types, the compiler emits the deserialization code at build time. Zero reflection needed. The trimmer sees the generated code as regular reachable IL.

Setup is two steps.

Step 1: declare a partial JsonSerializerContext in your Core library:

using System.Text.Json.Serialization;
using TaxPlanner.Core.Models;

namespace TaxPlanner.Core.Json;

[JsonSourceGenerationOptions(
    PropertyNameCaseInsensitive = true,
    ReadCommentHandling = System.Text.Json.JsonCommentHandling.Skip)]
[JsonSerializable(typeof(TaxRulesConfiguration))]
public partial class TaxRulesJsonContext : JsonSerializerContext { }

The [JsonSerializable(typeof(T))] attribute is what triggers codegen. You list every root type you want serialized/deserialized. The generator walks the object graph — TaxRulesConfiguration contains a List<FinancialYear>, each FinancialYear contains a TaxRegime and a Deductions, and so on — and emits deserializer code for every nested type. No need to enumerate them explicitly.

Step 2: change the call site from the reflection overload to the source-gen overload:

// Before (reflection path — broken under PublishTrimmed):
_rulesConfig = await _httpClient.GetFromJsonAsync<TaxRulesConfiguration>(
    "data/tax-rules.json",
    new JsonSerializerOptions { PropertyNameCaseInsensitive = true });

// After (source-gen path — trim-safe by construction):
_rulesConfig = await _httpClient.GetFromJsonAsync(
    "data/tax-rules.json",
    TaxRulesJsonContext.Default.TaxRulesConfiguration);

The overload that takes a JsonTypeInfo<T> (which TaxRulesJsonContext.Default.TaxRulesConfiguration is) selects the generated deserializer instead of the reflection-based one.

Pushed. Cloudflare rebuilt. Core.wasm went from 49 KB (metadata preserved via IsTrimmable=false) to 156 KB (metadata + generated deserializer). About ~30 KB brotli-compressed. Downloaded once, cached immutable.

Calculate button worked. Every calculator worked. Four days of broken production ended.

Diagnostic patterns worth internalizing

Three signals I now watch for:

1. Small assembly, big size jump on IsTrimmable=false. If flipping trim off adds tens of KB of uncompressed WASM to an app-owned assembly, that assembly has reflection-consumed types the trimmer was silently deleting. Investigate those types. Same-size-before-and-after means trim was finding nothing trimmable there — usually safe to leave IsTrimmable=true.

2. dotnet build and dotnet publish both green does not mean runtime-correct under trim. The trimmer emits no warning for stripping a reflection-only constructor because it's doing its job. Trim regressions surface only in the browser, at the moment the deserialization fires. If you change anything trim-related — assembly split, IsTrimmable flip, DI graph reshaping — you must publish and actually navigate to the affected page in a real browser before believing the change is safe.

3. If the type is reflection-consumed, source-gen or nothing. [JsonSerializable] + JsonSerializerContext is not an optimization; it's the correctness contract under trim. Attributes like [JsonConstructor] are for choosing a constructor when there are multiple candidates — they don't preserve constructors that the trimmer already deleted. [DynamicallyAccessedMembers] in principle can preserve members but you have to annotate at the call site, and GetFromJsonAsync<T> is defined in an external library so you can't add annotations there. Source-gen sidesteps this entire class of problem.

The soft-fail alternative I considered and rejected

There's a tempting middle ground: keep the reflection-based deserialization, mark the target class with [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)], and hope the trimmer preserves everything. This can work in isolated cases. But:

It requires modifying every reflection-consumed type in your assembly (missing one is a silent runtime break)
It's easy to forget when you add a new type (there's no lint that catches it)
It preserves more than the deserializer actually needs (partially defeats the trim wins you wanted)

Source-gen scales better: one file per assembly, one [JsonSerializable] per root type, generator walks the graph and figures out the rest. It also happens to be the pattern that AOT compilation requires, so if you ever move to AOT (RunAOTCompilation=true), your work is already done.

The 4-day window, in retrospect

I've been thinking about why this survived so long unnoticed. The commit that introduced the bug was one of 32 shipped that Sunday — an SEO-focused audit day. Every calculator on the site was silently broken from that commit forward. The site's own health dashboard (GA4 exceptions on the "Reviewer" page) was elevated but I had a different working theory for that spike. The failure only showed up when a user opened the browser DevTools and clicked Calculate — which happened four days later when someone reported it.

Two things would have caught it in minutes instead of days:

Publish locally and click through the app after any assembly-boundary or trim change. I did the first (publish worked, bundle size was fine). I didn't do the second. Every "small architecture" change in a WASM app now gets a real-browser smoke test before I consider it done.
An end-to-end test that clicks Calculate on the homepage. I don't have Playwright/Selenium set up yet on this project. The 4-day incident convinced me it's worth the ~2 hours of setup.

If your Blazor WASM stack is anything like the one in this post, and you've been leaving IsTrimmable=true on your app assemblies because "size wins are size wins," here's your reminder: check that the trimmer isn't quietly deleting things System.Text.Json's reflection needs.

I build client-side Indian tax calculators at smarttaxcalc.in — all Blazor WASM, no backend, CA-reviewed. Every incident like this one makes the site a little more resilient.

I built a lint that caught 3 tax-rule lies my manual sweep missed — a pattern-based safety net for hand-maintained SEO

Chetan Sanghani — Wed, 22 Jul 2026 17:13:29 +0000

Three Sundays ago I found seven pages on my site independently asserting something factually wrong about Indian tax law. The .razor sources were all correct. The pre-rendered static HTML mirrors — which is what Google actually indexes — had drifted.

I fixed all seven by hand. I congratulated myself. I moved on.

Then this Wednesday I built a lint to catch the pattern automatically. It surfaced three more identical lies on three completely different pages. My manual sweep had missed them.

Here's what I built, why regex alone doesn't work, and the two-phase pattern that does.

The setup — why drift happens

SmartTaxCalc.in is a Blazor WebAssembly SPA deployed to Cloudflare Pages. Every blog post has two representations:

Pages/Blog/*.razor — the source of truth. Compiled into the WASM bundle. Rendered client-side after Blazor boots.
wwwroot/blog/<slug>/index.html — a static HTML mirror. What Cloudflare serves at page load. What Google indexes. What users see for the first 1-2 seconds before Blazor hydrates.

The mirrors are hand-maintained. No build step regenerates them from the razors. So when I fix a fact in a razor, nothing propagates it to the mirror. The mirror keeps the old, wrong content.

I already had one lint guarding one part of this:

# scripts/lint-title-parity.ps1
# Ensures the razor's <PageTitle> matches the mirror's <title>.
# Runs in CI on every push touching razor/mirror paths.

That catches SEO titles going out of sync. It does not catch anything below the title tag. Every paragraph of body content is on trust.

The Sunday crisis

Running through an editorial integrity audit, I found the same false claim in seven different blog mirrors:

"Section 80CCD(1B) NPS is now allowed in both regimes."

For readers not in India: this is wrong. Section 80CCD(1B) is a ₹50,000 individual NPS deduction that is Old-Tax-Regime-only. The New Regime disallows it. It matters — a taxpayer following that advice would over-claim and face a Section 143(1) intimation.

The razors said the correct thing everywhere: "80CCD(1B) is Old Regime only." Every mirror I inspected asserted the opposite. Seven of them. Independently. No shared component.

Root cause: some earlier session (months ago, before I was on the project) fixed the razors after a Budget-2025 misreading. Never touched the mirrors. Title-parity was 94/0 clean the whole time because titles never changed.

I fixed all seven mirrors in one commit and moved on.

The lint I built this Wednesday

Three days later, still uneasy that I might have missed one, I built a lint.

Naïve attempt: search for the deduction name near "New Regime":

$pattern = '80CCD\(1B\).*(?:allowed|available)(?:.*)?new\s+regime'

Ran it against 100 mirrors. Seventeen violations. All false positives. Every mirror flagged said something like:

"Section 80CCD(1B) is disallowed under the New Regime."

The word allowed is a substring of disallowed. Word boundaries help a little (\ballowed\b), but not enough — real sentences frame this rule in many ways: "not allowed", "not permitted", "only in Old Regime", "cannot claim", "forfeit", etc.

The two-phase pattern that works

The insight: a positive assertion and a negation can share the same lexical proximity. What distinguishes them is context. So don't try to write one regex that captures both.

Instead:

Phase 1: Find suspicious co-occurrences (the deduction name near "New Regime"). Cast a wide net.
Phase 2: For each hit, examine the surrounding ~400 characters. If any safe-indicator word appears (disallow, not allow, Old Regime only, without touching, mistake, cannot, etc.), the sentence is likely correcting the claim, not asserting it. Skip.

Here's the core of the current lint (PowerShell 7):

$forbiddenClaims = @(
    @{
        Name    = '80CCD(1B) claimed to work in New Regime'
        Pattern = '(?:80CCD\(1B\)[^\r\n]{0,120}(?:new\s+regime|new\s+tax\s+regime))' +
                  '|(?:(?:new\s+regime|new\s+tax\s+regime)[^\r\n]{0,120}80CCD\(1B\))'
        Fact    = "Section 80CCD(1B) is Old Regime only. Only 80CCD(2) survives the New Regime."
    }
    # ... more rules
)

$safeIndicators = @(
    '\bdisallow',
    '\bnot\s+allow',
    '\bdoes\s+not\s+(?:allow|permit|apply)',
    '\bold\s+regime\s+only',
    '\bwithout\s+(?:ever\s+)?touching',
    '\bmistake',
    '\bbelieving\s+80CCD',
    # ~20 more
)

function Test-HasSafeIndicator {
    param([string]$window)
    foreach ($ind in $safeIndicators) {
        if ($window -imatch $ind) { return $true }
    }
    return $false
}

foreach ($file in $mirrorFiles) {
    $bodyContent = # ...skip <head>...

    foreach ($rule in $forbiddenClaims) {
        $matches = [regex]::Matches($bodyContent, $rule.Pattern,
            [Text.RegularExpressions.RegexOptions]::IgnoreCase)

        foreach ($match in $matches) {
            $windowStart = [Math]::Max(0, $match.Index - 200)
            $windowEnd = [Math]::Min($bodyContent.Length, $match.Index + $match.Length + 200)
            $window = $bodyContent.Substring($windowStart, $windowEnd - $windowStart)

            if (Test-HasSafeIndicator -window $window) { continue }

            # Real violation. Report.
            $violations += [pscustomobject]@{
                File  = $file.FullName
                Rule  = $rule.Name
                Match = $match.Value
            }
        }
    }
}

Two hundred lines total, including all 4 rules and 30-odd safe indicators.

What happened when I ran it

First run against the "clean" tree (post my Sunday fixes):

Mirrors inspected: 100
Violations: 13

Thirteen? I'd sworn I fixed all of them.

Nine were false positives — sentences correctly stating the rule, plus a few worked-example patterns like "Under the Old Regime with HRA claim you would take home X" (correct, but "HRA" and "New Regime" appeared within 100 chars of each other elsewhere in the paragraph). I extended the safe-indicators list to cover those.

Four were real. Different pages, all mine, all live:

/blog/tax-saving-new-regime/, line 166 (intro paragraph):

"For FY 2026-27, a salaried New Regime taxpayer can still claim Rs 75,000 standard deduction, Rs 50,000 NPS under 80CCD(1B), and an uncapped employer NPS contribution under 80CCD(2)."
/blog/nps-tax-benefits/, line 383 (Bottom Line section):

"…NPS Tier-1 is one of the highest-leverage tax-saving instruments available — especially under the New Regime, where it's the only meaningful retirement deduction left. Contributing the full Rs 50,000 under 80CCD(1B) saves…"
/blog/tax-saving-tips/, line 166 (intro):

"…and Section 80CCD(1B) NPS is now allowed in both regimes. This guide cuts through the noise…"
/blog/section-80c-investments/ — the same class of drift, slightly different phrasing.

I'd manually fixed the other body sections of exactly these files on Sunday. The intros and bottom-lines were on completely different lines. I hadn't caught them because I was grep-searching for the specific phrasings I'd already found. The lint's proximity pattern didn't care about phrasing — it just noticed the semantic co-occurrence.

Same commit that added the lint also fixed the four newly-surfaced lies. Verification loop:

$ pwsh -File scripts/lint-mirror-integrity.ps1
Mirrors inspected: 100
Violations: 0

Why this generalizes

I'm not the only one running a Blazor/Astro/Next.js site with a JS-hydration layer over a static SEO mirror. The exact tech stack varies. The pattern is universal:

Two representations of the same content
Only one is authoritative (the source)
Only the other is what search engines actually see
Sync is manual or "should be automatic but isn't"

The lint doesn't care about the specific technology. It cares about the semantic co-occurrence in whatever HTML the crawler will see.

Adapt it to your own YMYL (Your-Money-Your-Life) content:

Financial: interest rates, tax brackets, deduction limits, loan terms
Medical: dosage claims, treatment eligibility, side-effect statements
Legal: statute-of-limitations, jurisdiction rules, filing deadlines
Coding tutorials: version-specific API claims ("this works in React 17" while React 19 shipped last month)

Each rule is one entry: a co-occurrence pattern and a fact. Safe indicators are shared across all rules. Both are easy to grow — the day I discover another drift class, I add one entry to the $forbiddenClaims array.

What the lint does not do

Deliberate non-goals:

It does not regenerate mirrors from razors. That's a build-step problem, orders of magnitude bigger. The lint just guards specific known-false claims.
It does not use an LLM. LLM-based fact-checking would be more general but expensive and non-deterministic. Regex + safe-indicator words is deterministic, runs in under a second on 100 files, and costs nothing in CI.
It doesn't check the razor sources. Those are the source of truth. If a razor is wrong, the CA reviewer catches it. The lint's scope is: mirrors must not be worse than razors.

Wire it into CI

.github/workflows/lint-title-parity.yml picked up the new job:

mirror-integrity:
  name: Mirror body-content YMYL integrity
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Run lint-mirror-integrity
      shell: pwsh
      run: pwsh -File ./scripts/lint-mirror-integrity.ps1

Path-filtered to razor/mirror/lint-script paths so it doesn't fire on unrelated pushes. Fails the check on any violation.

What I learned

Three things I didn't expect:

My "manual sweep" felt thorough because I'd fixed the specific phrasings I'd found. I hadn't fixed the pattern. The lint caught what I'd missed because it looked for the pattern, not the phrasing.
Safe-indicator words are the harder half. The forbidden-pattern list was five minutes of work. The safe-indicator list has been iterated three times as new false-positives appeared. Every new indicator I add reduces false positives across every rule.
The first run showed me things I didn't want to see. Discovering four more lies after I thought the crisis was resolved was uncomfortable. But it's exactly why the lint exists. If it never surfaced a real violation, it wouldn't be earning its CI time.

The current state

Six rules cover 80CCD(1B), HRA, Section 24(b), plus a MathSolver-schema guard (a Google-validator gotcha I ran into weeks earlier and don't want to accidentally re-introduce).
Safe-indicators list is at 30-odd terms.
Runs in about 400 ms across 100 mirror files.
Zero current violations. Sitting on main as a tripwire.

The lint is short. The insight is small. But it caught real user-facing YMYL bugs that a human editor and a title-parity lint had both missed. That's a fair trade for 200 lines of PowerShell.

If you're running a Blazor / Astro / Next.js site with a similar hydration pattern and want the full script, the SmartTaxCalc repo is public at github.com/chetan00118/IndiaTaxPlanner. The file is scripts/lint-mirror-integrity.ps1.

If you have a YMYL-content-heavy site and no drift guard, this is your polite nudge.

Six directory emails promised me a dofollow backlink. My 40-line PowerShell verifier said otherwise.

Chetan Sanghani — Wed, 22 Jul 2026 16:56:16 +0000

Every few days now, my inbox gets another version of the same email:

"Hi there! 👋 We discovered your product and think it's a great fit. Submit it and get a high-quality dofollow backlink from a trusted domain."

In one evening last week I got six of them. Different brand names, same pitch. And because I'm chasing external-validation signals for an AdSense approval, "dofollow backlink" is exactly the phrase designed to make me click.

I didn't click. I ran a script instead. This post is:

Why "dofollow" is worth verifying at all (and why the standard SEO guidance is now stale)
The two silent-nofollow discoveries that made me build a verifier (Medium, GitHub)
The 40-line PowerShell verifier itself + the header dance to get past bot-detection
The newer trap: sites that actively claim dofollow — and how the claim falls apart when you check the submission funnel, not just an existing listing

What "dofollow" means, and why it moves

Every <a href="..."> on the web is either dofollow or nofollow. Google treats them very differently:

Dofollow (rel doesn't contain nofollow / ugc / sponsored): the source domain vouches for the destination. Passes SEO "link equity." Counts toward the destination's ranking authority.
Nofollow / UGC / Sponsored: the source domain explicitly declines to vouch. Google largely discounts these for ranking. Still fine for referral traffic and brand exposure — just doesn't move the SEO needle.

For an AdSense-approval situation like mine — where the question is "does this site have external validation from real sources" — dofollow domains matter and nofollow domains are decorative.

The catch: platforms shift policies. What was dofollow in 2020 may be nofollow today, and a cached SEO guide from a few years back gives you the outdated answer with total confidence.

Discovery 1: Medium is now `ugc nofollow`

I republished a home-loan article on Medium expecting the author-bio + in-article links to be dofollow (per most 2020–2022 SEO guides). Curl'd the live article:

curl -sL "https://medium.com/@author/article-slug" `
  -A "Mozilla/5.0" | Select-String -Pattern 'smarttaxcalc'

Result on every anchor:

<a class="z rm" href="https://smarttaxcalc.in/..." rel="noopener ugc nofollow" target="_blank">

That rel="noopener ugc nofollow" is Medium's current platform-wide default (rolled out ~2023–2024 to kill SEO spam). Every outbound link on Medium is nofollow now, including your author-bio link.

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

Same day, I forked an "awesome-personal-finance" repo, added my site, and pushed. Standard advice says: "even if the PR isn't merged, your fork's README anchor is a dofollow link from github.com." Curl the rendered README:

<a href="https://mint.intuit.com/" rel="nofollow">Mint</a>
<a href="https://smarttaxcalc.in" rel="nofollow">SmartTaxCalc</a>

Every external anchor on any GitHub-rendered README is rel="nofollow", platform-wide, since ~2020. Even Mint — a heavyweight fintech domain — is nofollow on the upstream repo. Nothing you can do overrides it.

Both discoveries invalidated ~30 minutes of prep in one afternoon. Both would have been caught by a 30-second check before the work.

The lesson: verify the `rel` before you write

Fetch any existing outbound link on the target platform, look at its rel. If it contains nofollow, that's the blanket policy — no author, no article, no PR overrides it. I didn't want to remember to do this manually every time, so I wrote it into my weekly analytics script.

The verifier — 40 lines of PowerShell

The core loop, minus try/catch scaffolding:

$siteHost = ([Uri]$config.siteUrl).Host   # e.g. "smarttaxcalc.in"

foreach ($src in $config.knownReferringUrls) {
    $resp = Invoke-WebRequest -Uri $src -UseBasicParsing -TimeoutSec 20 `
        -Headers $browserHeaders   # see next section for the header set

    # Match every anchor pointing to our host
    $pattern = '<a[^>]*href="[^"]*' + [regex]::Escape($siteHost) + '[^"]*"[^>]*>'
    $anchors = [regex]::Matches($resp.Content, $pattern,
                [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)

    foreach ($m in $anchors) {
        $tag = $m.Value
        $rel = if ($tag -match 'rel="([^"]*)"') { $Matches[1] } else { '' }

        # Dofollow = no nofollow, no ugc, no sponsored in rel.
        # rel="noopener noreferrer" is fine — security attributes, not SEO.
        $isDofollow = -not ($rel.ToLower() -match '\b(nofollow|ugc|sponsored)\b')

        [pscustomobject]@{
            sourceUrl  = $src
            rel        = $rel
            isDofollow = $isDofollow
        }
    }
    Start-Sleep -Milliseconds 500   # polite pause between hosts
}

config.knownReferringUrls is just a list of URLs where you've published or shared a link back — Medium articles, Dev.to posts, forum threads, directory listings, whatever. Output feeds a scorecard row in my weekly insights.md:

| Dofollow referring domains | 1 | ≥ 5 | 🔴 |

The header dance for Cloudflare-fronted sites

A bare Invoke-WebRequest gets 403'd instantly on Medium, Quora, and anything behind Cloudflare. Even -UserAgent 'Mozilla/5.0' isn't enough. This header set gets me through most sites:

$browserHeaders = @{
    'User-Agent'                = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36'
    'Accept'                    = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'
    'Accept-Language'           = 'en-US,en;q=0.9'
    'Sec-Ch-Ua'                 = '"Chromium";v="121", "Not A(Brand";v="99"'
    'Sec-Ch-Ua-Mobile'          = '?0'
    'Sec-Ch-Ua-Platform'        = '"Windows"'
    'Sec-Fetch-Dest'            = 'document'
    'Sec-Fetch-Mode'            = 'navigate'
    'Sec-Fetch-Site'            = 'none'
    'Upgrade-Insecure-Requests' = '1'
}

The Sec-Ch-Ua* and Sec-Fetch-* headers are what Chrome sends automatically that a bare HTTP client doesn't. Even with the full set, some sites still block on a TLS-fingerprint check Invoke-WebRequest can't spoof — for those the verifier reports ❓ Unknown (fetch blocked) rather than misclassifying. When it can't confirm, it says so.

The newer trap: when the site emails you claiming dofollow

Discoveries 1 and 2 were silent nofollow — platforms that quietly changed policy. The newer pattern is louder: directory sites that email you promising "a high-quality dofollow backlink from a trusted domain." That's the actual selling point in the pitch.

So I did what the verifier taught me — checked an existing listing on one of these networks before submitting. And here's the twist that makes this worth a whole section: the existing listing checked out. Outbound product links carried:

rel="noopener noreferrer"

No nofollow, no ugc. By the rule above, that's dofollow. Naive verdict: "great, submit."

Then I opened the actual submission form. That's where it fell apart:

The free tier's dofollow was conditional. You got it only if your product hit a top-3 daily ranking (which needs a vote campaign), or you embedded their badge on your site — i.e. a reciprocal link exchange, which is a named Google link-scheme pattern, not a free win.
The "guaranteed dofollow" was a paid tier. Buying a dofollow link is, again, squarely against Google's link-scheme guidelines — the last thing you want pointing at a site mid-review.
The free launch slots were exhausted on every available date. The date picker showed "0 free slots" for every day in range. The paid tier's headline perk? "Skip the free queue." The free path wasn't a path; it was a funnel.

The same operator, it turned out, ran several of these under different brand names and emailed me from each. Live listings looked dofollow; the submission was gated behind a condition or a payment.

The lesson upgrade: verify the funnel, not just a listing

Checking an existing listing's rel is necessary but not sufficient. A network can serve genuinely dofollow HTML on its live pages while gating new free submissions behind:

a ranking condition you can't meet without vote-farming,
a reciprocal-badge requirement (link scheme), or
a paid tier (paid link = link scheme).

So the check I run now has two steps:

Listing check (the script above): does an existing outbound link carry a clean rel?
Funnel check (manual, 2 minutes): open the submit form. What tier grants the dofollow? Is the free tier actually available (slots), or zeroed out to push you to pay? Does "free dofollow" require a badge/reciprocal link?

If step 2 says "dofollow only via payment or reciprocity," the answer is no — regardless of what step 1 showed. A paid or reciprocal dofollow isn't just low-value; it's an active risk if Google is looking at your link profile.

Why this matters more than a one-off check

Platform policies drift one-way, and you find out via ranking drops, not announcements: LinkedIn nofollow ~2016, Twitter 2019, Quora 2022, Medium ~2023–2024, GitHub READMEs ~2020. Any pre-2023 SEO guide is potentially wrong about at least one. And the newer directory-spam layer means the claim of dofollow is now marketing copy, not a fact — the fact lives in the rel attribute and the submission funnel.

Two rules I now live by:

Nobody's claim of "dofollow" counts. The rel attribute counts.
An existing listing's rel isn't the offer. The submission tier is the offer — check it.

Steal the pattern

The verifier runs alongside my GSC / GA4 / Bing / PageSpeed fetches — one script, one double-click, all marketing signals in one place. Two changes to fit your setup:

Point $config.siteUrl and $config.knownReferringUrls at your domain + your list.
For 403-heavy platforms, either add retry logic or just report them Unknown (I do the latter — I already know their policies).

If you're a solo founder shipping links across platforms and hoping some count toward SEO: run the listing check weekly, run the funnel check before every submission, and stop being surprised.

I'm Chetan Sanghani, building SmartTaxCalc.in — a free, browser-based Indian tax + finance calculator platform. Previously wrote about Google's MathSolver JSON-LD validator quirks, dropping mobile LCP under 2s on Blazor WASM, and a self-cleaning Product Hunt teaser banner.

Launching SmartTaxCalc on Product Hunt today 🚀

Chetan Sanghani — Sat, 18 Jul 2026 07:43:26 +0000

Just went live on Product Hunt: SmartTaxCalc — 38 free Indian tax + finance calculators

If you've followed my previous writeups on the Blazor WASM + Cloudflare Pages stack, this is the culmination — 38 tools, 30+ blog articles, all client-side, CA-reviewed, no signup, no data collection.

What's live

Live tools: smarttaxcalc.in — free forever, mobile-friendly, works offline once loaded (Blazor WASM caches locally)
PH launch page: producthunt.com/products/smarttaxcalc — upvotes appreciated 🙏

What I learned (5 quick engineering wins from the build)

LCP preload trick — a 5.6 KB JSON at the tail of Blazor's critical chain was costing 5.5s of "element render delay." One <link rel="preload"> in <head> fixed it.
Getting LCP under 2s on Blazor WASM — six mechanical fixes across a weekend, real commit hashes + before/after numbers.
Self-cleaning PH teaser banner in Blazor — 100 lines, auto-hides after launch date via DateTime.UtcNow < KillDateUtc in OnInitialized. No manual removal.
GSC's MathSolver JSON-LD validator is stricter than Schema.org — learned the hard way that "valid according to schema.org" ≠ "valid according to Google's Rich Results validator."
Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier that curls each referring page + greps for rel="nofollow". Now runs nightly.

The stack

Blazor WebAssembly on Cloudflare Pages (free tier)
Pre-rendered static HTML mirrors for SEO (crawler sees content immediately, Blazor hydrates on top for interactivity)
No backend — every calculation runs client-side in the browser
No signup, no email capture, no data sent to any server
CA-reviewed by an ICAI-registered Chartered Accountant (Ankitkumar Italiya, membership 644575)
91 razor pages, 91 matching static mirrors, title-parity enforced by pre-commit lint

Total spend to date: ~$0 (Cloudflare Pages free tier + a domain).

Ask

If you're a Blazor dev, Indian expat/NRI, or anyone in the CA/tax space — please:

Upvote on Product Hunt if the tool looks useful
Try it at smarttaxcalc.in — 38 calculators to explore
Reply here with feedback on the tech choices — always curious about how others approach Blazor SEO / CWV / SPA deployment

Also: if there's a specific Blazor architectural pattern you want a deep-dive on (like "how to prerender content that Blazor also renders without double-render CLS issues"), drop a comment. Article #7 in the series is TBD.

Thanks for the support 🙏

One cut my Blazor WASM LCP by 500ms — the invisible file at the end of the critical chain

Chetan Sanghani — Fri, 17 Jul 2026 16:19:20 +0000

Two weeks ago I wrote about getting my Blazor WebAssembly site's LCP under 2 seconds. I thought I was done.

I wasn't.

Last week I ran a fresh PageSpeed Insights audit and saw this:

FCP:  0.3s   ✅ Great
LCP:  3.5s   ⚠️ Needs Improvement
TBT:  2,360ms 🔴 Poor

FCP was 0.3 seconds. Something was painted in under a third of a second. So how was LCP 3.5 seconds? What was the browser waiting for?

The "LCP breakdown" panel in PageSpeed had the answer:

Subpart              Duration
Time to first byte   0 ms
Element render delay 5,500 ms

5.5 seconds of "element render delay." Not download time. Not parse time. Not layout. Something was preventing the browser from painting the LCP element for five and a half seconds after it was ready.

Let me walk through the diagnosis and the three-line fix.

The "Network dependency tree" was the smoking gun

PageSpeed Insights has an under-appreciated panel: Network dependency tree. It shows the critical request chain — every resource the browser had to fetch before it could paint the LCP element.

Mine looked like this (edited for brevity):

Maximum critical path latency: 5,464 ms
Initial Navigation
  https://smarttaxcalc.in       169 ms   14.6 KiB
  /js/site-helpers.js          251 ms    8.7 KiB
  /_framework/dotnet.js         642 ms   17.5 KiB
  /_framework/dotnet.runtime… 740 ms   57.7 KiB
  /data/tax-rules.json       5,464 ms    5.6 KiB   ← ??
  /_framework/dotnet.native…    719 ms   37.9 KiB
  /_framework/dotnet.native…wasm  920 ms  1,155.7 KiB
  ... 40 more .wasm files ...

Notice the /data/tax-rules.json line. 5.6 KB. 5,464 ms wall-clock.

That file is tiny. Downloading it should take a few hundred milliseconds max. Why was the wall-clock 5.5 seconds?

Because the browser was fetching it at the end of the chain, after all 43 .wasm assembly files had finished loading.

Why this happens on every Blazor WASM app

Blazor WebAssembly's boot sequence is roughly:

Browser fetches index.html.
Parses <script src="_framework/blazor.webassembly.js"> — starts downloading.
blazor.webassembly.js downloads and starts running.
It fetches blazor.boot.json (the manifest of runtime + your assemblies).
It fetches all the .wasm files in parallel.
It instantiates the runtime.
It starts your Program.cs main.
Your DI container resolves services, including HttpClient.
Your app's initial render kicks off.
Now any HttpClient.GetFromJsonAsync("/data/tax-rules.json") call runs.

Step 10 sits at the end of the wall-clock, waiting for everything above it to finish.

If your app renders content that depends on that JSON — in my case a tax slabs table that's a large above-fold element — LCP does not fire until step 10 completes.

FCP fires much earlier because the pre-rendered static HTML is painted at step 1. But LCP measures the LARGEST content, and Blazor re-paints the largest content only after step 10.

The fix — three lines in `index.html`

The browser has no idea /data/tax-rules.json is on the critical path until Blazor's runtime asks for it. But we can tell it, using a <link rel="preload"> hint at the very top of <head>.

Here's the diff:

<!-- Preload critical assets -->
<link rel="preload" href="_framework/blazor.webassembly.js?v=..." as="script" fetchpriority="high" />

<!-- NEW: Preload tax-rules.json — end of Blazor's critical request chain -->
<link rel="preload" href="data/tax-rules.json" as="fetch" fetchpriority="high" crossorigin />

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin />

Three attributes matter:

as="fetch" — matches the HttpClient.GetFromJsonAsync() request that will happen later. Without this, the browser preloads it as the wrong type and skips using the cached copy.
fetchpriority="high" — hints that the browser should start this fetch immediately, not wait until the current parse yields.
crossorigin — required for as="fetch" preloads to match a CORS-enabled fetch. Even for same-origin, Blazor's HttpClient sends CORS-mode requests.

Before / after (real numbers, mobile Lighthouse, Slow 4G throttled)

Metric	Before	After	Delta
FCP	0.4s	0.3s	▼25%
LCP	1985ms	1518ms	▼467ms
Element render delay	5,500ms	180ms	▼97%
Network critical path latency	5,464ms	106ms	▼98%
CLS	0	0	same

The 5,500ms element render delay collapsed to 180ms. LCP dropped 467ms on mobile.

Verified a day later via the PageSpeed Insights API in my nightly analytics fetch — the improvement stuck across measurements.

When this pattern applies

Anywhere in your Blazor WASM app you're doing something like:

// Program.cs or a startup component
protected override async Task OnInitializedAsync()
{
    var config = await Http.GetFromJsonAsync<TaxConfig>("data/tax-rules.json");
    // ...
}

If that JSON blocks the first meaningful render (i.e., the LCP element depends on it), preload it in <head>. The file can be:

A JSON config file
A CSV/TSV data file
A pre-computed lookup table
Any other static resource under wwwroot/ that Blazor fetches during boot

If the file is under 20 KB it costs nothing to preload. If it's larger, weigh the bandwidth cost against the LCP win.

The trap I fell into first — assuming Blazor boot was fixed cost

I spent months blaming Blazor for slow LCP. Every diagnosis started with "Blazor WASM is inherently 3-4 seconds to boot."

That's true in the aggregate. But the aggregate hid the fact that one specific 5.6 KB file was sitting at the tail of the chain, single-handedly adding 3+ seconds to my perceived boot time.

If I'd read the "Network dependency tree" panel two months earlier, I would have shipped this fix in October.

Look at that panel first. Every time.

Anti-pattern — don't preload everything

You get one or two "high priority" preload slots that meaningfully move the needle. If you preload every static asset:

The browser can't prioritise the truly critical ones.
Bandwidth for blazor.boot.json (which is the actual entry point) gets contended.
Lighthouse will flag "Unused preload" audits.

Rule of thumb: preload only resources that would otherwise be at the end of the critical chain — meaning Blazor's runtime asks for them AFTER everything else is done.

Bonus lessons from the same optimization pass

While I was at it, I also tried:

Enabling <RunAOTCompilation>true</RunAOTCompilation> — Cloudflare Pages CI build failed silently ("No deployment available"). Turns out the CI environment ships the base .NET SDK without the wasm-tools workload, and dotnet workload restore in a MSBuild target doesn't pull the emcc + binaryen native binaries. Reverted the same night. If you're on GitHub Actions with proper toolchain, this is worth trying.
Deferring Google Analytics until first user interaction — moved 275ms of gtag.js main-thread evaluation out of Lighthouse's measurement window. TBT dropped ~500ms. Real users still get tracked as soon as they interact.
Disabling Cloudflare Web Analytics beacon — 11 KB + 17ms main thread. Redundant if you already use GA4. Toggle it off in the Cloudflare dashboard under Analytics → Web Analytics.

Combined with the preload fix, my mobile Performance score went from 47 (desktop) → 73 (mobile) with mobile LCP firmly in the "Good" range.

Desktop LCP is still 3.5s though, and that's a longer story — Blazor SPAs replace pre-rendered content on wider viewports differently. That'll be article #6.

If you're on Blazor WebAssembly and your LCP feels stuck, open PageSpeed Insights, scroll to the Network dependency tree, and look at the last line. There's probably a 5 KB file sitting there costing you seconds.

The site: smarttaxcalc.in — a free Indian tax + finance calculator platform. 38 tools, CA-reviewed, all Blazor WebAssembly.

Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier

Chetan Sanghani — Thu, 09 Jul 2026 17:17:00 +0000

I burned about 30 minutes of work on Monday shipping content to Medium and GitHub in the belief they'd give me dofollow backlinks. Both turned out to be platform-wide nofollow. Both discoveries came from a single curl command that I should have run before the work, not after.

This post is: (1) the two discoveries and why the standard SEO guidance is now stale, (2) the 40-line PowerShell verifier I wrote so I never make the mistake again, and (3) the specific header dance you need to actually get past bot-detection on Medium and Quora.

What "dofollow" means, and why it moves

Every <a href="..."> on the web is either dofollow or nofollow. Google (and other search engines) treats them very differently:

Dofollow (rel doesn't contain nofollow / ugc / sponsored): the source domain vouches for the destination. Passes SEO "link equity." Counts toward how Google decides the destination's ranking authority.
Nofollow / UGC / Sponsored: the source domain explicitly declines to vouch. Google largely discounts these for ranking purposes. Still useful for referral traffic and brand exposure, but doesn't move the SEO needle.

For an AdSense-approval situation like mine — where reviewers look at "does this site have external validation from real sources" — dofollow domains matter. Nofollow domains are decorative.

Now the catch: platforms shift policies. What was dofollow in 2020 may be nofollow today, and cached SEO guides from a few years back get you the outdated answer.

Discovery 1: Medium is now `ugc nofollow`

I republished a Section 24(b) home-loan article on Medium, expecting the author-bio + in-article links to be dofollow (per most SEO guides from 2020-2022). Curl'd the live article:

curl -sL "https://medium.com/@author/article-slug" `
  -A "Mozilla/5.0" | Select-String -Pattern 'smarttaxcalc'

Result on every anchor:

<a class="z rm" href="https://smarttaxcalc.in/..." rel="noopener ugc nofollow" target="_blank">

That rel="noopener ugc nofollow" is Medium's current default — they rolled it out platform-wide around 2023-2024 to kill SEO spam. Every outbound link on Medium is now nofollow, including your author-bio link. Google discounts them all.

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

Same day, I forked an "awesome-personal-finance" repo, added SmartTaxCalc to the list, and pushed. Standard SEO advice says: "even if the PR isn't merged, your fork at github.com/YOUR-USER/awesome-XXX/README.md still has the anchor to your site — that's a dofollow link from github.com."

Wrong, at least since ~2020. Curl the rendered README:

<a href="https://mint.intuit.com/" rel="nofollow">Mint</a>
<a href="https://smarttaxcalc.in" rel="nofollow">SmartTaxCalc</a>

Every external anchor on any GitHub-rendered README is rel="nofollow". GitHub applies this platform-wide to reduce link-farming via repo forks. Even Mint on the upstream repo (a heavily authoritative domain in the fintech space) is nofollow. There's nothing you can do to force it dofollow.

Both discoveries invalidated ~30 minutes of preparation work in the same afternoon. The Medium article was still worth publishing (referral traffic + canonical protection so Medium doesn't outrank the original), but I wouldn't have spent time on the GitHub PR pack if I'd known.

The lesson: curl before you write

Both would have been caught by a 30-second check before the work: fetch any existing outbound link on the target platform, look at its rel attribute. If it contains nofollow, that's the platform's blanket policy — no author, no article, no PR can override it.

But I don't want to remember to do this manually every time. So I wrote it into my weekly analytics script. Every Sunday, along with GSC/GA4/Bing exports, the script now curls every referring URL I care about and reports which anchors are dofollow vs nofollow.

The verifier — 40 lines of PowerShell

The core loop, minus try/catch scaffolding:

$siteHost = ([Uri]$config.siteUrl).Host   # e.g. "smarttaxcalc.in"

foreach ($src in $config.knownReferringUrls) {
    $resp = Invoke-WebRequest -Uri $src -UseBasicParsing -TimeoutSec 20 `
        -Headers $browserHeaders   # see next section for the header set

    # Match every anchor pointing to our host
    $pattern = '<a[^>]*href="[^"]*' + [regex]::Escape($siteHost) + '[^"]*"[^>]*>'
    $anchors = [regex]::Matches($resp.Content, $pattern,
                [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)

    foreach ($m in $anchors) {
        $tag = $m.Value
        $rel = if ($tag -match 'rel="([^"]*)"') { $Matches[1] } else { '' }

        # Dofollow = no nofollow, no ugc, no sponsored in rel.
        # rel="noopener noreferrer" is fine — it's a security attribute, not SEO.
        $isDofollow = -not ($rel.ToLower() -match '\b(nofollow|ugc|sponsored)\b')

        [pscustomobject]@{
            sourceUrl  = $src
            rel        = $rel
            isDofollow = $isDofollow
        }
    }
    Start-Sleep -Milliseconds 500   # polite pause between hosts
}

config.knownReferringUrls is just a list of URLs where you've published or shared a link back to your site — Medium article URLs, Quora answer URLs, Dev.to posts, forum posts, whatever.

Output goes into a CSV (backlink-rel-verification.csv) and — this is where it stops being just a report — feeds a scorecard row in my weekly insights.md:

| Dofollow referring domains | 1 | ≥ 5 | 🔴 |

If Medium ever does switch back to dofollow (unlikely), or a new post I published turns out to be a hidden dofollow win, I'll see it in Sunday's report without doing anything. Same in reverse: if a platform I currently count as dofollow shifts to nofollow silently, the scorecard row updates.

The header dance for Medium and Quora

The naive Invoke-WebRequest -Uri $url -UseBasicParsing gets 403'd immediately on Medium, Quora, and any Cloudflare-fronted site. Even adding -UserAgent 'Mozilla/5.0' isn't enough — they check other headers too.

This is the header set that gets me through most sites:

$browserHeaders = @{
    'User-Agent'                = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36'
    'Accept'                    = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'
    'Accept-Language'           = 'en-US,en;q=0.9'
    'Accept-Encoding'           = 'gzip, deflate, br'
    'Sec-Ch-Ua'                 = '"Chromium";v="121", "Not A(Brand";v="99"'
    'Sec-Ch-Ua-Mobile'          = '?0'
    'Sec-Ch-Ua-Platform'        = '"Windows"'
    'Sec-Fetch-Dest'            = 'document'
    'Sec-Fetch-Mode'            = 'navigate'
    'Sec-Fetch-Site'            = 'none'
    'Sec-Fetch-User'            = '?1'
    'Upgrade-Insecure-Requests' = '1'
}

The Sec-Ch-Ua* and Sec-Fetch-* headers are what Chrome sends automatically that a bare HTTP client doesn't. Without them, Cloudflare's bot detection has a very high true-positive rate on your requests.

Even with the full set, Medium and Quora still block on my Windows box — probably a TLS fingerprint check that Invoke-WebRequest can't spoof (curl.exe fails the same way). For those, the verifier reports ❓ Unknown (fetch blocked) rather than misclassifying as nofollow. When it can't confirm, it says so.

What the scorecard actually shows

Running against 6 known referring URLs — 3 Dev.to articles, 1 Medium republish, 1 GitHub Awesome-List fork, 1 Quora answer:

| Source     | Rel                     | Dofollow?               |
|------------|-------------------------|-------------------------|
| dev.to     | noopener noreferrer     | ✅ Yes (x10 anchors)    |
| medium.com | (fetch blocked 403)     | ❓ Unknown              |
| github.com | nofollow                | ❌ No                   |
| quora.com  | (fetch blocked 403)     | ❓ Unknown              |

Unique dofollow referring domains: 1 (dev.to). Both Medium and GitHub, which I thought would boost this count to 3, contribute zero. The Quora and Medium fetch blocks aren't a huge loss — I already know from a prior manual curl (on a Linux box with a different TLS fingerprint) that both are nofollow.

Why this matters more than a one-off check

Two reasons.

One: platform policies drift, and you find out via ranking drops rather than an announcement. LinkedIn made outbound links nofollow around 2016. Twitter went nofollow in 2019. Medium moved to ugc nofollow around 2023-2024. Quora went nofollow-by-default in 2022. GitHub went nofollow on README external links around 2020. The pattern is one-way — platforms don't go back to dofollow. Any pre-2023 SEO guide you're reading is potentially wrong about at least one of these.

Two: if you publish enough content across enough platforms, you lose track. I have 3 Dev.to articles, 2 Quora answers, 34 LinkedIn Company Page posts, 1 Medium republish, and 1 GitHub fork. Manually curling each one every Sunday to check the rel attribute is real work. Encoding it into the analytics script — 40 lines of PowerShell — means it becomes a green/red row on the weekly report, and I only pay attention when something changes.

Steal the pattern

The full script lives in SmartTaxCalc's analytics folder (search for BACKLINK REL-ATTRIBUTE VERIFIER). It runs alongside GSC / GA4 / Bing / PageSpeed fetches — one script, one double-click, all your marketing signals in one place.

Two changes to make it fit your setup:

Change $config.siteUrl and $config.knownReferringUrls to your domain + your list
Depending on your platform mix, you might want to add retry logic for the 403-heavy platforms — I chose to just report them as Unknown because I already know their policies

If you're an indie hacker or solo founder shipping content to multiple platforms and hoping some of them count toward your SEO signal, run this once a week and stop being surprised.

A self-cleaning Product Hunt teaser banner in Blazor WASM — 100 lines, auto-hides after launch, GA4-tracked

Chetan Sanghani — Mon, 06 Jul 2026 15:47:16 +0000

I'm launching SmartTaxCalc.in on Product Hunt on Tuesday, 14 July 2026. It's a 38-tool Blazor WebAssembly tax + finance calculator I've written about here before (the SEO/schema saga, and dropping mobile LCP from 6-8s to under 2s).

The Product Hunt launch algorithm heavily rewards products that arrive with a real coming-soon follower base — day-of upvotes correlate strongly with pre-launch "Notify me" clicks. My PH page started with 1 follower. I had 9 days to get to 50+.

The obvious answer: post on LinkedIn, ask friends, DM your network. All of that has ceilings (you can only ask a favor once). The non-obvious answer that has no ceiling: convert your own organic search traffic into PH followers automatically.

This is the ~100 lines of Blazor code that does that, plus the design decisions I made along the way. It's also self-cleaning — after the launch date, the banner disappears with no manual work required. Steal the pattern for your own launch.

The problem

SmartTaxCalc gets modest but real organic traffic — mostly from Google Search Console impressions on tax-season queries. That traffic is the warmest possible audience for a PH launch (they already found the site, they're in the target demo). But how do you route them to a PH page without:

Disrupting the tax content (they came for a tax calculator, not a marketing pitch)
Cannibalizing the existing tax-season banner (which drives users to /tax-calendar/ — a real retention lever)
Leaving code debt after 14 July (a dead PH banner still on the site in September)
Losing the dismiss preference across page navigations (SPA reality — no page refresh)

Those constraints ruled out a modal, a full-width interrupt, and a "hardcoded remove after launch" approach.

The design

Slim horizontal bar at the top of every page. Sits ABOVE the existing tax-season banner. PH-brand orange, different from the tax-season banner's yellow/red so both are visually distinguishable when stacked. Dismissible per-user via localStorage. Auto-hides after a hard kill date. GA4 events on click + dismiss for measurement.

Structurally, it mirrors the existing TaxSeasonBanner.razor conventions (same DOM shape, same a11y attributes) so the two components have consistent tab-order and screen-reader behavior when both are visible.

The component

Shared/ProductHuntTeaserBanner.razor:

@inject IJSRuntime JS

@if (Visible && !Dismissed)
{
    <aside class="ph-teaser-banner" role="complementary"
           aria-label="Product Hunt launch teaser">
        <div class="ph-teaser-banner-content">
            <span class="ph-teaser-banner-icon" aria-hidden="true">🚀</span>
            <span class="ph-teaser-banner-text">
                <strong>Launching on Product Hunt Tue 14 July</strong>
                <span class="ph-teaser-banner-sub">Follow to get notified when we go live.</span>
            </span>
            <a class="ph-teaser-banner-cta"
               href="https://www.producthunt.com/products/smarttaxcalc"
               target="_blank"
               rel="noopener"
               @onclick="OnCtaClicked">
                Notify me on PH →
            </a>
            <button class="ph-teaser-banner-close"
                    @onclick="OnDismissClicked"
                    aria-label="Dismiss Product Hunt teaser"
                    type="button">&times;</button>
        </div>
    </aside>
}

@code {
    // Kill date: banner stops showing after this instant regardless of dismissal state.
    // 2026-07-14 23:59 IST = 18:29 UTC — one full day AFTER launch so day-of visitors
    // see it, but 07-15 onwards is clean.
    private static readonly DateTime KillDateUtc =
        new DateTime(2026, 7, 14, 18, 29, 0, DateTimeKind.Utc);

    private const string DismissKey = "ph-teaser-dismissed-2026-07-14";

    private bool Visible;
    private bool Dismissed;

    protected override void OnInitialized()
    {
        // Server-side timing gate. If we're past the kill date, don't render at all —
        // no localStorage check needed, no re-render churn, no bytes shipped.
        Visible = DateTime.UtcNow < KillDateUtc;
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender && Visible)
        {
            try
            {
                var dismissed = await JS.InvokeAsync<string?>(
                    "localStorage.getItem", DismissKey);
                if (dismissed == "1")
                {
                    Dismissed = true;
                    StateHasChanged();
                }
            }
            catch
            {
                // localStorage unavailable (private mode, edge cases) — banner just shows.
                // Failing "open" is better than failing "hidden" for a follower-growth tool.
            }
        }
    }

    private async Task OnCtaClicked()
    {
        try
        {
            await JS.InvokeVoidAsync("trackEvent", "ph_teaser_cta_clicked",
                new { launch = "2026-07-14" });
        }
        catch { }
    }

    private async Task OnDismissClicked()
    {
        Dismissed = true;
        try
        {
            await JS.InvokeVoidAsync("localStorage.setItem", DismissKey, "1");
            await JS.InvokeVoidAsync("trackEvent", "ph_teaser_dismissed",
                new { launch = "2026-07-14" });
        }
        catch { }
        StateHasChanged();
    }
}

That's the whole thing. About 90 lines of C# + Razor including comments and whitespace.

Design decisions worth calling out

Kill-date is server-side, dismiss is client-side

The OnInitialized gate runs in Blazor's render tree before any HTML is emitted. After 2026-07-14 18:29 UTC, the whole <aside> never renders — no wasted bytes, no dead DOM, no need for the JS to check anything.

The dismiss check has to be client-side because it depends on the user's localStorage. So it lives in OnAfterRenderAsync and updates via StateHasChanged if the user previously dismissed.

This split matters. If I'd tried to do the kill-date check client-side too, I'd have shipped the banner HTML to every user post-launch, then hidden it with JS — wasteful and briefly visible during hydration. Server-side gate is free.

localStorage key is versioned by launch

private const string DismissKey = "ph-teaser-dismissed-2026-07-14";

The -2026-07-14 suffix means my next PH launch (if I do a re-launch or feature launch later) uses a different key — users who dismissed the July teaser will still see the future teaser. No dismiss-forever bug.

Failing open, not closed

The try/catch around localStorage.getItem:

catch
{
    // localStorage unavailable (private mode, edge cases) — banner just shows.
}

If localStorage throws (Safari private mode, ITP restrictions, some enterprise browsers), we DON'T hide the banner — we show it. For a follower-growth tool, false-positive display beats false-negative hiding.

Kill date uses UTC everywhere

The Cloudflare Pages server runs in UTC. The user's browser could be in any timezone. Blazor WASM runs in the browser but I'm doing the check at component initialization which happens after WASM boots — timezone at that point depends on how Blazor was invoked. Sticking with DateTime.UtcNow + a UTC kill-date instant sidesteps every possible drift.

The CSS — matching existing patterns

.ph-teaser-banner {
    background: linear-gradient(135deg, #ff6b35, #da552f);  /* PH brand orange */
    color: #ffffff;
    padding: 0.5rem 1rem;
    font-size: 0.9rem;
    line-height: 1.35;
    border-bottom: 1px solid rgba(255, 255, 255, 0.15);
}
.ph-teaser-banner-content {
    max-width: 1200px;
    margin: 0 auto;
    display: flex;
    align-items: center;
    gap: 0.75rem;
    flex-wrap: wrap;
}
.ph-teaser-banner-cta {
    background: rgba(255, 255, 255, 0.15);
    color: #ffffff;
    font-weight: 700;
    padding: 0.35rem 0.75rem;
    border-radius: 4px;
    border: 1px solid rgba(255, 255, 255, 0.35);
    min-height: 32px;
    display: inline-flex;
    align-items: center;
}
.ph-teaser-banner-close {
    background: transparent;
    border: 0;
    color: inherit;
    font-size: 1.5rem;
    cursor: pointer;
    padding: 0 0.25rem;
    opacity: 0.75;
    min-width: 32px;
    min-height: 32px;
}
.dark-mode .ph-teaser-banner {
    background: linear-gradient(135deg, #c94820, #a83a1b);
}

Two things worth noting:

32×32 minimum touch targets on the CTA and dismiss button (WCAG 2.5.5 — Success Criterion for touch target size). This is easy to forget on slim horizontal bars where the visual height is smaller. The button padding + min-height: 32px guarantees the tap area meets the standard.

Dark-mode variant because SmartTaxCalc has a full dark-mode toggle. Any new component that ships without a .dark-mode .foo variant looks jarring for the ~30% of users on dark mode.

Wiring into layout

Layout/MainLayout.razor — one line, above the existing tax-season banner:

<header class="app-header">...</header>

@* PH launch teaser — active 2026-07-05 → 2026-07-14 EOD IST *@
<ProductHuntTeaserBanner />

@* Tax-season-aware banner — May-Jul ITR, Dec advance tax, Mar year-end *@
<TaxSeasonBanner />

<main class="main-content">
    @Body
</main>

Stacking order matters. PH banner is time-critical (9-day window), tax banner is a permanent retention CTA. Time-critical goes on top.

The cache-buster gotcha

Cloudflare Pages caches CSS aggressively. Deploying the new CSS with the same filename means returning users don't see the new styles until their browser cache expires (often hours or days).

Every CSS/JS reference on the site uses a query-string version:

<link href="/css/app.css?v=20260705a" rel="stylesheet" fetchpriority="high" />
<link rel="preload" href="/_framework/blazor.webassembly.js?v=20260620j" as="script" />

On any deploy that ships new CSS, bump the v= string. I ran this one-liner to update every static HTML file in the wwwroot mirror:

perl -i -pe 's|app\.css\?v=20260703a|app.css?v=20260705a|g' `
  $(grep -rlE 'app\.css\?v=20260703a' frontend/web/TaxPlanner.Web/wwwroot/)

Skipping this step meant users on returning-visit cache would see the banner in DOM (Blazor renders it) but with no styles — invisible text/button on a normal background. Nothing worse than a launch banner that only works for first-visit users.

The telemetry

Two GA4 events I care about:

ph_teaser_cta_clicked — fires when the user clicks "Notify me". This is the metric that matters. It correlates directly with PH follower growth.
ph_teaser_dismissed — fires when the user clicks the ×. If this is >30% of impressions, the banner is annoying and I should tune it.

I don't track banner impressions separately — Blazor renders it if OnInitialized allows AND the user hasn't dismissed. Impression count = pageview count from GA4 minus ph_teaser_dismissed count minus post-kill-date pageviews.

Realistic conversion math

Here's the funnel math I set targets against:

Daily organic pageviews on SmartTaxCalc: ~50-80 (Indian tax queries)
Percent of pageviews that click Notify me: 2-5% (informed guess; will measure)
Expected daily new followers: 1-4 from the banner alone
Nine days of banner active pre-launch: 9-36 followers
Combined with LinkedIn + personal DMs: target 50+

50 pre-launch followers is the informal PH threshold for "you have a shot at Top 20 of the day." Below 20 and the launch is dead on arrival. Above 100 and you're guaranteed Top 10 barring a bad launch-day thumbnail.

What I skipped

Modal/interrupt version: kills UX for the tax content (users came for a calculator, not a launch pitch)
Cookie banner-style at page bottom: lower click-through, competes visually with the actual cookie consent banner
Homepage-only version: 60% of my traffic lands on deep pages (calculator URLs from Google), not the homepage
Manual removal after launch: not scalable if I do another launch later — kill-date automates the "remove" step

Two takeaways

1. Time-bounded UI needs a self-cleaning mechanism from day one. Every "temporary" banner I've seen without a kill date has ended up living on production long past its usefulness. The kill-date constant is 3 lines of code and saves you a manual removal PR.

2. Convert your own traffic before you buy other people's. LinkedIn ads, PH-influencer shoutouts, upvote-swap groups — all lower conversion than your own site visitors who already trust you. If you're launching anything, this component (or the equivalent in your stack) is the highest-leverage growth code you can ship.

The launch itself

If you use tax calculators or you're a founder / indie hacker who wants to follow the launch curve, click Notify me on our PH page. Launch is Tuesday 14 July 2026 at 12:01 AM PDT (12:31 PM IST).

If this banner pattern is useful, feel free to lift it. Blazor + Razor + a few lines of CSS is all it takes.

About me: I'm Chetan Sanghani — I build SmartTaxCalc, a free CA-reviewed Indian tax calculator platform. This is my third article on Dev.to in the "Building SmartTaxCalc" series. Previous posts:

How I got LCP under 2s on a 38-page Blazor WebAssembly site (Cloudflare Pages)

Chetan Sanghani — Sat, 04 Jul 2026 11:06:06 +0000

I run SmartTaxCalc.in — a free Indian tax calculator platform built as a Blazor WebAssembly SPA on Cloudflare Pages. 38 tools, 20+ blog articles, all client-side. Very static, very cheap to host, easy to iterate.

For the first several months, mobile Largest Contentful Paint (LCP) was 6-8 seconds. That's failing Core Web Vitals by a mile. Every Lighthouse run screamed at me. And every SEO agency told me the same three things:

"It's Blazor. It's slow. Rewrite in Next.js."

Yeah, no. I like Blazor. I've shipped .NET for a decade. I don't want to rewrite for the sake of a Lighthouse score.

So over one weekend I ran a proper performance pass. Six mechanical fixes, six commits, mostly one-liners. By the end of it, mobile LCP was under 2 seconds — well inside the "Good" threshold — on every measured page.

Here's exactly what worked. Real commit hashes, real numbers, and honest notes on what didn't help.

The setup — what "LCP on Blazor WASM" actually means

Blazor WebAssembly is a Single Page Application. The initial HTML is a small shell (index.html) with a <base href="/">, some CSS <link> tags, and a <script src="_framework/blazor.webassembly.js">. That JavaScript downloads the .NET runtime, your app DLLs, and boots the Blazor renderer, which then constructs the DOM.

LCP is measured on the largest content element rendered above the fold. On a fresh Blazor site, that element usually doesn't exist until Blazor finishes booting and renders your first component. So "LCP" and "time-to-Blazor-hydrated" tend to be the same thing.

That said — a well-architected Blazor site with static HTML mirrors (pre-rendered content) can have LCP fire on the static content BEFORE Blazor hydrates, using Blazor purely for interactivity. That's the model my site uses.

So the LCP battle here is really a "get the browser to render the largest text/image element as fast as possible" battle. Blazor still boots, but LCP doesn't wait for it.

Before numbers — Lighthouse mobile, throttled 4G, Moto G4 CPU

Page	Mobile LCP (before)
Homepage	~6.2s
Tax calculator (deep interactive page)	~7.8s
Blog article (mostly static content)	~5.9s

The 6-8s range is what you get when you serve unminified CSS, ship a service worker that races the main thread, and don't preconnect to your CDN edges.

Fix 1: Delete the service worker (commit `910c606`)

The counter-intuitive one.

I originally shipped a service worker in June 2026 to fix a different bug (stale HTML cache after a build-tool migration). The SW's activate handler would detect its own version, unregister itself, and clear all caches. It was a one-time cleanup for existing users who were pinned to the old broken cache.

Two weeks later, every recurring visitor had had that cleanup fire. New visitors didn't need a service worker at all — but I was still registering one on every page load.

// Before — every page did this
if ('serviceWorker' in navigator && location.hostname !== 'localhost') {
    navigator.serviceWorker.register('/service-worker.js?v=cleanup-20260613', {
        updateViaCache: 'none'
    }).catch(function () {});
}

Removing that block saved:

One network request (/service-worker.js)
~50-100ms of post-load main-thread work as the browser evaluates the SW script
One CPU spike that competed with Blazor's own boot

Impact: ~200ms LCP win.

I left the service-worker.js file in wwwroot for now — old bookmarks that had registered the SW will still fetch it and run the self-unregister logic. That's a slow-decay migration, safe to leave.

Fix 2: Removed a version-check IIFE that force-reloaded users (commit `910c606`)

This one hurt when I found it.

Buried in index.html was a small self-invoking function that read a version field from /version.json, compared it to a value stored in localStorage, and if they mismatched, called location.reload(true) — a hard reload.

The intent was noble: force existing users to fetch new HTML after each deploy so they'd never see stale content. But the effect on a first-visit user was:

Browser fetches index.html
Browser starts parsing → hits the IIFE
IIFE fetches /version.json
IIFE reads localStorage, finds no version stored → sets oldVersion = null
IIFE sees null !== '20260620j' → calls location.reload(true)
Browser tears down the entire page and starts over. LCP timer resets.

The first-visit user was silently reloading their own page before LCP could fire. Which meant their LCP was measured on the SECOND load, but the timer count-up started from the FIRST navigation. Result: catastrophic LCP.

Deleted the IIFE entirely. LCP-first-visit dropped by an estimated 2 seconds.

Impact: ~2000ms LCP win on first visits.

Fix 3: Preconnect coverage on 7 pages that were missing (commit `910c606`)

<link rel="preconnect"> and <link rel="dns-prefetch"> don't do anything visible, but on a slow mobile connection they save hundreds of milliseconds by opening DNS + TCP + TLS connections to third-party origins BEFORE the browser actually needs them.

I had preconnect hints on the homepage and some tools, but 7 static HTML mirrors were missing them entirely. Namely:

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="preconnect" href="https://pagead2.googlesyndication.com" crossorigin>
<link rel="dns-prefetch" href="https://adservice.google.com">
<link rel="dns-prefetch" href="https://ep1.adtrafficquality.google">

These are the origins my site talks to for analytics + AdSense (site-wide). Without preconnect, the browser has to do the DNS lookup + TCP handshake + TLS negotiation only when the first request to those origins fires — which is AFTER my HTML is fully parsed.

With preconnect, those handshakes happen IN PARALLEL with HTML parsing. On a 4G mobile connection, that's ~300-500ms saved.

Added the four preconnect/dns-prefetch lines to every static HTML mirror. Nothing fancy.

Impact: ~300ms LCP win on cold pageviews.

Fix 4: Cache-buster pattern for CSS/JS (commit `a9255e8`)

Not a direct LCP fix, but a prerequisite for all the others actually reaching users.

If your CSS is at /css/app.css and you update it, browsers and CDN edges will keep serving the old content — because /css/app.css is the same URL as yesterday. Cache poisoning.

Standard fix: append a version query string that changes on every deploy: /css/app.css?v=20260703a. When the version changes, the URL changes, and every cache treats it as a new resource.

Baked this into every HTML mirror:

<link rel="preload" as="style" href="/css/app.css?v=20260703a" fetchpriority="high" />
<link href="/css/app.css?v=20260703a" rel="stylesheet" fetchpriority="high" />
<link rel="preload" href="/_framework/blazor.webassembly.js?v=20260620j" as="script" />

Also added fetchpriority="high" on the CSS <link> — a browser hint that tells Chrome to prioritize this request over async scripts.

Impact: without this, none of the other CSS/JS fixes would deploy reliably. LCP win: indirect but load-bearing.

Fix 5: Cloudflare Brotli edge compression

This one you don't code — you enable it in the Cloudflare dashboard. But it's the biggest single win of the six.

My app.css is 131KB raw. That's not small. GZIP compresses it to ~40KB on the wire (typical text ratio 3:1). Brotli — Cloudflare's default compression for modern browsers — takes it to ~24KB (ratio 5.5:1).

For a slow 4G mobile connection at 1 Mbps effective throughput:

131KB raw = ~1050ms transfer time
40KB gzip = ~320ms transfer time
24KB brotli = ~192ms transfer time

That's a ~700ms LCP win on the render-blocking CSS alone. FREE. Just toggle Brotli in Cloudflare Speed → Optimization.

If you're on Cloudflare and Brotli isn't on, this is your fastest-possible perf win. Zero code changes.

Impact: ~700ms LCP win.

Fix 6: Blazor WASM bundle size — `PublishTrimmed` + linking + InvariantGlobalization

The .NET runtime + your app DLLs downloaded on first visit is normally 3-5MB of WASM. That's a lot for a mobile connection. Three project-file switches shrink it significantly:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
  <BlazorWebAssemblyEnableLinking>true</BlazorWebAssemblyEnableLinking>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

PublishTrimmed — .NET's IL linker strips unused types. Removes everything from mscorlib you're not calling. Typically 50-70% size reduction.
BlazorWebAssemblyEnableLinking — same idea but Blazor-specific.
InvariantGlobalization — removes the ICU globalization data (~1.5MB). Only viable if you don't need locale-aware string formatting. For a tax calculator that runs in one language, safe.

Combined effect on my site: Blazor bundle dropped from ~5MB to ~1.8MB. That's a big deal on first-visit mobile.

Note: this doesn't affect LCP directly IF your static HTML already renders the content (which mine does). But it dramatically speeds up time-to-interactive, which affects INP (Interaction to Next Paint) — the other Core Web Vital.

Impact: 200-400ms INP win + faster hydration.

After numbers — Lighthouse mobile, same throttling profile

Page	LCP (before)	LCP (after)	Delta
Homepage	6.2s	1.84s	-4.36s
Currency converter	7.1s	1.21s	-5.89s
Salary tax guide	5.9s	1.56s	-4.34s
Tax calendar	5.5s	1.55s	-3.95s
HRA calculator	7.4s	1.54s	-5.86s

Every measured page is now under the 2.5s "Good" LCP threshold. Most are under 2s.

The homepage cut ~4.4 seconds from real user-facing render time with 6 commits of mechanical work. No framework rewrite. Blazor is still Blazor.

What did NOT help (I'm being honest)

Not everything I tried worked. Skip these:

Minifying CSS manually. Cloudflare's Brotli already compresses better than any hand-minifier. Diminishing returns.
Lazy-loading below-fold sections with content-visibility: auto. Improved paint but caused CLS (layout shifts) that hurt the CLS Core Web Vital more than the LCP improvement helped.
Removing Google Analytics 4. Yes, GA4 slows things down. No, removing it is not viable for a site that needs to measure user behavior. Async loading is enough — the perf cost is real but small (~50-100ms), and the observability win is huge.
Custom preloading of individual DLLs. Blazor's default boot flow is already tuned. My hand-crafted preloads made things worse.

Two takeaways for anyone doing this

1. Delete more than you add. My biggest wins were removing things — service workers, version-check IIFEs, unused globalization data. Every one of those was "added carefully to fix a specific bug last month" and had turned into dead weight. Audit your legacy carefully.

2. The CDN dashboard is code. Toggling Brotli in Cloudflare beat every code-level optimization I did. Don't skip the "settings you can change without deploying" — they're often the fastest win.

Result

Site: smarttaxcalc.in — free Indian income tax calculator, 38 tools, Blazor WASM on Cloudflare Pages.

Mobile Core Web Vitals: all Good.

Framework: unchanged. Still Blazor.

Total code changed: ~15 lines across 6 commits.

If you're on Blazor WASM and hitting the "just rewrite it" wall from external advice, try the six mechanical fixes above first. Most of them are one-line changes. Blazor is faster than it gets credit for — you just need to stop actively slowing it down.

About me: I'm Chetan Sanghani — I build SmartTaxCalc, a free CA-reviewed Indian tax calculator platform. I write about frontend performance, SEO for JavaScript apps, and building small-team B2C products on .NET. Previous article: Google's MathSolver JSON-LD validator is stricter than schema.org — I learned that the hard way over 4 rejections.

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

The Indian Income Tax notice cascade, as a state machine: CPC Supreme Court (walkthrough for salaried filers)

The state machine

State 1 → 2: filing to CPC

State 2 → 3: the department's deadline

State 3 → 4: the AO back-and-forth

The appellate deadlines — memorise these

The "20% rule" at CIT(A)

What NOT to do (the anti-pattern list)

What TO do (the correct-transition list)

The bogus-party defence

When to just pay and move on

Why I'm framing this as a state machine

The 4 Indian salary perquisites that survive the New Tax Regime (what your HR probably won't volunteer)

The rule that survived: Rule 3

1. Rule 3(7)(iii) — meal coupons

2. Rule 3(7)(iv) — gift voucher

3. Rule 3(7)(ix) — telephone + internet reimbursement

4. Rule 3(2) — company car (fuel + maintenance + driver)

Combined example — ₹25 lakh CTC dev

Why HR usually doesn't volunteer this

How to actually get these

Common misconceptions

Why I built a calculator for this

The 4 static-mirror drift classes hiding in your Blazor WASM SEO (and the audit script that finds them)

The setup, if you don't already have it

Drift class #1 — missing BreadcrumbList JSON-LD

Drift class #2 — missing FAQPage JSON-LD despite razor having FaqItems

Drift class #3 — asymmetric hreflang cluster

Drift class #4 — meta keywords copy-paste template

The audit script

Why this happens

Prescription

One more thing

IsTrimmable=false is not enough: how one WASM setting silently broke my Blazor app for 4 days

The setup

What the trimmer actually did

Fix attempt #1: turn trim off for the assembly

What actually happened at fix #1 (updated after a reader's diagnostic)

Fix attempt #2: source-generation (the real answer)

Diagnostic patterns worth internalizing

The soft-fail alternative I considered and rejected

The 4-day window, in retrospect

I built a lint that caught 3 tax-rule lies my manual sweep missed — a pattern-based safety net for hand-maintained SEO

The setup — why drift happens

The Sunday crisis

The lint I built this Wednesday

The two-phase pattern that works

What happened when I ran it

Why this generalizes

What the lint does not do

Wire it into CI

What I learned

The current state

Six directory emails promised me a dofollow backlink. My 40-line PowerShell verifier said otherwise.

What "dofollow" means, and why it moves

Discovery 1: Medium is now ugc nofollow

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

The lesson: verify the rel before you write

The verifier — 40 lines of PowerShell

The header dance for Cloudflare-fronted sites

The newer trap: when the site emails you claiming dofollow

The lesson upgrade: verify the funnel, not just a listing

Why this matters more than a one-off check

Steal the pattern

Launching SmartTaxCalc on Product Hunt today 🚀

What's live

What I learned (5 quick engineering wins from the build)

The stack

Ask

One cut my Blazor WASM LCP by 500ms — the invisible file at the end of the critical chain

The "Network dependency tree" was the smoking gun

Why this happens on every Blazor WASM app

The fix — three lines in index.html

Before / after (real numbers, mobile Lighthouse, Slow 4G throttled)

When this pattern applies

The trap I fell into first — assuming Blazor boot was fixed cost

Anti-pattern — don't preload everything

Bonus lessons from the same optimization pass

Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier

Discovery 1: Medium is now `ugc nofollow`

The lesson: verify the `rel` before you write

The fix — three lines in `index.html`

Discovery 1: Medium is now `ugc nofollow`

Fix 1: Delete the service worker (commit `910c606`)

Fix 2: Removed a version-check IIFE that force-reloaded users (commit `910c606`)

Fix 3: Preconnect coverage on 7 pages that were missing (commit `910c606`)

Fix 4: Cache-buster pattern for CSS/JS (commit `a9255e8`)

Fix 6: Blazor WASM bundle size — `PublishTrimmed` + linking + InvariantGlobalization

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

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

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

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