DEV Community: farcrak

Google indexed 428 of my 1,432 generated pages and none of my 2,290 handwritten ones

farcrak — Sun, 23 Aug 2026 19:50:35 +0000

I spent yesterday planning to delete the best part of my site.

I run a calculators-and-tools site, solo, five months old. About 5,800 pages across four language sections. Google has 642 of them in its index. Not great. The rest sit in two buckets: 1,153 "crawled, currently not indexed" and 4,161 "discovered, currently not indexed."

Like everyone in that situation, I had a theory. Somewhere in those 5,800 pages I had generated 1,432 timezone pages — every URL a pair of cities, /date-time/time-difference/london-and-buenos-aires, that sort of thing. One calculation, different arguments, spread across a URL space. It looks exactly like what Google's spam policy calls scaled content abuse, and I assumed it was dragging the whole host down. The plan was to collapse them into one hub page and 301 the rest away.

Before doing it, I exported the list of what Google actually has.

The export

This is the part I had never bothered with, and it takes about four minutes.

In Search Console: Indexing → Pages, then the link "View data about indexed pages." At the bottom of the examples table, change rows-per-page to 500. The examples table caps around 1,000 URLs, so if your indexed count is under that, you get the complete list, not a sample. Mine was 642, and I pulled 638 unique URLs out of it.

Then classify them. I did it with a throwaway script that buckets by URL prefix:

import re, collections

def family(url):
    p = re.sub(r'https://example\.com/[a-z]{2}', '', url) or '/'
    if re.match(r'^/date-time/(convert|time-difference|meeting-time|world-clock)/', p):
        return 'generated timezone pairs'
    if p.startswith('/recipes'):
        return 'handwritten recipes'
    if p.startswith('/cooking'):
        return 'cooking guides'
    if re.match(r'^/finance/[^/]+/.+', p):
        return 'generated finance scenarios'
    return 'tools and hubs'

urls = [l.strip() for l in open('indexed.txt') if l.strip()]
for name, n in collections.Counter(map(family, urls)).most_common():
    print(f'{n:5d}  {name}')

Do the same for the "crawled, not indexed" and "discovered, not indexed" drilldowns and you get the whole picture in three exports.

One trap if you automate the reading: the console reuses its DOM between drilldowns. My first pass at the "crawled, not indexed" list came back looking almost identical to the indexed list, and it took a set intersection to notice that 638 of those 660 rows were the indexed list, still sitting in the page. Reload the drilldown URL directly before reading it.

What came back

Family	Total	Indexed	Rate	Crawled, rejected	Never crawled
Generated timezone pairs	1,432	428	29.9%	647	24
Generated finance scenarios	180	74	41.1%	65	4
Cooking guides	530	61	11.5%	36	95
Tools and hubs	1,377	65	4.7%	45	407
Market-specific pages	593	8	1.3%	0	138
Handwritten recipes	2,290	0	0%	0	195

The two generated families I was about to delete are 502 of the 638 indexed pages. Seventy-nine percent of my index. They also have the two highest acceptance rates on the site.

The 2,290 recipes — the ones with photographs, per-serving nutrition, ingredient scaling rules, written natively in two languages rather than machine-translated — have zero pages in the index. Not rejected. Zero of them appear in the "crawled, not indexed" bucket either. Google has never fetched a single one.

(The counts in the last two columns are from samples — those drilldowns cap out around a thousand example URLs, and my buckets are larger than that. The indexed column is complete.)

Why this is not the story I expected

The obvious reading is "Google likes generated pages better," which is nonsense. Look at the last two columns instead.

For the timezone family, Google is finished. It crawled essentially all 1,432, kept 428, threw out 647, and has almost nothing left in the queue. That is a completed judgement, and 30% is the verdict.

For the recipes, Google hasn't started. They are all sitting in "discovered, currently not indexed," which does not mean rejected. It means Google knows the URLs exist and has not spent a request on them.

Those are two completely different failure modes and the summary number blends them into one scary total. "Crawled, not indexed" is a quality verdict. "Discovered, not indexed" is a scheduling decision — Google deciding your host isn't worth more requests right now. My Links report says external links: 0. That's the whole story: crawl allowance got spent on whatever was linked from the hubs first, and the rest of the site never got its turn.

So the site does not have a content-quality problem in the family I suspected. It has a "nobody links to this domain" problem, which no amount of deleting pages will fix.

