DEV Community: 孙永瑞

I shipped llms.txt and unblocked every AI crawler. Citation count: still zero.

孙永瑞 — Tue, 29 Sep 2026 08:36:42 +0000

I run five niche content sites. Two months ago I set out to get them cited by AI answer engines, and I did what the current advice says to do.

I shipped llms.txt on all five. It went from 404 to 200, 19–22.6 KB each, written in the same honest voice as the rest of the site — including the part where we state we don't run hands-on lab tests.

I unblocked every AI training and search crawler I could name — GPTBot, ClaudeBot, CCBot, OAI-SearchBot, PerplexityBot — and verified all five homepages returned 200 for each, then re-verified 12 hours later to confirm the config actually stuck.

I unified author attribution: real bylines, real LinkedIn, zero remaining "Editorial Team" placeholders.

Twelve hours later I measured citations again.

Zero. On all five sites, across all five probe questions.

First job: prove the zero is real

A zero is worthless until you've ruled out a broken measurement. This is the part most people skip, and I nearly got it wrong.

My check was source count. The probe returns a set of sources per query, and those counts came back 20, 21, 23, 18, 22 — matching my baseline run one for one. Same numbers means the same retrieval is happening. The probe was working; the answer was genuinely empty.

The second check was stickiness. Over 12 hours, the head of the source pool didn't change at all. That told me something useful: this isn't a volatile set that might roll my way tomorrow. It's a high-retention pool, which means 30 days is the minimum meaningful re-measurement window. Measuring daily is noise.

The false zero I almost published

There was a trap sitting right next to the real one. Brave rate-limits repeated queries. When it happens, source count comes back 0 and navigation times out — which renders as "no citations found."

That is not the same thing as zero citations. It's an empty response wearing the same clothes. Same failure shape as the Cloudflare interstitial trap I'd already hit on Perplexity.

The guardrails I added, all cheap:

Treat a sample as valid only if source count ≥ 5. Below that, it's a failure, not a finding.
Retry invalid samples up to 3 times.
Space queries ≥ 25 seconds apart; ≥ 150 seconds cooldown after a confirmed rate-limit.
Record invalid samples explicitly instead of silently writing 0.

Without that, I would have written "AI search doesn't cite us" from a rate limit. With it, I can say the zero is real and know why.

Why it's actually zero

The tempting explanation is content shape — our pages just aren't the kind that get quoted. I went looking for evidence and didn't find it.

What I found in the citation pool was a lot of structurally identical small vertical sites. Project management tools, AI-for-education tools especially: the same comparison formats, the same depth, the same "vs" pages we publish. Those sites get cited. Ours don't.

So format isn't the differentiator. The remaining variable is domain age and accumulated authority — the one thing you cannot ship in a sprint.

Traditional search agrees. Across the same sites, Search Console reports an average position of 73 and a CTR of 0.011%. That's not a content-quality signal. That's a two-month-old domain behaving exactly like a two-month-old domain.

My working expectation now: first real citation somewhere in the 6–12 month range. We're two months in.

The conclusion I didn't want

Shipping llms.txt and unblocking crawlers changed nothing measurable. Those two actions moved real numbers — 404 to 200, blocked to allowed — and produced zero movement in the metric I actually care about.

So I downgraded them. They're no longer growth levers; they're completed compliance items. Necessary, cheap, done, and filed. What I will not do is keep re-measuring them and calling it progress.

The separation I now apply to every task on these sites:

Compliance work — correct, cheap, one-time. Does not move traffic or citations. Stop measuring it after it's done.
Growth work — expensive, slow, uncertain. This is where the 6–12 month bets live.

Mixing them is how you spend a month feeling productive. "Shipped llms.txt" is a real checkbox, and it is worth exactly zero citations.

The uncomfortable but useful part: the zero was honest data. Knowing why it's zero — and knowing it wasn't a rate limit — is worth more than a lucky citation I couldn't explain.

If you want a second pair of eyes on your site's AI-search visibility, structured data, or the measurements behind them: https://yongrui-services.pages.dev/

My honesty linter flagged my own honesty disclaimer

