DEV Community: Steven Browning

My FAQ Schema and My FAQ Had Become Two Different Documents

Steven Browning — Sun, 04 Oct 2026 22:18:09 +0000

I was rewriting the copy on one of my GPU comparison pages when I noticed something I probably should have checked much earlier.

The FAQ people could read and the FAQ in the page's structured data were completely different.

Not slightly different.

They didn't share a single question.

One page, two different FAQs

The FAQPage JSON-LD had four questions:

What matters most for running local LLMs?
Can I run a local LLM without a GPU?
How much VRAM do I need for local AI?
Is NVIDIA required for local LLMs?

The actual page had three:

Is VRAM more important than raw GPU speed?
Can two GPUs combine VRAM?
Should I buy a prebuilt AI PC?

So I had one FAQ for visitors and a different one sitting in the code for anything reading the structured data.

Both were on the same page. Both looked reasonable on their own. Neither matched the other.

I can see how I got there

On these pages, I had essentially been keeping the FAQ in two places.

One copy was the HTML people read. The other was JSON-LD, usually in the <head>.

They might start out matching, but then I rewrite an answer, change a question or add something to the page.

And forget to update the other copy.

Nothing obvious breaks.

The page still loads. The FAQ still opens. The JSON can still be perfectly valid.

But valid JSON doesn't mean it describes what's actually on the page.

That was the part I had missed.

I fixed the page and thought I was done

I rebuilt the GPU page's schema from the FAQ visitors could actually read.

Then I checked my email header analyzer and found a less obvious version of the same problem.

It had six questions. One question had a different title in the schema, and all six answers were worded differently from the answers on the page.

I fixed those too.

On another page, I added two FAQ entries and checked that those two matched in both places.

They did.

So, naturally, I thought I was making progress.

Then I wrote a scanner to check the whole site. Mostly because I wanted to confirm I hadn't left anything else behind.

That turned out to be optimistic.

The numbers were worse than I expected

The scan found:

What I checked	Result
Pages with `FAQPage` markup	45
Pages where schema and visible text matched under the check	17
Pages with mismatches	28
Questions in the schema	334
Schema questions not found on the page	56
Questions found, but with answer text that didn't match	105

On the mining calculator, the schema had six questions and the page had five. None of the questions matched.

The About page had the same problem.

And the email security checker, which I had considered finished a few hours earlier, still had three original questions worded differently in the two places.

One version said:

Why does the check say it could not verify DKIM?

The other said:

Why does it say DKIM could not be verified?

Those mean pretty much the same thing. But they were another sign that I was maintaining two separate copies instead of one source.

I had checked the entries I'd just added.

I hadn't checked the whole FAQ.

Of course, my first scanner was wrong too

The first version looked for a particular HTML pattern:

<details>
  <summary>A question</summary>
  <p>An answer</p>
</details>

It then told me that a lot of my pages had no visible FAQ at all.

Except I could open those pages and see the questions right there.

Some used headings and paragraphs. Some answers had more than one paragraph.

My scanner wasn't finding them because I had told it what the markup should look like instead of accounting for what was actually there.

So now I had a checker that needed checking.

The next version removed scripts and styles, extracted the page text, and compared that with the questions and answers in the schema.

The basic idea was:

const norm = t => t.toLowerCase().replace(/[^a-z0-9]+/g, ' ').trim();

const visible = norm(visibleText);

for (const q of faq.mainEntity) {
  if (!visible.includes(norm(q.name))) {
    fail(`question not on the page: ${q.name}`);
  } else if (!visible.includes(norm(q.acceptedAnswer.text))) {
    fail(`answer differs from the page: ${q.name}`);
  }
}

That caught the differences I was looking for without depending on one FAQ layout.

It still has limits. Finding a question and an answer somewhere in the page text doesn't prove they're paired correctly. And this simplified normalization is meant for my English-language pages, not every language or every kind of content.

But it gave me a much more useful check than assuming every page used the same HTML.

Was this hurting my SEO?

I don't want to turn this into a bigger SEO story than the evidence supports.

