389 Pages, 22 Clicks: A Teardown of My Own Site

In the 85 days ending 3 September 2026, santoshpaudel.me earned 22 clicks from 4,553 impressions across roughly 390 indexed URLs. That is a 0.48% click-through rate. 29% of those impressions came from Russia and produced zero clicks. The United States produced 970 impressions at average position 38.8 and zero clicks. In September I took the published count from 267 to 103. This post is the full teardown: every number, what I changed, and the part I cannot honestly claim yet, which is whether any of it worked.

The numbers, unedited

Here is the Search Console export with nothing removed.

The title says 389 because that was the indexed count on the day I pulled the report. It drifts by a few either way depending on when Google recrawls.

One definition matters before reading any of it. Google counts an impression when a user has seen, or potentially seen, a link to your site, and uses only the topmost position per query. So 4,553 is a generous count of appearances, and 38.8 is the best position I held on average, not the worst.

The one row that shows the machine still works

Nepal: 8 clicks from 74 impressions is a 10.8% CTR at position 9.2. Clicking is not broken. Search is not broken. When a page of mine ranks on page one for someone who recognises the name, it gets clicked at a completely normal rate.

Most of the rest of the table is a ranking problem: the US sits at 38.8, the UK at 50.1. Russia is a different fault entirely. It ranks at 10.5 — page one — and still returns zero clicks from 1,320 impressions, nearly all of them landing on one post about whether starting a podcast is still worth it in 2026. Rank is already where I would want it. What arrives is a market I never wrote for, and no amount of ranking work fixes that.

The "santosh paudel" row is the one that stung. Position 8.2 on my own name, zero clicks. On average about seven results ahead of me, for a query where I am the entity.

Two clusters, same author, same quarter

Splitting the 182 ranking URLs by what kind of post they were produced a cleaner separation than I wanted to see.

Same domain, same author, same 85 days, and a backlink profile of essentially nothing in both cases. The only variable is whether the post contained something I actually did. Google's self-assessment questions ask whether content provides "original information, reporting, research, or analysis." One cluster answered yes. One did not. Even at their nearest edges — 15.5 against 46 — the two clusters sit 30 places apart.

What the corpus actually looked like

I had seeded 279 posts. Classifying them was the point where the excuses ran out.

• —About 150 of them averaged 380 words, with no table, no code block, no internal link, and no image.
• —Across the whole seed corpus: 1,121 H2 headings and 39 H3s. A 29:1 ratio. Every post was a flat run of sections with nothing nested under anything.

380 words of unstructured prose is a headline with padding. And a 29:1 heading ratio tells you the writing process was "generate eight sections" rather than "explain one thing properly" — no post ever developed a sub-point, because nothing in the pipeline asked it to.

The query I should have run a year earlier

This is the whole census, and it takes seconds on Postgres. Run it against your own posts table before you argue with me about any of the above.

-- Thin-content census. Postgres. Adjust table/column names to your schema.
SELECT
  count(*)                                                        AS published_posts,
  round(avg(words))                                               AS mean_words,
  count(*) FILTER (WHERE words < 600)                             AS under_600_words,
  count(*) FILTER (WHERE content NOT LIKE '%|%')                  AS probably_no_table,
  count(*) FILTER (WHERE content NOT LIKE '%```%')                AS no_code_block,
  count(*) FILTER (WHERE position('](/blog/' in content) = 0)     AS no_internal_link,
  sum(h2)                                                         AS h2_total,
  sum(h3)                                                         AS h3_total
FROM (
  SELECT
    content,
    array_length(regexp_split_to_array(btrim(content), '\s+'), 1)   AS words,
    (length(content) - length(replace(content, E'\n## ',  ''))) / 4 AS h2,
    (length(content) - length(replace(content, E'\n### ', ''))) / 5 AS h3
  FROM blog_posts
  WHERE published = true
) t;

The heading counts work because stripping every occurrence of a 4-character marker shrinks the string by 4 characters per hit, and \n## never matches inside \n### . The pipe check is crude and returns a false negative on any post that uses a pipe in prose, which is why the column is named probably_no_table. Crude is fine. A number that is roughly right and that you have today beats a perfect number you never compute.

If the output of that query makes you uncomfortable, the discomfort is the deliverable. I turned the scoring logic that decided what survived into a repeatable model, written up in the content pruning scoring model. If you would rather someone else ran the census and handed you the kill list with the fix order attached, that is what a content audit is.

Four faults that had nothing to do with writing

The content was the biggest problem. It was not the only one, and the others were embarrassing in a different way, because they were bugs in software I wrote myself.

A missing route was orphaning 20 pages

I had 20 persona pages at /for/[persona]. There was no page at /for. The index route did not exist, so every link pointing at that hub returned a 404 and the 20 children had no internal entry point at all. They sat in the sitemap and nowhere else. Same class of self-inflicted indexing wound as the canonical hostname bug that cost me three months: invisible in the app, fatal in the crawl.

