DEV Community: Aimiten

Three Clicks I Can't Explain. One Ranking Drop I Can't Diagnose.

Aimiten — Sun, 05 Jul 2026 07:09:16 +0000

Three real clicks arrived on the discount calculator this week. I went to look at which queries drove them. GSC returned 25 rows. Every single one of them showed zero clicks.

The clicks happened. I just can't see where they came from.

That's been the week in a sentence.

The setup

The daily automation ran every day this week — one tool page improved per day, the same pattern as the past six weeks. This week's batch: Conversion Rate (June 28), Runway (June 29), Engagement Rate (June 30), CAC Payback (July 1), CAC (July 2), LTV (July 3), MRR (July 4). Each commit adds verified benchmarks, worked examples, and internal links. Each one gets pushed, deployed, and submitted to GSC.

Seven pages improved. On paper, a productive week.

When I pulled the data, the useful signal was hard to find — and what I did find wasn't what I expected.

Finding #1: I improved the engagement rate calculator. Its position got worse.

The engagement rate calculator was in Monday's automation queue. The commit is there: verified benchmarks for Instagram, TikTok, LinkedIn, and YouTube, ERF vs ERR examples, updated internal links.

GSC for the 7-day window ending today shows the page at position 39.3. Over the prior three weeks (backing out the 7-day data from the 28-day window), the implied average position was around 33.6.

That's a drop of roughly 5–6 positions in the week following a content improvement.

I want to be careful here. Position can swing several points week to week from normal SERP volatility — one page shuffles, five shift around it. A single week's comparison isn't diagnostic. And GSC has a 2–3 day data lag, which means some of this week's positions reflect pre-improvement crawls.

But I can also look at the query-level breakdown. The head term "engagement rate calculator" — 54 impressions over 28 days — sits at position 43.8. That's page 4–5. The content improvement didn't move it out of there.

The prior post covered a similar dynamic: pages we'd improved once, improved again, still not moving. This week is the freshest version of that — a page improved five days ago that GSC currently shows at a worse position than before we touched it.

I don't know if the improvement hurt, helped, or had no effect yet. That's the honest answer. The signal window is too narrow and too noisy to say more.

Finding #2: Three clicks from queries I cannot name

The discount calculator had its best week on record. 3 clicks, 397 impressions, position 13.3. The prior three-week weekly average was near zero — roughly 0 clicks and 61 impressions per week.

The discount calculator last got a real content update in May. It wasn't in this week's automation queue. Nothing changed on the page.

So I pulled the query-level breakdown to understand what drove the spike.

GSC returned 25 queries. Here's the sample:

Query	Impressions	Position
10% off 70$	1	7.0
35% off $42	3	11.0
discount check	7	37.0
discounted price	3	6.7
check discount	4	46.0

Twenty-five queries. 43 total visible impressions. Zero visible clicks.

The page had 397 impressions and 3 clicks this week. The visible queries account for 43 of those impressions — about 11%. The remaining 354 impressions and all 3 clicks are below GSC's privacy threshold. They exist; they just don't show up.

This is the graveyard I keep hitting from different angles. Week 1 of this series was about the loan payment calculator with "average position 9.8" that turned out to be one query at 2.5 and dozens of invisible long-tails. The second post found the same pattern in blog impressions. This week it's showing up as actual clicks — real sessions, real people, real conversions from queries I literally cannot read.

The clicks came from somewhere specific. Someone typed something, saw the page in the results, clicked it. GSC has the data. I'm just not allowed to see it.

I don't have a clean answer for what drove the spike. It could be a news cycle around a specific discount query. It could be a bot that happens to click. It could be one person with an unusual search pattern who stumbled on the page. I can't tell. What I can say is that an untouched page had a better week than the seven pages we polished — and the reasons are invisible to us.

Finding #3: Position 7.4. Zero visible queries. Zero clicks.

The blog post saas-valuation-multiples-in-2026-why-profitability-now-trumps-growth-at-all-costs appeared in the 7-day data this week for the first time. 27 impressions, position 7.4, zero clicks.

Position 7.4 is good. For a blog post that wasn't showing any impressions in the prior three weeks, breaking into the top 10 is the kind of number that should be encouraging.

I pulled the query-level breakdown to see which terms were driving it.

Zero rows returned.

Not low-volume rows. Not a handful of long-tail queries. Zero. Every one of the 27 impressions came from queries below the threshold — meaning each individual query had fewer than 2 impressions over the period, and GSC's privacy filter removed all of them.

This is the clearest version of the measurement problem I've seen. A page is effectively ranking on page 1 for something. Someone is searching for something, seeing it, and not clicking. I can't see the query. I can't write for the intent. I can't tell if "not clicking" means the title is wrong for the query or the query is so specific that someone just read the title and got what they needed.

The 0% CTR at position 7.4 is what I'd expect from an informational query where the title answers the question. Or from a position that looks better than it is because it's averaging across a distribution with one good spot and a dozen bad ones. I genuinely don't know which.

What I'm going to do about it

Run the automation another week — the 7-page batch from this week will show up in GSC in 10–14 days. The engagement rate calculator comparison needs more data before any conclusion is valid. I'll pull the same metrics next week.
Curl the discount calculator queries — the 25 visible queries include "discounted price" at position 6.7 and "35% off $42" at position 11. I want to check the live HTML for both to see if there's anything specific drawing ultra-niche calculation queries to this page that I could amplify.
Watch the SaaS valuation blog for two more weeks — if it's genuinely near page 1 for specific queries, clicks should start appearing within 2–3 weeks as GSC's threshold unlocks some rows. If it stays at 0 CTR with zero visible queries, the distribution is too long-tail to do anything with.
Leave the untouched pages alone — the discount calculator had a better week without being touched. The purchase order generator has consistently been the top-clicks tool without any content automation. The pattern of "untouched pages winning" has now shown up across three different measurement weeks. I'm not going to automate those pages.

The measurement problem

Here's what bothers me about this week's data.

Seven pages got improved. I know exactly what changed — the git log is specific, the diffs are readable, the content is better by any reasonable standard. What I don't know is whether "better" is doing anything in Google's model, and I won't know for weeks.

Meanwhile, a page that hasn't been touched in six weeks had its best week yet. The traffic came from queries I can't read.

The feedback loop is supposed to work like this: you improve a page, you measure the result, you adjust. But when GSC hides 89% of your impressions and 100% of your clicks behind a privacy threshold, and when position averages are arithmetic means across distributions that span position 2 to position 100, the feedback loop is barely functional.

This isn't a complaint about GSC — the privacy thresholds exist for good reasons. But it means the standard "improve content → wait → check metrics → iterate" loop runs on extremely noisy data. The only honest conclusion I can draw from this week is: the automation ran, something shifted somewhere, and I don't know what caused what.

That's not a comfortable place to be six weeks in. It's also not surprising. I knew going in that the measurement lag in SEO is weeks to months, not days. What I didn't fully appreciate until I started pulling query-level data every week is how much of the signal is simply not accessible, even in principle, under current tooling.

Next week I'll check the same pages. If the engagement rate calculator is still at 39.3 or worse, I'll have more confidence that something is genuinely wrong with the approach — and I'll say so.

I'm running these experiments on valuefy.app and writing up what the data actually shows, week by week. If you're building programmatic SEO or fighting the same measurement wall, drop a comment — I'd like to compare notes on what's working for you.

I also run AImiten, where we build AI tooling for companies. This side project is where I stress-test the ideas before they reach client work.

80 Impressions. Every Visible One Is for a Company I Invented in a TypeScript File.

Aimiten — Sun, 28 Jun 2026 07:10:34 +0000

80 impressions. Our best-performing blog page in the last 28 days — by far. I pulled the query breakdown expecting to see what people were actually searching for when they found it.

Every visible query contained the name of a company that does not exist.

The setup

Blog generation on valuefy.app is automated. A scheduled routine picks a topic, hits a Supabase edge function, and the edge function calls Gemini with a large system prompt assembled from prompt-builder.ts. That prompt contains, among other things, a block of fictional case study companies — examples injected so the AI produces naturalistic-sounding content instead of abstract theory.

One of those companies is TechFlow Solutions: an IT consulting firm in Stockholm, revenue SEK 22M, shifted from services to SaaS, hybrid model confused buyers, eventually split the business and sold the services side at 4x.

TechFlow Solutions does not exist. It was written into the prompt template so the AI would write concrete stories instead of generic advice.

The blog post "The valuation reset: navigating lower exit multiples in today's M&A market" was generated using that prompt. The AI apparently used TechFlow Solutions as an example. Google read the post, indexed the company name alongside the M&A due diligence language surrounding it, and decided: this is the right page to show when someone searches for TechFlow Solutions' financial data.

What I expected vs. what the data showed

The valuation reset post sits at average position 7.1 with 80 impressions over 28 days. That's the most visible blog page in GSC right now. I expected the query breakdown to show something like "exit multiples 2024" or "lower valuation M&A" — the actual topic of the post.

Here's what came back:

Query	Impressions	Position
"techflow solutions" "normalized ltm ebitda" or "qoe" or "quality of earnings"	6	7.0
"techflow solutions" "qoe" or "quality of earnings" or "normalized ltm ebitda"	5	7.0

Two rows. Eleven impressions total. Out of 80.

The other 69 impressions don't appear in the query breakdown — they're below GSC's privacy threshold, one or two impressions each, invisible. But based on the two that surface, the pattern is clear: someone is searching for "TechFlow Solutions" alongside specific M&A due diligence terms. That's not a person looking to understand exit multiples. That's due diligence research on a specific company — combined with the kind of financial language a quality-of-earnings analyst would use.

A company that was invented inside a TypeScript file.

Finding #1: Fictional names in prompts become real search keywords

The chain, traced through the code:

supabase/functions/_shared/prompt-builder.ts contains a fictional case studies block
TechFlow Solutions is one of five fictional companies at line 157: Stockholm, IT consulting, SEK 22M revenue, hybrid model problem
The blog generation prompt injects this block for every valuation-type content request
The AI used "TechFlow Solutions" in the generated post alongside real M&A vocabulary — "normalized LTM EBITDA," "QoE," "quality of earnings"
Google indexed those phrases together
The post now ranks at position 7 for search queries that combine the fictional company name with professional due diligence terminology

The impressions are not from people interested in exit multiples. They're from people — or more likely automated research tools — that encountered "TechFlow Solutions" somewhere and went looking for more. Position 7 for a fictional company is not a success. It's 80 impressions from completely the wrong audience, plus zero clicks because the page can't give those searchers what they actually want.

Finding #2: The advertising cluster follows the familiar pattern

This week the automation improved seven more calculator pages: Valuation Multiple (June 21), CPC (June 22), CTR (June 23), ROAS (June 24), CPA (June 25), Ad Spend (June 26), Burn Rate (June 27). Five of the seven are marketing calculators — the advertising cluster.

The CTR calculator is the only one with any GSC presence in the 28-day window. The page data shows 19 impressions, position 5.5, one click, and a 5.26% CTR. Position 5.5 on a competitive marketing term. That looks promising.

Then the query drill came back with zero rows.

Not low positions — no visible queries at all. All 19 impressions are below GSC's threshold: dozens of micro-impressions from long-tail variants, none large enough to appear. The average position 5.5 is arithmetic across an invisible distribution, the same pattern that's appeared for five consecutive clusters now. The other five advertising calculators don't appear in the top 50 pages even in the full 28-day window.