孙永瑞 — Mon, 28 Sep 2026 15:31:33 +0000

I run five small software comparison sites. I have not installed most of the tools I write about. That gap is the whole problem: the easy way to sound authoritative is to imply I did things I didn't do, and that is exactly the kind of sentence that gets a site rejected for ads, or quietly distrusted by readers.

So instead of promising myself I'd be careful, I wrote a checker.

The rule

site_verify.py scans every page before deploy and fails the build on phrases that assert first-hand experience. Not "we think" — "we tested," "hands-on," "in our testing," "we measured." If the site can't back the claim up, the phrase doesn't ship.

It isn't clever. It's a list of patterns and a hard exit code. After enough rounds it's at version 26, and this week it finally went green across all five sites — 59 of 59 checks.

The same discipline applies to the bylines. An earlier pass rewrote 302 author bios and 302 role lines that had been describing a persona with hands-on experience of the products. That number is what convinced me the manual approach had already failed: I cannot hand-audit 604 fields, and I definitely cannot hand-audit them every time I publish. A script can.

The bug

The failure wasn't a page. It was my own disclaimer.

One of the sites carries a line explaining the limits of the content: "We do not run hands-on lab tests." The checker's fallback rule was a bare regex on hands-on. It matched. My honesty checker was flagging my honesty disclaimer as a dishonest claim.

The same round produced two more: "We ran no benchmarks." and a "we measured no ..." line, on two different sites. Same cause.

Why the fix isn't "add an exception"

The tempting fix is to allowlist those exact sentences. That works today and rots next month — I write "we ran no benchmarks on the enterprise tier" and it sails through, or I rephrase slightly and it fails again for no reason.

What I actually changed: the matcher now looks at negation context. A phrase only passes if it's explicitly negated — "do not," "no," "never" — within the same clause. The allowlist strips negated forms; it never opens the door to affirmative ones. Claiming I tested something is still a hard fail. Saying I didn't is now fine.

That distinction is the entire point. The goal was never to remove the word "testing." It was to remove the impression of experience I don't have.

The sentence that got me anyway

A few hours later, reading a page I had already shipped, I hit this subheading:

How we built and checked these prompts

"Checked." It's on no pattern list. It passes every rule I wrote. And it reads exactly like someone opened the tools and verified the output.

I changed it to "How this prompt set is put together." Same information, no borrowed credibility.

That one is the honest lesson, and it's the part I can't automate: a linter catches patterns, not impressions. Every rule I have encodes a phrasing I already thought of. The one that slips through is always the verb I didn't consider — "checked," "verified," "tried," "ran it ourselves."

What I do now

Two passes, every time:

Run the checker. It's cheap, it's deterministic, and it catches the obvious 95%.
Read the page once, out loud, asking one question only: what would a reader believe I did, based on this sentence?

Step 2 caught the subheading. Step 1 never would have.

If you're running content sites where you don't have first-hand experience of the product, this is worth an hour of your time. The checker isn't the valuable part — anyone can grep for "we tested." The valuable part is the habit of asking what your sentence implies, independent of what it literally says.

If you want a second pair of eyes on your site's claims or your pre-deploy checks: https://yongrui-services.pages.dev/

I fixed 4 broken JSON-LD blocks at 3pm. Google found 32 more at 8pm.

孙永瑞 — Sun, 27 Sep 2026 15:59:05 +0000

At 15:40 I finished patching four pages where an affiliate link had been injected inside a JSON-LD block. I rewrote the safety check, re-ran the verifier, got zero failures, deployed. Felt done.

At 20:44 an email from Google Search Console arrived:

Unparsable structured data. Parsing error: Missing ',' or '}'

On a different site. Different pages. Same root cause.

What actually happened

Months earlier I wrote a script that inserts internal links into article bodies. It was a naive string operation: find anchor text, wrap it in an <a href="..."> tag.

The problem is that href="..." contains double quotes. JSON-LD lives inside a <script type="application/ld+json"> block, and a JSON string cannot contain a raw double quote. Every FAQ answer that got a link injected became unparsable JSON. The whole block — including the valid FAQPage markup around it — was dead.

