DEV Community: Aimiten

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

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

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

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

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

The setup

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

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

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

What I expected vs. what the data showed

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

What happened:

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

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

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

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

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

Query	Clicks	Impressions	Position
business plan generator	0	2	97.0

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

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

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

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

AI Business Plan Generator — 7 Sections | Valuefy

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

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

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

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

The query that moved:

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

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

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

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

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

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

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

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

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

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

What I'm going to do about it

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

The uncomfortable lesson

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

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

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

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

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

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

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

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

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

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

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

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

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

The setup

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

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

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

What I expected vs what the data showed

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

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

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

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

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

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

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

The automation has never touched it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What I'm going to do about it

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

The uncomfortable lesson

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

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

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

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

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

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

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

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

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

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

That was twelve days ago.

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

I went to figure out why.

The setup

Here's what was running this week:

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

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

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

What I expected vs. what I found

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

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

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

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

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

Here's the full commit message from March 31:

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

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

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

The commit added:

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

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

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

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

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

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

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

I confirmed this by curling the prerendered homepage:

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

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

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

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

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

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

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

The old favicon ICO. That's it.

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

Finding #4: The four-week scorecard

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

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

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

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

What I'm going to do about it

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

The uncomfortable lesson

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

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

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

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

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

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

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

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

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

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

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

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

The setup

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

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

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

GSC told a different story.

What the data showed

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

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

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

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

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

Clicks: 0.

Finding #1: The meta description says 2024

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

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

Then I looked at the meta description:

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

2024.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is the pattern that bothers me most.

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

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

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

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

What I'm going to do about it

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

The uncomfortable lesson

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

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

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

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

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

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

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

The Blog Posts Are Ranking. Nobody's Clicking. And I Found Three More Bugs.

Aimiten — Wed, 15 Apr 2026 07:50:17 +0000

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 &amp; 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:title duplicate — this week, no exceptions. Strip the four static tags from index.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 static og:url tag, same as the og:title problem.

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.

I Ran a Full SEO Audit on My Side Project — 45 Clicks in 90 Days. Here's What I Found

Aimiten — Tue, 14 Apr 2026 21:08:13 +0000

We have 160 calculator pages on valuefy.app. I spent most of February rewriting every single page title and meta description by hand. I spent March wiring up a daily Claude Code routine that now improves one calculator page every night. There's a full blog-writing automation for new posts every Monday and Tuesday, a weekday blog audit routine, an AI-powered internal linking queue on Supabase, and a Puppeteer prerender step that runs on every build.

Since January I've been in Google Search Console constantly — submitting 10 URLs a day for indexing, glancing at the weekly totals.

Last week I stopped glancing. I pulled the 90-day data into a spreadsheet for the first time and looked at it properly.

45 clicks. Not per day. Total. Over 90 days.

This is what I found when I actually dug in.

The setup

Here's what was running at audit time:

160 calculator pages (ROI, CAC, LTV, burn rate, runway, EBITDA — the usual SaaS/finance suspects)
~70 of them submitted to Google for indexing via the URL Inspection tool (batched 10/day because of the quota)
A daily Claude Code routine that picks one calculator and improves its body content — verified benchmarks, worked examples, internal links. Started about three weeks ago, 11 commits deep so far.
Two blog-writing routines, one on Mondays and one on Tuesdays, both pick a keyword, research it against competitors, and publish a new React page
A blog audit routine every weekday that verifies facts, checks links, fixes structure
A Supabase edge function applying AI-powered internal links to a queue
React Helmet for meta tags, full Puppeteer-based prerendering of every route at build time
February's mass rewrites: every single tool page title and meta description rewritten by hand for specificity

On paper this is a lot of SEO work. More than most agencies ship for paying clients. I'd assumed that with this much surface area being polished, clicks had to be climbing steadily.

They weren't climbing. They'd never been climbing.

What I expected vs what the data showed

I expected positions slowly improving on target keywords. Maybe a handful of calculators already in the top 10. Some impressions turning into clicks as metadata settled.

What I got:

Page	Impressions (90d)	Position
/tools/roi-calculator/	1,483	58
/tools/markup-calculator/	629	56
/tools/pe-ratio-calculator/	524	29
/tools/cpc-calculator/	468	48
/tools/hourly-rate-calculator/	418	59
/tools/churn-rate-calculator/	378	71
/tools/google-ads-calculator/	359	74
/tools/conversion-rate-calculator/	321	53
/tools/burn-rate-calculator/	280	73
/tools/ctr-calculator/	265	59

