Why "increase conversions" produces nonsense
Ask a capable model to increase conversions on a page and a fair share of what comes back is a countdown timer, a fake stock warning, and a confident prediction that the change will lift revenue by some percentage.
None of that is knowledge. Two thirds of it is a compliance risk in several jurisdictions, and the prediction is not something anyone can know in advance — not the model, not a consultant, not you.
The quieter failure is more expensive. An audit that finds problems and fixes them in the same session leaves a diff across thirty files, no report, and no way to tell which finding was real. Six weeks later the number has moved and nobody can say which of the thirty changes did it. So you cannot repeat it, and you cannot undo the one that hurt.
If the site is not built yet, this is premature — building it properly comes first, and getting it found comes before optimising what happens once people arrive.
Conversion work has an evidence problem before it has an ideas problem. Almost everyone has more ideas than they can test. Very few can say which of last quarter's changes worked.
Separate the four modes
The single most useful constraint is to decide, before the session starts, which of four things you are doing — and to say so in the prompt.
| Mode | What it may do | What it produces |
|---|---|---|
| Audit | Read. Change nothing at all. | Findings with evidence |
| Plan | Read, and rank what was found. | An ordered list with reasons |
| Implement | Change one agreed thing. | A diff and a way to check it |
| Validate | Measure what happened. | A verdict, including "cannot tell" |
The boundary that matters is the first one. Put it in the prompt in these words, or something close to them:
This session is an AUDIT. It changes nothing. Do not edit, create or delete any file. Do not open a pull request. Produce findings. If you believe something must be fixed immediately, say so and stop. An audit whose fixes land in the same run leaves a diff and no report, and afterwards nobody can tell which finding was real.
The reason this constraint has to be explicit is that being helpful is the default. Left to itself, a session that finds a broken form will fix the broken form, and it will be right to — but you will have lost the record of what was wrong, which is the thing you were trying to produce.
Measure: check the number before you chase it
Before diagnosing anything, establish that the number you are about to spend weeks moving is real.
Answer two questions about your conversion rate. What counts as a conversion, and what is the denominator — sessions, users, or something else? If you cannot answer both from memory, that is the first job, and it is not a formality: a meaningful share of "conversion rate" changes are actually changes to how it is counted.
Then verify the event fires, and fires once. A purchase event that fires twice makes every number in the funnel wrong in the same direction, which is exactly the kind of wrong that never looks unusual. Nothing in the report is worth reading if this step was skipped.
Before any analysis, verify the measurement itself. For each conversion event: where is it fired from, on which pages, and under what conditions? Load the page and confirm it fires exactly once. Report any event that fires zero times or more than once, and stop the analysis if the primary conversion event is among them. Report what you observed, not what the code appears to intend.
The Search Console workflow is the equivalent step on the traffic side: knowing whether the visitors arriving are the ones the page was written for.
Diagnose: find where people stop
Map the funnel before auditing any single page. A page audit tells you what is wrong with a page; a funnel tells you whether that page matters.
The order that works:
- List the steps a visitor must complete, in order, from arrival to conversion. Write them down even when they seem obvious — the writing is where the missing step usually appears.
- Attach a number to each step. If a step has no number, that is a finding in itself: you cannot diagnose a funnel you cannot see.
- Find the largest proportional drop, not the largest absolute one. A step that loses 60% of a small number is often a better target than one losing 20% of a large one, because the mechanism is usually more specific and easier to fix.
- Segment by device before concluding anything. A funnel that looks mediocre overall is frequently fine on desktop and broken on mobile, and the average hides it completely.
Only then open the page that owns the worst step.
Label every finding by what you actually know
This is the part that separates a usable report from a confident guess, and it costs one line per finding.
| Label | Means | Needs a test? |
|---|---|---|
| Proven problem | You reproduced it. A form that drops submissions, an event that never fires, a control unreachable by keyboard. | No. Fix it. |
| Strong heuristic | Well-evidenced practice with a clear mechanism, observed here. Not proof of a lift on this site. | Usually not worth one |
| Experiment opportunity | Plausible, genuinely unknown, and worth testing if you have the traffic. | Yes, if you can power it |
| Insufficient data | You do not know. Saying so is the finding. | Get the data first |
The fourth label earns its place. Most conversion reports have no way to say "I don't know", so everything gets written up as though it were known, and the reader cannot tell the reproduced bug from the hunch. Once the labels exist, the report sorts itself: proven problems get fixed this week, and nothing else competes with them for attention.
Prioritise: impact and confidence over effort
Rank by impact × confidence ÷ effort, scoring each from 1 to 5, rather than by how annoying each finding is.
Confidence is doing the real work in that formula. It is what stops a plausible-sounding redesign of the hero outranking a form that silently drops one submission in twenty. The redesign might be worth more; you do not know that it is, and the form is a certainty.
Two overrides worth keeping:
- Anything that loses data or money goes first, whatever it scores. A form dropping submissions is not a prioritisation question.
- Anything with a legal or accessibility dimension goes early. A checkout step that cannot be completed by keyboard is not a conversion optimisation, it is a defect with an exposure attached.
Change: one concern at a time
Implementation is a separate session with a separate instruction, and the reason is measurement rather than tidiness. Six changes shipped together produce one number, and the number tells you nothing about which of the six caused it.
Where volume forces batching — and on a small site it usually does — say so explicitly in the record: "these five shipped together on this date; the change in the number cannot be attributed to any one of them." That sentence is worth more than a false attribution.
Validate, or admit you cannot
An A/B test needs enough traffic to detect the size of effect you care about. If it does not have that, it does not return "no result" — it returns a number, and the number is noise wearing a decimal point.
Work it out before building the variant. At a 2% baseline, detecting a 10% relative improvement needs roughly 30,000 visitors per arm for a conventionally powered test. At 500 visitors a week that is well over a year, by which point seasonality has eaten the result.
So the honest output is often do not test this. Ship the change on the strength of the reasoning, write down what you expected, and check the trend later. Or fix the proven problems first, which need no test at all — a form that silently drops submissions is not a hypothesis.
A workflow that cannot produce the answer "you do not have the traffic to know" will instead produce a confident wrong answer, which is worse than silence.
The prompts for each of these stages, written out and organised by stage rather than by page type, are in the CRO prompt collection. If the page you are auditing is a landing page specifically, the landing page audit covers message match and the measured fold, which do not apply to a product page in the same way.
What never belongs in the output
Some of this is ethics and some is straightforwardly illegal in the EU, the UK and a growing number of US states. All of it is worth forbidding in the prompt, because it is what a model reaches for when asked to increase conversions without constraints:
- Countdown timers that reset, and urgency that is not real
- Stock or scarcity messages not tied to actual stock
- Invented customer numbers, testimonials or reviews
- Confirmshaming — "No thanks, I don't like saving money"
- Preselected paid options, and cancellation flows harder than signup
- Button labels that misdescribe what the button does
- Any predicted percentage lift, from anyone, in advance
That last one is the one people argue about. The argument against it is simple: if the number could be known in advance, there would be no reason to run the experiment.
Where to start on a real site
In this order, and no further until each is done:
- Verify the conversion event fires exactly once.
- Map the funnel and attach a number to every step.
- Audit the page owning the worst proportional drop, in audit mode, changing nothing.
- Label every finding, and fix only the proven problems.
- Work out whether you can power a test. If you cannot, say so in writing and stop pretending otherwise.
Most sites find enough proven problems in step four to keep them busy for a month, and shipping those requires no experiment and no argument. If you want the version that also covers accessibility on the conversion path, the accessibility audit workflow overlaps here more than people expect — a control that cannot be operated is a conversion problem before it is a compliance one.