Automate Your Pre-Publish Revenue Check: Stop Leaking Conversions with Claude Code

One morning I opened my analytics and froze. The article I’d published the day before had triple my usual pageviews. And yet: zero signups for the free PDF, zero clicks on the paid course. A “we went viral and not a single cent moved” situation.

When I dug in, the cause was embarrassingly dumb. The signup button at the bottom of the article still pointed at an old product page I’d taken down six months earlier. On top of that, the English version of the article switched from English to my native language partway through the body, so overseas readers bailed right there. The writing itself was fine. I was leaking the entire funnel in the last few lines.

After that, I completely separated “the work of writing an article” from “the work of confirming it’s actually ready to publish.” If I do the second part by hand every time, I will absolutely cut corners, so I hand it to Claude Code as a fixed routine. Today I’m putting the whole thing out in copy-paste form.

Key takeaways

• When pageviews go up but signups don’t, the cause is usually a mistake you could have caught before publishing: a dead link, an old product page, or a body that’s still in the wrong language.
• Lock the pre-publish checklist to nine items and run them in the same order every time. Leaks drop off a cliff.
• What you hand to Claude Code is the mechanical part: open the page and verify each item. Which button gets to be the star is a decision you keep for yourself.
• Narrowing each article down to a single primary call-to-action stops readers from hesitating, which makes the next action far more likely.
• Logging what you checked lets you trace, later, “on what basis did I decide this was ready.”

Decide on nine things to check before publishing

“Just check it properly” makes neither a human nor an AI do anything. A check is a list of concrete items. Here are the nine I keep fixed.

#	Check	What to look at
1	Page loads	Does the server return 200 (not 404 or 500)?
2	Heading is correct	Does the top-level heading match the article title?
3	Canonical URL	Does the canonical point to this article’s own URL?
4	Hero image	Does the image render (not an old image, not missing)?
5	Body language	Is each locale written in its language from the very first line?
6	Free PDF prompt	Does the signup button exist, and is its target live?
7	Course link	Does the link go to the intended product page (not a different product)?
8	Consultation route	Does the link land on the consultation page?
9	Mobile view	Is there no horizontal scroll (nothing overflowing the screen)?

The two that bite hardest are #3 and #7. If the canonical points at your home page or a different article, search engines treat that page as the authoritative one, and the article you actually wrote gets no credit. Mislinked targets show up most in articles you built by copy-pasting a previous one.

What I delegate to the AI, and what I decide myself

Blur this line and you’ll have an accident. Let me draw it sharply.

What Claude Code handles is anything you can judge mechanically. Open the page, read the heading, fetch the link target, see whether the image renders, check the layout at mobile width. This is the part that’s tedious for a human, and tedium means you’ll skip it, so I make the AI do it every single time.

What I decide myself is anything that needs judgment. Which button is the star of this particular article. Whether the phrasing reads naturally. Whether I’m pointing at a discontinued product. And the final call: “is this article truly okay to publish?” Hand that to the AI wholesale and you’ll ship articles where every link is live but the substance is off.

My rule when I’m unsure is simple. If there’s exactly one correct answer, it’s the AI’s job; if taste or strategy is involved, it’s mine. Whether a link returns 200 has one answer, so AI. Which of three buttons to emphasize is strategy, so me.

A prompt template you can paste straight in

Here’s an instruction you can paste directly into Claude Code. Swap in your own repository name and the URLs you want checked.

For each of the following URLs, run a pre-publish check.
Verify that: the page opens with 200; the top-level heading matches
the article title; the canonical points to the same article;
the hero image renders; the body is written in that locale's language;
the free PDF signup button is live; the course link goes to the
intended product page; the consultation link is correct; and there is
no horizontal scroll at mobile width.

For each URL, report in one line, separating items that passed from
items that failed. Do not mark a URL as passing just because it
"opened with 200." For any failed item, also give your best guess at
the cause and which file I should edit to fix it.

The last two sentences are the heart of it. If you stop at “opened with 200 = OK,” you’ll miss the single most common bug: a mislinked target. Force it to report failed items separately and to name the file to fix, and you can go straight into the repair.

A pass/fail script you can run as-is

The part that gathers the check results and mechanically returns “is this okay to publish” should live in code, so it never drifts. Here’s a minimal version that runs on Node.js.

// The nine items every article must clear before publishing
const requiredChecks = [
  "page opens with 200",
  "top heading matches article title",
  "canonical points to the same article",
  "hero image renders",
  "body is written in the right language",
  "free PDF signup button is live",
  "course link goes to the intended product",
  "consultation link is correct",
  "no horizontal scroll at mobile width",
];

// Pass `passed` an array of the names of the items that passed
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "okay to publish" : "fix, then re-check",
  };
}

// Example: only the course link failed
const passed = requiredChecks.filter((c) => c !== "course link goes to the intended product");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "PUBLISH OK" : "PUBLISH NO");
console.log("failed items:", result.missing);
console.log("next action:", result.nextAction);

Run this and you’ll see PUBLISH NO, the names of the failed items, and what to do next. If even one item is missing, ok is false, so you can’t accidentally publish on a “good enough” basis. All you do is fill the passed array with the results the AI produced from the prompt above.

Three places this actually paid off

1. Days when I publish several articles On days I ship three at once, the checking gets sloppy. I open each article one at a time at mobile width and scroll past the heading, the opening of the body, and the area around the signup button. If a non-English locale still has English in the body, I stop the publish right there. The fixed list earns its keep precisely on the days I’m most likely to rush.

