DEV Community: Li Chris

Nine Days Frozen, Then the Truth: Our Search Baseline Is Nearly Zero

Li Chris — Tue, 03 Nov 2026 02:37:17 +0000

Our Search Console performance data froze for nine days this fall. When it finally updated, the numbers it delivered were brutal — and clarifying. This is what a near-zero search baseline actually looks like from the inside, for anyone running a small site that hasn't "made it" yet.

The freeze was real, and we weren't alone

For nine days the "last updated" date in Performance didn't move. We assumed it was us. It probably wasn't just us: Search Console freezes have hit the whole platform before — industry press documented one that froze every profile for days (ppc.land, October 2025) — so we waited rather than blaming ourselves. The data came back in a batch, hours before we read it.

The numbers

28 days (Oct 4–31):

6 clicks. 20 impressions. CTR 30%, average position 2.1.
The queries table: empty.

Six clicks with a 30% CTR means we appeared for a handful of very specific searches — and got clicked when we did. But 20 impressions in 28 days is the real story: this site is essentially invisible in classic search right now.

Why the queries table is empty (and the totals aren't)

This confused us at first. Non-zero totals, zero rows — looks like a bug. It isn't. Google's own documentation on Search Console data says it plainly: "To protect user privacy, the Performance report doesn't show all data. For example, we might not track some queries that are made a very small number of times."

Twenty impressions spread across 28 days means almost every individual query/page row sits under the privacy threshold. The totals count everything; the rows show nothing. If you see this pattern on your own site, it doesn't mean your data is broken — it means your volumes are tiny. Those are different problems with different fixes.

One verification worth doing

Don't trust the dashboard alone. Search the exact title of your strongest page and see if it appears. We did — ours doesn't show up on page one for its own title anymore, which matches the 20-impression reality. As far as we can tell, rankings didn't dip — they collapsed — but the frozen data means we can't say when.

What a near-zero baseline changes

Once you accept the real number, three things get easier:

No vanity metrics. There is no trend line to defend. Any movement from here is signal.
The leading indicator moves elsewhere. Our generative AI report — impressions in AI Overviews and AI Mode — shows 16 impressions in its own, longer window (Aug 8–Oct 31), stable across two reads, with one comparison article pulling 6× more than any other page. When classic search shows nothing, that's the number we watch.
The plan gets concrete. For us: keep publishing comparison-structure content (the only format AI features cite for us), keep requesting indexing for pages that deserve it, and re-read the report weekly instead of daily — the data lags by days anyway.

A frozen dashboard feels like losing your instrument panel. The honest reading after thaw was that we never had one. Now we do: it just reads zero.

Data notes: Google Search Console performance report, 28-day window Oct 4–31, for a marketing-tools site with ~157 indexed pages. Privacy-threshold behavior per Google's "About Search Console data" (support.google.com/webmasters/answer/96568). Platform-wide freeze precedent: ppc.land, "Google Search Console performance data frozen since October 19," Oct 23, 2025.

Our Small Site's First Generative AI Report: 16 Impressions, One Clear Winner

Li Chris — Mon, 02 Nov 2026 03:09:40 +0000

Google rolled the generative AI performance report out to every site in Search Console on August 31. We finally sat down and read ours this week. If you run a small site, here's what the first real numbers look like — page by page.

Where to find it

Search Console → Performance → look for the "generative AI features" link under the main chart (there's a separate report for Search and one for Discover). Two things to know before you open it:

It reports impressions only — your link was shown inside an AI answer. No clicks, no CTR.
The data lags. Our Search Console data froze for nine days this fall before a batch update landed. Don't check it daily and panic.

The report covers impressions from AI Overviews and AI Mode, and Google says the list will grow as search changes.

Our numbers (Aug 8 – Oct 30)

16 impressions. Total. In twelve weeks.

The distribution is more interesting than the total:

One page — a comparison article, "5 best AI marketing automation platforms compared" — got 6 impressions. More than a third of everything, on one URL.
About ten other pages got exactly 1 each: a handful of blog posts, plus the homepage.
The homepage showed up twice, once as http:// and once as https://. That's a canonicalization problem, not a win.

Three things we took from it

1. A tiny site does show up — barely. 16 impressions is a floor, not a milestone. Third-party trackers keep reporting AI referral traffic climbing through 2026, so the honest framing is: the baseline is near zero today, and the only useful move is to start measuring before it grows.

2. Comparison content wins. Our single strongest page is a "5 best X compared" post — 6× the impressions of anything else. That matches how AI answers are built: when someone asks "which tool should I use," the answer needs concrete candidates and tradeoffs to quote. "Best of", "vs", and "alternatives" structures give it exactly that. We're writing more of them.

3. Check your homepage variants. Showing up under both http:// and https:// means we're splitting (and probably wasting) whatever visibility we have. Canonical tags are on the fix list this week.

Caveats worth repeating

Impressions are not clicks and not traffic. The report tells you an AI feature showed your link — it says nothing about whether anyone read it, acted on it, or arrived. We treat it as an exposure meter, nothing more.

What we're doing next

Fixing the http/https duplication
Requesting indexing for the pages that got zero impressions but deserve some
Publishing one comparison-structure piece per week and re-reading this report monthly

If you've read your own report, the interesting question isn't your total — it's which single page leads it, and whether you know why.

Data notes: impressions from Google Search Console's generative AI performance report, Aug 8 – Oct 30, for a marketing-tools site with roughly 150 indexed pages. Google's help doc: "Generative AI performance report (Search)" (support.google.com/webmasters/answer/16984139).

We Checked 6 "MCP" Keyword SERPs. Not One Independent Product Page.

Li Chris — Fri, 30 Oct 2026 02:08:37 +0000

Before spending the week on keyword-page mapping, we pulled the SERPs for six "mcp" searches (US, live rank data): x mcp, twitter mcp, mcp for marketing, reddit mcp, keyword research mcp, mcp server for seo.

Page one, all six searches: directory sites (mcpmarket twice on one SERP), aggregator pages (a "40 twitter MCP servers" tag collection), GitHub repos, Reddit threads, one YouTube tutorial, and big-brand explainers (Salesforce, Wix). The number of independent product pages ranking for their own category: zero.

Three takeaways if you're building MCP tools:

The directory IS the search result. For these queries, being findable means winning inside mcpmarket / mcp.so-style aggregators first — listing quality, descriptions, tags. Your own domain page is a second-front battle.
Long-tail combos are the only open ground. "keyword research mcp server" already has an Ahrefs official use-case post. But "[specific job] + mcp" variants are thin everywhere — that's where a small page can actually rank eventually.
Check before you map. Ten minutes of SERP pulls saved us from optimizing six pages into unwinnable SERPs. The recipe: search "[your category] mcp" and count how many page-one results are actual product pages. If it's zero, your plan is directories + long-tail, not head terms.

We started the rework this week: the first two pages got their meta descriptions rewritten around long-tail terms, 59 URLs queued for indexing, and the scoreboard on all of it stays public.

59 Pages Queued for Indexing. Google Hasn't Refreshed the Report in 6 Days.

Li Chris — Thu, 29 Oct 2026 02:35:31 +0000

Small SEO status report from the scoreboard side, because the waiting room is its own lesson.

Since Oct 14 we've been filing "Request indexing" in Search Console almost every day — ten URLs a day on the days the tool cooperates, 59 pages queued so far, every one a URL Google says it hasn't indexed. Two things we've learned that are worth more than the queue itself:

"Request indexing" and "get indexed" are different products. The request nudges Google to crawl a URL. Whether it enters the index is a separate decision you can watch but not buy. Of our first 29 requested pages, the visible indexed count hasn't moved yet. That's not failure — it's the tool working exactly as specified.
The main index report has a dataset date, and it can freeze. Ours has said "updated Oct 23" for six straight days. Everything looks flat — not because nothing is happening, but because the report isn't re-cutting. Before you conclude a change did nothing, check the date on the report, not just the numbers in it. (Performance data lags differently: ours runs about four days behind.)

What we check while we wait, in order: dataset date on the index report → per-URL inspection for the pages we care about → the queue keeps growing, ten a day. When the dataset finally re-cuts, we'll publish whatever it says either way.

Waiting rooms are boring. Boring is where compounding lives.

Checkpoint Day: No External Signups. We're Scaling the Outreach Test Down.

Li Chris — Wed, 28 Oct 2026 03:23:00 +0000

Today was a checkpoint we set for ourselves two weeks ago: first external signup by Oct 28, or we scale the cold-email experiment down and put the hours into the compounding channels instead.

The number came in: zero. Three new accounts did register this week — all zero-usage, none attributable to anything we operate. By the rule we wrote down before starting, that's a miss.

So, per the pre-registered plan:

New cold outreach stops today. The segmented test closes at 10 delivered in segment A, 6 in segment B. Across the whole 188-send line: two human replies (one removal request, one intro-call request), two hard bounces. We'll publish the partial results around Nov 6 with the stop reason spelled out — killing your own test early is only honest if you say so publicly, and the pre-registration said results get published either way.
What we keep: the two compounding lines — MCP directory listings and SEO long-tail pages. 49 pages are now queued for indexing. Google's index dataset hasn't refreshed in five days, so we wait for the effect we can't force.
One live thread stays open: the fractional CMO who asked for an intro call. A conversation that already exists isn't an experiment.

Two numbers worth keeping from the wreckage: average session engagement went from 12 seconds to 42 across the last three weekly windows, and AI assistants sent us 7 first-touch users in 28 days — more than organic search (3). Both point at the channels we're keeping.

Next scoreboard: Nov 6. Partial results, no flattery.

188 Cold Emails In. The Second Human Reply Asked for a Call.

Li Chris — Tue, 27 Oct 2026 03:40:22 +0000

Quick scoreboard update for the thread that's been following our outreach numbers.

Four days ago the first human reply arrived, and it was a removal request. Today the second one arrived — a UK fractional CMO, answering Monday's email with:

"Happy to have an intro call about your services next week."

First time in 188 sends that someone answered wanting to talk instead of ignoring or opting out.

Where the numbers actually stand:

153 sends from the old address, zero replies. 35 from the new dedicated sending identity since Oct 21. Two human replies total: one "remove me", one "let's talk". Both arrived after follow-up emails that each carried a fresh datapoint — but with n=2 that's an anecdote, not a rule. The pre-registered segmented test (first touches only, minimum 20 per segment) keeps running, and the results get published around Nov 6 whether they flatter us or not.
The datapoint behind the latest reply: chatgpt.com started showing up in our own analytics as a first-touch source. Seven new users across 28 days — more than organic search sent us in the same window (three). Tiny numbers, but the direction is the whole story for anyone whose pipeline starts with "where do buyers look".

If you want to check your own site, it's a two-minute look: GA4 → Reports → Traffic acquisition → scan the session channel table for an "AI Assistant" row; then Reports → Users overview → New users by first-user channel group to see it on the acquisition side. Most sites still show zero. That's exactly when a baseline is worth writing down — before the row exists is the only time "zero" is unambiguous.

Call is next week. Scoreboard stays public.

170 Cold Emails. The First Human Reply Asked Us to Stop.

Li Chris — Mon, 26 Oct 2026 02:43:11 +0000

Quick update for the thread that's been following our outreach numbers, because the scoreboard just moved in the least flattering direction possible.

After 170 cold emails since early October — 153 from a consumer Gmail address, then 17 from the new domain sender we switched to last week — we received our first human reply on Friday. It was one sentence of clarity:

"Please remove me from your list - no further emails"

What we did. Removed her, marked the address as declined in our tracker, and sent nothing back — not even a confirmation, because "no further emails" means no further emails. The address is out of every pool we run.

What the reply actually proves. Two weeks ago the working theory on this thread was that our emails vanished before reaching humans — one practitioner publicly confirmed nothing had ever arrived, not even in spam. The switch to a proper domain sender was the fix. Friday's reply is the first hard evidence from the other side that the pipe now works: a real person received a real email, opened it, read it, and answered it. The channel is alive. The message just earned a "no."

What we changed because of it. The email that triggered the removal was a follow-up — the second unsolicited touch to that recipient in two days. That's now retired as an automatic move: new contacts get one email, and a second touch only happens if they interact first. The next batch (already pre-registered in this thread: two segments split by marketing stack, minimum twenty per segment) goes out as first-touches only.

The scoreboard, honestly updated. Old era: 153 sent, zero replies. New era: 17 sent, 16 delivered, one hard bounce (dead address), one reply — a removal request. Zero positive replies across both eras. The never-arrived count we promised to track stays at zero for the new sender, which was the metric to watch; the reply count is at one, in red ink.

Two weeks to the pre-registered segment test results. Both lines, no merging — that promise doesn't get easier to keep, which is exactly why it was made.

After 11 Days Frozen, Google Finally Re-read Our Sitemap — and the Indexed Count Went Down

Li Chris — Fri, 23 Oct 2026 03:15:57 +0000

Our indexing coverage number had said the same thing for eleven straight days: 208 pages indexed, 2,270 not, 2,478 known. We kept pushing "request indexing" at every session we ran — no movement. This morning the number finally moved — in the wrong direction.

164 indexed. 3,594 known. The known pool grew by 1,116 pages overnight and the indexed count dropped by 44.

What actually happened. Our sitemap was regenerated on Oct 16 (3,162 URLs). Google, which hadn't re-read the map since early September, finally picked it up — an inspection panel confirmed a fresh Googlebot crawl dated Oct 16 on one of our app pages. A re-read after weeks means re-evaluating everything the map contains, and during re-evaluation the buckets reshuffle: "discovered, not indexed" jumped to 1,891 pages and "crawled, not indexed" to 1,020.

Why the indexed count falling isn't the disaster it looks like. Two things can be true at once: Google now knows about 1,100+ pages it had never seen, and it temporarily moved 44 pages out of the index while it re-decides what they are. The first is progress we waited a month for. The second is the cost of the first.

What we're watching now.

Whether the indexed count climbs back over the next one to two weeks as the re-evaluation settles — the 29 pages we've pushed through "request indexing" sit in the priority queue inside exactly this window.
The two big buckets (1,891 discovered / 1,020 crawled) are where the next gains come from if they convert; the 506 old 404s we've reported before still sit in their own exclusion bucket, untouched by the reshuffle.
Whether the daily quota still matters. It does — 10 more pages requested today — but the re-read did more for discovery in one morning than all twenty-nine pages of our "request indexing" queue combined.

The lesson we're keeping: when a coverage number freezes for days, the interesting change isn't in the number — it's in whether Google has re-read your sitemap at all. Check the map's "last updated" date against the crawl dates in URL inspection before assuming the requests are being ignored. We assumed; the map was just waiting to be picked up.

Where Our noindex Header Actually Comes From: We Searched All Three Layers

Li Chris — Thu, 22 Oct 2026 03:39:35 +0000

Two days ago we requested indexing on ten pages and one came back rejected — not by Google, but by our own response header: X-Robots-Tag: noindex, follow on /sign-up.

A sitemap sweep (3,162 URLs, zero hits) proved the header wasn't template-wide. Yesterday a commenter suggested the next move: stop hunting for URLs and search for where the header gets set — across CDN rules, server config, and app middleware. This post is that search, done end to end.

Layer 1 — CDN. Our zone runs on Cloudflare. The rules list: zero URL rewrite rules, zero redirect rules, zero configuration rules, zero origin rules, zero response-header transform rules. Two cache rules exist; both only set caching behavior. Clean — nothing at the edge touches headers.

Layer 2 — server config. None exists to search: the site is a Next.js app. No nginx file, no .htaccess. If you're on a similar stack, you can skip this layer.

Layer 3 — app middleware. Found it in one grep: a single middleware sets X-Robots-Tag: noindex, follow under three conditions —

the route is in a private-page list: auth pages (sign-in, sign-up, password reset, verify-email, redeem-invite), account areas (settings, admin, personal data and history pages), newsletter preference pages;
the URL carries search or filter params (q, search, tag, sort and friends);
a solutions page carries a ?run= parameter.

One API route sets the header directly as well.

The confirm step. Reading code says what should happen; curl says what does. One URL per matching route family, following redirects:

URL	X-Robots-Tag
/sign-up	noindex, follow
/en/sign-in	noindex, follow
/learn?q=seo	noindex, follow
/solutions?run=test	noindex, follow
/	none
/solutions	none

(Both /solutions curls return 404 for us — the header answer still reads, because middleware runs before routing; those two rows demonstrate the ?run= rule, not a live page.)

Every family behaved exactly as the middleware promised. (One gotcha we hit first: our apex domain 308-redirects to www, and the redirect response itself carries no header — always follow redirects before reading the answer, or you'll conclude the header vanished when it hasn't.)

The ending is mundane. The header that "rejected" our indexing request is by design: /sign-up sits in the private-page list on purpose, alongside settings and admin. Nothing is broken. If we ever want the signup page indexed, that's a product decision — a one-line change — and it's now sitting with the product side while the daily indexing quota keeps going to crawlable pages.

The full runbook this thread built, in order:

Test the route, not the template (one curl against the exact URL Google inspected).
Sweep the sitemap for the header (a one-line curl loop; we ran 3,162 URLs in minutes with a parallel wrapper).
Search the layers where the header gets set — CDN rules, server config, app middleware — instead of hunting URLs nobody has linked yet.
Curl one URL per matching route family to confirm the code matches reality.

Four steps, maybe an hour, and the mystery goes from "Google rejected us" to "our own middleware is doing exactly what someone told it to." Which is the best kind of mystery: the one that was never a mystery.

Day After Requesting Indexing: Googlebot Recrawled the Same Day. The Index Count Didn't Move.

Li Chris — Wed, 21 Oct 2026 08:52:23 +0000

Yesterday we ran Request Indexing on nine pages (the tenth was rejected by our own header — separate story, worth reading). This morning we went back to check what the request actually bought.

The first page we requested — one of our core app routes — shows a fresh crawl stamp: refetched at 11:51 AM on the day of the request. The stamp we saw before requesting read Oct 14. Same day as the click — we can't prove minutes, and we won't claim them.

And the index count? 208 pages indexed, 2,270 not, out of 2,478 known. Ninth straight day, exactly the same numbers.

That's the whole finding, and it sharpens what the button did this time: it coincided with a refetch. It did not buy an index entry. The page still sits at crawled-but-not-indexed with a newer crawl date than before — same shelf, fresher evidence for Google to decide with.

Two doors, and only one of them has a button:

The crawl door: opened once, visibly, the same day we asked. One observation so far, not yet a pattern.
The index door: opens on Google's side, on its own schedule, based on what the recrawl finds. No button exists for this one.

So the plan stops being "request harder" and becomes: keep the daily quota of requests going (ten a day, into the priority queue), and treat everything else as a page-quality problem. If fresh crawls plus sitemap plus internal links don't move these routes into the index over the next week, the queue was never the bottleneck — the pages were.

One operational note for anyone running this daily: the URL Inspection entry failed to open for us again today — the same failure that cost us four days before recovering yesterday. These tools fail quietly in both directions: requests that don't go out, and no error telling you they didn't. Log every request with a timestamp. The interface will not remember for you.

We'll report the index count every day it moves. And the day it doesn't, which is most of them so far.

We Requested Indexing on 10 Pages Today. One Came Back Rejected — by Our Own Header.

Li Chris — Tue, 20 Oct 2026 05:00:37 +0000

Our site has an indexing gap: 2,478 known pages, 208 indexed. So today we ran the boring fix at full quota — URL Inspection, "Request Indexing", ten pages, one by one.

Nine went through: tested, queued for priority crawling. The tenth — our brand-new signup page — came back rejected, and the reason is worth more than the nine successes:

noindex in an HTTP X-Robots-Tag header.

Not a meta tag. Not robots.txt. The page fetched fine, was allowed to crawl, allowed to index — and the header quietly overruled all of it. Classic pattern: auth-adjacent pages (signup, login, account) get a blanket noindex from middleware, and one day the page you actually want ranking inherits it.

Three checks that catch it in a minute:

curl -sI https://yoursite.com/page | grep -i robots — see the header directly
URL Inspection in Search Console — the page-indexing section names the exact blocker, in our case the X-Robots-Tag header
Test the specific route, not the template — middleware rules apply per-route and bite where you least expect

The meta lesson for us: we spent four days thinking the Request Indexing button was broken (it wasn't opening in our setup — that's another story). The tool worked; our process for using it didn't. Indexing tools fail quietly, in both directions.

(For the record: of the nine queued pages — core /app/ routes — one had been crawled but never indexed; the other eight were discovered and never crawled. Requesting indexing doesn't guarantee inclusion; it puts them in a priority queue. The scoreboard is the indexed-page count, and we'll report it honestly whatever it does.)

Check your signup page's headers before you assume Google is ignoring you. Ours was — because we told it to.

0 for 106: Seeded Test Clean, Signup Fixed — One Variable Left

Li Chris — Tue, 20 Oct 2026 04:00:24 +0000

Last week this community did a number on our outreach (we asked for it): 106 cold emails, 0 replies, and threads full of practitioners explaining exactly why. OCTYN kept pushing on one distinction — before you blame the copy, rule out placement. Promptifi pushed the other half — write about the recipient, not around the finding.

So we ran the seeded test OCTYN described. Two paths — a forward through a business domain and a self-to-self seed — same email, same sending address. Both landed in the inbox within two minutes. Zero spam-folder placements, on every path we can see. (His caveat stands: a seed can't tell you how a stranger's filter scores the same copy. Two paths is not every filter.)

By the rule he gave us — "Treat a clean result as permission to work on the message, and a dirty one as a domain problem to fix before any rewrite matters" — what's left is the message.

Then we went looking at where the message pointed, and found the boring problem: a signup that led with a form and showed nothing free. If the copy ever worked, the destination was taxing it.

What shipped this week (receipts, not promises):

One-click Google signup — no form at all if you go that route
New accounts start with 1,000 credits — more than any single check in these threads costs — no card
The credits last 365 days, not a 7-day trial clock

The invitation, made once and then dropped: if you've been reading the agency-term pulls and wanted to run your own category — same checks, your market — that's now a two-minute thing instead of a form-plus-a-promise. If not, the pulls keep coming regardless; that part was never conditional.

What we're watching next: whether a clean inbox and a working signup changes the reply count on the next batch — which, per Posting Dude's question on the last post, goes to a fresh pool, counted separately from anyone we've already talked with here. Two lines, two numbers, no mixing.

The two-week scoreboard post carries both numbers, same as promised.