On Oct 25, 21 pages of my site got impressions on Google. On Oct 28, one page did. If you have ever watched a Search Console chart do that, you know the dread: you check the date range, you check the property, and you refresh anyway, as if Google might reconsider.
The site is AuraMog, an AI reply generator for dating app conversations that I build. These are small numbers, so here they are in full:
| Day | Pages with impressions | Impressions |
|---|---|---|
| Oct 25 | 21 | 105 |
| Oct 26 | 10 | 98 |
| Oct 27 | 3 | 53 |
| Oct 28 | 1 | 5 |
Real visits from Google went from 4 to 6 a day to 0 or 1. Visits from AI chat referrals and direct visits kept coming, so the site itself was alive.
I found five things worth fixing and fixed them all the same day. One lived on a domain I don't own, and one was a line I copied from a competitor.
None of them explains the drop. Here is the whole trail, wrong turn included, with a checklist at the bottom you can paste into an issue.
My first diagnosis was wrong
I opened URL Inspection for the homepage and it said "URL is on Google". So I blamed Search Console lag and rank-tracker bots, since about 79% of my impressions had come from positions below 20, the kind scrapers generate.
The Pages report didn't help. It had been frozen since Oct 23 and still said 42 pages indexed, more than a week later. A report frozen since Oct 23 knows nothing about Oct 28.
URL Inspection on the eight pages with the most impressions told a different story. Seven said "Crawled - currently not indexed". Only the homepage was still on Google.
Inspect your top pages. The homepage survives on brand queries and hides the drop.
Everything else came back clean
- Every sitemap URL returns 200 to a Googlebot user agent.
- One meta robots tag with "index, follow", a self-referencing canonical, no X-Robots-Tag header.
- robots.txt allows everything except /api/.
- The URL Inspection live test renders the real page, and the Rich Results Test passes.
- No manual actions, no security issues, no removal requests.
- Crawl stats show a clean host status for 90 days, with no 5xx and no 403.
- The HTML served to Googlebot is byte-for-byte identical to what Chrome gets.
- Vercel firewall and bot protection were off.
Every one of those checks passed, and seven of my top pages were still out of the index. So I kept digging.
Fix 1: my site had a twin on vercel.app
Vercel also serves your production deployment at <project>.vercel.app. Mine answered at auramog.vercel.app with a 200, "index, follow" and a canonical pointing at the real domain. That is a full, indexable copy of the site on a domain I don't own.
Open yours and check the status code, the meta robots tag and the canonical.
The obvious fix is a redirect, and it is a trap. Vercel's docs say cron jobs call your production deployment URL on vercel.app, so a domain-level redirect can break your crons. It also breaks performance checks that measure deployment URLs.
So I left the twin alive and told Google not to index it. The middleware (Next 16 calls the file proxy.ts) adds X-Robots-Tag: noindex to any page request whose Host is not the canonical host. That part looks like this:
// proxy.ts
import { NextResponse, type NextRequest } from "next/server";
const CANONICAL_HOST = "auramog.app";
export function proxy(request: NextRequest) {
const response = NextResponse.next();
const host = request.headers.get("host") ?? "";
if (host !== CANONICAL_HOST) {
response.headers.set("X-Robots-Tag", "noindex");
}
return response;
}
export const config = {
matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};
Fix 2: a Sitemap line I copied from a competitor
My robots.txt had a second Sitemap line pointing at /llms.txt, a trick I copied from a competitor.
Google's robots.txt spec supports only these fields: user-agent, allow, disallow, sitemap. None of them is for llms.txt. The trick borrowed the Sitemap field, but a text sitemap must contain nothing but URLs, and llms.txt is Markdown.
I can't prove the line cost me anything, but I can't think of a reason to keep it either, so it's gone. The file itself still lives at /llms.txt.
Fix 3: /Tinder-Bio returned 200
Static pages matched case-insensitively. /Tinder-Bio returned 200 with a canonical to /tinder-bio, so every page had an unlimited supply of duplicate URLs, one per way of capitalizing it.
The same proxy.ts now also sends a 308 to the lowercase path. It keeps the query string and skips static files. Locale codes like pt-BR stay as configured.
Fix 4: lastmod was wrong on 36 of 39 pages
My rule was to bump updatedAt in the same commit as the content. It had silently failed on 36 of 39 pages.
I rebuilt the dates from git history by diffing each page's visible text between consecutive commits. On the legal pages, the screen said "Last updated October 2" while the sitemap and the JSON-LD said August. A test now ties those dates together.
Google uses lastmod only when it is consistently accurate, and mine was not.
Fix 5: two more robots directives
The meta robots tag was valid as "index, follow". It now also carries max-image-preview:large and max-snippet:-1.
So why did the traffic drop?
I don't know. None of these five explains a sitewide drop in two days.
Two suspects I can't rule out. An unconfirmed Google ranking update landed in the middle of the drop. Search Engine Roundtable reported a volatility spike on Oct 27, 2026, the day my pages with impressions fell to 3, and the Semrush Sensor read 9.5 out of 10.
My domain is also about a month old, after a rebrand and a domain move.
Google's own documentation says a "Crawled - currently not indexed" page "may or may not be indexed in the future". Request Indexing is a lever for "Discovered - currently not indexed", and most of my top pages are Crawled, so that button is the wrong one here.
What is left is content quality and external signals, plus waiting.
The checklist
Paste this into an issue and work through it top to bottom:
- [ ] URL Inspection on your 8 top pages by impressions, homepage last
- [ ] Pages report: check when it last updated, a frozen one proves nothing
- [ ] Fetch every sitemap URL with a Googlebot user agent, expect 200
- [ ] HTML served to Googlebot matches what Chrome gets, byte for byte
- [ ] One meta robots tag, a self-referencing canonical, no X-Robots-Tag
- [ ] robots.txt: Google supports only user-agent, allow, disallow, sitemap
- [ ] Every Sitemap line points at a real sitemap (text sitemaps: URLs only)
- [ ] Open <project>.vercel.app. A 200 with "index, follow" is a twin
- [ ] Twin fix: noindex any Host that is not yours (redirects can break crons)
- [ ] Request a page with capitals: 200 means duplicate URLs, add a 308
- [ ] Sitemap lastmod, JSON-LD date and the date on the page must agree
- [ ] Rebuild wrong dates from git history, add a test that keeps them in sync
- [ ] Manual actions, Security issues, Removals, Crawl stats: all clean
- [ ] Vercel firewall and bot protection: confirm Googlebot gets through
- [ ] "Crawled - currently not indexed": Request Indexing is not the lever
The current setup is live on auramog.app if you want to look at the robots.txt and the response headers yourself.
If a young domain of yours lost its top pages to "Crawled - currently not indexed", what brought them back: something you changed, or just time?
Top comments (0)