GSC reported one affected page. A full scan found 32 broken blocks across three sites: 27 on one, 3 on another, 2 on a third. Two sites were clean, purely because nobody had run the link-injection script on them.

The part that bothers me

My own checker had reported zero failures on all three sites that same week. It was green the entire time this was broken.

The reason is simple and embarrassing: my verifier validated the things I was worried about. Titles, canonicals, link attributes, image alt text, ads.txt. It never parsed the JSON-LD. I had written a checker for the failure modes I had already imagined, and this was not one of them.

Google submitted to the same pages my checker passed and got a different answer, because Google actually parses structured data and my script didn't.

Two bugs, one class, one day

The afternoon fix and the evening discovery are the same bug with different entry points:

15:40 — affiliate link injection wrote an anchor into a JSON-LD block. My "safe spot" heuristic checked the first 300 characters of the file and missed script blocks that opened earlier than that. Four pages hit.
20:44 — internal link injection had done the same thing months earlier and I never noticed, because nothing was watching. Thirty-two blocks hit.

I patched symptoms at 15:40. The class of bug wasn't addressed until 20:44, and only because an external system told me.

What I changed

Three rules, all cheap:

Any script that writes into HTML must first map the <script> and <style> regions and treat them as off-limits. Not "check the first N characters" — build the actual exclusion ranges. My 300-character window was a guess dressed up as a check.
The verifier now parses every ld+json block with a real JSON parser and fails the build if any one is unparsable. Not regex. json.loads.
When injecting into a JSON string, escape or strip. I chose stripping: remove the <a> tag, keep the anchor text. An FAQ answer reads fine without a hyperlink, and structured data validity is worth more than one internal link.

The general lesson

A local checker only tells you about the questions you asked it. Every green run I had was real — and every one of them was silent about structured data, because I had never asked.

The fix isn't a better checker. It's treating external systems as the second opinion they are. GSC, browser consoles, and third-party validators cost nothing and catch the category you forgot existed. In my case the gap between "my tool says fine" and "Google says broken" was five hours and 28 pages.

If you want a second pair of eyes on your structured data or your site's search setup: https://yongrui-services.pages.dev/

Every indexing request failed today. The bug was my timezone.

孙永瑞 — Sat, 26 Sep 2026 15:31:24 +0000

My daily job was simple: open Google Search Console, paste in a URL, click Request Indexing, repeat for ten URLs, done. It ran every morning at 10:07 Beijing time. It had been working.

Then one morning every single request came back with the same popup:

Sorry! We are unable to process this request because you have exceeded your daily quota. Please try again tomorrow.

Zero accepted. Zero skipped as already indexed. Sixty-two URLs still sitting in the queue, untouched.

First assumption: the script broke

I wrote the automation myself — a headless browser that fills the inspect field, waits 24 seconds for Google's check to finish, clicks the request button, waits another 5 seconds, and verifies the result. My first instinct was that something in that flow had rotted.

It hadn't. The script did exactly what it was told. It typed the URL. It clicked. Google answered. The answer was just "no."

Nothing in my verification logic was wrong. I was checking for the wrong failure mode — I had accounted for "already indexed" and "not found," but never for "quota." So every attempt looked like a clean run with no URL removed.

The actual cause

Search Console's indexing quota resets per US Pacific natural day. That's a hard cutover at 15:00 Beijing time (during PDT).

Here's what my two runs looked like after conversion:

Previous batch, submitted at 22:11 Beijing on Sept 22 → 07:11 PT, Sept 22
That morning's batch, at 10:07 Beijing on Sept 23 → 19:07 PT, Sept 22

Same Pacific day. I had already spent that day's quota twelve hours earlier, from my own point of view "yesterday."

Being nineteen hours apart in local time means nothing to Google. It counts calendar days in one fixed timezone.

Why my schedule made it inevitable

A single daily job at a fixed Beijing hour is safe on its own. 10:00 Beijing today and 10:00 Beijing tomorrow land on two different Pacific days. No collision.