What I would have lost

Had I shipped the collapse-and-redirect plan, here is the sequence.

Day one, the old URLs are still in the index. Someone searches for a city pair, finds the old URL, clicks, gets a 301 to the hub with the pair pre-filled. Fine — the reader gets their answer.

Week four, Google re-crawls, sees the redirects, drops the old URLs and shows the hub. Now one generic hub page has to rank for every city-pair query on its own. A hub with two dropdowns competes badly against a page whose title is literally the query.

Net effect: hand back 67% of the index in exchange for rankings the hub would have to earn from scratch. To fix a quality problem that the data says is not there.

The actual takeaway

If you are about to prune pages because they feel thin, export the indexed list first. Four minutes. The report you need is one click below the chart most people stop at, and the answer may be the opposite of your theory. Mine was.

And split those two "not indexed" reasons in your head permanently. If your pages are crawled and rejected, work on the pages. If they are discovered and never crawled, the pages are irrelevant — go get links, because you are asking Google for more of its budget than your domain currently earns.

I am doing the second one now. If it's useful to anybody, the recipe data those uncrawled pages are built on is published as an open dataset — 501 dishes from 127 countries, JSON and CSV, CC BY-SA 4.0, with per-serving nutrition and sourced cooking times: theunitools.com/en/data. Google hasn't read it either, but you might.

My number input turned 3,635,758 into 758 and said nothing

farcrak — Tue, 18 Aug 2026 14:18:46 +0000

I run a small site with a few hundred calculators. One of them writes an amount out in words — the thing you have to do on a cheque or a contract in Spanish. It is by a wide margin my most successful page: it brings 43 of the 44 search clicks the whole site gets in a month.

Yesterday I finally looked at which searches those were. Almost all of them were shaped like this:

como se escribe con letra 1,370,801,919.12
3.635.758 escribir letras
10,377.84 se escribe en letra
como se escribe 77107,10 enletra

People do not arrive wondering how the tool works. They arrive with a number already in their hand, copied out of an invoice, and they paste it.

So I pasted one myself.

3.635.758 went into the field. The field showed 758. And the page answered, in complete confidence:

setecientos cincuenta y ocho euros

Seven hundred fifty-eight euros. The number was three million six hundred thirty-five thousand seven hundred fifty-eight. Off by a factor of about 4,800, with no error, no warning, nothing red. On a page whose entire job is to produce the amount you then sign your name under.

Why it happens

The field was <input type="number">.

That input does not accept "a number as people write it". Per the HTML spec it accepts a valid floating-point number: optional sign, digits, optional . and more digits, optional exponent. That's it. No thousands separators. No locale. 1,234.56 is not a valid value. Neither is 1.234.567,89. Neither is 1 234,56.

What the browser does with an invalid value is the actual problem. It doesn't reject the input in a way you notice. Typing character by character, each keystroke is sanitized against that grammar, and you are left with whatever survived — in my case, 758. Pasting usually leaves you with an empty string instead, and element.value is "". valueAsNumber hands you NaN.

Every one of those outcomes is silent. The field looks fine. And that is the part worth internalising: type="number" doesn't protect you from bad input, it converts bad input into plausible input. A blank field is a bug you notice. 758 is a bug that ships.

The same bug from the other end

While I was in there I found the server-side half:

const normalized = value.replace(",", ".").trim();
const numeric = Number(normalized);
return Number.isFinite(numeric) ? numeric : fallback;

String.prototype.replace with a string pattern replaces the first match only. I wrote that line myself and had read past it many times.

"1234,56" becomes "1234.56" becomes 1234.56. Fine — which is why it survived so long.
"1 234,56" becomes "1 234.56" becomes NaN, and falls back to 0.
"1,234.56" becomes "1.234.56" becomes NaN, and falls back to 0.

So the two halves of the same system failed in opposite directions — one invented a small number, the other invented zero — and both did it quietly.

Reading a number the way a person reads it

You cannot fix this by picking one locale. My own traffic proves it: 10,377.84 and 77107,10 are both real inputs from real people on the same page, one written the American way and one the Spanish way. Force either convention and you are wrong for half your users.

But you don't need to guess, because a human reading 1.370.801.919,12 has no trouble at all. Write down what they're doing:

Both . and , appear — the one that appears last is the decimal separator, the other groups thousands. 1,370,801,919.12 decides on .; 208.333.333,33 decides on ,.
One kind of separator, and it repeats — it groups thousands. 3.635.758 has two dots, so the dots are grouping.
One separator, exactly three digits after it — genuinely ambiguous. 1.234 is "one thousand two hundred thirty-four" to a Spaniard and "one point two three four" to an American, and nothing in the string tells you which. This is the only case where the page's own locale decides.
Anything else — decimal separator. 77107,10, 1.5, 0,5.

Here it is, minus the currency-symbol stripping:

export function parseHumanNumber(raw, decimalSeparator) {
  const cleaned = raw.replace(/[\s  ]/g, "").replace(/[€$£¥]/g, "");
  if (!cleaned) return null;

  const negative = cleaned.startsWith("-");
  const body = cleaned.replace(/^[+-]/, "");
  if (!/^[\d.,]+$/.test(body)) return null;

  const lastDot = body.lastIndexOf(".");
  const lastComma = body.lastIndexOf(",");
  let decimalAt = -1;

  if (lastDot >= 0 && lastComma >= 0) {
    decimalAt = Math.max(lastDot, lastComma);          // rule 1
  } else if (lastDot >= 0 || lastComma >= 0) {
    const at = Math.max(lastDot, lastComma);
    const mark = body[at];
    const howMany = body.split(mark).length - 1;
    const digitsAfter = body.length - at - 1;

    if (howMany > 1) decimalAt = -1;                   // rule 2
    else if (digitsAfter === 3)                        // rule 3
      decimalAt = mark === decimalSeparator ? at : -1;
    else decimalAt = at;                               // rule 4
  }

  const wholeRaw = decimalAt >= 0 ? body.slice(0, decimalAt) : body;
  const fraction = decimalAt >= 0 ? body.slice(decimalAt + 1) : "";
  if (/[.,]/.test(fraction)) return null;

  // Separators left in the integer part have to be real grouping:
  // one kind of mark, groups of exactly three.
  if (/[.,]/.test(wholeRaw)) {
    if (wholeRaw.includes(".") && wholeRaw.includes(",")) return null;
    const mark = wholeRaw.includes(".") ? "." : ",";
    const groups = wholeRaw.split(mark);
    if (groups[0].length < 1 || groups[0].length > 3) return null;
    if (groups.slice(1).some((g) => g.length !== 3)) return null;
  }

  const whole = wholeRaw.replace(/[.,]/g, "");
  if (!whole && !fraction) return null;

  const value = Number(`${whole || "0"}.${fraction || "0"}`);
  return Number.isFinite(value) ? (negative ? -value : value) : null;
}

That last block is the one I nearly skipped, and it matters most. Without it, 1,23,4.5 parses to 1234.5 — a confident answer to a string that means nothing. Returning null on garbage is the whole point. If you are replacing a silent wrong number, do not replace it with a different silent wrong number.

The element itself

<input
  type="text"
  inputMode="decimal"
  value={typed}
  onChange={(e) => {
    setTyped(e.target.value);
    setValue(parseHumanNumber(e.target.value, ",") ?? NaN);
  }}
/>

inputMode="decimal" still brings up the numeric keypad on phones, which is the one thing type="number" was genuinely providing here. You also lose the spinner arrows, and nobody has ever wanted to increment an invoice total by one.

There is a React trap in those few lines. The typed text and the parsed number have to be separate state. If the input's value is the parsed number, then the moment someone types 1, the value is 1, React re-renders, and the comma disappears from under their fingers. They cannot type a decimal at all. Show what they typed; compute from what you understood.

One more change, and it costs nothing

The page now prints the amount it understood, in digits, right beside the words:

1.370.801.919,12 €  ->  mil trescientos setenta millones ochocientos
                        un mil novecientos diecinueve euros con doce céntimos

Any parser like this has a genuinely ambiguous case — rule 3 above. I can pick a sensible default, but I cannot be right every time, and a tool that writes the sum on a contract has no business being quietly wrong. Echoing the parsed number back turns an invisible failure into one the reader catches in half a second.

The tests are just the search log

I didn't invent test cases. I pasted in the actual queries people had used to reach the page:

assert.equal(parse("1,370,801,919.12", ","), 1370801919.12);
assert.equal(parse("3.635.758",        ","), 3635758);
assert.equal(parse("10,377.84",        ","), 10377.84);
assert.equal(parse("77107,10",         ","), 77107.1);
assert.equal(parse("208.333.333,33",   ","), 208333333.33);
assert.equal(parse("$14.688.000",      ","), 14688000);
assert.equal(parse("1 234,56",         ","), 1234.56);

