Landing page optimization checklist: start here

Optimizing a live page usually means a burst of edits. Someone rewrites the headline, moves the form, changes the button color and swaps a photo, all in one afternoon. If results move the next week, nobody can say which edit caused it, and the one that helped can be reverted along with the one that hurt. A checklist asking for one change per run solves this, but only if each change is paired with a record of where visitors stopped before it. Without that record, the owner remembers the page as it was on the day they liked it.

• A baseline run exists before the first edit, with the stopping step and a screenshot.
• Stops are ranked from the top of the path down, so the first screen is fixed first.
• Each run changes one thing, and the log names that change in a few words.
• Tracking that reads a button's label or position still fires after the change.
• Each fix is followed by a full run from the first screen, not only the step changed.

Before any change, run a set of first-time visitors through the path and write down the step where each one stopped, with a screenshot of that step. Three lines per visitor are enough: the step, the reason the visitor gave, and what the screen showed. This is the baseline. A baseline that only says three of five left is useless, because you cannot tell which step they left at, or why. Keep the screenshots, since your memory of the page will drift within a day. The baseline is also what you compare against after the edit, so write it before the first change, not after.

Why visitors leave

Order the stops by how far each one cuts the path. A stop on the first screen cuts everything after it, so it comes before a stop near the bottom of the page. A wrong order is to polish the headline while the form rejects valid postal codes. A right order is to fix the form first, because every visitor who meets the form is lost before the headline matters. Work from the top of the path down, and stop when the next stop is one you cannot fix this week. Then write down what is left, so the list survives the week.

A run is one change, followed by the same visitors through the same path. Name the change in your log in a few words, such as moved price range above form. Do not bundle a button label with a new photo, because a visitor who now gets further will not tell you which change did it. If the change is a label or a position, check that any tracking event that reads the old label still fires. Analytics that counted a click on the old button can go quiet after a rename, and a quiet count looks like a drop in visitors.

A run tells you whether a visitor got further on the path. It does not tell you whether the page sells more, whether a change lifted anything in real traffic, or whether a difference of a few visitors is noise. For those, use a live experiment or your analytics once real visitors arrive. Use the runs to find the stop, fix it, and confirm the stop moved. Then move to the next stop on the list.

A log of fixes is only useful if the next redesign reads it. A new template, a new form tool or a seasonal banner can bring back a stop you already fixed. Run the same visitors through the path after each of those, and compare each stop with your log. Each preview copy can be run against the same log before the link goes to the team.