Google stopped showing FAQ rich results on May 7, 2026. Its general structured-data guidelines still require marked-up content to be visible to readers.

Those are separate points.

The mismatches were real, but I don't have evidence that they cost me rankings.

What bothered me was simpler: my page was saying two different things depending on which copy you read.

This time it was FAQ wording. With a calculator, it could be a number shown in the explanation that no longer matches the number used in the calculation.

That's the sort of thing I want to catch before someone else has to point it out.

Fixing the copies isn't enough

I could go through all 28 pages and edit the JSON by hand.

That would make them match today.

It wouldn't stop me from changing an answer next week and creating the same problem again.

So the approach I'm moving toward is:

Use the visible FAQ as the source. Generate the schema from it at build time instead of editing both copies.
Check the whole site on each build. Include pages I didn't touch that day.
Don't add FAQPage markup without a visible FAQ. There shouldn't be a separate set of answers available only in the structured data.

The StashGrid local LLM GPU comparison was where this started. By the time I ran this scan, its seven questions matched in both places. The scan had also given me a list of 28 other pages to work through.

The lesson for me was pretty basic.

Checking that my latest edit is correct isn't the same as checking that the page is correct.

And if I'm keeping the same information in two places, I need something that makes sure it stays the same.

Update: all 28 now match. Each page's FAQ is fenced in one marked block, the schema is generated from it, and a weekly check fails if they drift.

My AI Crawler Analyzed an Error Page Like It Was the Real Site

Steven Browning — Sun, 04 Oct 2026 19:37:13 +0000

I built a small tool recently that checks how visible a webpage is to AI crawlers.

You give it a URL, and it tries to fetch the page the way a crawler might. Then it checks things like:

Did the page actually respond?
Is there a noindex?
Does robots.txt allow GPTBot, ClaudeBot and other AI crawlers?
Is there a title?
Is there an H1?
Is there readable content?
Is there structured data?
Is there a canonical URL?

Pretty straightforward.

Fetch the page, look at what came back, report what you find.

At least that was the idea.

Then I pointed it at nytimes.com.

My tool reported:

No H1
Only about 81 words of readable text
No JSON-LD structured data
No canonical URL
No meta description

Technically, every one of those statements was correct.

They were also completely useless.

The server had returned HTTP 403.

My tool received 771 bytes of an error response and then happily analyzed it as if it were the New York Times homepage.

Nothing was actually broken

This is what made the problem interesting to me.

The code looking for an H1 worked.

There wasn't an H1 in the response, so it correctly reported that there wasn't one.

The word counter worked.

There were about 81 words, so it reported 81.

The structured-data check worked.

There wasn't any JSON-LD in the response.

Everything did exactly what I had asked it to do.

The problem was that I never really asked the most important question:

Did I actually get the page I wanted to analyze?

The code was basically doing this:

const res = await fetch(target, { headers: { 'User-Agent': UA } });
const html = await res.text();
const page = await extract(html);
return report(page);

It went straight from "I received something" to "let's analyze it."

The funny part is that res.status was already available.

I was even displaying it.

There was a little grey row near the bottom of the report that said:

Status: 403

Meanwhile, above that, the tool was confidently telling me what was supposedly wrong with the page.

So technically the information was there.

It just wasn't being treated like the most important information on the page.

The fix was embarrassingly small

Once I realized what was happening, the first fix was only a few lines:

if (res.status >= 400) {
  findings.push({
    level: 'blocker',
    title: `The page returned HTTP ${res.status} to our crawler`,
    detail: 'Everything below was read from the error response, not from the real page.',
  });
}

There was another problem hiding in the same area.

The scanner could also display:

Nothing is blocking this page.

That message was based on whether the findings list was empty.

It wasn't based on whether the page had actually loaded successfully.

So under the right conditions, a site could refuse the request completely and my tool could still give it the equivalent of an all-clear.

That obviously wasn't what I intended.

I'm starting to see a pattern

I'm not a professional developer.

I'm mostly building these tools with AI, experimenting, breaking things, fixing them and learning what I should have checked the first time.

