DEV Community: Aimiten

Wrong Math on the EBITDA Calculator. The Automation Noticed — Eventually.

Aimiten — Sun, 02 Aug 2026 07:11:06 +0000

The automation fixed a math error this week. Not a broken link, not a stale date. A math error — three of them, actually, in three different worked examples, each wrong in a different way. All on the EBITDA calculator.

The page that calculates EBITDA was calculating EBITDA incorrectly.

I found it in the git log. Commit f501018, July 28: "SEO: improve EBITDA calculator content — fix worked example math errors, update verified benchmarks." The same daily improvement routine that reviews each calculator page had gotten to this one and flagged its own previous output as wrong.

The setup

The improvement automation has 42 commits now — one calculator page per night, every weekday. The process is straightforward: pick a page from the queue, pull current industry benchmarks, rewrite the worked examples with verified numbers, wire in internal links, commit. The automation handles both the initial review and subsequent passes.

This week it touched seven pages: WACC, GRM, EBITDA, Occupancy Rate, P/E Ratio, CPM, and SaaS Valuation. Five of those seven are invisible in GSC — not in the top 50 pages by impression volume over 28 days. Google knows they exist; it just doesn't show them to anyone.

The EBITDA commit was the outlier. Every other commit this week said some version of "add verified benchmarks, update internal links." This one said "fix worked example math errors." Which means the examples were committed with wrong math and are now being corrected.

What the diff actually showed

The EBITDA calculator had three worked examples — SaaS company, manufacturing company, specialty retail chain. Each one walked through how to calculate EBITDA from a P&L statement. Each one got the arithmetic wrong.

Retail chain (before the fix):

Revenue: $8,000,000
- COGS: $5,200,000
- OpEx: $2,000,000
= Operating Income: $800,000
+ D&A: $225,000
= EBITDA: $575,000 (7.2% margin)

$800,000 + $225,000 = $1,025,000, not $575,000. The example was subtracting D&A instead of adding it back. The entire point of "DA" in EBITDA is the add-back of non-cash depreciation and amortization charges. The example did the literal opposite.

Manufacturing company (before the fix):

Revenue: $10,000,000
- COGS: $6,500,000
- OpEx: $2,200,000
= Operating Income: $1,300,000
+ D&A: $450,000
= EBITDA: $1,300,000 (13% margin)

$1,300,000 + $450,000 does not equal $1,300,000. The D&A line appears, but the result is the same as operating income — as if the addback was never applied. EBITDA = EBIT, effectively.

SaaS company (before the fix):

Revenue: $5,000,000
- COGS: $750,000
- OpEx: $2,500,000
= Operating Income: $1,750,000
+ D&A: $250,000
= EBITDA: $1,500,000 (30% margin)

$1,750,000 + $250,000 = $2,000,000. The stated EBITDA of $1,500,000 doesn't follow from the numbers above it. No version of the arithmetic gets you there.

The fix adjusted OpEx in each example to make the chain consistent: SaaS OpEx went from $2.5M to $3M (operating income $1.25M, + D&A $250K = EBITDA $1.5M, 30% margin — correct). Manufacturing OpEx went from $2.2M to $2.75M (operating income $750K, + D&A $450K = EBITDA $1.2M, 12% margin — correct). Retail OpEx went from $2M to $2.4M (operating income $400K, + D&A $225K = EBITDA $625K, 7.8% margin — correct). Every example now adds up.

Before the fix, none of them did — and they were each wrong in a different way.

Finding #1: The page had no traffic. The errors were invisible.

I pulled the query-level GSC breakdown for the EBITDA calculator over the last 28 days. One visible query: "ebitda quality calculator," one impression, position 70, zero clicks. That's it. The page has essentially no SEO footprint.

This cuts in two directions. Nobody saw the wrong worked examples — the page simply isn't getting traffic yet. No user clicked through expecting to learn EBITDA and got a subtraction where there should have been an addition. Damage: zero.

But the flip side: fixing the math also won't move any metric I can see. The page has to build enough authority to rank before content quality becomes a traffic variable. We're correcting content that Google isn't yet surfacing to anyone. The arithmetic is now right; the audience is still coming.

Finding #2: The automation catching its own output raises an audit question