164 of 453 built pages shipped no og:image

Just over a third of the site had no social card. That is not a ranking factor and I am not going to pretend it is one. It is a click factor, on exactly the surfaces where a link renders as a card rather than a blue line.

One anonymous Person, repeated 453 times

The site emitted a different anonymous Person entity on every page. No stable @id, so nothing tied page 12's author to page 300's author. To a parser I was 453 different unnamed people who had each written exactly one thing. Whatever entity-level credit an author accumulates, I had built a system that reset it on every route.

That is the likeliest explanation I have for position 8.2 on my own name. I want to be precise about its status: it is a hypothesis consistent with the data, not something I proved.

The measurement layer was the last thing I built

I had 279 posts before I had a report that would tell me which ones were dead. That ordering is the root cause underneath everything above. The metrics I should have been watching from day one are in the five SEO metrics that matter.

What I cut

I unpublished rather than deleted. Google's core updates documentation is explicit that "deleting content is a last resort, and only to be considered if you think the content can't be salvaged," while also saying that where a section really was built for search engines first, "deleting the unhelpful content can help the good content on your site perform better." Unpublishing takes the site-quality benefit and keeps the raw material for the dozen or so posts I intend to rewrite properly. Nothing about that choice is clever. It is reversible, and reversible is what you want when you are acting on a hypothesis.

What broke when I cut

Removing 61% of the published posts breaks links. I knew that in principle and still under-planned for it.

32 broken internal links, live in production after the prune. Twenty-two of them had a single cause: a seed file had been committed to the repo and never run against the production database. The code referenced slugs that existed in git and did not exist in Postgres. The build passed. The type-check passed. The links 404'd for real people.

The lesson is narrow and worth stating plainly: a committed migration is not an applied migration. My deploy pipeline verified the code and never verified that the database agreed with it.

I did not find those 32 with a tool. I found them by accident — and a crawl would not have found them either. ISR keeps serving a pruned URL as a 200 from cache for about an hour, and the stale sitemap for a day, so the live site goes on agreeing with you long after the database has stopped. The database is the only source of truth here. The check I run now after every content SQL file queries blog_posts for every published row, regexes each body for ](/blog/<slug>) targets, and exits non-zero if any target is missing from the published set. One request, no browser, and it is correct the moment the SQL lands rather than an hour later.

What I do not know yet

Here is where a case study usually turns. This one does not.

It is too early to say whether the prune worked. It landed in September 2026. Google's guidance on this exact scenario says "it could take several months for our systems to learn and confirm that the site as a whole is now producing helpful, reliable, people-first content," and adds that if a few months pass with no effect, "that could mean waiting until the next core update." I am inside that window. Any number I quoted today would be noise dressed as a result.

Worse for the experiment: I published roughly 20 new posts in the same window as the prune. That was a defensible business decision and a bad piece of study design. Two large changes, one measurement period, no control. If traffic improves I will not be able to attribute it cleanly, and I am not going to quietly forget that caveat later when the graph looks flattering.

What I will commit to is the reporting shape. The follow-up will carry the same Search Console table as this post, over a comparable window, with the same metrics, whichever direction they moved. If they moved the wrong way, that is the post. The honest version of the timeline question is in how long SEO actually takes, and it is longer than anyone selling audits likes to say.

FAQ

Should I delete underperforming blog posts?

Google's core updates documentation calls deleting content "a last resort," to be considered only when the content cannot be salvaged. Unpublishing is the safer version: the page leaves the index, the site-quality signal improves if the content really was thin, and you keep the source material. I cut 267 published posts to 103 and deleted none of them.

How many impressions does a page need before I judge it?

Mine gave a clear signal at very low volume. 111 of my 182 ranking pages earned 5 or fewer impressions across an entire quarter. A page with 3 impressions in 85 days is not under-measured, it is not competing. You do not need statistical significance to act on that. You need a report that shows the distribution instead of the site-wide total.

Why does my site get impressions but no clicks?

Check average position first. My US traffic sat at position 38.8, which is page four, and no title tag fixes page four. Then check who is seeing you. My Nepal traffic sat at 9.2 and clicked at 10.8%; my Russian traffic sat at 10.5, a whisker over the page-one boundary, in the same week — and clicked at zero, because almost all of it was one post reaching a market I had never written for. Position explains the first gap. It does not touch the second.

Is a content audit worth it for a small site?

The census query above is free and takes minutes, so run that first. The paid version earns its place when the page count is large enough that deciding what to keep, one page at a time, becomes the bottleneck, or when the faults are structural — orphaned routes, entity problems, missing images — rather than editorial.

Want this census run on your own site, including the numbers you would rather not publish? You get the page-level kill list, the structural faults, and the order to fix them in. Book a content audit or get in touch.