And I've noticed that a lot of the mistakes I've run into have the same basic shape.

I previously had a GPU mining calculator tell me an RTX 4090 could make more than $5,000 a month because I mixed up GH/s and TH/s.

I also had calculators where a perfectly valid value of zero was treated as if there was no answer at all.

Different bugs, but the same general problem:

Something receives an input nobody really questioned, processes it correctly, and produces a very confident answer.

Nothing crashes.

There isn't necessarily an error message.

The page loads.

The report looks good.

The answer is just wrong.

In this case, every part of the scanner worked.

It was simply analyzing the wrong thing.

What I'm checking now

The lesson for me wasn't that I need a better HTML parser.

It was that before analyzing something, I need to make sure I actually received what I think I received.

There are a few surprisingly basic checks that would have caught this.

Did the request actually succeed?

A 403 response is still a response. JavaScript will happily hand me the body and let me analyze it.

Did I get the type of content I expected?

If I'm expecting HTML and receive JSON, a PDF, a login page or an error message, searching it for an H1 doesn't tell me much.

Does the size make any sense?

The response from nytimes.com was 771 bytes.

That alone should have made me suspicious that I probably wasn't looking at a major news homepage.

Did I end up at the URL I expected?

A request can follow redirects and eventually land on a login page, error page or something completely different from the URL that was originally entered.

The biggest change I'm making is what happens when one of those checks fails.

Instead of producing a normal report with a warning somewhere in it, the tool now needs to say, prominently:

I couldn't properly inspect this page, and here's why.

Anything it found inside the error response becomes secondary.

Then I almost made the exact same mistake in this post

This part was a little embarrassing.

I originally had a much better opening planned.

The idea was:

nytimes.com loads normally in a browser but returns 403 to an AI crawler.

That's a nice example.

There's only one problem.

Before publishing this, I actually checked it.

I requested the same page from the same machine using an ordinary Chrome user agent.

403 again.

So I don't actually know that the site was specifically rejecting my crawler.

It could be my IP range. It could require more of a normal browser fingerprint. It could be something else entirely.

All I can say from my test is:

The server refused the requests I made, and my scanner analyzed that refusal as if it were the real webpage.

Which is enough to demonstrate the problem.

The irony wasn't lost on me.

I built a tool because I wanted evidence instead of assumptions, and then nearly opened the article with an assumption I hadn't verified.

Checking it took about ninety seconds.

There was still useful information

One thing I could verify separately was robots.txt.

That request returned HTTP 200.

Of the ten crawlers my tool checks, eight were disallowed:

GPTBot
OAI-SearchBot
ChatGPT-User
ClaudeBot
Claude-User
PerplexityBot
Google-Extended
CCBot

Googlebot and Bingbot were allowed.

That's actually a useful distinction for this kind of tool.

A website can make different choices about traditional search engines and AI-related crawlers. Those aren't necessarily the same thing, and putting everything under a single "AI visibility score" can hide that.

Which is one reason I don't give the scanner a score out of 100.

A page with a slightly short meta description and a page with noindex shouldn't just lose a different number of points.

One is a small optimization issue.

The other can prevent the page from appearing where you expect it to.

If you want to try it

The tool is StashGrid AI Visibility.

It's free, doesn't require an account and doesn't store the URLs you enter.

Paste in a URL and it checks what the crawler actually receives, including:

HTTP status
Redirects
noindex
X-Robots-Tag
robots.txt rules for ten named crawlers
Canonical URL
H1
Structured data
Whether useful page content is actually present in the HTML

The HTTP response now comes first.

If the page returns a 403, that's the headline.

Not the missing H1 buried inside the error page.

I also rank findings as blocker, warning or info instead of turning everything into one score.

And wherever possible, the scanner shows the evidence that caused the finding.

I want someone using it to be able to look at the result and decide whether they agree with it.

For comparison, I ran it against one of my own pages that it could actually reach.

HTTP 200.

No redirects.

One H1.

2,272 words of readable content.

Three JSON-LD blocks.

A self-referencing canonical.

All ten crawlers allowed.

It's a much more boring report.

Which is exactly what I want.