The automation that found and fixed these errors is the same system that runs all 42 commits of improvements. It didn't write the original EBITDA content — that predates this repository's git history — but it's been reviewing other pages for weeks, committing "verified benchmarks" and "worked examples" without a separate validation step.

The EBITDA case reveals how that can go wrong: the math looks plausible on the surface (there are numbers, they're in the right order, they have the right labels), but it doesn't actually add up. A generation pass can produce this kind of fluent-but-wrong output. A review pass can catch it — but only if the review pass is specifically looking for arithmetic correctness, not just content completeness.

I don't know how many of the other 41 pages have worked examples with math that doesn't reconcile. The EBITDA errors were visible to me because the commit message flagged them explicitly. Other pages have commit messages that say "add verified benchmarks" without any indication of what was wrong before.

Finding #3: The 15-minute fix I still haven't shipped

Curling the EBITDA calculator as Googlebot out of habit now — and checking og:title:

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
...
<meta property="og:title" content="EBITDA Calculator: Add-Backs &amp; EV Multiple | Valuefy" data-rh="true">

Two tags. Same on the homepage:

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

I flagged this in the first post in this series. The fix is two lines in index.html — strip the static og:title and og:description and let React Helmet be the single source. I estimated 15 minutes at the time. Seven weeks and 42 automation commits later, the bug is still there.

The contrast is sharp. The automation ships one calculator improvement per night, reliably, without being asked. A two-line structural fix in a template file has been in the backlog since week 1. The automation isn't built to touch index.html. I am — and I haven't.

What I'm going to do

Fix the og:title bug this week. Not next week. Two lines, index.html. The automation won't do this; I have to.
Add an arithmetic check to the improvement routine. Before committing a worked example, verify that the numbers in the code block add up to the stated result. This is mechanical — it just needs to be in the prompt.
Spot-check the top 10 pages by impression volume. These are the pages where content quality is starting to matter to actual users. I'll pull the worked examples from each and verify the arithmetic manually. If I find more errors, I'll report what the distribution looks like.

The thing I can't avoid thinking about

The automation is good at shipping. Forty-two commits in seven weeks, every weekday, without a missed night. That part works.

What it's less reliable at is knowing whether what it shipped is correct. Plausible and correct aren't the same thing — especially in a domain that requires arithmetic. A financial calculator page needs math that verifiably adds up, not just prose that sounds right.

The honest framing: running more automation passes helps, because the review pass catches what the generation pass missed. But that only works if the review pass is actually looking for correctness — and if every page eventually gets reviewed. The pages that get one pass and never get revisited are the ones I don't know about.

I'll pull the sample next week. If the EBITDA errors are an outlier, I'll say so. If they're representative, that's a different problem — and one that requires a different solution than another nightly commit.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building AI-driven content pipelines, automating SEO improvements, or navigating the gap between "correct content" and "more content," 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 I find out what breaks before it reaches client work.

Seven Pages Improved. All Seven Invisible in GSC.

Aimiten — Sun, 26 Jul 2026 07:08:43 +0000

The automation ran every night this week. Seven commits. Seven calculator pages with benchmarks rewritten, worked examples added, internal links wired in. I checked GSC this morning to see which of them had moved.

None of them are in the 28-day data. Not in the top 50 pages by impressions. Not with a single visible query in the query-level breakdowns. The pages exist — I curled them, they load, they have proper titles and meta descriptions. Google just isn't showing them to anyone.

Meanwhile, the one page that actually gained ground this week is one the automation never touched.

The setup

The automation queue has been running for 42 commits now — one calculator page per night, improving content with verified benchmarks, worked examples, and internal links. This week the queue pulled seven pages from the real estate and investment cluster:

Cap Rate Calculator (July 20)
EPS Calculator (July 19 — earnings per share, not technically real estate, but adjacent)
Rental Yield Calculator (July 21)
NOI Calculator (July 22)
DSCR Calculator (July 23)
Cash-on-Cash Return Calculator (July 24)
Compound Interest Calculator (July 25)

Seven nights. Seven commits, each one adding 300-500 words of specific, non-generic content to a page that previously had boilerplate. The automation is working exactly as designed. I just hadn't asked whether it was working on the right pages.

What I expected vs what the data showed

I expected at least some of these pages to be visible in GSC — even one visible query per page would tell me Google had seen the content and filed it somewhere. Here's what the 28-day query breakdown returned for each:

Page	Visible queries (28d)	Impressions
/tools/cap-rate-calculator/	0	0
/tools/compound-interest-calculator/	0	0
/tools/dscr-calculator/	0	0
/tools/noi-calculator/	0	0
/tools/rental-yield-calculator/	0	0
/tools/cash-on-cash-calculator/	0	0
/tools/eps-calculator/	0	0

Zero across the board. Not "below threshold" — literally no rows returned from the API.

Finding #1: The pages are live, but Google isn't showing them

This took me a moment to parse. My first instinct was an indexing problem. So I curled the cap rate page as Googlebot:

<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>

The page is live. Proper title, specific description, correct H1. Same story for compound interest:

<title>Compound Interest Calculator — Daily to Annual | Valuefy</title>
<meta name="description" content="Free compound interest calculator. Compare daily, 
monthly, and annual compounding, add regular contributions, and see year-by-year 
growth with the Rule of 72." data-rh="true">

These aren't broken pages. They're well-structured pages that Google simply isn't surfacing at all. Not at position 50. Not at position 100. Not anywhere visible in the data.

The most likely explanation is authority — a new domain competing in "cap rate calculator" against calculators on real estate platforms with actual domain authority. The content improvements the automation made this week are probably fine. They just don't matter yet, because the authority gap is so large that Google won't surface the page for anyone to even notice the content.

The automation has no way to know this. It has a list of pages and a prompt. It improves them. It has no feedback loop into GSC to notice that some pages are visible and some are dark.

Finding #2: The page that moved is one we never scheduled

The impression calculator — /tools/impression-calculator/ — is the best-performing tool page by clicks right now. It wasn't in the automation queue this week. It wasn't scheduled for any improvement. It just quietly moved on its own.

28-day average: 9 clicks, 1,508 impressions, position 31.3.

Last 7 days: 4 clicks, 381 impressions, position 25.9.

Running those numbers: in the 20 days before this week, the page averaged 0.25 clicks per day. This week, 0.5 clicks per day. Click rate doubled. Position improved by 5 slots. Nothing changed in the codebase — the last automation commit to that page was weeks ago.

I pulled the query breakdown:

Query	Impressions	Position
impression calculator	52	28.9
ad impression calculator	17	39.4
any free ones	1	1.0

Only 70 visible impressions against 1,508 total. The usual distribution: hundreds of long-tail queries each generating one or two impressions below GSC's privacy threshold, all averaged into a position number that looks like "31" but is really dozens of different ranks across dozens of different intents.

But the trend is real. Position 31 to position 26, click rate up. Something is moving, and I didn't cause it by adding content this week.

Finding #3: The SaaS valuation blog ranks at position 7 for a firm's research

The SaaS Valuation Multiples 2026 blog post has 182 impressions over 28 days at an average position of 7.3. Zero clicks. I pulled the query breakdown expecting to see "saas valuation multiples 2026" or similar. Here's what was visible:

Query	Impressions	Position
aventis advisors saas valuation multiples 2026	2	9
aventis advisors saas valuation multiples 2026 ev revenue	1	7
aventis advisors saas valuation multiples 2026 median ev revenue	2	7.5
aventis advisors saas valuation multiples 2026 median revenue multiple	1	8

Every visible query is a navigational search for a specific M&A advisory firm's research. The blog content cited Aventis Advisors' data, and now our page shows up when people search for that firm's actual report — which they then immediately don't click, because they want the primary source.

We're a librarian who mentions the book. People searching for the author don't stop at the librarian.

The other 176 impressions are invisible, which means the page might have some real "saas valuation" traffic hiding below the privacy threshold. But the only window I have shows four navigational queries with no click intent. Position 7 with zero clicks isn't a CTR problem — it's a query mismatch problem.

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

While curling pages for findings #1 and #2, I noticed the duplicate og:title pattern again. Every page still has two of them:

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

The first one is the static fallback in index.html, lines 23-24. The second is React Helmet's hydrated version. The fix — strip lines 23-24 from index.html — was on the action list from the first audit. Seven weeks later, both tags are still there on every page.

Some social sharing platforms take the first tag. Some take the last. The result is unpredictable — which social preview shows up depends on which platform scraped the page and when. This isn't catastrophic, but it's also a 15-minute fix I've now described twice in these posts without doing it.

What I'm going to do about it

Fix the og:title duplicate — tonight. This one is genuinely overdue.
Add a GSC visibility check to the automation queue — before scheduling a page for improvement, check whether it has any impressions in the last 28 days. If zero, skip it. The automation's time is better spent on pages Google is already showing to someone.
Identify which of the 42 improved pages have any GSC visibility — run the same check retroactively. If the impression calculator can drift from position 31 to 26 without intervention, some of the pages we've already improved might be showing early movement worth tracking.
Don't touch the impression calculator — let it keep moving on its own. Check back in two weeks.

The uncomfortable lesson

We've been running the automation as if every page were equally worth improving. Pick a page, write better content, commit, move to the next one. Forty-two commits of work, all applied to a list that was never sorted by "does Google actually show this to anyone?"

Content improvement on a page with zero impressions is not SEO. It's maintenance on a building nobody walks past.

The pages that matter right now — the ones with positions between 20 and 40, the ones getting impressions even at low click rates — those are the pages where better content might convert some impressions to clicks. The cap rate calculator, the DSCR calculator, the rental yield calculator: they might be excellent pages. I don't know, because Google hasn't told me anyone is looking for them.

I'll check back in two weeks on the impression calculator. If position 26 becomes position 20, something is working. If it reverts to 31, then this week's data was noise. Either way, I'll report it accurately.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO, debugging React SEO issues, or fighting the same "automation running, nothing moving" wall, drop a comment — I'd like 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.

Position 7. 145 Impressions. Zero Clicks. The Queries Explained Everything.

Aimiten — Sun, 19 Jul 2026 07:11:57 +0000

Last week I wrote about the ROI calculator finally breaking out of the basement — position 24 after months at position 58, and how that still produced exactly one click from 1,145 impressions. The click cliff problem. I thought I understood what I was dealing with.

This week I pulled the query breakdown for the top-performing blog post on the site and found something different. Not a distribution problem. Not an authority problem. An intent problem — and a weirder one.

The setup

The automation ran seven consecutive investment calculator improvements this week — IRR (Jul 12), DCF (Jul 13), NPV (Jul 14), ROI (Jul 15, second pass), Payback Period (Jul 16), CAPM (Jul 17), Dividend Yield (Jul 18). Seven pages, seven commits, seven days straight. The same pattern that's been running for two months.

At the 28-day level, the site is showing 42 clicks from 10,286 impressions. Twelve pages produce any clicks at all out of 50 with measurable impressions. I started looking at which blog posts were pulling their weight — and that's where it got strange.

What I expected vs what the data showed

The SaaS valuation blog post has been sitting in the data with impressive-looking numbers. Average position 7.3 over 28 days, 145 impressions. For context, the ROI calculator — the site's highest-impression page — sits at position 33.3 with 2,484 impressions. A page at position 7 should be competitive.

Page	Impressions (28d)	Position	Clicks
/tools/roi-calculator/	2,484	33.3	2
/tools/impression-calculator/	1,413	33.0	6
/tools/pe-ratio-calculator/	823	26.6	9
/blog/saas-valuation-multiples-in-2026-...	145	7.3	0

Position 7. Zero clicks. Not one. Not occasionally. Zero over 28 days.

My first guess was a meta-description problem. I curled the page to check:

<title>SaaS Valuation Multiples 2026: ARR Ranges + Free Calculator | Valuefy</title>
<meta name="description" content="SaaS multiples average 4.5x ARR in Q1 2026 
(range: 3x-10x). Use the free calculator: enter ARR, NRR, and growth rate 
for your specific multiple range." data-rh="true">

The title is specific, the description is specific and contains a number. Not the issue.

Finding #1: Every visible impression is for someone else's search

I pulled the 28-day query breakdown for the SaaS valuation post.

The page has 145 impressions. GSC shows 4 visible queries. The rest — 139 of 145 impressions — are below the privacy threshold. I've started to accept that the invisible tail is the norm on this site; most queries have one or two impressions each and never surface.

What stopped me was those 4 visible queries:

Query	Impressions	Position
aventis advisors saas valuation multiples 2026	2	9.0
aventis advisors saas valuation multiples 2026 median ev revenue	2	7.5
aventis advisors saas valuation multiples 2026 ev revenue	1	7.0
aventis advisors saas valuation multiples 2026 median revenue multiple	1	8.0

Every single visible query contains the name of one specific advisory firm. Aventis Advisors is a real M&A advisory shop that publishes SaaS valuation multiple data. People are searching for their named report, and our blog post — which discusses SaaS multiples and probably cited or referenced their data — is appearing alongside those searches at position 7-9.

They are not looking for us. They are looking for the Aventis Advisors report specifically. We happen to rank adjacent to what they want.

0 clicks. That's the correct outcome. A person searching for "aventis advisors saas valuation multiples 2026 median ev revenue" is not going to click a Valuefy blog post. They want the source. We're noise.

The 7-day breakdown is even starker: zero visible queries at all. All 47 impressions from the past week are below the privacy threshold. The invisible tail is likely more of the same — fragmented micro-impressions across narrow branded variations we can't see.

What I had interpreted as "a blog post ranking well" is actually "a blog post appearing at position 7-9 for searches where a specific named firm's report is what the user wants." Two very different things.

Finding #2: The investment calculator cluster is in the basement — even after improvements

The seven calculators improved this week all share the same profile. DCF, improved July 13:

Query	Impressions (28d)	Position
discounted cash flow calculator	168	67.1
dcf calculator	108	57.3
discount cash flow calculator	8	70.9

Position 57-67 on the head queries, six days after adding worked examples and sector benchmarks. The ROI calculator — second pass on July 15 — sits at position 35.9 over the last 7 days with 2 clicks from 2,484 impressions.

The outlier is the P/E ratio calculator. I improved it on June 16 — 33 days ago. Right now it's the highest-CTR calculator page on the site:

Page	Clicks (28d)	Impressions	CTR	Position
/tools/pe-ratio-calculator/	9	823	1.09%	26.6
/tools/impression-calculator/	6	1,413	0.42%	33.0
/tools/roi-calculator/	2	2,484	0.08%	33.3

Nine clicks in 28 days — more than any other calculator. I looked at the query breakdown expecting to see which queries were converting. The 25 visible queries have 49 impressions between them and zero clicks. All the visible queries are at positions 50-91. The nine clicks come from 774 impressions that fall below the privacy threshold — queries I cannot see, positions I cannot check.

The P/E ratio calculator is performing well, and I cannot tell you why. The visible data says position 72 average on identifiable queries. The hidden data produces all the actual clicks.

Finding #3: The og:title fix I promised in week one is still not done

The first post in this series identified a structural bug: every page serves two og:title meta tags. A static fallback in index.html, and a dynamic one injected by React Helmet during prerender. Crawlers and social media scrapers see both.

<!-- index.html — static, site-wide -->
<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">

<!-- injected by React Helmet at build time -->  
<meta property="og:title" content="SaaS Valuation Multiples 2026: ARR Ranges + Free Calculator | Valuefy" data-rh="true">

That post said: "Fix: strip the static og: tags out of index.html and let React Helmet be the single source. About 15 minutes of work, touches one file. This wasn't the bug I was looking for. But it's the one I can fix tonight."

I checked index.html today. The static tags are still there at lines 23-29. I checked the git log for any commit that touched og: tags or index.html. No results.

It has been several weeks since that post. Every page still ships two og:title values. Some social platforms take the first one — the generic, site-wide fallback — which means individual blog posts are still sharing as "Valuefy - Free Business Calculators & Financial Tools" on those platforms, even though prerender generates the correct per-page title.

This is a 15-minute fix that has been sitting undone through multiple weekly cycles. I'm putting it on the list again, this time in writing, in public.

What I'm going to do about it

Fix the og:title duplicate now — remove the static og:title, og:description, og:image, og:url from index.html. React Helmet has per-page values for all of these; the fallbacks fight the correct values and lose on some platforms.
Stop treating page-level GSC position as a performance signal — average position at the page level tells you the arithmetic mean of a distribution I can rarely see. The SaaS valuation blog at position 7 looked like a win until I pulled the query breakdown. From now on I will not flag a page as "performing well" without checking the query-level data first.
Give the investment calculator improvements time — the P/E calculator took 33 days before its week looked good. I shipped improvements to DCF and NPV six and five days ago. Checking them today and calling it a failed experiment would be premature.
Audit the other blog posts for intent mismatch — if the SaaS valuation post is getting impressions from one specific firm's branded searches, other blog posts may have similar problems. Posts that cite named sources for data may end up indexing adjacent to those sources' own brand searches. That's not useful traffic.

The uncomfortable lesson

Week one, the lesson was: aggregates hide distributions. A page at position 9.8 was actually one query at position 2.5 averaging with dozens at 80+. Week four, it was content indexing for names invented inside the prompt. This week, the same failure shows up with a real name: a page at position 7 appearing for searches that want a specific named advisory firm's report — and getting zero clicks because we are definitionally not it.

Position is the wrong signal if you don't know what queries are driving it.

Twelve pages produce any clicks at all out of 50, 42 total clicks in 28 days — better than the 45 I found over 90 days at the start of this series, but still thin. The investment calculators are in a slow climb that has nothing to do with what I committed this week and more to do with what happened 30-60 days ago.

I'll check whether the DCF improvement from July 13 shows any position movement in a week. If it does, I'll write about it. If the position is still 57, I'll write about that instead.

I'm running these experiments on valuefy.app and writing up what I find as I go. If you're building programmatic SEO tools, fighting the same "page looks like it's ranking but no clicks" wall, or just curious how these distribution problems keep recurring — drop a comment.

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

Position 24. 1,145 Impressions. One Click. Six Weeks After the Automation.

Aimiten — Sun, 12 Jul 2026 11:00:02 +0000

Eight weeks in. Forty-three automation commits since May 30 — one calculator page improved per day, every day, without a gap. This week's batch: seven startup/VC pages, ARR through Cap Table. And while pulling the GSC data for this post, I landed on a single row in the ROI calculator breakdown that derailed the whole narrative I'd planned to write.

Last week I found three clicks I couldn't explain. This week I found one click I can explain too well.

1 click. From 1,145 impressions on the query "roi calculator." In 28 days.

The setup

Here's the current state of things:

43 automation commits since May 30, one page per day, every day
160+ calculator and generator pages across valuefy.app
This week's vertical: startup/VC calculators (ARR, Churn Rate, DCF, Funding, Vesting, Dilution, Cap Table)
GSC, last 7 days: 5 total clicks, 1,004 impressions across 30 pages
GSC, last 28 days: 46 clicks, 10,330 impressions across 50 pages

The 28-day per-week average works out to about 11 or 12 clicks. This week delivered 5. The four weeks of automation commits — and specifically the startup cluster we ran this week — produced a down week.

What I expected vs what the data showed

The ROI calculator was the second page the automation ever ran on — May 31, day two. Six weeks later, here's where it stands in the 28-day GSC window:

Metric	Week 1 (90-day average)	Week 8 (28-day)
Page-level avg position	58	33.1
Query "roi calculator"	not tracked separately	24.7
Impressions	1,483	2,630
Clicks	part of 45-click total	1

Position moved. Clicks did not.

Finding #1: Page 3 is a number that sounds good and does nothing

Position 24.7 on "roi calculator" is page 3 of Google — the third page of results, technically above position 30. When I saw it in the data I thought: that's close. That's progress I can feel.

Then I looked at the CTR: 1 click from 1,145 impressions. 0.09%.

I curled the live page to check what Google actually renders:

<title>ROI Calculator: Return on Investment &amp; Payback | Valuefy</title>
<meta name="description" content="Calculate ROI, annualized return, and payback period
for any investment. Compare options side by side with consistent metrics.">

The title is specific. The description is benefit-driven. Neither is the problem. The problem is that at position 24, most searchers never see it. "Roi calculator" is a head term with abundant choice in the top 5 — and nobody solving a real problem scrolls to page 3 when page 1 has four adequate answers.

Moving from position 58 to 33.1 (page-level) and 24.7 on the head query is measurable progress. It's also progress toward a cliff. The click rate on head terms doesn't improve gradually as position improves — it's nearly flat from position 60 down to somewhere around position 10, and then it steps up sharply when you cross into the top 5. Everything below that step is a different shade of "not found."

Finding #2: The DCF calculator has real queries and zero clicks

The DCF page was improved July 7 — five days ago. In the 28-day window (which includes the weeks before the improvement), it shows up like this:

Query	Impressions	Position
discounted cash flow calculator	195	66.6
dcf calculator	117	57.6
discount cash flow calculator	10	68.3
dcf intrinsic value calculator	6	47.5

521 total impressions on the page. One click from a query below GSC's privacy threshold. Every visible query: zero clicks.

"Discounted cash flow calculator" getting 195 impressions in 28 days at position 66.6 is actually useful — it tells me the query is real, the page is indexed, and Google is matching the intent correctly. It also puts the page at position 67, which is page 7 of Google. The content improvement happened five days ago. Whether that changes the position — and by how much — is a 30-day question, not a 5-day one.

The DCF calculator today looks exactly like the ROI calculator six weeks ago. Same pattern: real query volume, positions in the 50s and 60s, no clicks.

Finding #3: The ARR calculator is ranking for German queries I didn't write

The ARR calculator — improved July 5 — has one of the stranger query distributions I've seen in this data:

Query	Impressions	Position
arr calculator	45	58.3
arr mrr berechnung	30	89.1
arr multiples	23	87.5
annual recurring revenue calculator	8	70.0

"Arr mrr berechnung" is German — it means "ARR MRR calculation." The page is English-language:

<title>ARR Calculator: MRR to ARR, NRR &amp; SaaS Multiples | Valuefy</title>

Google is matching the concept across languages and surfacing the page to German searchers at position 89. Which is page 9 — so nobody clicks it from Germany either. But the cross-language behavior is new to me in this dataset. We haven't done any localization. We haven't added hreflang. Google just decided the ARR concept is relevant to German searchers of "arr mrr berechnung" and started sending those impressions to an English page.

"Arr multiples" at position 87 is a different mismatch. That's a VC valuation lookups query — someone checking current ARR multiples in the market, not calculating their ARR. The page catches it at position 87 because the term overlaps, but the intent doesn't align. Which is probably why it's at position 87.

Finding #4: Six of the seven pages we improved this week aren't in the data yet

Of the seven startup/VC pages automated this week, only DCF shows up in the 28-day GSC top-50 pages. ARR, Churn Rate, Funding, Vesting, Dilution, Cap Table — not there.

This is expected. When a page sits at position 80 or 90, improving its content moves a signal that Google may eventually re-evaluate. It doesn't immediately surface the page in impression rankings. The feedback loop on content improvements runs on weeks, not days.

Meanwhile, the pages delivering what little 7-day traffic there is are the ones I didn't touch: the impression calculator (299 impressions, position 34.8, 1 click) and the P/E ratio calculator (157 impressions, position 24.8, 2 clicks). I wrote about this in week 4. It keeps being true.

What I'm going to do about it

Track DCF's head query specifically — "discounted cash flow calculator" at position 66.6 is the number to watch over the next 30 days, not the page-level average.
Rerun the ROI drill-down in a month — if position 24.7 holds, there's something limiting CTR beyond position. If it climbs toward 15, I'll report what happens to the one click per month.
Stop using page 3 as a success metric — position 24 felt like almost-there when I saw it. The click data says it isn't. Page 3 belongs in the same category as page 6 for conversion purposes.
Continue the startup cluster — none of the seven pages are showing traffic yet. That's what I expected. This is month-scale work, and the cluster logic (related pages linking to each other) takes time to compound.

The uncomfortable lesson

There's a mental trap in position metrics I keep falling into: the assumption that "better rank" means "closer to getting traffic." The ROI data breaks that assumption cleanly.

Moving from position 58 to 33.1 on the page level — and 24.7 on the head query — took 43 days of automation and one dedicated content pass in late May. That's real work on a real signal. And the return is 1 click from 1,145 impressions.

The click curve on head terms is not a slope. It's a cliff. From position 60 to position 11, you're essentially trading impressions for impressions, not impressions for clicks. The jump happens when you cross into the top 5 or 10 — and we're not there yet on anything.

I still think the work is worth doing. You can't cross the cliff without crossing the territory before it. But I'd be misleading myself if I counted position 24 as meaningful progress toward traffic today. It's meaningful progress toward a position where meaningful progress might start.

I'll check back in 30 days with the DCF and ROI numbers. If something actually moved, I'll show the data. If it didn't, I'll say that instead.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're working through the same impression-without-clicks wall — or building programmatic SEO and wondering what 40+ days of daily automation actually produces — drop a comment. I'd like 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.

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.