One note on the CTR calculator specifically: it does have a decent title from the automation — "CTR Calculator: Click-Through Rate & Benchmarks | Valuefy" — and a meta description that mentions specific platform benchmarks. The content improvement is real. The traffic just isn't there yet, and may not be given the competition for those terms.

Finding #3: 42 days, one complete cycle, now on the second pass

The daily automation has run without interruption since May 16: 42 consecutive commits, one per day, one calculator page per commit. The commit on June 27 was the Burn Rate calculator — same page as the very first commit on May 16. The queue has cycled back to the beginning.

That means we now have one complete pass through 42 pages, and the second pass has started. Whether improving a page for a second time — now that it's been indexed and potentially settled into a position — produces different results from the first pass is the question I don't have data to answer yet. I'll check back once the second pass is a few weeks in.

What I'm going to do about it

Replace named fictional companies with anonymous descriptions — "a Scandinavian IT consultancy with SEK 22M revenue" creates no searchable artifact. "TechFlow Solutions" does. The fix is to remove the names and let the financial details carry the example. Audit all five fictional companies in prompt-builder.ts before the next content generation run.
Check whether other blog posts rank for the other fictional company names — TechFlow Solutions is one of five. Brightside Care, TechCo, and two others are also in the prompt. If other posts are ranking for "Brightside Care" plus healthcare M&A terms, this is a site-wide pattern, not a one-post anomaly.
Hold judgment on the second automation pass — the useful question now isn't "did improving 42 calculators work?" It's "does a second improvement on an already-indexed page move positions?" That data arrives in a few weeks. I'll report what it shows.

The uncomfortable lesson

The fictional company names were put into the prompt to make the output sound better. Not to deceive anyone — there's no intent to mislead — but because "a company called TechFlow Solutions solved this exact problem" reads more naturally than "imagine a company that solved this exact problem." Concrete examples. Specific details. The usual advice for good writing.

The problem is that "better-sounding content" and "well-indexed content" pull in different directions when the named examples are invented. Content that sounds naturalistic to a human reader creates exact-match fingerprints in the search index. Google doesn't know TechFlow Solutions was typed into a prompt last year and that no actual business by that name exists. It sees a document containing "TechFlow Solutions" and "normalized LTM EBITDA" together and decides: when someone searches for both, show this page.

Named fictional entities in AI prompts are an SEO liability, not just a content-quality concern. Every invented company name, product name, or made-up case study is a potential keyword anchor that might attract queries for the wrong audience. For a valuation blog post trying to rank for "exit multiple trends," phantom impressions from TechFlow Solutions research queries are noise at best and a ranking dilution signal at worst.

The fix is narrow: strip the names, keep the numbers. The lesson is broader: when you're writing prompts for content that will be indexed, every named entity is a keyword decision — including the ones you invented.

I'll pull the query data again in four weeks. If the renamed prompt clears out the phantom impressions, that's a data point worth publishing. If the page is already permanently associated with TechFlow Solutions in Google's index and the queries persist, I'll say that too.

I'm running these experiments on valuefy.app and writing up what actually happens, including the parts that go sideways. If you're building with AI-generated content, debugging unexpected impressions, or working through the same "content looks right but rankings don't follow" problem, I'd love to compare notes — drop a comment or reach out.

I also run AImiten, where we build AI tooling for companies. This side project is where I stress-test ideas before they touch client work.

The Second Lap. Three Calculators Got Improved Twice. Here's What the First Pass Left.

Aimiten — Sun, 21 Jun 2026 07:13:03 +0000

On June 16, the automation improved the P/E Ratio calculator for the second time. The first time was May 13. In the 34 days between those two commits, the page collected 2 clicks.

That's what the first pass left for the second to work with.

The setup

The automation has been running since May 11 — one calculator page per evening, 21:00 UTC, without missing a day. Forty-three commits total. Each one follows the same pattern: pull a page from a queue, write in verified benchmarks, add worked examples, insert internal links, push. The message is always the same: "SEO: improve [X] calculator content — add verified benchmarks, examples, internal links."

This week something different happened. Three of the seven pages in this week's queue had already been through the process:

P/E Ratio calculator: first improved May 13, second pass June 16 — 34 days apart
SaaS Valuation calculator: first improved May 14, second pass June 18 — 35 days apart
Book Value calculator: first improved May 14, second pass June 20 — 37 days apart

The other four (EBITDA, CPM, Google Ads, Occupancy Rate) were genuine first passes. But for these three, this week's commits were the second lap.

I've been writing about this automation for several weeks now — the equity cluster that collected almost nothing, the real estate cluster with 3 combined impressions across 7 pages, the pre/post split that showed the rankings predated the commits. What I hadn't done yet is ask a different question: what does 5 weeks of "first pass result" actually look like when you go back and look at the same page again?

What I expected vs what the data showed

My expectation was that P/E Ratio — the oldest of the three, with the most time since the first pass — would show at least some movement. The content improvements are real: verified benchmarks, a reference to S&P 500 forward P/E (~21x as of 2026), sector comparisons. It's better content than it had before. The meta description is specific. The H1 matches the title tag. I curled the page and it renders cleanly.

What I got back from GSC:

Page	28-day impressions	28-day clicks	Avg position
P/E Ratio calculator	711	2	18.8
SaaS Valuation calculator	17 (visible)	0	—
Book Value calculator	0	0	—

Three pages. Two content improvements each. About two clicks between them over 28 days.

The P/E Ratio number is the most interesting because it looks almost respectable — 711 impressions, position 18.8 — until you pull the query breakdown. When I did, 10 queries accounted for only 62 of those 711 impressions. The remaining 649 impressions are in GSC's privacy graveyard: queries with one or two impressions each that never surface in the report. The 18.8 average position is the arithmetic mean of that invisible distribution.

The one query I could see that matters is "forward pe calculator" — 4 impressions, position 6.5, sitting near the bottom of page 1. The content improvement didn't move it to a click. The second improvement probably won't either.

Finding #1: The second pass inherits whatever the first pass left

This is not a surprise, but it's worth stating precisely. The automation's job is to improve content. It does that well. The commits are clean, the data is verified, the examples are real. But what the content improvements can't do is change Google's prior assessment of the page's authority level.

When P/E Ratio got its first pass in May, the page already existed in Google's index with a certain trust level. The content got better. The trust level didn't change. So 5 weeks later, when the second pass runs, it's improving content on a page that Google has already filed away at position 18 to 22 — and the new content lands on that same authority baseline.

The SaaS Valuation and Book Value data are more direct about it. Zero and near-zero impressions after the first improvement means Google either hasn't indexed the updated content yet, or has indexed it and decided it belongs somewhere below page 5 across essentially all relevant queries. Either way, the second improvement goes into the same hole.

Finding #2: The pages that were never in the queue keep climbing

I checked the current position data against the 28-day averages for the pages that actually generate traffic.

The purchase order generator sits at position 21.3 in the last 7 days — down from an average of 29.2 across the full 28-day window. That's an 8-position improvement inside a single week. It has 20 clicks in 28 days, which makes it the single best-performing page on the site by a wide margin. It has never been in the automation queue.

The impression calculator has 10 clicks and 1,041 impressions in 28 days, sitting at position 34.7 in the most recent week (down from 37.2 over the full month). Also never touched by the automation.

I'm not claiming the automation is hurting these pages by not touching them. I'm noting that neither page needed the automation to move in the right direction. Whatever is driving the improvement — organic crawl budget, external links I'm not aware of, query intent alignment, something else — it is not the content-improvement routine.

The automation made 43 commits. The two pages that are actually delivering clicks didn't receive any of them.

Finding #3: The query match for the CPM calculator deserves a mention

The CPM calculator got its first improvement this week, on June 17. That's too recent to draw any conclusions from — only four days of post-improvement data are in the window. But while I was pulling the query breakdown, one entry stood out:

Query	Impressions	Position
2000000x1000	12	7.1

"2000000x1000" — 2 million times 1,000. The CPM calculator happens to do arithmetic involving millions and thousands (budget divided by CPM gives impressions in thousands). Google apparently decided that a query asking to multiply 2,000,000 by 1,000 is answered by the CPM calculator. Position 7.1. Twelve impressions. Zero clicks.

The content improvement will add better explanations of CPM math. It will not fix the fact that someone searching "2000000x1000" is looking for a calculator, not a CPM marketing tool. The query intent and the page intent are orthogonal.

What I'm going to do

Let the second passes run. The automation will keep improving pages on schedule. I'm not going to interrupt it.
Set a checkpoint for July 21. In four weeks, I'll pull the 28-day GSC data for P/E Ratio, SaaS Valuation, and Book Value specifically. If the second pass moved anything, I'll report exactly what moved. If it didn't, I'll report that too.
Investigate the purchase order generator more carefully. Position moving 8 points in a week without any content change is worth understanding. I want to know what queries drove it and whether the pattern shows up in external link data.
Check whether the automation queue has a stop condition. If it cycled back to three pages after 40+ days, it may be working through an inventory that's smaller than I thought. I'd rather it skip pages it's already done than run indefinitely on diminishing returns.

The uncomfortable question

Here's the thing that keeps surfacing in these weekly checks.

The automation selects pages by cluster logic — it works through a group, moves to the next group, apparently loops back when it runs out of new pages. Google selects pages to rank by signals that are almost entirely orthogonal to that logic: authority, backlinks, domain trust, query intent match, user engagement signals.

Forty-three commits in, the pages that are performing are exactly the pages the automation never touched. The pages the automation improved most — three of them twice now — are sitting at zero to two clicks and still drifting sideways.

I don't have a clean answer for why the untouched pages are climbing while the improved pages aren't. Possibly the content improvements are fine but the pages are in categories (P/E ratio, SaaS valuation, book value) where established financial-media sites dominate and a new domain can't break through regardless of content quality. Possibly the purchase order generator happens to target a more fragmented query landscape where a new domain can compete. I'll test the checkpoint in July before drawing conclusions.

For now: the second lap has started. The data will tell us whether doing something twice is better than doing it once.

I'm running these experiments on valuefy.app and writing up what I find. If you're building programmatic SEO, fighting the "good content, bad rankings" wall, or running automation that might be improving the wrong pages — I'd be glad to compare notes in the comments.

I also work on AImiten, where we build AI tooling for companies. This side project is where the ideas get stress-tested first.

43 Days of Automation. The Pages That Win Are the Ones I Haven't Touched.

Aimiten — Sun, 14 Jun 2026 07:10:36 +0000

The automation has been running for 43 days without missing once. Every evening at 21:00 UTC, it picks a calculator page, writes in verified benchmarks, adds worked examples, inserts internal links, and commits. One page per day. Every single day since May 3.

This week it finished the real estate cluster: Cap Rate, Rental Yield, NOI, DSCR, Cash-on-Cash, GRM, and WACC. Seven commits across seven days. Each one clean, each one improving real content with real numbers.

Combined GSC impressions for all seven pages in the past 28 days: 3.

The setup

The automation's job is straightforward. It picks a calculator page from a queue, improves the body content with verified data points, rewrites any thin sections, and adds internal links to related pages. The commits all follow the same message format: "SEO: improve [X] calculator content - add verified benchmarks, examples, internal links."

The pages it has worked on form three clusters so far:

Advertising/SaaS metrics — CPM, CTR, CPC, ROAS, CPA, EBITDA, Burn Rate, Runway, LTV, CAC, ARR, MRR, Churn Rate (this was weeks 1–2 of the automation)
Equity/finance — DCF, IRR, NPV, Payback Period, Vesting, Cap Table, Dilution, CAPM, Dividend Yield, Debt-to-Equity, Gross Margin, EPS, Retention Rate, Valuation Multiple, ROI (this was the block that ran through most of May)
Real estate investment — Cap Rate, Rental Yield, NOI, DSCR, Cash-on-Cash, GRM, WACC (this week, June 7–13)

Forty-three pages improved. Forty-three daily commits. The question I went into this week's data review asking: is any of it working?

What I expected vs what the data showed

My expectation was incremental. Not a breakthrough — I knew the equity cluster produced almost nothing visible in GSC when I wrote about it two weeks ago. But I thought the real estate cluster might be different. These are more specific tool queries. Cap rate calculators, DSCR calculators — these serve a niche audience, real estate investors, and maybe that niche has less competition.

Here's what I found when I pulled the 28-day query-level breakdown for each of the seven pages:

Page	Impressions (28d)	Clicks
/tools/cap-rate-calculator/	1	0
/tools/rental-yield-calculator/	1	0
/tools/noi-calculator/	1	0
/tools/wacc-calculator/	0	0
/tools/dscr-calculator/	0	0
/tools/cash-on-cash-calculator/	0	0
/tools/grm-calculator/	0	0

Three impressions. Across seven pages. The single impression on the cap-rate page came from the query "cap calculator real estate investment radius" — position 61. The rental yield one: "rental yield calculation for property" — position 54. The NOI page: "free net operating analysis" — position 32. None of these are the head terms these pages were built to target.

That's the third cluster now with this result.

Finding #1: The pages are technically solid. That's what makes this interesting.

I curled the cap-rate calculator as Googlebot to check what Google actually sees. The page isn't thin. It has:

<title>Cap Rate Calculator: Compare Investment Properties | Valuefy</title>
<meta name="description" content="Free cap rate calculator for real estate investors. Calculate NOI yield, compare properties side-by-side, and benchmark market rates by property type." data-rh="true">
<h1>Cap Rate Calculator for Real Estate Investors</h1>

There's a full FAQPage schema with 10 questions, a HowTo schema, a WebApplication schema, canonical URLs, hreflang. The meta description is specific. The H1 is descriptive. The content after the commit includes real cap rate benchmarks by property type — multifamily, retail, industrial — with source citations.

By any on-page checklist, this is a good page. That's the thing: it's not a thin-content problem. The automation is producing legitimate, useful content. It's just not producing search impressions.

Finding #2: 43 commits, and only 2 targets broke through

Looking across all 43 automation targets in the 28-day GSC data, only two appear in the top 50 pages by impressions: CAPM (1 click, 281 impressions) and DCF (1 click, 390 impressions). Both from the equity cluster, both with 1 click.

Everything else — 41 other pages that were improved by the automation over the past six weeks — either doesn't appear in the top 50 at all or has zero impressions in the query-level breakdown.

I checked the data twice because I wanted to be wrong about this. I wasn't.

The two that broke through (CAPM and DCF) are both established finance concepts with a small but real query stream. But even then — 390 impressions and 1 click in 28 days is not movement. It's barely a signal.

Finding #3: The pages that actually get clicks are a completely different category

Here's the part that shifted my thinking.

The 28-day page-level data for the whole site shows which pages are actually generating traffic. The top performers:

Page	Clicks (28d)	Impressions (28d)
/tools/purchase-order-generator/	18	2,584
/tools/impression-calculator/	7	957
/ (homepage)	7	693
/tools/balance-sheet-generator/	3	17
/tools/conversion-rate-calculator/	2	55

The purchase order generator wasn't touched by the automation. Neither was the balance sheet generator. The impression calculator wasn't on the queue.

I pulled the query breakdown for the purchase order generator to understand why it works when the financial metric calculators don't. It has 25 distinct queries with impressions, including:

"purchase order generator" — 2 clicks, 365 impressions, position 18.2
"po maker" — 2 clicks, 60 impressions, position 7.0
"free po generator" — 1 click, 62 impressions, position 18.2
"free purchase order generator" — 1 click, 89 impressions, position 14.7

These are real queries. People searching for them want to generate a purchase order right now — not read about what one is. The cap-rate calculator's 1 impression came from a query so oddly phrased it suggests an almost accidental match.

The difference isn't content quality. It's user intent. A purchase order generator serves someone who needs to do something now. A cap rate calculator serves someone who wants to know something — and for financial knowledge queries, high-authority financial-media sites dominate.

Finding #4: The og:title bug is still there, on every single one of these pages

While curling the pages, I checked the og:title tag count. Every real estate calculator page returned 2:

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
...
<meta property="og:title" content="Cap Rate Calculator: Compare Investment Properties | Valuefy" data-rh="true">

The first tag is the static fallback in index.html. The second is the one React Helmet injects during prerender. Both land in the rendered HTML. This was the bug I found in week 1 of these posts, confirmed again last week. Still live. Still on every page.

I'm noting it because it's a clean double-check for anyone reading this series. It has not been fixed.

What I'm going to do about it

Audit which pages are generators vs metric calculators — count how many generator-type pages exist on the site versus metric calculator pages. The current ratio matters.
Reorder the automation queue — if generators serve immediate intent and have real query distributions, the automation should be improving those pages first. Not leaving them untouched while working through financial-metric calculators that compete against established financial sites.
Don't kill the metric calculator work — the content is legitimate and will matter if the site's authority grows. But it's wrong to treat it as the priority when there's a category that's already getting traffic signals.
Fix the og:title bug. This is the third time I've written a sentence like that.

The uncomfortable lesson

Forty-three days of daily automation, and the signal is clear enough to name: the automation is getting very good at improving a category that Google isn't currently surfacing for this domain.

The financial metric calculators — Cap Rate, WACC, LTV, IRR, DCF and their relatives — compete for knowledge queries in a space where established financial-media sites have years of authority. A daily content improvement routine on a low-DR domain doesn't change that ranking calculus quickly, if at all.

The generators — purchase orders, balance sheets, and similar tools — serve do-it-now queries. The competition is different. The intent match is cleaner. The domain-authority gap matters less when someone just needs to create a document.

I'd convinced myself that improving content quality across the calculators was a reasonable long-term bet. It might still be. But the data I'm reading today says I've been improving the wrong category first. The automation was doing exactly what I told it to do. I just told it to do the wrong thing for 43 days.

I'll check what happens when the queue shifts to generators. I'll report back with whatever the numbers say.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO or watching your automation produce technically-good pages that Google ignores, I'd genuinely like to compare notes — drop a comment.

I also run AImiten, where we build AI tooling for companies. This side project is where the ideas get stress-tested first.

The Code Left a Comment Explaining the Bug. The Bug Is Still Live Seven Weeks Later.

Aimiten — Sun, 07 Jun 2026 07:12:23 +0000

13 clicks. The top-performing tool on the site this month. The automation never touched it.

Not once in 30 days of daily commits does a "SEO: improve Purchase Order Generator content" message appear. The page runs on whatever it shipped with — no verified benchmarks added, no worked examples, no internal linking pass. And yet purchase-order-generator leads every other page on valuefy.app by clicks in the last 28 days: 13 clicks, 1,538 impressions, and one real page-1 ranking for "po maker" at position 7.2.

Meanwhile, seven financial calculators were improved this week — ROI, CAPM, Dividend Yield, Debt-to-Equity, Gross Margin, EPS, Retention Rate. Combined clicks across those seven in 28 days: zero.

There's a lot going on this week. The purchase order generator irony is just the opening act.

The setup

The daily automation has now run for well over a month. The commit history for this week:

May 31 — ROI calculator (a second pass — this page was also the first one improved at the start of the routine)
Jun 1 — CAPM calculator
Jun 2 — Dividend Yield calculator
Jun 3 — Debt-to-Equity calculator
Jun 4 — Gross Margin calculator
Jun 5 — EPS calculator
Jun 6 — Retention Rate calculator

Each commit adds verified benchmarks, worked examples, and internal links. Each tool page gets a meaningful content pass. And per GSC, none of them have crossed the impression threshold in 28 days — Google has not served any of them to anyone at a visible volume.

The ROI calculator is the most striking case. It was the very first calculator the routine improved, weeks ago. Then the routine came back to it again this week for a second pass. In 28 days: 0 clicks. Query breakdown spans 20 queries, every position between 40 and 96. Nothing moved.

Finding #1: The top page by clicks was never on the automation's list

I pulled the 28-day leaderboard across all pages on the site:

Page	Clicks	Impressions	Position
/tools/purchase-order-generator/	13	1,538	40.8
/ (homepage)	8	747	7.9
/tools/impression-calculator/	5	776	47.5
/tools/balance-sheet-generator/	4	19	13.4
/tools/conversion-rate-calculator/	2	62	10.8

The purchase-order-generator leads by 5 clicks. Second place is the homepage. Third is the impression calculator. None of these three pages were part of the automation's current sequence.

The query breakdown for the purchase-order-generator explains why it outperforms. It has a real, dominant query: "purchase order generator" at position 20 with 211 impressions and 2 clicks, plus "po maker" at position 7.2 with 42 impressions and 1 click. That's page one. There's a definite user intent — somebody wants to make a PO document — and the page is the answer Google sometimes picks.

The ROI calculator has no equivalent. Its query spread covers everything from "3 year roi" to "accounts receivable roi calculator" to "annualised roi calculator" — dozens of overlapping phrasings of a head term that every financial site in the world targets. No single query dominates. No query is above position 40.

The difference isn't content quality. It's intent clarity and competition density. "Po maker" is a real long-tail with lower competition. "Roi calculator" is a head term with a thousand incumbents.

Finding #2: The code left a note explaining the bug. Then left the bug in place.

In the first post in this series, I found that every page on valuefy.app had two competing og:title meta tags — one static in index.html, one injected by React Helmet during prerender. I said I'd fix it that night.

Seven weeks later, I curled the homepage:

curl -sSL -A "Mozilla/5.0 (compatible; Googlebot/2.1)" "https://valuefy.app/" | \
  grep -cE '<meta property="og:title"'

Result: 2.

Two tags. Still. I curled the purchase-order-generator page to double-check:

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
<meta property="og:title" content="Free Purchase Order Generator &amp; PO Maker | Valuefy" data-rh="true">

Also two. Every page on the site is shipping two og:title tags. Which one wins in a social share depends on the platform — most crawlers take the last tag, some take the first. For any individual tool page, some previews show the page-specific title, others show the generic site-wide one.

Then I opened client/index.html to understand what happened with the fix. Here's what's in the file:

<!-- Open Graph defaults (overridden by SEOHelmet per page) -->
<meta property="og:title" content="Valuefy - Free Business Calculators & Financial Tools" />
<meta property="og:description" content="150+ free business calculators and AI generators..." />
<!-- Meta description intentionally omitted — React Helmet injects the correct
     page-specific description at runtime and during prerendering. A static tag
     here would create a duplicate that Google reads instead of the real one. -->

The comment is accurate and well-written. A static <meta name="description"> was removed because someone understood that a duplicate description tag means Google reads the wrong one. The comment explains exactly why.

That comment is two lines below a <meta property="og:title"> tag with the same problem — also static, also getting duplicated by React Helmet, also causing Google and social crawlers to see two competing values.