Nine bugs, one cause: my calculators all thought zero meant nothing

Steven Browning — Mon, 28 Sep 2026 14:12:44 +0000

I spent two days checking the arithmetic on fifteen of my calculator pages. The audit turned up 34 defects. Nine came back to the same mistake: treating zero as if the user had left something blank.

What bothered me was how normal the code looked. These were separate tools, built at different times, and I had repeated the same assumption across them.

Here is one example:

const inflationRate = parseFloat(document.getElementById('inflationRate').value) || 3;

Empty field? Use 3%. Seems reasonable.

Enter 0? Still 3%.

The calculator quietly replaced the number the person actually entered. No warning, no error, just a different calculation.

Where zero went missing

These are examples from the browser audit, using the pages' own fields and buttons.

Retirement calculator: entering 0 for inflation still applied 3%. With the other inputs unchanged, the target stayed at $1,884,400 instead of $900,000. If someone wants to compare a scenario without inflation, zero needs to stay zero.

EV vs. petrol calculator: entering 0 for electricity still used 14¢/kWh. In the test case, that produced $480 a year in charging costs instead of $0. Free workplace charging is a perfectly reasonable scenario to compare. The calculator should allow it.

Credit card payoff: entering 0% APR cleared the results without explaining why. This was the check:

if (!balance || !apr || !dueDateStr)

Zero APR failed the same check as a missing APR. That rules out an ordinary use case: a promotional 0% offer. The offer's duration needs its own handling, but zero itself is still a valid rate.

GPU mining profitability: this one was in the output logic:

const breakEvenDays = profitDay > 0 ? Math.ceil(gpuCost / profitDay) : null;

if (breakEvenDays) {
  // Show the breakeven time.
} else {
  document.getElementById('res-breakeven').textContent = 'Never';
}

With no new hardware cost and positive daily profit, the result is 0 days. But if (0) is false, so the page showed "Never / Not profitable at this rate" alongside +$0.27/day.

It should distinguish zero days from no breakeven. For this model, that means checking breakEvenDays !== null, rather than whether the number is truthy.

Two GPU comparison tables: a $0 budget showed every card because || Infinity turned zero into an unlimited budget. One table also selected a default GPU when the filtered list was empty. It managed to show "0 cards" beside a named recommendation.

Those are different screens, but the question I had failed to ask was the same: does zero mean something here?

Why I missed it

I had checked empty fields, typical values and very large values. I had not consistently tested zero as its own case.

Looking at the code did not make the problem obvious either. A fallback beside an optional field looks helpful. A truthiness check looks like basic validation. And a number type alone cannot tell you whether zero is allowed for a particular field.

I also relied too much on attributes such as min="0" and max="100". They define validation constraints; they do not automatically stop a custom calculation handler from reading an invalid value. The page still needs to invoke validation or check the inputs itself. MDN explains how number-input validation works.

Blank, zero and invalid need separate decisions

I would not replace every || just because of this audit.

On a travel budget page, a blank optional cost might intentionally mean zero:

const flights = parseFloat(document.getElementById('flights').value) || 0;

That does preserve a typed zero, because the fallback is also zero. It can still hide invalid input, though, so it is not a complete validation strategy.

On a fuel calculator, zero miles per gallon is a different problem: MPG is a divisor. The page should reject it with an explanation, rather than silently replace it with 30.

For an optional numeric field, I would make those choices explicit:

function readOptionalNumber(raw, fallback) {
  const text = raw.trim();
  if (text === '') return fallback;

  const value = Number(text);
  if (!Number.isFinite(value)) {
    throw new Error('Enter a valid number.');
  }

  return value;
}

const inflationRate = readOptionalNumber(
  document.getElementById('inflationRate').value,
  3
);

The caller still needs to show the error beside the field and check any allowed range. This helper only separates blank, zero and non-finite input.

And parseFloat(raw) ?? 3 is not a drop-in fix. An empty string produces NaN, and ?? only falls back for null or undefined. These are separate behaviors: parsing a number and nullish coalescing.

Another way to lose a number: formatting