What broke it was a manual extra run. I'd kicked off an additional batch at 22:00 the night before, which landed early in Pacific day Sept 22. The next morning's automated run then landed late in that same Pacific day — after the quota was gone.

So: not a script bug, and not really a timezone bug either. A scheduling bug, exposed by mixing manual runs with automation.

What I changed

Three fixes, all cheap:

Moved the job to 16:00 Beijing — one hour after the Pacific reset, so the quota is always full when it fires. Shift the run to after the reset rather than hoping the previous day left something behind.
Taught the verifier to recognize the quota popup and stop immediately. Burning five attempts into a dead quota teaches you nothing and risks looking like abuse. Now it reports "blocked by quota," keeps every URL in the queue, and retries next cycle.
Added a rule for anything touching "tomorrow": convert to Pacific first. If a service resets daily and doesn't tell you in which timezone, find out before you build a cron around it.

The last one generalizes furthest. Rate limits, daily quotas, usage caps, "resets at midnight" — if it's a daily window, it belongs to someone's midnight, and it's usually not yours.

The part I got wrong

I spent my first twenty minutes reading my own code, convinced there was a bug. The script was fine. The honest lesson: when an automated task fails after previously working, check the external system's state before you audit your own logic. Confirm the limit, the timeline, and the timezone first. Often the bug isn't in your code at all — it's in the calendar.

If you want a second pair of eyes on your site or your indexing setup: https://yongrui-services.pages.dev/

There's no API" doesn't mean "can't be automated

孙永瑞 — Fri, 25 Sep 2026 14:54:12 +0000

For weeks I told myself Google Search Console's "Request indexing" had to be done by hand. The reasoning felt solid: there's no API for it, therefore a human must click it.

That conclusion was wrong, and it cost me days.

The distinction I was missing

No API means no programmatic interface. It doesn't mean no browser interface. If a human can do it by clicking, a script driving a browser can usually do it too.

What it actually took

One afternoon:

Open the URL inspection tool
Find the input field (locate it by its aria-label, which is more stable than any selector)
Set the value using the native property setter, then dispatch an input event — Angular ignores direct assignments
Dispatch Enter
Wait for the check to finish
Click "Request indexing"

Roughly 26 seconds per URL. Batched two at a time to avoid timeouts. Ten priority pages pushed the first day, and a queue handles the rest daily.

The part that stung

I'd been sitting on 72 undiscovered pages while telling myself the bottleneck was unavoidable. The bottleneck was my own assumption.

I'd even said it out loud more than once: "this one has to be manual." Nobody challenged it, including me.

The general lesson

When you catch yourself saying "X has to be manual," check which claim you're actually making — "no API" or "no interface." They're different, and only the first one is usually true.

Site builds and diagnostics if you want help automating this kind of thing: https://yongrui-services.pages.dev/

HRIS Migrations Don't Fail on the API. They Fail on the Data Model.

孙永瑞 — Thu, 24 Sep 2026 14:47:31 +0000

Every HRIS implementation plan has a data migration phase that reads like a file transfer: export from the old system, map the columns, import into the new one, reconcile the headcount, go live. The integration work gets estimated in story points. The data model gets a spreadsheet.

That ordering is backwards, and it is why go-lives slip by a quarter. The endpoints are rarely the hard part — rate limits, pagination and webhook retries are solved problems with published patterns. What breaks migrations is the quiet assumption that an employee is a row with columns.

HR data is temporal, and most schemas are not

In a typical application table, a row holds current state. In an HR system, nearly every meaningful field is effective-dated: compensation, job title, manager, department, location, cost center, FTE percentage. Each carries a validity window, and the history is the point. You cannot answer "what was this person's salary in March" or "who approved that backdated promotion" from current state.

Load current-state columns and you get a system that is accurate on day one and wrong forever after. Retroactive pay, accrual recalculation and any audit request all fail against it. The load has to target effective-dated records, which usually means one source row fans out into several target rows that must be inserted in chronological order — and most vendor APIs reject an out-of-sequence effective date outright.

That single constraint, ordering, is what breaks most first-pass migration scripts.