Every page with meaningful impressions is sitting somewhere around page 5-8 of Google. Not page 2. Not "almost there." Basement-level.

Finding #1: Google has already judged these pages

Here's the uncomfortable part. Google knows the ROI calculator exists. It matches the page to the query "roi calculator" correctly. It has crawled it, rendered it, looked at it, and decided: rank 58 material.

All the content automation in the world doesn't change that assessment on its own. Over the last three weeks my daily routine has been adding worked examples and verified benchmarks to page after page. Google has seen all of it and the positions haven't moved. Because the problem isn't the content. The problem is authority signals — backlinks, brand mentions, referring traffic from trusted sources. The kind of thing you can't write a prompt for.

I'd somehow convinced myself that "enough good content" would eventually overpower the authority gap. The data says no. When you're a new domain with almost no backlinks, targeting head terms dominated by long-established financial-media sites, no amount of on-page polish moves you from page 6 to page 1.

Finding #2: The quick win that wasn't

This one I'm almost embarrassed about.

I was pulling page-level metrics and saw /tools/loan-payment-calculator/ sitting at an average position of 9.8 with 299 impressions and zero clicks. Position ten. Already on page one. A CTR problem, not a rankings problem. A 30-minute fix.

I got excited. I started drafting the title rewrite in my head before I'd even opened the page.

Then I opened the page. The title was fine:

Loan Payment Calculator: Monthly & Total Interest | Valuefy

58 characters, descriptive, specific, mentions "monthly" and "total interest" which are the two things a searcher actually wants to know. The meta description was also fine — "Free loan payment calculator: enter amount, rate, and term to see monthly payment, total interest paid, and payoff date. Auto, mortgage, and personal loans." Benefit-driven, 155 characters, specific use cases.

So I pulled the query-level breakdown for that page, expecting to see one big query at position 9.8. Here's what GSC actually returned:

Query	Impressions	Position
15000 loan 4.5% 36 months monthly payment	2	2.5
add on interest monthly payment	8	62.9
calculate loan amount from payment and interest rate	1	98
payment calculator with interest paid	2	93

Thirteen impressions. Across four ultra-specific queries. I was missing two hundred and eighty-six impressions.

The rest of them were GSC's privacy-threshold graveyard — queries with one or two impressions that don't show up in the query breakdown at all. Dozens of tiny long-tail variations, each getting crumbs of traffic from different positions scattered between 2 and 100.

The "9.8 average position" was the arithmetic mean of that graveyard. It wasn't a real top-10 ranking at all. It was one query at position 2.5 and one at position 98 averaging out to look like hope.

There was no title fix. There was nothing to fix. The page just has a weirdly diffuse distribution of tiny long-tail queries with no dominant intent target, and GSC's aggregate math lied to me about what that meant.

That's the thing about SEO metrics. Every aggregate hides a distribution, and every distribution hides a reason.

Finding #3: I don't rank #1 for my own brand name

The query "valuefy" gets 325 impressions per month. Position 9. Five clicks.

Let that sit. My site, literally called valuefy, ranks ninth for its own brand name. Even searches for the misspelling "vacuefy" (269 impressions) put us at position 6 with zero clicks.

Part of this is the authority problem again — a new domain without external mentions isn't obviously "the valuefy" Google should trust. But part of it is something I can actually fix. I curled the homepage to see what Google sees:

<title>Free Business Calculators & AI Generators | Valuefy</title>

The brand name is at the end of the title, after the pipe. From Google's perspective, the primary tokens are "Free," "Business," "Calculators," "AI," and "Generators." "Valuefy" is tacked on like an afterthought. I'm telling Google "this page is about free business calculators that happens to be made by somebody called Valuefy," and then I'm surprised the homepage doesn't rank #1 for "valuefy."

Lead with the brand on the homepage. Organization schema with sameAs links to the social profiles that do exist. That's a 20-minute fix, not a three-month fix.

Finding #4: I'm invisible in the markets I actually care about

Top countries by clicks, 90 days:

Country	Clicks	Impressions
India	12	1,177
France	4	448
Malaysia	3	214
Egypt	2	94
Nigeria	2	125
Pakistan	2	189
USA	—	not in top 20