The explanation for why the bug matters is sitting inside the file that still has the bug.

The og:title and og:description tags in index.html have a comment above them: "Open Graph defaults (overridden by SEOHelmet per page)." The word "overridden" is the misunderstanding. Having two tags isn't an override — it's a conflict. The second tag doesn't cancel the first; they coexist in the HTML, and each crawler resolves the conflict on its own terms.

This is a one-line fix repeated twice: delete the static og:title and the static og:description from index.html. The regular <title> tag can stay as a fallback — that's fine, there's only one of those. It's the og: duplicates that are the problem.

Finding #3: The homepage is partly ranking for the wrong Valuefy

While reviewing homepage performance, I pulled the query-level breakdown for the "/" path in GSC to understand what's behind 747 impressions at position 7.9. The expected answer was brand queries for "valuefy." Here's what was there:

Query	Clicks	Impressions	Position
valuefy	5	251	7.4
valuefy app	1	8	2.5
valuefy official website	0	12	5.7
valuefy dfsa reporting	0	7	9.0
valuefy 50+ custodian integrations	0	1	9.0
valuefy technologies private limited	0	1	37.0

"DFSA reporting" and "50+ custodian integrations" are product features of a wealth management platform — Valuefy Technologies Private Limited, an Indian fintech company with a similar name. Their searches are showing up in our GSC data as impressions for the homepage.

Our homepage appears in their brand searches — near page one, in some cases — because we share a name. None of those impressions will ever click. The user is looking for enterprise wealth management software.

This is a small volume effect (maybe 20-25 of the 747 impressions). But it does mean the "7.9 average position" for the homepage is partly pulled from searches that have nothing to do with our product, which makes the headline metric mildly misleading.

What I'm going to do about it

Finish the og:title fix. Delete <meta property="og:title"> and <meta property="og:description"> from client/index.html. Same logic as the description fix that already happened. Same file. Two lines removed.
Audit the automation queue against the click leaderboard. The purchase-order-generator, balance-sheet-generator, and impression-calculator are generating real clicks without automation. The ROI, CAPM, and EPS calculators have been improved multiple times with zero return. Check whether the queue can be reordered toward pages that already have some query demand.
Add Organization schema to the homepage. A proper @type: Organization block with sameAs links to any social or directory listings that exist. It won't erase the naming overlap with Valuefy Technologies, but it gives Google a cleaner signal about what this site is and who operates it.

The uncomfortable lesson

The og:title bug has been live for seven weeks because fixing it never broke anything. No error, no alert, no test failure — the site works fine with two og:title tags. The duplicate just silently corrupts social previews for every page on the site.

This is what technical debt actually looks like most of the time. Not a visible failure. A quiet mismatch between what the code says it's doing ("Open Graph defaults, overridden by SEOHelmet") and what it's actually doing (shipping two competing tags to every crawler that visits).

The automation ran every night this week. The bug ran alongside it. Every CAPM calculator improvement that ships to Google also ships with a duplicated og:title, which means any social share of that page has a coin-flip chance of showing the wrong title. They've been running in parallel for over a month.

I'll fix it this week. I'll check the og: tags again in the next post. If fixing them shows up in any measurable metric — social shares, referral traffic, anything — I'll report that too. If the data says it made no difference, I'll say that instead.

I'm running these experiments on valuefy.app and writing the findings here as I go. If you're building programmatic SEO, debugging React meta tag issues, or watching automation run alongside unfixed technical debt — drop a comment, I'd be glad to compare notes.

I also run AImiten, where we build AI tooling for companies. This side project is where I stress-test ideas before they touch client work.

7 Days of Automation on Pages Google Has Never Seen

Aimiten — Sun, 31 May 2026 07:14:12 +0000

The automation ran every night this week. Seven commits, seven calculator pages polished with verified benchmarks and worked examples. The equity and startup finance cluster: DCF, IRR, NPV, Payback Period, Vesting, Cap Table, Dilution. One per night, 21:15 UTC like clockwork.

When I pulled the GSC data to see what had changed, I got an answer I hadn't seen before.

Five of the seven pages have zero impressions in 28 days. Not a low position. Not privacy-threshold queries hiding behind GSC's anonymization. Empty rows.

The setup

The automation has been running for over 40 consecutive days at this point. If you've been following this series, the arc of the last two weeks matters:

Last week's cluster was SaaS and marketing calculators — CPM, CTR, ROAS, Churn, Burn Rate, ARR, MRR, and several others. When I checked those pages in GSC, they appeared at near-page-1 positions. Then I drilled into the query-level breakdown and those positions dissolved — they were arithmetic averages across dozens of one-impression long-tail queries scattered between position 2 and position 95. Not real top-10 rankings. A mean of a graveyard.
This week's cluster was equity and startup finance calculators.

The tools look polished. Specific titles, contextual meta descriptions, worked examples, internal links. Here's what GSC shows for the 28 days covering the improvement window:

Page	28d Impressions	Avg Position
/tools/dcf-calculator/	~12 (query drilldown)	57.4
/tools/dilution-calculator/	2	72.0
/tools/irr-calculator/	0	—
/tools/npv-calculator/	0	—
/tools/payback-period-calculator/	0	—
/tools/vesting-calculator/	0	—
/tools/cap-table-calculator/	0	—

Five pages with no data at all. Two with single-digit impressions. Seven pages improved this week. Combined: 0 clicks across the entire cluster.

Finding #1: The escalation — from fake positions to no positions

Last week, the SaaS calculators had the decency to show up in GSC with positions between 9 and 12. That turned out to be an illusion — GSC's page-level average flattened a distribution of invisible long-tail queries into something that looked like "almost page one." Not useful, but at least it existed.

This week is a step down from that.

The IRR, NPV, Payback Period, Vesting, and Cap Table calculators don't collapse under query-level inspection — they return empty responses. When I query GSC for those specific page URLs, the API comes back with "responseAggregationType": "byPage" and no rows. No queries, no positions, no data at all.

I curled all five pages as Googlebot to confirm they're actually live and rendering. They are. The IRR calculator serves:

<title>Free IRR Calculator with MIRR &amp; Hurdle Rate | Valuefy</title>
<meta name="description" content="Free IRR calculator that computes MIRR and compares against your hurdle rate. Enter cash flows, get IRR, Modified IRR, and a clear go/no-go verdict." data-rh="true">
<h1>IRR Calculator with MIRR &amp; Hurdle Rate Comparison</h1>

Well-formed title, specific description, clean H1. The page is there. Googlebot can render it. Google just hasn't decided it's worth returning for any query above the privacy threshold in 28 days.

The SaaS cluster had fictional rankings. The equity cluster has no rankings at all. Week over week, the automation is running against pages with less and less Google surface area.

Finding #2: The page driving 24% of site traffic was never automated

Over the past 28 days, valuefy.app got 42 clicks total across all pages. One page contributed 10 of them:

/tools/purchase-order-generator/
10 clicks | 1,048 impressions | position 46.1

That's 24% of the site's clicks from a single page — one the automation has never touched. The query breakdown is the clearest I've seen on the entire site: specific terms with real user intent. po maker at position 7.8 (29 impressions, 1 click). purchase order generator at position 22.6 (117 impressions, 2 clicks). free purchase order generator at position 14.9 (16 impressions, 1 click). purchase order maker at position 18.5 (16 impressions, 1 click).

Five distinct clicks from five distinct queries. Actual people searching for a concrete thing, finding the page, clicking it.

The seven equity calculators improved this week combined for 14 impressions and zero clicks.

The automation picks the next page from an internal queue. The purchase-order-generator is apparently not in that queue. The pages getting the least Google attention are — which is either very principled (improving weak pages to bring them into the index) or exactly backwards (spending effort where Google has already signaled no interest). Right now the data doesn't support the principled interpretation.

Finding #3: India clicks 7.5x harder than the USA per impression

In the 28-day country breakdown, the United States generated 6,630 impressions. That's about 72% of all country-attributed impressions for the month. The average position for US traffic is 60.5. The US delivered 2 clicks.

India generated 734 impressions — roughly 8% of the total. Average position 18.5. India delivered 15 clicks.

Country	Impressions	Clicks	Avg Position	CTR
USA	6,630	2	60.5	0.03%
India	734	15	18.5	2.04%

The US market generates enormous impression volume because the absolute search volume for finance and calculator terms is enormous there. But we're ranking at position 60 for almost all of those US queries — page 6, where the crawlers operate and humans don't. India gets our pages at positions where a 2% CTR is achievable because those queries are less contested.

This isn't a hreflang problem or a geo-targeting problem. It's the authority gap with a geographic filter on it. Wherever the site happens to rank in the top 20, CTR is normal. Everywhere else, it's 0.03%.

Finding #4: The og:title duplicate is still there

I curled each page as Googlebot to verify meta tags as part of this week's check. Every page — IRR, NPV, DCF, purchase-order-generator, the homepage — returns two og:title tags:

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
...
<meta property="og:title" content="Free IRR Calculator with MIRR &amp; Hurdle Rate | Valuefy" data-rh="true">

This was identified in Week 1. Week 3 explained why it wasn't fixed quickly — a deliberate architecture decision with one wrong assumption about React Helmet's behavior during prerendering. Since that post: no change across any route.

I'm not relitigating the decision here. I'm noting it because the automation now ships improved content on pages that carry this conflict. Whatever click-through value a page-specific og:title provides for social sharing is partially undercut by the generic sitewide tag that loads first.

What I'm going to do about it