One human is not one record

The second mismatch is identity. In the source system a person is usually one row. In the target, the same human may legitimately be several: an employee record, a separate contractor record, a rehire with a new hire date, or a worker holding two concurrent assignments in different legal entities.

The join keys are worse than they look. Email addresses change. Some vendors reuse employee IDs after termination. National identifiers are jurisdiction-specific and frequently absent for non-payrolled workers entirely.

The fix is to stop treating any vendor-supplied field as a primary key. Generate a durable surrogate key you control, persist it on both sides, and join on that. It is one extra column, and it is the difference between a clean load and re-importing everyone because somebody got married.

Stored values versus derived values

This is the one that produces silent corruption instead of loud failures.

PTO balances, tenure, accrued liability, FTE-normalized headcount, compa-ratio — these are computed from events, not stored facts. Import a balance snapshot and the new system holds a number with no ledger underneath it. The first time someone books a day off, the balance moves from a starting point nobody can explain, and HR and payroll stop agreeing.

Import the events instead: hires, terminations, accrual rules, grants, leave taken. Let the target compute the balances. Then compare the computed balance against what the old system reported — any gap is a genuine configuration difference, and it is far better to find it during migration than during the first payroll run.

"The counts match" is not reconciliation

A matching headcount is the most common false green light in a migration. Row counts say nothing about whether the values are correct.

Reconcile on aggregates that a finance or HR stakeholder can independently verify:

active headcount by department and by legal entity
year-to-date gross pay by legal entity
total PTO liability, in hours and in currency
workers with no manager assigned
workers with a null cost center

The last two matter more than they look. Nulls in structural fields are what actually break downstream reporting, and they are invisible in a row count.

Make the load idempotent before you make it fast

Migration runs fail partway. A vendor gateway times out at record 600. Someone re-runs the job. If the load is not idempotent, you now have 600 duplicated employees and a cleanup project considerably nastier than the migration itself.

Every upsert should carry an external ID you own, and the job should be safe to run twice against the same dataset. Test that explicitly: run a full load into a sandbox, run it again, assert the record count is unchanged. It is a short test that prevents the most common migration disaster there is.

HR data is the most sensitive data you will touch

Salaries, health information, leave reasons, disciplinary records, immigration status, bank details. Handle it accordingly:

no production HR data in staging or local environments
no employee records in logs, error messages or support tickets — log the surrogate key, not the payload
redaction before anything reaches third-party observability tooling
a retention and deletion path defined before you load, not after someone files a request

If a script dumps a full employee payload to stdout on failure, that payload is now sitting in CI logs with a longer retention period than the HR system has.

The order worth running it in

Freeze the source data, or snapshot it with an explicit as-of date.
Model the target's effective-dated fields first, before writing any load code.
Generate and persist your own surrogate keys.
Build an idempotent load, and prove it by running it twice.
Reconcile on finance-verifiable aggregates, not row counts.
Run a parallel or dual-write window before the hard cutover.
Only then automate webhooks and ongoing sync.

Steps 1 through 6 are data engineering. Step 7 is the part every team staffs for.

The API is not where HRIS migrations go wrong. The data model is: temporal records, ambiguous identity, and derived values that should never have been imported in the first place. Get those three right and the integration really is the easy part.

If you are scoping the other half of this — vendor selection, change management, training and the go-live sequence — the full walkthrough lives here: HR software implementation guide.

60% of my keyword list wasn't real. Here's the filter that fixed it.

孙永瑞 — Thu, 24 Sep 2026 14:42:58 +0000

I exported 4,122 queries from Search Console across five sites and nearly built a content plan around all of them.

Then I looked at the impression counts.

The noise

On two of the sites, 57–60% of queries had two impressions or fewer over three months. Hundreds of them showed exactly one.

Those aren't keywords. Nobody is searching for them in any meaningful volume — they're artifacts of Google showing a page once or twice, or long-tail phrasings that appeared a single time.

Treating them as keywords is worse than useless: it makes you write content for demand that doesn't exist.

The filter I use now