2. When I swap out just the button on a popular article Even when I’m only changing one bottom-of-page button on a well-read article, asking “find the related parts and fix them” is too broad. First I decide which files I may touch, which I won’t, which URLs to check, and what each link should point to. That alone turns the post-work verification from “seems fine, I guess” into “with this evidence, I can publish.”

3. Quality-checking multilingual articles Even if the article’s configured language setting is correct, the article isn’t publish-quality if the body is still in the wrong language. For each locale I look at the top heading, the opening of the body, and the area around the buttons, and check whether a reader of that language can tell what to do next. For an English reader, the free PDF description, the course pointer, and the consultation nudge all need to read naturally in English.

Common pitfalls and how to fix them

Pitfall 1: Reporting “published” just because the local build passed A successful build on your machine doesn’t guarantee the live page renders correctly. The fix is to make the target of your check “the real thing at the public URL,” not “the local build output.” Tell the AI explicitly: “open the public URL and verify.”

Pitfall 2: Lining up every signup button at once Put the free PDF, course A, course B, and consultation side by side at the same size, and the reader can’t tell which to press, so they press none. The fix is to choose one primary button per article and demote the rest to quiet, secondary links.

Pitfall 3: A link that goes to the wrong product “Free PDF” in the text but a click that lands on a paid course is rampant in copy-pasted articles. The fix is to make the AI always fetch the link target from check item 7, and to eyeball-match it all the way down to the product ID.

Pitfall 4: Making a big change with no way to undo it The worst case is rewriting a wide area right before publishing, having it break, and being unable to revert. The fix is to limit each pass to a scope where you can write down “here’s how I undo this if it’s wrong” in advance. If you can’t write the rollback, the change is too big for that pass.

FAQ

Q. Pageviews went up but signups didn’t. What do I look at first? A. Look at the signup button’s link target and the body language first. The two biggest causes are a target that’s still an old product page, and an overseas-facing locale that isn’t actually translated. Those are check items 5, 6, and 7.

Q. Do I really have to do this every time? It’s a pain. A. Every time. That’s exactly why you don’t do it by hand — you hand the prompt in this article to Claude Code and let it run mechanically. The more tedious a check is, the more reliably people skip it on busy days. And it’s always the skipped day that goes wrong.

Q. If I narrow it to one button, don’t I lose entry points to my other products? A. The number of entry points matters less than whether the reader can press one without hesitating. Line up several and they fail to choose and leave. Pick one star, and place just one or two supporting links naturally in the body. That’s the right balance.

Q. Why does the canonical URL matter so much? A. Search engines treat the page named as canonical as the authoritative one. If that points at a different article or your home page, that other page gets evaluated instead of the one you wrote, and your ranking signals pool there too.

Q. What’s the point of keeping a check log? A. So you can trace later “on what basis did I publish this.” When something breaks, it’s far easier to isolate whether the body, a button, a link, or the consultation route was where it failed. Without a log, your next run starts the verification from scratch.

Leave the check on a single page

A short note after publishing makes the next check dramatically easier. Something like this is plenty.

- article: claude-code-revenue-smoke-test
- published: 2026-06-14
- proof checked: public URL, top heading, canonical, hero image, body language, button link target
- primary button: course link (for self-driven readers)
- metrics to watch: PV, PDF signups, course clicks, consultation-page visits

When you read the numbers, don’t judge by PV alone. Line up free PDF signups, course clicks, and consultation-page visits on the same date. Then test them against a hypothesis: a beginner-facing article should grow PDF signups, while an article about configuration or permissions should grow course clicks. With this habit, daily posting shifts from “just shipping” to “a system that nudges the funnel a little better each time.”

This split between “checks you hand to a machine” and “judgment you keep for yourself” applies well beyond revenue checks. For the big picture of using Claude Code as a non-engineer, see How non-engineers can use Claude Code; for small tricks that speed up daily work, see Claude Code productivity tips. Since asking the AI to verify things correctly comes down to the precision of your prompt, advanced Claude Code prompt techniques is a useful companion read.

The mechanics that underlie having the AI read files and check links are documented in the official Claude Docs. When behavior feels like it changed, checking the primary source first is, in the end, the fastest route.

What happened when I actually tried it

I ran this routine on my own site for about two weeks. What I wanted to confirm was whether the nine-item pre-publish check really reduces leaks.

It did. Problems that used to sail through when I only checked “does the page open with 200” surfaced more than once. Specifically: two articles about to publish with another article’s hero image still attached; one with a signup button pointing at a discontinued product; and one where the English version’s body was still in my native language partway down. Every one of those would have counted as a pass on “opens with 200” alone.

The biggest win was the rule of one signup button per article. I cleaned up an article that had been lining up the free PDF, the course, and consultation at equal weight, reorganizing it around a single star — and the button’s click rate visibly went up. I felt, in the numbers, that readers move more when they have fewer choices.

The flip side I learned: this check doesn’t survive as manual work. I did it by hand for the first few days, then breezily skipped it on a busy day. Only after shaping it into a prompt plus a script, run the same way every time, did it finally stick.

Make the dull pre-publish check a system. That turned out to be the cheapest insurance for turning pageviews into revenue. If you want to build this into a company blog operation or a team’s publishing flow, I can design a routine that fits your real workflow together with you through training and consultation.