I'm running an English-language SaaS tool site and Google is showing it primarily to users in India, France, Malaysia, Nigeria, and Pakistan. The USA — the single biggest English SEO market on earth — doesn't crack the top 20 countries by impression volume.

I don't have a clean answer yet. Possible culprits: missing hreflang, hosting region in Europe adding latency to US crawls, no US-specific content hooks, or simply DR so low we don't surface at all in the world's most competitive SERP. I'll rule these out one at a time.

Finding #5: I found one real technical bug on the way

While curling pages to investigate Finding #3, I noticed something odd in the HTML. Every page has two og:title meta tags:

<meta property="og:title" content="Valuefy - Free Business Calculators & Financial Tools">
...
<meta property="og:title" content="Loan Payment Calculator: Monthly & Total Interest | Valuefy" data-rh="true">

The first one is static, baked into index.html. The second is injected by React Helmet during prerender. Same story for og:description. Two competing tags per page, on every route.

Which one wins depends on which crawler you ask. Most modern crawlers take the last one, but some take the first. For social sharing, this means some platforms are showing a generic site-wide title for every individual page — the exact opposite of what the rest of the SEO work has been trying to achieve.

Fix: strip the static og: tags out of index.html and let React Helmet be the single source. Same for the static <meta name="description"> tag that's also fighting with the hydrated one. About 15 minutes of work, touches one file.

This wasn't the bug I was looking for. But it's the one I found, and it's the one I can fix tonight.

What I'm going to do about it

None of these is "more content."

Fix the duplicate og: tags — tonight. Strip the static fallbacks from index.html. One-file change.
Fix brand SERP — lead the homepage title with "Valuefy," add proper Organization schema with sameAs links. Twenty minutes.
Investigate the geo problem — verify hreflang, check hosting region, look at what signals Google is using to decide our audience.
Build authority slowly, honestly — no routine, no script, no prompt fixes DR from zero. Outreach, guest posts, directory submissions, off-site work that compounds over 6-12 months. Including this post, which is the first brick.
Pause new tool pages and new blog posts — not forever, but until I know which of the existing 160 can actually be rescued. I'd rather run one audit routine that tells me which pages improved week over week than ship more content into a pile Google has already rated.

The uncomfortable lesson

Before the audit, if you'd asked me what my SEO strategy was, I'd have said: "Build valuable tools, write good content, automate the tedium, let time do the work." All of those things have been happening, every day, on autopilot and by hand, for three months.

None of it mattered because none of it changed the one variable that was actually constraining the outcome.

Worse, the data tricked me twice inside one audit. Once at the top level — 45 clicks was lower than I'd been willing to admit. And once at the exception level — Finding #2 looked like hope and turned out to be an averaged fiction. Aggregates hide distributions. Distributions hide reasons. The only way out is to pull the actual query-level data and look at it with both eyes open.

Automation is a force multiplier on a working strategy. It is not a strategy by itself. Running faster in the wrong direction just gets you lost faster.

I don't know yet if the things I'm about to try will work. I'll check back in a month with whatever the data says. If the answer is "still 45 clicks," I'll say that too.

I Rebuilt Our Company Website With Astro and Claude Code - Here's What Actually Worked

Aimiten — Mon, 30 Mar 2026 11:29:30 +0000

We had an 85-page company website on Typedream. It was slow, messy, and impossible to maintain. Pages were duplicated, the design was inconsistent, and every small change meant logging into a drag-and-drop editor that fought you at every step.

So I decided to rebuild the whole thing. From scratch. Using Astro, Tailwind, and Claude Code as my main coding partner.

Two months later we had a 30-page site that loads faster, ranks better, and actually converts. Here's what I learned along the way — the stuff that worked, the stuff that didn't, and practical tips if you want to try the same thing.

Why Astro

If you haven't tried Astro, it's a web framework that ships zero JavaScript by default. You write components, and Astro renders them to static HTML. When you need interactivity — a mobile menu, a calculator, a form — you add a "React Island" that hydrates only that component.

For a content-heavy site like ours, this is perfect. Most of our pages are guides, service descriptions, and comparisons. They don't need JavaScript. The few interactive bits (contact form, mobile navigation) get React, and everything else stays as fast static HTML.

Our Lighthouse scores went from "meh" to consistently 95+ across the board. Not because we did anything clever, but because Astro's architecture just doesn't ship unnecessary code.