Three or more impressions before a query counts. Two or fewer, it goes in a separate bucket labelled "noise" and gets ignored for planning purposes.

That one number cut my working list by more than half, and what remained was actually worth writing for.

The second filter

Of what's left, I only act on queries ranking 21 to 60.

Below 21: already competitive, needs links and authority, not another article
Above 60: too far to close with on-page work alone
21–60: close enough that internal links and page improvements can actually move it

Combined, those two filters turned 4,122 queries into a few hundred actionable ones.

Why the raw export misleads you

Search Console is a log of what happened, not a list of what people want. It will faithfully record every single-impression phrase your pages matched, and present it to you in the same table as a term with 2,925 impressions. The spreadsheet doesn't rank them by importance — you have to.

Free diagnosis if you want help reading your own export: https://yongrui-services.pages.dev/

The HTML used a CSS class that was never defined. Three of them, actually.

孙永瑞 — Wed, 23 Sep 2026 13:24:57 +0000

Three separate visual bugs on my sites had the same cause: the HTML referenced a CSS class that didn't exist in any stylesheet.

No build error. No console warning. The markup was completely valid. The class just did nothing.

The three

1. .hero-visual — used on the homepage to center and constrain the hero image. Never defined. The image rendered at full width, uncentered, with no rounded corners.

2. .card-thumb — used on card thumbnails. Also never defined. One card had a portrait image (798×942) next to landscape ones (1192×941), so it stretched taller and the whole row looked broken.

3. Styles written after the closing </style> tag. During a redesign, about 460 characters of CSS got appended past the closing tag — including the rule that centered the hero image. The browser rendered it as body text. So the fix for bug 1 was sitting on the page as visible text instead of being applied.

Why nothing caught it

My pre-deploy check validated content, structured data, affiliate compliance, image alt text, and that CSS files return 200. All green.

What it didn't check: whether a class used in HTML is actually defined anywhere. A missing definition isn't an error — it's a no-op. Validators don't flag it.

The two checks I added