The percentage calculator had a separate issue. It displayed:

0.01% of 1 = 0

The answer is 0.0001. This time, a falsy check was not responsible. The formatter was:

function fmt(n) {
  const rounded = Math.round(n * 10000) / 10000;
  return parseFloat(rounded.toFixed(4)).toLocaleString();
}

It rounded to four decimal places, then handed the number to a formatter that normally displays at most three fractional digits for plain numbers. The fourth decimal disappeared. The default is documented here.

If four decimal places are the intended display limit, say so:

function fmt(n) {
  return n.toLocaleString(undefined, {
    maximumFractionDigits: 4
  });
}

That fixes this example. It still rounds smaller values, so a tool that needs to show those should use more precision or scientific notation. The displayed answer deserves a test too.

Then there was the opposite problem

The maths page checked for an exact zero before calculating tangent:

const tanV = Math.cos(rad) !== 0 ? r(Math.tan(rad)) : 'undefined';

At 90 degrees, JavaScript's cosine calculation returns approximately 6.123233995736766e-17, not exactly zero. The guard passed, and the page displayed:

cos = 0
tan = 16331239353195370

Underneath was a note explaining that tangent is undefined at 90° and 270°. The explanation was right; the result above it was wrong.

A tolerance can help a degree-based display handle that boundary:

const nearPole = Math.abs(Math.cos(rad)) < 1e-12;
const tanV = nearPole ? 'undefined' : r(Math.tan(rad));

That threshold is a display choice, not a universal floating-point fix. It also catches angles very close to a pole where tangent is large but defined. Choose the rule for the tool's accepted inputs and intended precision, then test both the boundary and nearby values. Tolerance depends on scale and input accuracy.

The audit needed checking as well

Two early findings turned out to be mistakes in how I tested the pages. I called an internal function directly and skipped a guard that ran when a visitor clicked the button.

That changed how I checked the remaining issues: enter the values, click the actual button, and inspect what the visitor sees. A suspicious line of code is a reason to investigate, not proof that the live page is broken.

Checks on the fixes helped too. One caught a hardcoded year I had updated in one function but missed in another. A few checks were wrong themselves and needed correcting. Useful checks need review just like the code they test.

What I would check first now

For each numeric field:

Leave it blank.
Enter zero.
Enter a small positive decimal.
Try an invalid or out-of-range value.
Check the displayed result, not just the value inside the function.

The frustrating part was that these pages still looked fine. They loaded, the layouts worked, and the numbers were neatly formatted. That made the wrong answers easy to trust.

I build free calculators at StashGrid.site. After this audit, zero gets its own test case.

If you have a calculator or numeric form, try zero in the fields where it is allowed. Does it stay zero, trigger a useful message, or quietly become something else?

My calculator told people a GPU earns $171 a day. It loses $1.12

Steven Browning — Wed, 23 Sep 2026 15:32:16 +0000

For about four days, a calculator I built was telling people that one RTX 4090 could make $171.31 a day mining Ergo.

That worked out to around $5,101 a month, with a $1,799 graphics card supposedly paying for itself in 11 days.

Yeah. That was very wrong.

The real result with the same settings was closer to 18 cents a day in revenue and about a $1.12 loss per day after electricity.

Break-even wasn't 11 days.

It was never.

I wanted to write this up because I'm not a professional developer. I'm probably closer to what people now call a vibe coder. I know enough to build things, troubleshoot them, change code, use AI to help me, and usually figure out why something isn't working.

But I'm still learning as I go.

And this was one of those bugs where everything looked completely reasonable until I stopped and said:

There is absolutely no way this number is real.

What the calculator was showing

If you loaded the page and didn't change anything, you'd see something like this:

Daily revenue     $171.31
Daily profit      +$170.02    Profitable ✅
Monthly           +$5,101
Break-even        11 days

Even worse, basically every coin in the comparison table looked profitable.

They weren't.

Anyone who knows GPU mining would probably spot the problem immediately.

If you could really buy an RTX 4090 for around $1,800 and recover the cost in 11 days, people would be buying every 4090 they could find.