// ambiguity resolved by the page's language
assert.equal(parse("1.234", ","), 1234);   // Spanish page
assert.equal(parse("1.234", "."), 1.234);  // English page

// and the ones that must not produce an answer
for (const junk of ["", "abc", "12abc", "1.2.3,4,5", "1,23,4.5"])
  assert.equal(parse(junk, ","), null);

Your search console already knows the exact strings your users bring you. It is the best fixture list you will ever get, and it is free.

The takeaway

type="number" is fine for a quantity picker. It is the wrong control for any figure a person copies from somewhere else — an invoice total, a salary, a price, an account balance — because those arrive already formatted, and formatting is precisely what that element cannot survive.

Go and paste 1,234.56 into your own form right now. Then paste 1.234,56. Then look at what your backend stored.

The tool in question, if you want to see the fix in place: Número a letras — it writes amounts out in Spanish for contracts and cheques, in euros, pesos or dollars.

How long to cook 200 foods in the oven — as an open dataset with official sources (CC BY-SA 4.0)

farcrak — Thu, 06 Aug 2026 01:08:09 +0000

Yesterday I released a recipe dataset. Today its companion: oven cooking times and temperatures for 200 products, from chicken breast to cheesecake — every number backed by a primary source.

Download

JSON (~216 KB): https://theunitools.com/data/unitools-cooking-times-v1.json
CSV (one product per row): https://theunitools.com/data/unitools-cooking-times-v1.csv
Docs: https://github.com/farcrak/unitools-recipes
Dataset page: https://theunitools.com/en/data

What each record holds