CSS outside <style> — look for { appearing right after a closing tag
Undefined classes — extract class names from HTML, confirm each is defined in a stylesheet

Both are cheap. Both would have caught this in seconds.

The third thing isn't automatable, and it's the one that actually matters: open the page and look at it after every deploy. Ten seconds. It would have caught all three.

If you want a second pair of eyes on your site: https://yongrui-services.pages.dev/

Your LLM API Key Is a Production Credential. Start Treating It Like One.

孙永瑞 — Tue, 22 Sep 2026 14:04:00 +0000

Every team I have watched handle an LLM key leak made the same category error, and it has nothing to do with carelessness. They filed the API key under configuration — a string you paste into a settings panel — instead of under credentials. Configuration gets committed, copied into a Notion doc, and pasted into a Slack thread. Credentials get a rotation policy.

That distinction is the whole problem. An OpenAI or Anthropic key is a bearer token: whoever holds it is you, for as long as it lives, with no second factor and no per-request verification. The blast radius is not data exfiltration. It is your invoice.

Why LLM keys leak more easily than database passwords

A database password tends to be protected by network topology. The database is in a VPC, the app server is in the VPC, and a stolen string is useless unless the attacker is also inside. LLM API keys are called over the public internet from anywhere, which means the string alone is sufficient. There is no network layer to fall back on.

Three properties make them worse than a typical SaaS key:

They are long-lived by default. Nothing forces expiry. A key minted during a hackathon in March is still valid in September.
Spend is the abuse signal, and it lags. Most teams look at usage monthly. By the time a spike is visible on a statement, the attacker has had weeks.
Attribution is hard. A shared OPENAI_API_KEY in a team workspace means a spike could be any of eleven services, and nobody can prove which one.

There is also a resale market, which is what makes this worth an attacker's time. Paid model access gets resold as cheap API capacity. The buyer runs a real workload; you pay the bill.

The five places these keys actually end up

This is not a theoretical list. These are the paths that show up over and over in post-incident writeups.

1. Git history after a "quick fix." Someone commits .env, a scanner flags it, they add .env to .gitignore and push again. The blob is still in the object database, and every fork and clone still has it. Deleting a file in a new commit does not delete it from history.

2. Client-side bundles. Any variable prefixed for client exposure — NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_ — is compiled into JavaScript that ships to the browser. If a server-side key ends up behind one of those prefixes, it is public the moment you deploy. The build succeeds. Nothing warns you.

3. CI logs and artifacts. A debug echo $OPENAI_API_KEY in a workflow, or an uploaded jest output directory that captured the environment. CI logs are often readable by far more people than production secrets are.

4. Docker image layers. COPY . . before RUN that needs the key, or an ARG baked into the final stage. Anyone who can pull the image can read it, including anyone downstream of a registry misconfiguration.

5. The new one: agent config files. MCP server configs, .cursorrules side files, local agent runner settings. These are plain JSON on disk, usually outside the repo, usually not covered by whatever secret scanning you run against the repo. Info-stealer malware enumerates exactly these locations because they are high-yield and unguarded.

The audit

Six checks, roughly in order of value per minute spent.

Scan history, not just HEAD. gitleaks detect or trufflehog git file://. against the full history, including all branches. Run it in CI on every push so a new leak fails the build rather than surfacing nine months later.

Grep your build output. After a production build, search dist/, .next/, or your static bundle for your providers' key prefixes (sk-, sk-ant-). If one appears, you have shipped a credential. This takes under a minute and catches the entire class of prefix mistakes.

Separate keys per environment, with hard spend caps. One key per environment, one per service if you can. Most providers now let you set a monthly spend limit per key — check your provider's docs for the current mechanism, because these features change quickly. A per-key cap converts "unlimited liability" into "worst case is $50 and the key stops working."

Baseline your spend. Record tokens and cost per key per day. You do not need sophisticated anomaly detection; you need to know what normal looks like so a 4x day is visible the next morning instead of on the invoice. Alert on new models being called and on unusual request volume outside your working hours.

Audit the key list by hand, quarterly. Every provider console has a key list with a creation date and last-used date. Anything with no recent legitimate use gets revoked. This is boring and it is the single highest-yield check on the list.

Write the rotation runbook before you need it. Rotation is an order-of-operations problem, and the order is counterintuitive.

Rotation order: revoke the key first

When access is compromised, the instinct is to change the password. For credential theft, that is close to useless. Active sessions and issued API keys survive a password reset unless you revoke them explicitly, and in some publicly reported account takeovers the attacker had also minted additional API keys under the victim's account — so access persisted through every password change.

The correct order:

Revoke the exposed key (or all keys) in the provider console.
Revoke active sessions and OAuth grants, not just the password.
Delete any key you do not recognise, including ones created under your account by someone else.
Rotate the password last, and enable 2FA if it was not on.
Mint a replacement with a spend cap and a narrower scope than the one you just killed.
Go back and find the leak path, or you will be doing this again in a month.

Step 6 is the one teams skip. Revocation stops the bleeding; it does not close the wound.

If you only have twenty minutes

Do the build-output grep, set a spend cap on every key, and turn on secret scanning for the repo. That covers the two most common leak paths and converts the worst-case outcome from an open-ended bill into a bounded one.

The mental model shift is the part that sticks, though: an LLM API key is a production credential with a credit card attached. It belongs in the same rotation policy as your database password, not in a .env file someone pasted into a chat window.

I wrote a longer version of this focused on the subscription side — how to tell whether a paid AI account is being used by someone else, and what the usage data can and cannot tell you — over on Toolkit Creators.

11 articles were missing from my sitemap and Google never told me

孙永瑞 — Tue, 22 Sep 2026 13:03:37 +0000

One of my sites had 81 pages indexed and 53 not. I spent a day assuming the sitemap was broken.

It wasn't broken. It was incomplete — and that's a much quieter failure.

The difference matters

A broken sitemap gives you errors. An incomplete one gives you nothing: no warning, no error, just pages that quietly never get discovered. Search Console will happily show you "not indexed" without ever mentioning that you never submitted the URL.

How I found it

I did the least clever thing possible — I diffed two lists:

Every URL Google knew about (pulled from the index report, with rows-per-page set to 500 so I actually saw all of them)
Every URL in my sitemap

Anything in the second list but not the first is a candidate. Anything in neither is invisible.

Eleven articles were in neither. One of them was the landing page for a keyword cluster pulling 30 impressions a month — I'd spent time optimizing content for a page Google had never been told existed.

Why it happened

Those eleven were added after the last time the sitemap was regenerated. Nobody refreshed it. The sitemap wasn't wrong when it was written; it was just stale.

What I changed

Regenerating the sitemap from the actual file list, not from memory. And a check that compares sitemap contents against files on disk — because "the sitemap exists and returns 200" is not the same as "the sitemap is complete."

Both of those are true statements about a sitemap that's missing eleven pages.

Free diagnosis if you want me to look at yours: https://yongrui-services.pages.dev/

69,000 impressions, 5 clicks. Here's what a 0.04% CTR actually means.

孙永瑞 — Mon, 21 Sep 2026 15:31:24 +0000

My five sites got 68,921 impressions and 5 clicks over three months. That's a 0.04% click-through rate.

My first reaction was "the content must be bad." The data said something else.

Impressions without clicks means page 7

Average position across the sites: 65 to 77.

Google was showing my pages. People weren't clicking because they never scrolled far enough to see them. The content wasn't invisible — it was ranked where nobody looks.

That distinction matters, because the fixes are different. Bad content needs rewriting. Page-7 content needs authority and links.

Half my keyword list wasn't real

On two sites, 57–60% of "keywords" had two impressions or fewer across three months. That's not search demand, that's log noise. I nearly built a content plan around numbers that meant nothing.

Filter used now: three or more impressions before a query counts as a keyword.

The biggest finding was an absence

One cluster of six phrasing variants ("marketing automation software", "...tools", "...platform" and so on) accounted for 2,925 impressions. It ranked 83–91.

The page existed. It was complete. Nothing pointed at it — so Google treated it as an orphan page with no reason to rank it.

What I'd tell anyone staring at the same numbers

Impressions are not progress. They're a signal that Google knows you exist. Clicks are the only part that turns into money, and clicks come from position.

Check average position before you touch a single word of content. If it's past 30, you don't have a content problem yet.

Site builds and SEO diagnostics, if you want help reading your own numbers: https://yongrui-services.pages.dev/

My 60-point pre-deploy check passed. The homepage was still broken.

孙永瑞 — Mon, 21 Sep 2026 15:27:45 +0000

I have a 60-point pre-deploy check. It validates content structure, FAQ coverage, schema markup, affiliate link compliance, image alt text, OG tags, CSS references.

Every site passed all 60 points.

Then someone opened the homepage and found raw CSS rendering as visible text at the top of it.

What was actually broken

Four separate visual bugs, all invisible to my checks:

Raw CSS as body text. A </style> tag closed early, so ~460 characters of stylesheet sat outside it — displayed as text instead of applied. This included the rule that centered the hero image, which is why the hero image wasn't centered.
A CSS class with no definition. The homepage used .hero-visual, but that class wasn't in the stylesheet at all. The image had no width constraint and no centering.
Another class with no definition. Card thumbnails used .card-thumb, also undefined — so a portrait image (798×942) stretched its card taller than the landscape ones next to it. The row looked broken.
Stale CSS cache. Fixing the stylesheet did nothing until I bumped the version parameter in the <link> tag.

The pattern

Three of the four are the same mistake: the HTML uses a class, the CSS never defines it. Typo, incomplete copy-paste during a redesign, a code block pasted past the closing tag. All of it renders fine as far as a validator is concerned — the markup is valid, the class just does nothing.

What I changed

A check for CSS sitting outside <style> tags (looks for { immediately after a closing tag)
A check that every class used in HTML is actually defined somewhere in the CSS
And the one that mattered most: open the page after every deploy.

That last one isn't automatable in a useful way — and it would have caught all four bugs in about ten seconds.

I do site builds and SEO diagnostics if you want a second pair of eyes: https://yongrui-services.pages.dev/