Check It Before It Costs You a Customer: A Pre-Launch Page Check
The five-second stranger test
Show the page to someone who has not seen it. Ask what it sells and who it is for. If they cannot say, the headline and the first screen need work, not the rest of the page.
Your own eyes miss what you already know. One stranger who looks like your buyer is worth ten rereads by you.
A phone check that goes past a glance
Open the page on your own phone, on mobile data, not wifi. Read it. Tap every button. Then run the four checks most people skip:
1. Zoom to 200%. Does anything overlap, disappear or force sideways scrolling? The WCAG 2.2 baseline expects text to survive 200% resizing without losing content or function.
2. Put the phone down; try a keyboard. On a laptop, tab through the page with no mouse. Can you reach the buy button, and can you see where you are? WCAG expects everything to work by keyboard, with a visible focus indicator.
3. Check contrast in daylight. Pale text that looked stylish at midnight can be unreadable at noon. The WCAG minimum for ordinary text is a 4.5:1 contrast ratio (3:1 for large text).
4. Trigger an error on purpose. Enter a bad card number in your test checkout or leave a required form field empty. Does the page say what went wrong and what to do next - or does it just sit there?
Borrowed from the professionals: these four checks come from the same accessibility basics (WCAG 2.2) that auditors use. Sources are linked at the end of this guide.
Spot it first: one flawed mobile view
One flawed mobile view. What do you fix first?
A candle shop page, one hour before launch (fictional). On the phone: a large photo loads slowly, the buy button jumps down the screen as the photo arrives, the text under the photo is pale gray, and the shop name at the top is still the template default.
Practice choices stay in this open page only. Nothing is sent or saved.
Write findings as audit lines, not worries
"I should fix some things" cannot be finished. An audit line can. One fictional example (an illustration, not a real shop): Maya's candle page looks done on her laptop. On her phone, the buy button sits under a photo that loads late, so the button jumps as she goes to tap it.
Watch: the pre-launch check worked end to end on a fictional shop - desktop and phone, one broken link, one unreadable section, one delivery path.
The audit line for that finding: Check: phone layout, buy button. Result: FAIL. Severity: could lose a sale - the button moves at tap time. Owner: Maya (template fix). Evidence: phone screen recording, 6:12 pm, mobile data. Retest: reload three times and tap the button each time without it moving.
Six short fields per finding: check, result, severity, owner, evidence, retest. Severity sorts the work into three piles - could lose a sale, could hurt trust, can wait. Fix the first two before launch. Date the third and come back to it.
Test the full purchase path - and the way back
Run a test purchase from the first click to the delivery email. Check the price at checkout matches the page. Check the confirmation, the delivery message and the access link. A page that looks great and cannot take payment is not ready.
Then check the three routes buyers need when something goes wrong:
1. Refund route. Your refund terms exist, are easy to find, and say what a buyer should do.
2. Contact route. A real way to reach you, tested - send yourself a message and confirm it arrives.
3. Access recovery. Pretend you are the buyer who paid but cannot open the file. Is there a way back in, or a person who answers? This is the message no buyer should ever have to send - but some will.
Every claim earns its place
Read every promise on the page and ask whether you can back it up. Remove results, testimonials or numbers you cannot prove. Where your content is educational, say so. A claim you cannot prove is not a sales tool; it is a debt.
A pass is not a certificate
What this check is - and is not: this audit catches common problems that cost sales and trust. Passing it does not make a business safe, legal or compliant. It is a usefulness check you run yourself, not a professional review.
How long does it take? It varies. One page with one simple product can fit in an afternoon if you test the purchase path properly. More products or a longer checkout takes longer. Plan the time the audit needs, not a fixed hour.
Run the audit on your own page
Eight checks. Mark each as you test it; anything failed gets a severity. Then write your first fix, its owner and your retest.
Your answers stay in this open page only. Copy them before closing. They are not sent or saved.
Your next step
Once your page passes, trace where the buyer goes after payment: map checkout to delivery. The same audit habit works there - evidence first, then fixes.
Sources. Accessibility references checked 24 October 2026: WCAG 2.2 quick reference, contrast minimum (4.5:1, 3:1 large text), resize text to 200% and focus visible. This guide teaches a checking method. It is not an accessibility certification, a legal review or a guarantee that a passing page is error-free.
Related reads
Join the list
New guides and drops, straight to your inbox. Double opt-in, unsubscribe any time.
Common questions
Who should check my page?
Someone who has not seen it before and who looks like your buyer. Your own eyes miss what you already know.
Do I need to check again after launch?
Yes. Re-run the purchase test after any change to the page, the checkout or the delivery email.
What if I find more than I can fix?
That is what severity is for. Launch blockers first, trust problems second, everything else dated and scheduled. A shorter honest page beats a longer broken one.