Oven temperature (°C and °F) and a practical time range in minutes
Safe minimum internal temperature where an official one exists (FoodSafety.gov / USDA FSIS charts)
Rest time, reference weight/thickness, doneness levels, and the key geometry driver (thickness vs weight vs batch size)
sources — the actual URLs each number came from: government charts, King Arthur Baking, manufacturer package directions (Ore-Ida, Gorton's, Stouffer's, Totino's…)
confidence — an honest high / medium flag: chart-backed numbers vs converging culinary sources

Why sources per row matter

Most cooking-time tables on the internet are copies of copies with no provenance. Here you can trace "boneless chicken thighs: 18–25 min at 425°F" back to the page it came from, and decide for yourself whether to trust it. The medium confidence flag marks numbers where no official chart exists — that honesty is baked into the data rather than hidden.

Licence

CC BY-SA 4.0 — commercial use allowed. Credit "UniTools — theunitools.com", share derivatives alike.

If you build a kitchen timer, an Alexa skill, or a meal-prep planner on top of it — tell me in the comments, I'd genuinely love to see it.

501 world recipes as an open dataset: per-serving nutrition, step timings, ingredient scaling rules (CC BY-SA 4.0)

farcrak — Thu, 06 Aug 2026 00:05:32 +0000

Last month I wrote about building a 1,800-page calculator site solo. Since then the recipe hub on that site grew to 501 dishes from 127 countries — and today I'm releasing all of it as an open dataset.

Download

JSON (full dataset, ~2.6 MB): https://theunitools.com/data/unitools-recipes-v1.json
CSV (one dish per row): https://theunitools.com/data/unitools-recipes-v1.csv
Docs + sample record: https://github.com/farcrak/unitools-recipes
Dataset page: https://theunitools.com/en/data

What's inside

501 home-cooking recipes, 127 countries, bilingual (English + Russian, both written by hand — no machine translation)
Per-serving nutrition (calories, protein, fat, carbs) on every single dish
3,200+ steps, each annotated with minutes
Ingredients with stable ids and scaling rules: meat scales linearly with servings, salt and spices are damped — the way an actual kitchen scales a recipe, not naive multiplication
Human-reviewed Wikimedia Commons photos with author + licence per photo

Why the scaling rules matter

Most recipe datasets store "2 tbsp salt for 4 servings" and leave scaling to you. Multiply salt linearly to 16 servings and the dish is inedible. Each ingredient in this dataset carries a scaling field (linear | damped | fixed), so a portion calculator can be built directly on top of the data. That's exactly how the recipe pages on the site work.

Licence

CC BY-SA 4.0 — free for commercial use. Credit "UniTools — theunitools.com" and share derivatives under the same licence. Photos carry their own Commons licences (in the data).

Honest caveats

Nutrition is computed from ingredients, not lab-measured — a planning reference, not medical data. The dataset is maintained by one person; if you spot an error, open an issue on the repo and the fix lands in the next version.

If you build something with it — a meal planner, a viz, a model fine-tune — I'd genuinely love to hear about it in the comments.

How I built ~1,800 "honest" calculator pages with Next.js + SQLite

farcrak — Tue, 07 Jul 2026 00:57:08 +0000

It started with a dumb frustration. Every "how long to cook chicken thighs" page gives you a different number, and none of them tell you where the number comes from. Some say 25 minutes, some say 40, and you're standing there with a thermometer wondering who to trust.

So I did the developer thing and over-engineered a solution. What began as one cooking-time calculator turned into ~1,800 generated pages. Here's how it's built and a couple of footguns that cost me real traffic.

The data model: start from a source, not from blog numbers

The core idea: don't hardcode "chicken = 30 min". Start from the official safe internal temperature (USDA/FSIS charts — poultry 74°C, whole cuts 63°C + rest, fish 63°C) and treat time as a function of geometry.

Each food is a row with a reference point and a driver:

type CookingEntry = {
  slug: string;
  safeMinInternalTempC: number | null;
  referenceTempC: number;
  referenceTimeMin: number;
  referenceTimeMax: number;
  referenceThicknessCm: number | null;
  referenceWeightG: number | null;
  keyGeometryDriver: "thickness" | "total_weight";
};

Then the estimate scales the reference time by how far your piece is from the reference, using a power law instead of a linear guess (a steak twice as thick doesn't take twice as long — heat diffusion is closer to thickness²):

const ratio = input.thicknessCm / entry.referenceThicknessCm;
const factor = Math.pow(ratio, 1.2); // clamped to sane bounds
const minutes = referenceCenter * factor * tempFactor;

Is it perfect? No — it's a household estimate, and the page says so and shows the safe temperature so you can verify with a thermometer. But it's honest about where it comes from, which is more than most results give you.

1 entity = 1 indexable page

The whole thing is programmatic SEO: every food, every city, every scenario is its own route under the Next.js App Router.

app/[locale]/cooking/how-long-to-cook/[slug]/page.tsx
app/[locale]/date-time/world-clock/[slug]/page.tsx

Metadata is generated per-entity in generateMetadata, and there's a dynamic app/sitemap.ts that enumerates every dataset entry. The trap here is lastmod: I first set it to new Date(), which re-stamped all ~1,800 URLs as "changed" on every deploy. Crawlers learn to distrust that fast. Fix: a single datasetLastReviewed constant I bump only when the data actually changes.

SQLite is fine (really)

The datastore is SQLite via Prisma. For a read-heavy site with curated datasets it's genuinely fine — no connection pool, no separate DB server, the whole thing is a file you can .backup in a cron job. The dataset itself lives in versioned TSV/JSON, so the DB is more of a cache than a source of truth.

Time zones will humble you

The world-clock pages use the Temporal API (via the polyfill) instead of raw Date, because DST math is where naive code dies:

const zoned = instant.toZonedDateTimeISO("Europe/Prague");
const offsetMin = Math.round(zoned.offsetNanoseconds / 60_000_000_000);

Each page also computes the next clock change by binary-searching for the offset flip, so a "12:00 UTC to Kyiv" page can tell you when the answer will shift. Real IANA zones, date-aware offsets, no static UTC+2 lies.

Two footguns that cost me traffic

www returning 200. Behind a proxy, request.nextUrl.hostname isn't reliable — I had to check Host and X-Forwarded-Host in middleware to 301 www → apex. Until I did, Google had two copies of every page and split the signals.
hreflang x-default pointing at the wrong locale. It decides what Google serves everyone outside your declared locales. Mine defaulted to the non-English version while the inventory targeted English queries. One-line change, big difference.

Stack, for the curious

Next.js (App Router) + TypeScript + Tailwind + Prisma/SQLite, ~1,800 pages generated from curated datasets, deployed with a boring git pull + pm2 restart script. Solo project.

If you want to poke at the actual output, it's live and free (no signups, no paywall): https://theunitools.com/en — I'd genuinely like to hear if a cooking time looks off to you, since that's the part I care about most.