But the whole reason I built a calculator like this is for people who don't already know the answer.

If you're researching whether mining is worth trying, you might look at that number and think:

Wow, I didn't realize GPU mining was still this profitable.

That's where a bad calculator becomes more than just a funny bug.

Someone could actually make a purchasing decision based on it.

So what went wrong?

Part of the site uses automatically updated mining data.

The data included a value like this:

{
  "symbol": "ERG",
  "algorithm": "Autolykos2",
  "rev_per_th_usd": 1310.945239
}

The important part is the unit.

That number was based on terahashes per second, or TH/s.

Elsewhere, the calculator was doing this:

const revPerTh  = parseFloat(coinOpt.dataset.rev);
const totalHash = hashrate * count / 1000; // MH/s -> GH/s
const grossRev  = totalHash * revPerTh;

I had one value in GH/s and another value based on TH/s.

Those aren't the same thing.

There's a factor of 1,000 between them.

Once I understood that, the crazy result suddenly made perfect sense.

For example:

132 MH/s = 0.132 GH/s

0.132 × 1310.945 = $173.04

After the pool fee = $171.31

That matched exactly what the site was showing.

So the calculator wasn't randomly broken.

It was very confidently doing the wrong math because I had given it two values using different units.

This is the part that surprised me

Nothing looked obviously broken.

The data file was loading.

The numbers were valid.

The calculator was doing multiplication correctly.

The page wasn't throwing errors.

From the browser's point of view, everything was working.

That's probably one of the bigger lessons for me from building things with AI.

AI can help you write code that runs.

It can help fix syntax errors.

It can help explain functions.

It can even help build a pretty complicated tool.

But code running successfully doesn't mean the answer makes sense.

In this case, the most useful debugging tool ended up being common sense.

An RTX 4090 does not make $5,000 a month mining Ergo.

Once I accepted that the output itself had to be wrong, it became much easier to work backward and find out why.

One comment actually made me ignore the problem

The page loaded the live mining data using code like this:

// fails silently if unavailable
fetch('/mining/mining-data.json')
  .then(r => r.json())
  .then(applyLiveCoins)
  .catch(() => {});

I had looked at that comment multiple times.

In my head, I read it as:

If the live data doesn't work, no big deal. The page has fallback values.

So I more or less stopped paying attention to that section.

Except the live data wasn't failing.

It was loading correctly every time.

And every time it loaded, it was replacing the reasonable fallback numbers with the bad ones.

So the part I had mentally categorized as harmless was actually the thing causing the problem.

My first fix wasn't really enough

My first reaction was basically:

Fine. Make the variable names more obvious.

Instead of something like:

revPerTh

use something that spells the unit out.

That's definitely better.

But then I realized something.

The bad number was so ridiculous that the site probably should have rejected it regardless of how the mistake happened.

So I added what is basically a sanity check:

const REV_SANITY_MIN = 0.0001;
const REV_SANITY_MAX = 100;

const usable = rows.filter(c => {
  const v = Number(c.usd_per_ghs_day);

  return (
    isFinite(v) &&
    v >= REV_SANITY_MIN &&
    v <= REV_SANITY_MAX &&
    c.symbol
  );
});

if (!usable.length) return;

I'm not trying to say the value has to be perfectly accurate.

I'm just saying:

If this number is completely outside the range of anything believable, don't automatically publish it.

And if the live data looks suspicious, the page keeps the older known-good numbers instead.

I'd rather show slightly outdated numbers than confidently tell someone their GPU is going to print $5,000 a month.

Then I started noticing the same kind of problem everywhere

Once I started looking for numbers that were technically valid but obviously wrong, I found more of them.

What I saw	What was actually happening
Used RTX 4090 for $171.68	The scraper grabbed a cable instead of a GPU
RTX 3090 for $2,399	The search also matched an RTX 3090 Ti
Insane mining revenue numbers	The reference hardware was an ASIC, not a GPU
$5,101/month from one RTX 4090	GH/s and TH/s got mixed together

The funny part is that none of these were really complicated programming mistakes.

The code was doing what I told it to do.

