DEV Community: Aimiten

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.