The blog posts are doing something the calculator pages couldn't manage last week. They're showing up near the top of Google. /blog/saas-valuation-multiples-in-2026-why-profitability-now-trumps-growth-at-all-costs/ averaged position 8.87 last week with 62 impressions. Multiple queries put it at positions 1 through 5.
Zero clicks. Not one. Over seven days. From a page with genuine top-of-page rankings.
This is week two of the build log for valuefy.app. The first post covered the big-picture audit — 45 clicks in 90 days, the authority gap, the average-position trap. This week I dug into the exception cases: the pages that look like they're working. What I found was a different class of problem.
The setup
The daily SEO routine ran all week. Six calculator pages got the full treatment — verified benchmarks, worked examples, updated internal links:
- CAC calculator (April 8)
- LTV calculator (April 9)
- ARR calculator (April 10)
- MRR calculator (April 11)
- Churn Rate calculator (April 12)
- Funding calculator (April 13)
There was also a one-line fix on April 9: the burn multiple was being credited to a16z in the BurnRateCalculator. The actual source is David Sacks at Craft Ventures. A human caught it, made the correction.
I wanted to know if any of the six improvements were showing up in position data yet. They weren't — too soon, expected — but in the process of looking, I found the SaaS valuation blog post sitting at the top of the results page for several queries and not converting a single click.
That became the story.
What I expected vs what the data showed
The expectation going into week two: some early signal on the improved calculator pages. Maybe one or two had nudged upward in the 28-day data.
What actually surfaced: the blog content had more interesting movement. Here's the week's page-level picture — pages with nonzero clicks in the last seven days:
| Page | Impressions | Clicks | CTR | Avg Position |
|---|---|---|---|---|
| / (homepage) | 112 | 2 | 1.8% | 7.2 |
| /tools/equity-ratio-calculator/ | 15 | 1 | 6.7% | 62.3 |
| /tools/financial-analysis-tool/ | 22 | 1 | 4.5% | 36.5 |
| /tools/retention-rate-calculator/ | 44 | 1 | 2.3% | 31.6 |
Five clicks total this week. The SaaS valuation blog — which had more impressions than any of those tool pages — is absent from this table because it contributed zero to the click column.
Finding #1: Ranking #1 for queries nobody types
The SaaS valuation multiples blog has 62 impressions in seven days at an average position of 8.87. That aggregate looked interesting — same pattern as the loan calculator in week one, where average position hid a distribution. So I pulled the query-level breakdown for the last 28 days:
| Query | Impressions | Position |
|---|---|---|
| saas company valuation multiples 2026 | 9 | 3.1 |
| saas valuation multiples 2026 arr | 8 | 3.0 |
| b2b saas valuation multiples 2026 | 6 | 5.0 |
| saas startup valuation multiples 2026 | 5 | 3.0 |
| acquire.com saas valuation multiples 2025 | 2 | 1.0 |
| saas arr valuation multiples 2026 | 4 | 3.7 |
| fe international saas valuation multiples 2025 report | 1 | 67.0 |
| saas capital index median valuation multiple 2026 | 1 | 1.0 |
| saas valuation multiples 2026 forecast | 1 | 1.0 |
| private saas valuation multiples 2026 arr | 1 | 2.0 |
The total visible impressions in the query breakdown: 62. Which means — unlike week one's loan calculator — there's no privacy-threshold graveyard here. All impressions are accounted for. Google is being fully transparent.
And what the data shows is that I'm ranking #1 for "saas capital index median valuation multiple 2026." That query got one impression in 28 days. "Saas valuation multiples 2026 forecast" — also position 1.0, also one impression. The queries where the page sits at position 3.0-3.1 are better, but the top one has nine impressions across 28 days.
The week one trap was that a good-looking aggregate hid bad distributions. The week two trap is that genuinely good positions on genuinely relevant queries can still generate zero clicks — because the queries themselves are typed by almost nobody.
Position 1 on a dead query is not a win. It is a proof of concept with no audience.
Finding #2: The trailing slash split I hadn't noticed
While I was in the page-level seven-day data, another pattern surfaced. The business valuation formula blog post was appearing twice:
| URL | Impressions | Avg Position |
|---|---|---|
| /blog/business-valuation-formula-what-every-business-owner-should-know | 13 | 2.5 |
| /blog/business-valuation-formula-what-every-business-owner-should-know/ | 18 | 2.7 |
Two URLs. Same content. Different impression tallies. Google is treating them as separate pages.
The page does have a canonical tag — and it points to the no-slash version, which is the right call. But the with-slash variant is getting crawled and counted independently. Forty-one combined impressions at an average position around 2.6 — not bad — but split across two URL signals. That's confusion Google doesn't need when it's already deciding how to rank the page.
I curled the no-slash URL and confirmed: the canonical is set correctly, but there's also a static og:url pointing to the homepage and a React Helmet og:url pointing to the correct page. The static og:url problem — the same class of bug as the duplicate og:title — is making the page emit conflicting signals on every crawl.
Finding #3: The bug from week one is still live
Last week I found duplicate og:title tags on every page: one static tag baked into index.html with the generic site title, one injected by React Helmet with the correct page title. I said it was a 15-minute fix.
It's still there. I curled two pages this week to verify:
curl -sSL -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
"https://valuefy.app/blog/saas-valuation-multiples-in-2026-..." | \
grep -oE '<meta property="og:title"[^>]*>'
Output:
<meta property="og:title" content="Valuefy - Free Business Calculators & Financial Tools">
<meta property="og:title" content="SaaS valuation multiples in 2026: why profitability now trumps growth-at-all-costs | Valuefy Blog" data-rh="true">
Same structure on the ARR calculator: grep -cE '<meta property="og:title"' returns 2.
When anyone shares the SaaS valuation post on LinkedIn or Twitter, some crawlers — the ones that take the first og:title rather than the last — display "Valuefy - Free Business Calculators & Financial Tools." The specific title that convinced someone to share the post disappears in the preview. The fix is one file change, index.html, strip the four static og: and meta description tags and let React Helmet be the only source.
I haven't done it. I should have done it last week.
Finding #4: The blog template has two H1 elements
While curling the SaaS valuation blog for the og:title check, I noticed something else:
curl -sSL -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
"https://valuefy.app/blog/saas-valuation-multiples-in-2026-..." | \
grep -oE '<h1[^>]*>[^<]*</h1>'
Two <h1> elements. Both with identical text: "SaaS valuation multiples in 2026: why profitability now trumps growth-at-all-costs."
The ARR calculator has one H1. A tool page I curled has one H1. It's specific to the blog template. Something in the blog page component is rendering the H1 twice — likely a layout wrapper that wraps the heading and a content renderer that also wraps it. Google recommends one H1 per page. Two identical H1s is not catastrophic, but it's unnecessary signal noise on a page that's already working against an authority gap.
Finding #5: The automation shipped a wrong attribution
On April 9, commit 1513577: "fix: correct burn multiple attribution from a16z to David Sacks (Craft Ventures)."
One line changed in BurnRateCalculator.tsx. The burn multiple — the metric SaaS investors use to assess how efficiently a company converts burn into ARR growth — had been attributed to a16z in the page content. The actual origin is David Sacks, when he was at Craft Ventures.
This one was caught by a human reading the page, not by any automated check. The daily SEO routine adds content, but it doesn't have a fact-checking pass. It can add a plausible-sounding claim — "popularized by a16z" — that's directionally correct (a16z does use the metric and has written about it) but wrong on origination.
The ARR, LTV, MRR, Churn Rate, and Funding calculators were all updated by the same routine this week. I have no systematic way right now to know whether similar errors were introduced in those improvements. The burn multiple error was one change in one file. The others are in review.
This is the quality risk that comes with automated content at scale: the machine is confident, fast, and occasionally wrong about attribution.
What I'm going to do about it
-
Fix the
og:titleduplicate — this week, no exceptions. Strip the four static tags fromindex.html. The Helmet tags are correct; the static tags are just noise fighting them. - Investigate the double H1 in the blog template. Find the component that's rendering it twice and remove one. Should be a 10-minute fix once located.
- Audit the five calculator pages improved this week for attribution claims. Manual review of any sentence that names an external source, framework, or benchmark. The burn multiple fix was one line; the others probably need the same scan.
- For the SaaS valuation blog: find the queries with volume. Position 1 on a one-impression query is useless. The page is clearly about the right topic — Google is matching it to correct intent. The next step is identifying which of those queries have actual monthly volume and whether the page directly answers the question they're asking.
-
Add a canonical
rel="canonical"audit to the next investigation pass. The trailing slash split shows that canonical tags exist but aren't preventing the split. The underlying bug is the staticog:urltag, same as theog:titleproblem.
The uncomfortable lesson
Week one taught me that ranking high requires authority signals — backlinks, brand mentions — that no amount of on-page automation can substitute for. The constraint was authority.
Week two added a second constraint: even if you have the position, the query has to have volume. You can write a technically perfect post, optimize every tag, fix every heading structure, and rank #1 — for something nobody searches for.
The two constraints are independent. A low-authority new domain is unlikely to rank for high-volume queries because those positions are locked by established sites. But a new domain CAN rank for long-tail queries, because there's less competition. The catch is that truly long-tail queries, specific enough to be rankable, are often specific enough to have almost no traffic.
This is not a new insight in SEO. It's documented everywhere. I just hadn't felt it on my own data until now.
What I keep tripping over, though, isn't the SEO theory. It's the gap between identifying something and fixing it. The og:title bug was in last week's post. It's still live this week. The automation is running every night. The fixes aren't. That asymmetry is the actual bottleneck — not the rankings, not the bugs, not the content quality. The rate at which identified issues get resolved.
I'll check back in a week. If the og:title fix is still not deployed by next Sunday, I'll say that too.
I'm Sampsa, CEO at AImiten. We build AI tooling for companies — and sometimes I run experiments on my own side projects to stress-test the ideas. valuefy.app is one of those experiments. If you're curious what we do at AImiten, have a look.
Top comments (0)