The problem was that what I told it to do didn't match reality.

I even managed to create basically the same bug while fixing another one.

I was trying to filter RTX 3090 Ti cards out of RTX 3090 results.

So I checked whether the listing contained:

ti

That seemed reasonable.

Until I realized a perfectly valid listing said:

Founders Edition

Which also contains:

ti

So my fix for bad matching was itself doing bad matching.

That one made me laugh once I figured it out.

Sanity checks can be wrong too

There's another side to this.

You have to be careful not to assume that every surprising number is bad data.

I ran into that while working on another GPU tool for local AI performance.

I expected cards with higher memory bandwidth to generally perform better.

Then I had an RTX 3090 with around 936 GB/s of bandwidth showing worse results than a 4070 Ti Super with around 672 GB/s.

My first reaction was:

The benchmark must be wrong.

Except it wasn't.

The newer architecture was simply using its available bandwidth more efficiently.

So now I'm trying to treat these sanity checks as warnings, not corrections.

The system should basically say:

This looks strange. Check it.

Not:

This is definitely wrong, so I'm going to change it automatically.

That distinction matters.

Otherwise I'm just replacing one bad assumption with another one.

What I learned from it

The main thing I'm changing in how I build these tools is pretty simple.

Whenever I'm showing a calculated number to someone, especially something involving money, I want to ask:

Does this result pass a basic reality check?

Not just:

Did the code run?
Did the JSON load?
Is this a valid number?
Did the formula execute?

But:

Could this number actually make sense in the real world?

I'm still going to use AI heavily to build things.

That's part of what makes projects like StashGrid possible for me.

But this was a good reminder that AI-generated code, APIs, automated feeds, tests, and working JavaScript still need a human somewhere in the loop asking:

Wait...does that actually make sense?

In this case, the answer was definitely no.

The calculator that caused all of this is the GPU Mining Calculator on StashGrid.

The numbers are a lot less exciting now.

Which is probably a good sign.

Your DMARC record might contain something that no longer exists

Steven Browning — Sat, 19 Sep 2026 22:07:42 +0000

Most of us set up SPF, DKIM and DMARC once, watch the reports for a week or two, and then leave them alone. That's usually the right call. They aren't systems that need constant attention.

This year is worth an exception, though — and not quite for the reason you'd expect. The spec changed in May, and one of those changes means that tidying up your DMARC record can quietly make it stricter than you intended.

Here's what moved, and what I'd look at.

What actually changed

On 19 May 2026, DMARC moved onto the IETF Standards Track as RFC 9989, replacing RFC 7489 and RFC 9091. Reporting moved out into two companion documents: RFC 9990 for aggregate reports, RFC 9991 for per-message failure reports.

For the ten years before that, DMARC carried the status Informational — a description of something the industry had already built, rather than a standard anyone was obliged to follow. A lot of records out there were written against that older spec and haven't been touched since. Some of them contain a tag that no longer exists.

The `pct` tag is gone, and deleting it isn't free

If you rolled DMARC out gradually, you probably used pct:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

It was a reassuring idea: apply the policy to a quarter of failing messages, watch what breaks, then raise the number. In practice receivers interpreted it inconsistently enough that RFC 9989 removes it altogether — there's an appendix titled "Removal of the 'pct' Tag."

This is the part I'd slow down for. If you delete pct=25 from that record, you don't land back where you started. Receivers that don't recognise the tag already treat the policy as applying to everything, and removing it just makes that explicit. You've gone from quarantining a quarter of failing mail to quarantining all of it.

That may be exactly what you want. It's nicer to be the person who decided it than the person who finds out from the helpdesk.

The replacement is a t tag, for testing. t=y asks receivers to handle mail one step below your published policy — p=reject behaves as quarantine, p=quarantine behaves as none — while you carry on collecting reports. It's a cleaner mechanism than sampling, though it does mean the gradual percentage ramp isn't available any more.

Stricter isn't automatically the goal

There's an assumption running through a lot of DMARC advice that p=reject is the finish line and everything else is a waypoint. RFC 9989 is more careful than that. Section 7.4 puts it directly:

domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of p=reject

The reasoning is practical rather than theoretical. Mailing lists and forwarders relay and rewrite messages in ways that break the original authentication, so rejecting on failure can bounce your own users' perfectly legitimate mail — and list software often responds to those bounces by unsubscribing them.

If your domain is purely transactional, p=reject is a sound destination. If real people send mail from it, quarantine may be as far as you want to go.

Three smaller changes worth knowing about

Organizational domain discovery no longer uses the Public Suffix List. RFC 9989 replaces it with a series of DNS queries the spec calls the DNS Tree Walk. Worth knowing by name — it's what you'll be searching for the day something behaves oddly on a multi-level domain.

np covers non-existent subdomains. Carried over from RFC 9091, it lets you publish a separate policy for subdomains that don't exist at all, which is handy, because those are a favourite for spoofing. Without it they inherit sp, or failing that p.

sp only applies where you'd expect it to. It's ignored on records published below the organizational domain or public suffix level. If you've ever set it on a subdomain and wondered why nothing happened, that's the reason.

SPF: a short record can still be doing a lot of work

An SPF record can look completely manageable and still sit close to a hard limit, because every include: pulls in whatever that provider has published — and their includes count too.

RFC 7208 puts the ceiling at ten DNS-querying terms per evaluation, and going over it produces a permerror. That's a hard failure, not a soft one, and it isn't something you'll notice unless you're reading your reports. Three or four mainstream providers is enough to get uncomfortably close.

There's also a recommended limit of two "void" lookups — queries that come back empty, or for a name that doesn't exist. Which is a good reason to clear out includes for services you stopped using two migrations ago.

Check how your SPF record ends

This one takes ten seconds, and it's the first thing I'd look at:

v=spf1 include:_spf.google.com all

That record passes every sender on the internet.

A mechanism with no qualifier defaults to +, so a bare all means +all — pass. It's one missing character, the record looks perfectly tidy, and nothing anywhere warns you. ~all is softfail and -all is fail; one of those is almost certainly what was intended.

While you're in there: if you added a second v=spf1 record when you onboarded a new provider, the two don't combine. More than one SPF record at the same name is a permerror, and the fix is to merge the mechanisms into a single record.

DKIM: "not found" often means "not found by this checker"

If a checking tool tells you DKIM is missing, it's worth a second look before you go and re-key anything.

DKIM keys live at names called selectors, and there's no standard lookup that lists them. So a checker has to guess: it tries a handful of common selectors and reports what comes back. If yours isn't on its list, you get an empty result and a record that is perfectly healthy.

A real signed message settles it in seconds. Find the DKIM-Signature header on a message you sent externally — s= is the selector, d= is the signing domain. That domain often isn't the one in the From field, particularly when a marketing platform signs on your behalf, and that's expected rather than a problem.

Two things worth filing away. Finding a key doesn't prove your messages are actually being signed correctly — it only proves the key is published. And a record with an empty p= value means the key has been revoked, not that it's missing. The record is there; the key just isn't usable any more.

If you only do three things

Look at a real message header from your own domain, on something that went to an external recipient. It'll hand you your DKIM selector and signing domain straight away.
Read the end of your SPF record, and count the includes while you're there.
Read a week of DMARC aggregate reports before you tighten anything. They're the only thing that tells you who is genuinely sending as you, and there's nearly always one legitimate sender nobody remembered.

I built a free checker for this, mostly because I got tired of tools reporting "DKIM: missing" when they simply didn't know my selector: stashgrid.site/emailcheck. It reads the public SPF, DKIM, DMARC, MTA-STS, TLS-RPT and DNSSEC records for a domain and explains each result in plain English. It runs in the browser, there's no sign-up, and nothing is stored. Treat it as a starting point rather than an audit — the fuller picture comes from your reports and your own message headers.

One last thing, worth saying plainly: these records stop people sending mail as your domain. They don't filter what arrives in your inbox, and they can't stop someone registering a domain that merely looks like yours and sending from that instead. Different problem, different tools.

Sources: RFC 9989 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).