Gate the automation on GSC existence — before the bot improves a page, check whether that page has any impressions in the last 28 days. Zero impressions means skip and move to the next candidate. Improving pages Google can't see generates no useful signal.
Audit why the equity cluster is absent from GSC — five live, well-structured pages with zero GSC presence. Most likely causes in order of probability: not internally linked from anywhere (so Googlebot hasn't crawled them), missing from the sitemap, or simply not yet indexed despite being crawled. Check all three before writing off the pages entirely.
Protect the purchase-order-generator from the automation queue — it's the only page with consistent, identifiable traffic from real queries. I need to understand what Google likes about it before the automation inadvertently changes it.
Stop improving pages ranked at 50+ — better content can lift rankings, but not from position 60. The constraint at that depth isn't on-page quality. It's authority.

The uncomfortable lesson

The automation moves through clusters in sequence: SaaS calculators last week, equity calculators this week, something else next week. Each cluster has connected worse to actual Google visibility than the last one. SaaS pages had fictional page-1 positions. Equity pages have no positions at all.

There's something odd about running a content improvement loop on pages that are invisible to the index. The pages get genuinely better — more specific titles, real benchmarks, worked examples. Nobody reads them. Google doesn't surface them. The loop runs again tomorrow night at 21:15 UTC.

The positive signal: 15 clicks in the last 7 days against a 28-day average of roughly 10.5 per week. Site-level traffic is trending up slightly. It's just not coming from the pages being improved — it's coming from the purchase-order-generator and a handful of others that the automation has apparently passed over.

I'll check in four weeks whether any of the equity calculators have developed GSC presence — not positions, just existence. Impressions above zero. If they're still empty at that point, improving them was the wrong activity entirely, and the automation needs a different filtering step before it picks the next page.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO, debugging an automation that runs on its own priorities, or stuck on the gap between "content improved" and "traffic improved" — I'd be glad to compare notes. Drop a comment or reach out.

I also run AImiten, where we build AI tooling for companies. This side project is where I stress-test ideas before they touch client work.

Six SaaS Calculators at Position 10. None of Them Actually Rank for Anything.

Aimiten — Sun, 24 May 2026 07:18:23 +0000

The automation ran every single day this week. Seven SaaS calculators landed in the repo on schedule — Runway on Monday, CAC on Tuesday, LTV on Wednesday, ARR on Thursday, MRR on Friday, Churn Rate on Saturday, Funding on Sunday. The commit messages are uniform: "SEO: improve [X] calculator content — add verified benchmarks, examples, internal links." Seven out of seven days. No misses.

When I pulled the 28-day GSC data this morning to see what that cluster looks like from Google's side, the numbers looked encouraging. Then I pulled the query breakdown for two of them.

The same thing I found in Week 1 is back — except this time it isn't one page. It's the whole cluster.

The setup

Here's where the SaaS calculator cluster stands after this week's improvements:

Runway calculator — how much time before you run out of money, improved May 17
CAC calculator — cost to acquire a customer, improved May 18
LTV calculator — lifetime value, improved May 19
ARR calculator — annual recurring revenue, improved May 20
MRR calculator — monthly recurring revenue, improved May 21
Churn Rate calculator — customer attrition, improved May 22
Funding calculator — how much to raise and at what dilution, improved May 23

Each improvement follows the same pattern: pull the existing page, add verified benchmarks (sourced, not invented), add a worked example with real numbers, tighten the internal link structure. The automation has been running this routine since late March — 37 consecutive days now, one calculator per day.

The 28-day GSC data showed all six of the SaaS-focused calculators appearing in Google's index with aggregate positions that looked like near-page-1 territory. I expected to need to write a boring update post about flat metrics. Then I drilled in.

What I expected vs what the data showed

Here's what the 28-day page-level data says about the SaaS cluster:

Calculator	Impressions (28d)	Avg Position
ARR calculator	70	10.2
Runway calculator	61	8.4
CAC calculator	11	10.2
LTV calculator	8	10.4
MRR calculator	9	30.8
Churn Rate calculator	8	10.9

ARR at position 10.2. Runway at position 8.4. Most of the others clustering around 10–11. On the surface that looks like a cluster approaching page 1 with some volume behind it.

On the surface.

Finding #1: The ARR calculator's invisible 69

ARR calculator: 70 impressions, position 10.2 in the 28-day window. That sounds like a page flirting with page 1. I pulled the query-level breakdown.

GSC returned one query.

mrr / arr hesaplayıcı    1 impression    position 28.0

One query. One impression. In Turkish. Position 28.

The other 69 impressions are below GSC's privacy threshold — queries with one or two impressions that don't surface in the query breakdown at all. Dozens of tiny long-tail variations, each generating a crumb of signal, each arriving from a different position scattered somewhere between 2 and 100.

The "position 10.2" is the arithmetic mean of that invisible distribution. There is no ARR calculator query where the page actually ranks at position 10. The aggregate hides a graveyard of sub-threshold queries averaging out to look like progress.

The ARR page title — "ARR Calculator: MRR to ARR, NRR & SaaS Multiples" — is fine. The content quality went up after the May 20 improvement. None of that is the issue. The issue is that the average position metric is lying again, and it's the same lie Week 1's loan payment calculator told.

Finding #2: Runway has the same disease

Runway calculator: 61 impressions, position 8.4. Even more promising than ARR — position 8 would mean top-of-page-1 territory. I pulled the query-level breakdown.

GSC returned one query.

startup runway calculation    1 impression    position 49.0

One query. One impression. Position 49.

Sixty impressions below the threshold. The "position 8.4" is the average of one query at 49 and dozens of queries from positions I can't see — some of which are probably in the top 5, which would pull the average sharply upward. A single query at position 2 plus 59 queries at position 50 would produce an average somewhere around 10. That's what I'm looking at.

The Runway calculator isn't ranking at 8.4. It's ranking at different positions across dozens of undetectable searches, and the mean of those positions happens to be 8.4. Those are different sentences.

Finding #3: None of the improved pages showed up in 7-day data

Here's the detail that ties it together. The seven calculator improvements this week landed May 17–23. I pulled the 7-day GSC data (May 16–24) expecting to see at least some of them with new impressions.

None of the SaaS tool pages appear in the 7-day window. Zero impressions across all seven pages in the week they were improved.

The two "runway" and "funding" entries that did show up in the 7-day data were blog posts — /blog/how-to-calculate-and-manage-your-startup-runway-effectively (1 impression, position 72) and /blog/digital-health-ma-how-a-48-funding-drop-creates-acquisition-opportunities (3 impressions, position 31). Not the tool pages.

This doesn't mean the improvements were wasted. Google hasn't crawled, re-rendered, and re-evaluated all seven pages in a week — that's not how the indexing cycle works. The 28-day data showing them at position 10 was from before the improvements. Whether the new content moves anything won't show up for another 2–4 weeks, minimum.

What it does mean: I'm evaluating the SaaS cluster on pre-improvement data. The "near page 1" aggregate is the baseline, not the result.

Finding #4: The clicks are flat

Overall: 9 clicks this week from 853 impressions. The prior week — May 8–15, before this week's improvements — was 11 clicks from 852 impressions. Almost identical numbers, essentially flat.

The 28-day total is 42 clicks. Week 4's published post noted 52 clicks in the equivalent 28-day window. Whether the 10-click decline is signal or noise is unclear — the sample sizes are small enough that it could be either. What I can say is that the growth that was visible through Week 4 has not continued into the past two weeks.

The homepage continues to generate the most clicks: 3 this week from 188 impressions at position 7.8. The purchase order generator came in second at 2 clicks from 194 impressions. Everything else was 0 or 1.

What I'm going to do about it

The cluster-building strategy is working in one narrow sense: the automation is consistent, the pages are in Google's index, and the aggregate position numbers have moved upward from the depths they were at in Week 1. But "position 10 on average" does not mean "ranking for anything useful."

Pick one calculator and verify a real ranking. For a page to generate clicks, it needs a dominant intent query where it actually holds a top-10 position — not an averaged fiction across a long tail. I'll identify which of the SaaS calculators has the most concentrated query distribution rather than the most diffuse, and focus improvement effort there.
Wait for the May improvements to settle before re-measuring. Pulling GSC data on pages that were updated in the same week tells me nothing about impact. I'll check the same 6 pages again in 4 weeks with a split at the improvement date.
Stop counting "average position" as a signal. Every week the aggregate position for a new page looks promising; every week the query breakdown shows the same distribution problem. At this point I should treat page-level average position as noise until I can see at least 5 queries with meaningful impressions each.
Check whether any click-generating query is consistent week-over-week. The homepage and purchase order generator are getting clicks, but I haven't verified whether those clicks come from stable recurring queries or different one-off searches each week.

The uncomfortable lesson

Week 1's version of this lesson was: aggregate position averages hide query distributions. I wrote it, published it, and moved on.

Seven weeks later, the same trap ran on six pages simultaneously — an entire content cluster — and it nearly produced a false-positive "cluster is working" headline in this post. The only thing that stopped it was pulling the query drilldown. Not every week, not for the first time: specifically this week, specifically because I remembered to.

The pattern doesn't go away just because you've seen it before. It shows up every time there's a new page with impressions below the privacy threshold, which is every page with less than a few hundred impressions on any given query. For a new domain without authority, that's nearly everything.

The automation is real. The 37-day streak of improvements is real. The positions averaging around 10 are not real — they're arithmetic on a distribution I can't fully see. I'll check back when those distributions have had a month to respond to the content changes. If the ARR and Runway calculators stay at position 10-with-nothing-visible, I'll say that too.

I'm running these experiments on valuefy.app — a set of SaaS and finance calculators I've been building and optimizing through automated content routines. The weekly data usually punches holes in what I thought I knew about how the experiment was going. If you're fighting the same "the aggregate looks fine but nothing is clicking" problem, drop a comment.

I also run AImiten, where we build AI tooling for companies. This side project is where the ideas get stress-tested before they touch client work.

31 Pages, 30 Days. I Split the Pre/Post Data. The Win Predated the Work.

Aimiten — Sun, 17 May 2026 07:20:17 +0000

The 28-day data for /tools/pe-ratio-calculator/ showed "forward pe calculator" sitting at position 6.7. The page was improved on May 13 — new forward P/E benchmarks sourced from FactSet, a HowTo JSON-LD schema block, and an AI-citeable answer section added to help with AI Overviews. Position 6.7 on the exact sub-query the improvement had targeted. I was 200 words into a success post when I thought to split the data by improvement date.

The ranking was already there. Before the commit.

The setup

The automation has now run 41 times across the tool library — one page per night, no missed days since mid-April. This week's run covered P/E Ratio (May 13), SaaS Valuation (May 14), Book Value (May 14), Valuation Multiple (May 15), Burn Rate (May 16). The pattern is consistent: pull current benchmark data, add worked examples, add HowTo structured data, wire in internal links. 31 pages improved in the last 30 days alone.

The question I've been trying to answer for six weeks is whether any of this is measurable in GSC. This week I had what looked like a candidate.

What I expected vs. what the data showed

The 28-day page-level data looked encouraging for the P/E calculator:

Metric	Value
Impressions (28d)	516
Clicks (28d)	4
Avg. position (28d)	20.9

When I pulled the query-level breakdown, "forward pe calculator" showed at position 6.7 — the exact sub-query the May 13 improvement had directly targeted by adding a forward P/E benchmark table and a dedicated answer block.

This looked like evidence. The automation added forward P/E content. A forward P/E query surfaced near page 1. Clean cause-and-effect.

Then I ran the narrow windows.

Finding #1: The ranking existed before the improvement

Pre-improvement window (May 6–12 — the full week before the May 13 commit):

Query	Impressions	Position
forward pe calculator	4	4.5
p/e ratio calculator	4	36.3
pe ratio calculator	3	60.0

"Forward pe calculator" was at position 4.5 the week before the improvement went live. One click. Already on page 1.

Post-improvement window (May 13–17):

Query	Impressions	Position
pe ratio calculator	3	50.3
peg ratio calculator	3	43.3
forward pe calculator	1	12.0
ratio calculator	1	9.0
price earning ratio calculator	1	11.0

"Forward pe calculator" dropped from 4.5 to 12.0 after the improvement. The 28-day aggregate had averaged them together — 4 impressions at 4.5, plus 1 at 12.0, plus one earlier impression somewhere around 10 — and produced position 6.7. Which looked like a result the change caused.

It wasn't. The sequence I had constructed from the aggregate was backwards.

This is the same trap as the loan payment calculator from Week 1: an aggregate position metric telling a plausible story that the underlying distribution immediately contradicts when you open it. There, the "average position 9.8" hid a distribution from position 2.5 to position 98. Here, the "position 6.7 after improvement" hid a timeline where the best result predated the work.

Finding #2: The improvement did something — just different

The post-improvement window does show real effects.

"Pe ratio calculator" — the head term — moved from position 60.0 to 50.3. Ten positions. Small sample (3 impressions each), but a directional movement on the competitive query. Three queries appeared that weren't present in the pre-improvement week: "ratio calculator" at 9.0, "price earning ratio calculator" at 11.0, "debt to earnings ratio calculator" at 21.0.

"Ratio calculator" at position 9.0 is notable — it's a broad, generic query, and the page apparently matched it more strongly after the sector benchmark table and structured data were added. One impression. Too small to act on. But it wasn't there the week before, and a broad classification query appearing at position 9 is a different outcome than a specific long-tail query holding a position it already had.

The improvement created new query surface on generic and related terms. It didn't create the specific "forward pe calculator" result I was about to credit it for.

Finding #3: 78% of the P/E calculator's impressions are invisible

The 28-day page-level data: 516 impressions for the P/E calculator. The query-level breakdown: 113 visible impressions across 25 queries.

403 impressions — 78% of the total — are below GSC's privacy threshold. Individual queries with 1–2 impressions each. GSC counts them in the aggregate and won't tell you what they are.

This matters for the attribution question. "Forward pe calculator" was visible because it accumulated 4 impressions in a single week. Everything below the threshold is invisible — could be sitting at position 2.0 on a query I'll never see, or at position 90. The pre/post split I ran above only reveals the above-threshold queries. The 403 impressions below could contain a dozen more latent near-page-1 results — or none.

The query breakdown for the 28-day window returned 25 visible queries. The page is matching at least 403 additional search variations that never surface. Some of those were there before any improvement. Some might be new. I can't tell.

Finding #4: The og:title tag is confirmed still live

While verifying the P/E calculator's HTML state after the improvement, I ran the standard og:title count:

$ curl -sSL -A "Googlebot/2.1" "https://valuefy.app/tools/pe-ratio-calculator/" | \
  grep -cE '<meta property="og:title"'
2

Two tags. Static generic one in index.html, React Helmet one in the rendered output. Eight weeks since it was first flagged. Still there.

I won't relitigate this — Week 5 covered why it exists and what the wrong assumption was. But it's worth noting that every improvement the automation commits — including the structured data additions and benchmark updates on the P/E page — lands on a page that still ships a generic site-wide title as its first og:title signal.

What I'm going to do about it

Run pre/post splits before claiming attribution. From now on: whenever an improved page appears in the weekly GSC data, the pre-improvement window check runs first. The aggregate is for trend-watching; the narrow window is for attribution.
Check "ratio calculator" in two weeks. It appeared post-improvement at position 9.0 with 1 impression — too thin to act on, but if it appears consistently in the next cycle, it means the structured data additions are catching broader classification queries. That would be the actual story of what the automation builds.
Run the same analysis on three prior improvements. The April batch covered EBITDA, ROAS, CTR, CPC, DCF, Cap Rate, and a dozen others. Some of those pages are generating impressions. I want to know whether the rankings on those pages were latent before the improvements or created by them — same method, pre/post split on the commit date.
Fix the static og:title. Not because it's clearly blocking anything — the P/E calculator is generating clicks and position movement despite it. But eight weeks is long enough. It's one line removed from index.html.

The uncomfortable lesson

Aggregate time windows are good for tracking trends. They are bad for attribution.

When I saw "forward pe calculator" at position 6.7 in the 28-day data after a May 13 improvement that explicitly added forward P/E content, my brain completed the pattern: improvement → ranking. The temporal overlap made it feel true. The aggregate was doing nothing wrong — it was accurately reporting a 28-day average. I was the one reading sequence as causation.

Every improvement the automation makes now has to be verified with a pre/post split before I write about it. Not as a final check, but as the first step. If the ranking was already there, the post isn't about that ranking. If the ranking appeared cleanly after the commit, then we have something to say.

The good news: the improvement did real work. "Ratio calculator" at position 9.0. "Pe ratio calculator" moving from 60 to 50. New query surface that wasn't there before. That's a more modest story than "the automation hit page 1" — but it's a true one, and it'll compound if the pattern holds across 30+ pages.

I'll come back in two weeks with the pre/post analysis on the April batch. Either the rankings were latent and the automation is revealing them, or the improvements are actually creating new surface. That's a question the data can answer.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO or fighting the same "the aggregate looks fine but the distribution is hiding something" problem, I'd like to compare notes — drop a comment or reach out.

I also run AImiten, where we build AI tooling for companies. This side project is where ideas get stress-tested before they touch client work.

52 Clicks in 28 Days. One Page Has a 26% CTR. I Can't See What It Ranks For.

Aimiten — Sun, 10 May 2026 07:20:07 +0000

52 clicks in 28 days. That's 1.79 per day — and compared to the Week 1 baseline of 45 clicks in 90 days (0.5 per day), it's a genuine 3.5x improvement. I'll take it.

But as soon as I started drilling into which pages moved and why, the clean narrative fell apart. The best-performing page has a 26% CTR driven by queries I can't see. The commitments I made in Week 5 — reorder the automation queue, fix the og:title bug — didn't happen. And the biggest English-language search market in the world is showing us 6,967 impressions per month and handing back 3 clicks.

The click rate tripled. The story is messier than that.

The setup

The automation has been running every day since early April — one calculator page per night, verified benchmarks added, worked examples, internal links. 40+ pages improved over 90 days. Week 5's post identified that 8 of those pages weren't even getting impressions from Google, and committed to four things:

Reorder the queue by impressions — hourly rate calculator first (880 impressions at the time)
Use the WACC calculator as a two-week control for whether on-page changes move positions
Watch the ROI calculator for position recovery
Fix the duplicate og:title tags on every page — treated as a build blocker

Here's what the 28-day GSC data shows.

What I expected vs. what the data showed

I expected the pages the automation touched in early April to start showing movement. And I expected the four action items from Week 5 to have been executed.

What happened:

Metric	Expected	Actual
Early-April pages (PE ratio, Funding, Cap Table)	Some position gain after 4-6 week crawl lag	PE ratio: 29 → 18.7. Funding: position 11.5, 2 clicks. Cap Table: position 9.5, 1 click.
Recent improvements (CPM, CTR, ROAS, CPA, EBITDA)	Still too early	Confirmed buried at position 60-90
Queue reordered to hourly rate first	Done	Automation ran CPM, CTR, ROAS, CPA, EBITDA, AdSpend, ConversionRate instead
og:title bug fixed	Done	Still 2 og:title tags on every page (curled and confirmed)

Two of four action items sat idle for another week. The automation kept running the queue it had.

Finding #1: The best-performing page is hiding its traffic from me

The business plan generator showed up in the 28-day data with 5 clicks, 19 impressions, 26.32% CTR, position 12.2. A 26% CTR would be extraordinary for any page. At position 12 — the top of page 2 — it's essentially impossible under normal distributions.

So I pulled the query-level breakdown. Here's what GSC returned:

Query	Clicks	Impressions	Position
business plan generator	0	2	97.0

That's it. One query, two impressions, position 97, zero clicks. The remaining 17 impressions and 5 clicks are below GSC's privacy threshold — queries with fewer than 16 impressions that don't show up in the breakdown at all.

The 26% CTR isn't what it sounds like. There isn't a single query where one in four searchers clicks our result. What it means is: this page ranks high (probably top 3) for some specific queries that I can't identify, those high-position queries generate clicks, and meanwhile a cloud of long-tail queries at position 50-97 pulls the aggregate position down to 12.2. The aggregate math hides a bimodal distribution. Again.

The week 1 post had the loan-payment calculator sitting at "position 9.8" that turned out to be a fiction. This is the same trap from the other side — a "26% CTR" that's actually a few invisible top-3 rankings averaged with a long tail of zeros.

The page is working. I just can't see for what. The title Google is using:

AI Business Plan Generator — 7 Sections | Valuefy

The live H1: "Free AI Business Plan Generator — 7 Sections, Instant Output." Those seven-sections hooks are probably matching something specific in the query tail. I won't know until the queries break above the threshold.

Finding #2: PE ratio shows improvements work — on a 5-6 week delay

The PE ratio calculator was last improved on April 2 — 38 days ago. No automation has touched it since. The 7-day GSC position: 18.7. The 28-day average: 21.1. Week 1 baseline: roughly position 29 across the 90-day window.

That's a genuine ~10 position gain. From the back of page 3 to the front of page 2. With 4 clicks and 517 impressions in the 28-day window, it's the second-highest click earner among tool pages.

The query that moved:

Query	Impressions	Position
pe ratio calculator	32	25.2
forward pe calculator	4	18.0
p/e ratio calculator	9	35.2

The "forward pe calculator" query landing at position 18 is why the 7-day average looks better than the 28-day average — it's a low-impression query that happens to be ranking well right now, and it's skewing the recent average toward a better number than the distribution actually represents.

But the directional trend is real: position moved from ~29 to ~21 over 38 days after a single improvement commit. No follow-up automation. No link building. Just on-page content changes — and then 5-6 weeks of waiting.

The implication for everything else in the queue: CPM, CTR, ROAS, CPA, EBITDA — improved in early May — shouldn't show anything visible until mid-June. We're flying blind on last week's work for another month.

Finding #3: The US is our biggest impression market and worst converter

Country-level 28-day data, sorted by impressions:

Country	Clicks	Impressions	Avg Position
United States	3	6,967	45.6
India	10	734	17.4
Canada	1	441	53.6
Indonesia	1	166	13.5
Pakistan	4	156	21.7

The US has 9.5x India's impressions and 3x fewer clicks. At position 45.6 average, we're buried on page 4-5 for US searches — deep enough that even 7,000 impressions converts to almost nothing. India's 17.4 average position is page 2, and at that depth the clicks start coming.

This isn't a geo-targeting problem. It's an authority problem expressed geographically. The US markets we're showing up in (finance, SaaS, business calculators) are the most competitive on Earth. We get impressions because the search volumes are so large that even position 45 accumulates visibility. We don't get clicks because nobody scrolls to page 5.

The 3 US clicks in 28 days did come from somewhere — the query data doesn't show which — but at $0 in ad spend and domain authority barely above zero, 3 is what page 4-5 looks like in English at scale.

What I'm going to do about it

Actually run the hourly rate calculator next — it was first on the Week 5 priority list and still hasn't been touched. This needs a manual queue intervention, not an assumption that the automation will self-correct.
Don't interpret ROAS, CTR, CPM, or EBITDA results before mid-June — the PE ratio example shows the lag is real. Mark the calendar and check those pages on June 15th.
Try to surface the business plan generator queries — narrow the GSC query filter by date to find if any query broke the 16-impression threshold in a single week. If not, wait.
Fix the og:title tags — this is the fourth post mentioning this. At this point the commitment is meaningless until there's a commit that proves it happened.

The uncomfortable lesson

Writing action items in a blog post and then not doing them is a specific kind of self-deception. The items go onto a list, the list gives the impression of progress, and the automation keeps running its queue while the list sits there.

None of Week 5's four action items made it into git. The WACC calculator — which was supposed to be a controlled experiment — is at position 55.8 with 1 click and 653 impressions. The queue wasn't reordered. The og:title fix didn't ship. The ROI calculator is at position 41.1, still drifting.

The click rate did triple, which is the genuine good news this week. But the tripling came from early-April improvements starting to surface — not from anything decided or built this week or last week. The lag is long enough that cause and effect barely feel connected.

The experiment running in the background is working. The promises running in the foreground aren't.

I'll check back in June on the pages improved in May. If the PE ratio pattern holds, ROAS should be somewhere around position 55-65 by then. If it's still at 74, the pattern doesn't generalize and I'll say that.

I'm running these experiments on valuefy.app and writing them up as they happen. If you're building programmatic SEO, watching Claude automate your content queue, or trying to make sense of GSC's privacy threshold noise, I'd be glad to compare notes in the comments.

I also run AImiten, where we build AI tooling for companies. This project is where I pressure-test the ideas before they touch client work.

30 Days of Daily Automation. The Bot Improved the Wrong Pages.

Aimiten — Sun, 03 May 2026 07:27:30 +0000

The daily automation has been running for 30 consecutive days. One calculator page per day, every day since April 3rd — verified benchmarks, worked examples, internal links added, body content rewritten. 28 different pages touched.

This week I pulled the GSC data to see what actually happened.

8 of those pages don't appear in the 200-page snapshot of the last 28 days. Not low impressions. Absent entirely.

The automation ran every day, made measurable improvements, and spent most of its effort on pages Google isn't showing to anyone.

The setup

The routine picks a calculator from a queue, fetches the current page, asks Claude to add verified benchmarks and worked examples, commits the result. Runs at 9 PM UTC. Has not missed a day since April 3.

This week's batch: NOI (Apr 26), DSCR (Apr 27), Cash-on-Cash Return (Apr 28), GRM (Apr 29), Occupancy Rate (Apr 30), WACC (May 1), CPC (May 2). All real estate and finance metrics. Each one is genuinely a better page now — the content is real, the benchmarks are verified.

The question I didn't ask until this week: which pages should have been first?

What I expected vs what the data showed

I expected the earliest-improved pages — improved in the first week of April, now four weeks old — to show some position movement. Google crawl cycles at this authority level run roughly 2–4 weeks. Four weeks should be enough to see something.

Here's what the 28-day GSC data shows for the early-April batch:

Page	Improved	Impressions 28d	Clicks	Position
arr-calculator	Apr 10	46	0	8.0
cac-calculator	Apr 8	115	0	22.5
burn-rate-calculator	Apr 6	28	0	6.8
ltv-calculator	Apr 9	26	0	6.5
mrr-calculator	Apr 11	not in top 200	—	—
runway-calculator	Apr 7	not in top 200	—	—

Zero clicks across all of them. The pages that appear have positions between 6.5 and 22.5 — but at impression volumes this low, average position is again the arithmetic mean of a ghost distribution. The query-level breakdown for ARR returns zero visible queries. For LTV, the same.

No movement. Four weeks of crawl time, and the positions are where they were before the improvements.

Finding #1: The site's highest-impression tool page hasn't been touched

The hourly rate calculator has 880 impressions in the last 28 days. That's the highest impression count of any tool page on the site. It sits at position 57.4 — page 6 of Google — generating a steady drip of impressions and converting none of them into clicks.

The automation has never touched it.

Git log confirms: no commits to hourly-rate-calculator.tsx in at least 90 days. I also curled the live page:

<title>Hourly Rate Calculator for Freelancers | Valuefy</title>
<meta name="description" content="Free hourly rate calculator for freelancers and
  consultants. Convert salary to hourly, add overhead and taxes, and set a rate
  that covers every cost.">

Reasonable title. Reasonable description. The page also carries the og:title duplicate bug — two competing og:title tags, one static from the shell HTML, one injected by React Helmet. Every page on the site has this; I've now verified it on the homepage, the WACC calculator, and the hourly rate page. It's been there since Week 1.

The automation queue did not sort by impression count. It ran through a list. The list didn't cross-reference GSC.

Finding #2: The five pages that should have been first

When I sorted tool pages by 28-day impressions and filtered for pages the automation hasn't touched, this is what came out:

Page	Impressions 28d	Clicks	Position
hourly-rate-calculator	880	0	57.4
pe-ratio-calculator	546	4	22.0
purchase-order-generator	395	3	39.6
roas-calculator	357	2	62.0
markup-calculator	345	2	43.0

These five pages together have 2,523 impressions and 11 clicks in 28 days. The four with clicks have CTR between 0.5% and 0.8%. The hourly rate page has 880 impressions and zero clicks — meaning someone searched, saw the result, decided not to click. A title or meta description problem, not a ranking problem. All of them sit between position 22 and 62 — basement-level, but visible. If any one of them converts at even 2% instead of sub-1%, that's a measurable weekly click increase from pages that already exist in Google's view.

The automation improved pages that averaged fewer than 30 impressions per month. These five averaged 505.

Finding #3: The ROI calculator — the Week 1 flagship — has nearly disappeared

In the Week 1 audit, /tools/roi-calculator/ led the table: 1,483 impressions over 90 days at position 58. The most visible tool page on the site at the time.

The automation improved it on April 20. Thirteen days ago.

It no longer appears in the top 200 pages in the 28-day data. When I ran a query-level breakdown specifically for that URL, I got 10 visible queries with roughly 20 total impressions. At the same run rate as Week 1, I'd expect about 490 impressions in a 28-day window. It's now at 20 plus whatever sits below GSC's privacy threshold.

I don't know the cause. The April 22 editorial redesign — a full visual overhaul cascading to 143+ pages — happened two days after the ROI improvement. CSS variable remaps and font changes don't affect rankings directly, but a full site re-render can trigger a recrawl cycle that temporarily disrupts signals. That's a more plausible cause than the content improvement itself.

What I know: the page dropped. I'll check it again in two weeks.

Finding #4: The WACC calculator has the most impressions — and was just improved

The WACC calculator has 560 impressions in 28 days, position 56, one click. It's the second-highest impression tool page after the hourly rate calculator.

The automation improved it on May 1 — two days ago. Too early to see any effect in GSC. I curled the page:

<title>WACC Calculator: Cost of Capital Formula | Valuefy</title>
<meta name="description" content="Calculate your weighted average cost of capital
  from debt, equity, and tax rate. Used in DCF models and capital structure decisions.">

This is one of the rare cases where the automation hit a high-impression page by coincidence — WACC was next in the queue, and it happened to be second-highest in impressions. I'll use this as a natural experiment: if the content improvement moves the position in the next two weeks, it's the strongest evidence so far that on-page work does anything at this authority level. If it doesn't, that's also data.

The query breakdown confirms the impression distribution is real here — 11 visible queries, 508 visible impressions, with "wacc calculator" alone driving 188 impressions at position 59.9. This is not another averaged ghost. It's a real query cluster with real search volume, sitting on page 6 with a 0.18% CTR.

What I'm going to do about it

Reorder the queue by impressions — sort descending, cross-referenced against GSC, starting with hourly rate (880), then P/E (546), then purchase-order generator (395). The queue already works; it just needs the right priority.
Use the WACC calculator as a control — check its position in two weeks. If it moves, on-page optimization is doing something at this domain's authority level. If not, the Week 1 conclusion still holds.
Watch the ROI calculator — if it recovers from the post-redesign dip, the April 22 redesign was the variable. If it keeps dropping, something else is happening.
Fix the og:title duplicate — I keep saying this. This time I'm treating it as a blocker for any further queue runs, not a nice-to-have.

The uncomfortable lesson

Automation removes friction from a decision you've already made. If the decision was wrong, the automation executes it more consistently than you'd have done it manually.

The queue existed. It worked through a list. Nobody asked whether the list matched the data.

30 days later, 28 pages are better, 8 of them have fewer monthly impressions than a single Reddit comment gets views, and the site's highest-impression tool page still looks like it did in February.

I said in Week 1: "I'd rather run one audit routine that tells me which pages improved week over week than ship more content into a pile Google has already rated." I then ran 30 more improvements without that audit. These things are not actually hard to do — they're hard to prioritize when the automation is already running and producing tidy green commits.

I'll reorder the queue this week. In two weeks I'll report whether the WACC experiment moved. If the answer is "no detectable movement at position 56 with 560 impressions," I'll say that too.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO or trying to figure out whether automated content work is actually doing anything, I'd be glad to compare notes — drop a comment.

I also run AImiten, where we build AI tooling for companies. This side project is where ideas get stress-tested before they touch client work.

The og:title Bug Was Deliberate. The Code Already Explained Why It Would Fail.

Aimiten — Sun, 26 Apr 2026 07:23:44 +0000

In Week 1 of this series, I found a duplicate og:title bug on valuefy.app and wrote: "Fix: strip the static og: tags out of index.html. About 15 minutes of work, touches one file."

That was twelve days ago.

I curled the homepage this morning. Two og:title tags. Still there.

I went to figure out why.

The setup

Here's what was running this week:

Eight content automation commits in seven days: "SEO: improve [X] calculator content — add verified benchmarks, examples, internal links." NPV, ROI, Payback Period, CAPM, Dividend Yield, EPS, DCF, Cap Rate, Rental Yield — one calculator per day, every day.
One site-wide editorial redesign (April 22): 1,437 insertions, 857 deletions, 23 files. New palette (oxblood #8B2E2A, off-black, paper #F5F2EA), Fraunces serif headlines, masthead-style layout. The redesign cascades to 143+ calculator pages via CSS variable remap.
One targeted SEO tweak on the Purchase Order Generator: title rewritten to "Free Purchase Order Generator & PO Maker," H1 updated to include "PO" and "Maker" variants. Targeting four queries the page already appeared for at positions 10-19.

That's a lot of shipping. The og:title fix — which was supposed to be tonight's work twelve days ago — did not ship.

I expected this to be a story about procrastination. It wasn't.

What I expected vs. what I found

I expected to find that the duplicate og:title was a legacy accident — a leftover static tag I'd never cleaned up after wiring in React Helmet.

Instead, I found git log --oneline -- client/index.html:

79e0c67  Design: site-wide editorial redesign
3ef0538  SEO: add static Open Graph meta tags to index.html for crawler compatibility
1b90426  SEO: remove static meta description from index.html to fix duplicate tag
d7fdcf5  SEO: fix prerender meta description hydration

The static og:title tag was introduced on March 31, deliberately, in a commit that also wrote an explanation for why it was safe. The bug I found in Week 1 wasn't a legacy artifact. It was a design decision.

Finding #1: The commit that introduced it had a valid reason and a wrong assumption

Here's the full commit message from March 31:

SEO: add static Open Graph meta tags to index.html for crawler compatibility

SPA crawlers (RankInPublic, Facebook, Slack) don't execute JS so they
miss og:image from React SEOHelmet. Static fallbacks in index.html
ensure previews work everywhere.

The rationale is completely valid. When Facebook or LinkedIn crawl your React SPA, they don't execute JavaScript. They read index.html as-is. If your og:image only exists in the React Helmet component, social sharing is broken for a large class of crawlers.

The commit added:

<!-- Open Graph defaults (overridden by SEOHelmet per page) -->
<meta property="og:title" content="Valuefy - Free Business Calculators & Financial Tools" />
<meta property="og:description" content="150+ free business calculators..." />
<meta property="og:image" content="https://valuefy.app/og-default.jpg" />

The comment says "overridden by SEOHelmet per page." This is the assumption that turned out to be wrong.

Finding #2: React Helmet adds alongside. It does not remove.

Sit two lines above those new Open Graph tags in index.html. There's already a comment there:

<!-- Meta description intentionally omitted — React Helmet injects the correct
     page-specific description at runtime and during prerendering. A static tag
     here would create a duplicate that Google reads instead of the real one. -->

That comment is about <meta name="description">, which was correctly removed in 1b90426. The understanding was right: if you put a static meta description in index.html, the prerendering step captures it alongside the React Helmet version, and you get two description tags.

What the March 31 commit missed is that the same behavior applies to og:title and og:description. React Helmet does not replace static tags it didn't create. When the prerender runs, it appends the Helmet-managed tags — with data-rh="true" attributes — to whatever was already in index.html. The static tags stay.

I confirmed this by curling the prerendered homepage:

<meta property="og:title" content="Valuefy - Free Business Calculators & Financial Tools">
...
<meta property="og:title" content="Free Business Calculators & AI Generators | Valuefy" data-rh="true">

Two og:title tags. On every page. When you share a specific calculator on LinkedIn, most crawlers read the first og:title they encounter. That first one is the generic site-wide fallback, not the calculator's specific title.

There's also a stale number in the mix. The static og:description says "150+ free business calculators." Every other file in the codebase says "105+." The static tag is from March 31 and was never updated.

Finding #3: 1,437 lines of redesign — 1 line deleted in index.html

The April 22 redesign is the most significant commit this month. 23 files, 1,437 insertions, 857 deletions. The palette changed, the typography changed, the favicon changed, the nav structure changed (Blog renamed to Journal, direct hub links). The commit message describes it as cascading to 143+ calculator pages.

index.html was touched in that commit. One deletion:

-    <link rel="alternate icon" href="/favicon.ico" />

The old favicon ICO. That's it.

I'm not criticizing the choice. The redesign was clearly scoped as a visual layer change, and the og:title is a meta tag problem with a different owner in the commit history. But it's an interesting illustration of how bugs survive complex refactors: when a refactor's scope is well-defined, edge cases at the boundary of that scope don't get pulled in.

Finding #4: The four-week scorecard

49 clicks in the last 28 days across 50 pages. That's up from the Week 1 baseline of 45 total in 90 days — roughly a 3.5× improvement in click rate.

Period	Clicks
90-day baseline (Week 1)	45
Last 28 days (Week 4)	49

The directions are right but the absolute numbers are still small. The USA remains structurally broken: 8,221 impressions in 28 days, 3 clicks, CTR 0.036%, average position 56. India gets 892 impressions and 10 clicks at position 16. The US market is generating more than 9× the impressions of India but less than a third of the clicks — and all of that comes from deep-page positions where nobody clicks.

The daily automation is producing work. The positions haven't moved on the core head terms. The authority gap from Week 1 is still the binding constraint.

What I'm going to do about it

Fix the og: tags tonight. Remove og:title, og:description, and og:url from index.html. Keep og:image, og:image:width, og:image:height, and og:type — those are the tags that React Helmet doesn't reliably inject and that non-JS crawlers need. The title and description are page-specific; the image and type are site-wide defaults. Split them correctly.
Update the static og:description count. "150+" is wrong; it should match the "105+" used everywhere else in the codebase. One character change.
Verify the Purchase Order Generator title change landed. GSC shows "po generator" at position 16.3 over 28 days. The April 21 commit targeted that query. I'll check position week-over-week in two more GSC pulls to see if the title change moved anything.
Keep the daily automation running. The 3.5× improvement in weekly clicks is directional. I won't interrupt it.

The uncomfortable lesson

The comment in index.html explains the exact problem that the line right below it creates.

That's not unusual. Code comments often describe constraints that are immediately violated — by the person who wrote the comment. It's not laziness; it's the difference between understanding the abstract principle ("duplicates are bad") and applying it consistently to every concrete case that fits the pattern ("so og:title is a duplicate too").

The React Helmet behavior is genuinely non-obvious if you haven't run into it before. <title> and <meta name="description"> get replaced because React Helmet has special handling for those. Custom og: properties don't have the same handling. The distinction isn't documented prominently. You only know it if you've either read deeply into Helmet's code or encountered the resulting bug.

I'm writing it here so the next person building a React SPA with prerendering and React Helmet doesn't spend a week running the wrong commit log search.

The four-week summary: the content machine is running, the click curve is improving slowly, and there's one structural SEO bug left that's been there since before Week 1. That's next.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO on a React SPA, dealing with prerendering quirks, or fighting the same "I know about the bug but haven't fixed it" wall — drop a comment or reach out.

I also run AImiten, where we build AI tooling for companies. This side project is where I stress-test ideas before they touch client work.

22 Queries, Position 2, Zero Clicks — Because the Meta Description Said 2024

Aimiten — Sun, 19 Apr 2026 07:16:43 +0000

22 queries. Positions ranging from 1 to 5. 56 impressions. Zero clicks.

Not "near zero." Not "a handful." Zero. A blog post on valuefy.app sat at the top of Google's results for more than twenty search queries about SaaS valuation multiples in 2026, and not one searcher clicked it.

I went looking for why. What I found was a metadata bug so obvious I'm still annoyed I didn't catch it sooner — and a bigger pattern about what happens when automation runs on a schedule instead of on a signal.

The setup

This week's git log tells one story. Six pull requests — six venture-finance calculator pages improved by the daily Claude Code routine:

IRR Calculator (April 17)
Cap Table Calculator (April 16)
Dilution Calculator (April 15)
Vesting Calculator (April 15)
Funding Calculator (April 13)
Churn Rate Calculator (April 12)

Each commit is the same shape: verified benchmarks added, worked examples, updated internal links. Six pages touched in seven days. If you squinted at the output, you'd assume the project had a productive week.

GSC told a different story.

What the data showed

I pulled the 28-day page+query breakdown — which pages were getting impressions and for which specific queries. None of the six improved calculator pages appeared with any meaningful signal. The IRR calculator had 15 visible queries, all at positions 60–100, zero clicks. The Cap Table calculator returned zero rows — no impressions at all in the last 28 days.

But one page kept showing up in the data. A blog post:

/blog/saas-valuation-multiples-in-2026-why-profitability-now-trumps-growth-at-all-costs

Query	Impressions	Position
saas valuation multiples 2026 arr	9	4.2
saas company valuation multiples 2026	8	2.5
b2b saas valuation multiples 2026	6	5.0
saas startup valuation multiples 2026	5	3.0
saas arr valuation multiples 2026	4	3.0
saas valuation multiples arr 2026	3	3.7
saas valuation multiples compression 2026	2	8.0
rule of 40 saas valuation impact 2026	2	7.0

22 queries total. 56 visible impressions. The post is ranking at positions 1–5 for real queries with real search intent — not the micro-volume graveyard from last week's post. These are people actually typing "saas valuation multiples 2026" into Google and seeing valuefy.app in positions 2, 3, 4.

Clicks: 0.

Finding #1: The meta description says 2024

I curled the page as Googlebot. The title tag was fine:

<title>SaaS valuation multiples in 2026: why profitability now trumps growth-at-all-costs | Valuefy Blog</title>

Then I looked at the meta description:

<meta name="description" content="Discover how a focus on profitability is reshaping 
SaaS valuation multiples in 2024. This case study explores how a SaaS company 
achieved a premium e..." data-rh="true">

2024.

The title says 2026. The queries say 2026. The searcher's intent is 2026. But the meta description — the two lines that appear directly under the title in Google's results — says "reshaping SaaS valuation multiples in 2024."

The blog automation wrote this post with a 2026-targeted title and H1 but generated the meta description from case study content that referenced 2024 data. Nobody caught the mismatch. The description is also truncated — it ends with "e..." cut mid-word — which is a separate readability problem on top of the year contradiction.

A searcher types "saas valuation multiples 2026." They see a title that matches. They read the snippet. It says "2024." They click something else.

That's the entire explanation for 56 impressions and zero clicks at position 2.5.

Finding #2: A structural bug lives in every blog post

While I was in the HTML, I checked the H1 count. Curling the SaaS blog post and counting <h1> opening tags:

$ curl ... | grep -oE '<h1[^>]*>' | wc -l
2

Two H1 tags. I checked the business valuation formula post — same result, 2. I checked the IRR calculator tool page — 1. The double H1 lives in the blog template, not in tool pages.

A page with two H1s sends mixed signals about what the primary topic is. It's not a crisis-level bug, but it compounds the other issues. If the meta description is wrong and the page has two H1s, Google has fewer reliable signals for what the page is actually about — and it's already chosen not to send clicks even from positions where it's ranking.

Finding #3: The og:title bug from week one is still there

I reported a duplicate og:title bug in the first post in this series. The static index.html bakes in a generic site-wide og:title, and React Helmet adds a page-specific one on top. Two competing tags, every page.

It's still there. I curled the homepage and the IRR calculator:

# Homepage
$ curl ... | grep -cE '<meta property="og:title"'
2

# IRR calculator
$ curl ... | grep -cE '<meta property="og:title"'
2

This isn't new information. But six weeks is a long time for a 15-minute fix to sit in a backlog.

Finding #4: The automation improved pages ranked nowhere, ignored the one with actual signal

This is the pattern that bothers me most.

The daily routine picked six pages to improve this week. All startup-finance tools — IRR, Cap Table, Dilution, Vesting, Funding, Churn Rate. The routine added verified benchmarks and worked examples to each one. That content is now live. None of those pages appear in the 28-day GSC data with any meaningful traction.

Meanwhile, the SaaS valuation blog post was sitting at position 2.5 for 8 impressions, position 3.0 for 5 more impressions, position 4.2 for 9 more — and its meta description had a year error in it that anyone would have caught in 30 seconds.

The automation doesn't read GSC. It has a queue of pages to improve and it works through them in order. Whether a page has 1000 impressions or zero impressions doesn't affect which one gets picked next. The blog post with the broken metadata was never on the list, because the list is driven by a schedule, not by what's actually losing clicks right now.

A human checking GSC once a week would have caught the year mismatch before the post published. The routine — running every night, producing clean commit messages, improving content by every objective measure — never looked at the output.

What I'm going to do about it

Fix the meta description on the SaaS blog post — change "2024" to "2026," fix the truncation. Five minutes. This is the highest-leverage fix available right now because the post is already ranking.
Fix the double H1 in the blog template — this touches every blog post, but it's a one-file change.
Strip the static og:title from index.html — this was overdue in week one. It's more overdue now.
Add a GSC signal check to the automation queue — before choosing the next page to improve, pull its 28-day impression count from GSC. Pages with zero impressions should wait. Pages with impressions but poor CTR should go first.
Audit the remaining blog posts for year mismatches — the automation publishes frequently. If one post has a wrong year in the description, others probably do too.

The uncomfortable lesson

Automation is good at doing the thing it's programmed to do. It's not good at noticing when it's doing the wrong thing.

The calendar routine delivered this week. Six pages improved, six clean commits, six sets of verified benchmarks added. From a process perspective it looks like progress. From a signal perspective, six pages were polished that Google hasn't surfaced to anyone — while a page Google was actively showing to searchers at positions 1–5 had a metadata mismatch that made every one of those impressions worthless.

The fix for the year bug takes five minutes. The fix for the scheduling problem — teaching the routine to check whether a page has signal before picking it — is a morning of work. Neither fix is hard. Both required a human to look at GSC data and connect it to what the automation was doing.

Running a content routine without a signal-feedback loop is the same bet as optimizing a conversion funnel without looking at where users drop off. You can improve every step in isolation and still move nothing.

I'll fix the meta description today. The og:title fix and the blog template H1 are going in this week. The queue-prioritization change — routing automation effort toward pages that already have impressions — is the one I want to report back on in a month. Either the click data improves or it doesn't, and I'll say which.

Running these experiments on valuefy.app and writing up what I find. If you're building programmatic SEO tooling, debugging a content automation that's technically working but not converting — or just hitting the same "impressions up, clicks flat" wall — drop a comment. I want to hear what the same data looks like from other projects.

I also run AImiten, where we build AI tooling for companies. This side project is where the ideas get stress-tested.