The stack

Astro 5 with server mode (for forms and dynamic content)
React only for interactive islands
Tailwind CSS with a custom design system
Supabase for contact form submissions
Plus Jakarta Sans loaded locally (no Google Fonts dependency — GDPR matters in Finland)

Why Claude Code

I've used Copilot, ChatGPT, Cursor — all of them. Claude Code is the one I kept coming back to, and here's why: it actually reads your whole project.

When I say "update the pricing on the Claude guide page," it doesn't just find-and-replace a number. It reads the layout, understands the component structure, checks the data layer, and makes changes that are consistent with how the rest of the site works.

That said, Claude Code is not magic. It's a very capable tool that still needs a human who knows what they want. The biggest mistake I see people make is treating AI coding tools like a vending machine — put in a vague request, get out a website. That's how you end up with generic-looking sites that all feel the same.

Setting up your project for AI-assisted development

This is the part nobody talks about. The quality of your AI-generated code depends almost entirely on how you set up your project. Here's what made the biggest difference for us:

1. Write a proper CLAUDE.md

This is a file in your project root that tells Claude Code how your project works. Ours includes:

The tech stack and how things connect
Our design system rules (colors, shadows, typography, spacing)
Content guidelines (tone of voice, SEO rules, author information)
File structure conventions

Think of it as onboarding documentation, except your coworker is an AI that reads it every single time. The better this file is, the less you repeat yourself.

2. Create a design system before you start coding

This was probably our most important decision. Before writing a single component, we defined:

Exact color values — not "use blue" but #0066FF for accent, rgba(255,255,255,0.5) for card backgrounds
Shadow definitions — we call our style "minimalistic claymorphism." Two shadows: a subtle outer shadow and a thin white border. No complex inset shadows, no neumorphism
Typography scale — font sizes, weights, line-heights, letter-spacing for every heading level
Border radius — from 12px for buttons to 24px for large cards
Spacing system — consistent padding and gap values

Why does this matter for AI-assisted development? Because when Claude Code has specific design tokens to work with, it generates components that actually look consistent. Without a design system, every component looks slightly different — different shadows, different spacing, different border radius. That's the "AI slop" look that people recognize instantly.

3. Build reusable components first

Before creating any pages, we built a library of Astro components:

src/components/
├── ui/          # Card, Alert, Stats, FeatureList, PricingCard...
├── seo/         # Breadcrumbs, Schema, AuthorBox, FAQSection...
├── layout/      # Header, Footer, MobileMenu (React)...
└── sections/    # CTASection, HeroSection...

Each component follows the design system strictly. When I then ask Claude Code to "create a new service page," it composes from these existing building blocks rather than inventing new styles.

4. Use specialized layouts

We have five layout templates, each designed for a specific content type:

OpasLayout — for guides (sticky table of contents on desktop)
PalveluLayout — for service pages (hero, schema, CTA)
BlogLayout — for articles (author box, reading time)
TyokaluLayout — for tools and calculators
LandingLayout — for the homepage (free-form structure)

The layouts handle all the repetitive stuff automatically: breadcrumbs, structured data, meta tags, default CTAs. Content creators (human or AI) just focus on the actual content.

The workflow that actually works

Here's my daily workflow with Claude Code on this project:

For new pages: I write a brief with the target keywords, the intended audience, the page structure (which H2 sections I want), and which layout to use. Claude Code creates the page using existing components and the design system. I then review and adjust the content, especially anything related to pricing or specific claims.

For updates: I describe what needs to change and why. "The Claude pricing changed, update the Claude guide and the comparison pages." Claude Code finds all the relevant files, updates them consistently, and I verify.

For new components: I describe the component, reference a similar existing one, and specify which design tokens to use. "Create a Timeline component similar to FeatureList but vertical, with a show-more button. Use the clay shadow and accent color for the connector line."

What I never do: I never ask Claude Code to "make it look nice" or "design a landing page." Vague aesthetic requests produce vague results. The more specific you are about the visual system, the better the output.

Managing 85 redirects without losing SEO

One thing that scared me about the migration was losing our existing search rankings. We had 85 pages, many with organic traffic, and we were consolidating them into 30.

We handled it with Astro's middleware:

// middleware.ts — simplified example
const redirectMap: Record<string, string> = {
  '/tekoalysovellukset': '/oppaat/ai-tyokalut-vertailu',
  '/mita-tekoly-on/neuroverkko': '/oppaat/llm',
  '/kokeile-tekoalya': '/oppaat/ai-tyokalut-vertailu',
  // ... 82 more
};

Every old URL returns a proper 301 redirect. We mapped each old page to the most relevant new page, not just the homepage. This preserved most of our link equity and kept Google happy.

The result? Our impressions grew roughly 10x in the first two months, and our average search position improved from around page 2 to the top half of page 1. Consolidating 85 thin pages into 30 comprehensive ones actually helped our SEO — Google seems to prefer fewer, better pages over many shallow ones.

The design philosophy: avoiding AI slop

Every AI-built website looks the same. You've seen them: purple gradients, generic hero illustrations, "Revolutionize your workflow" headlines, emoji bullets everywhere. It's become so recognizable that people call it "AI slop."

We deliberately went the other direction:

No emojis as icons. We use simple symbols like ◎, ▦, ↗ or proper SVGs
No gradients. Our background is a flat warm gray (#EAEAEC) with semi-transparent white cards
No stock illustrations. Real screenshots, real product images
No hype copy. We write in first person ("We offer..." not "AImiten offers...") and we're honest about limitations
Claymorphism, not neumorphism. Subtle outer shadows with a thin white border, giving depth without screaming "look at my CSS"

The irony is that building with AI makes it even more important to have strong design opinions. Claude Code will happily generate generic-looking components if you let it. The design system is your defense against mediocrity.

One unexpected benefit: AI crawlers love clean Astro sites

We made a deliberate choice to allow AI crawlers (GPTBot, ClaudeBot, PerplexityBot) in our robots.txt. As an AI consulting company, we want to appear in AI-generated answers, not just traditional search results.

Clean HTML, proper heading structure, schema markup, and fast load times — all things Astro gives you out of the box — seem to help with what people call GEO (Generative Engine Optimization). Our AI tools comparison guide regularly gets cited in AI search results, which drives a meaningful amount of traffic.

Tips if you're doing this yourself

Start with the design system, not the pages. Spend a day defining your visual language. Every hour you spend here saves ten hours of inconsistency fixes later.

Keep your CLAUDE.md updated. When you make a design decision or establish a new pattern, add it to the file. Future-you (and Claude Code) will thank you.

Don't let AI write your marketing copy. Use it for structure, components, and repetitive code. But headlines, value propositions, and anything customer-facing should sound like a human wrote it — because a human should write it.

Prerender what you can. Astro lets you mark individual pages as prerendered even in server mode. For content that doesn't change often (guides, service pages), this gives you static-site speed with server-side capabilities where you need them.

Build for content updates. We update our guides weekly — new model releases, pricing changes, feature announcements. The component architecture makes this fast. Updating a price in our data layer automatically updates it across all pages that reference it. If you're in a fast-moving space like AI, this kind of automation is worth the initial setup.

Use layouts aggressively. The more your layouts handle automatically (breadcrumbs, schema, CTAs, author boxes), the less can go wrong when creating new pages. Our Claude guide and our AI coaching page look completely different but share the same structural guarantees.

Was it worth it?

Two months in, the numbers speak for themselves. Search visibility grew 10x. Session duration doubled. Bounce rate dropped. And most importantly, I can update any page in minutes instead of fighting a no-code editor.

The combination of Astro's performance-first architecture and Claude Code's project-wide understanding is genuinely powerful. But the key insight is this: AI coding tools amplify your decisions, good and bad. A solid design system and clear project structure turn Claude Code into an incredibly productive partner. Without them, you just get fast-generated mediocrity.

If you're considering a similar rebuild, start with the foundation. The code will follow.

I'm Sampsa, CEO at AImiten. We help companies figure out how to actually use AI — not just talk about it. If you're curious, check out what we do.

Building Arvento: Automating Business Valuations with AI and Real-Time

Aimiten — Tue, 14 Oct 2025 11:25:01 +0000

Built a tool that automates business valuations for Finnish SMEs.

What it does:Connects to business registries, pulls financial data, runs valuation calculations, generates reports.

Stack:React, TypeScript, Supabase, AI for analysis

Why:Consultants charge €2000+ and take weeks. We do it instantly for €89.

Try it for free Try our free calculator to automate this entirely.