A landing page launch checklist you can actually test
Check your landing page as a visitor: open the right URL, use it on a phone, complete its main action, and confirm the enquiry reaches its destination.
In this guide
Before sharing a landing page, follow its main action all the way to the result. A button that looks right and a form that says “Thank you” are only part of the check. If the page promises to send you an enquiry, find that enquiry where you will actually handle it.
Use this checklist on a page you have already built. Have its intended public URL, permission to submit a test, access to the form’s destination, and a phone if available. You do not need to purchase a testing tool or change builders.
For the checks below, use an enquiry marked LAUNCH-01 and an email address you control. Do not use a customer’s information. If your page’s main action is a booking, download or purchase instead, check that promised result using the product’s authorized test mode. Do not place a real order just to tick a box.
1. Open the address a visitor will receive
Copy the intended URL into a private browser window, where you are not signed in to your site builder. Confirm that the correct page opens over HTTPS without a certificate warning. A private preview that only works in your editor account does not pass this check.
Check the address after the page finishes loading. Is it the address you intend to share? If you use a custom domain, try both the bare domain and www; an unwanted version should lead visitors to the intended page, not a parked domain or old draft.
Write down the final URL. Use that same version for the remaining checks so you do not accidentally test the editor preview instead.
2. Read the page without filling in the gaps yourself
Look at the opening screen and answer three questions: What is being offered? Who is it for? What should the visitor do next?
Check the details someone needs before acting: the service area, what’s included, any stated price or availability, and how they will hear back. Delete template text and promises you cannot meet. Open each main link and confirm that its destination matches its label—including contact, booking, download and privacy links where applicable.
For a page offering one service, a clearly labeled action such as Request a repair quote gives the visitor more information than Submit. The purpose is clarity, not adding more buttons.
3. Complete the page on a narrow screen
On your phone, open the same URL from step 1. Read the page, open any menu and reach the main action. Text should be readable without pinching to zoom, and controls should not sit off the side of the screen or underneath another element.
If a phone is unavailable, Chrome’s device toolbar can simulate a narrow viewport: open DevTools, turn on the device toolbar and choose a phone size. This helps find layout problems; it does not reproduce every real device or mobile keyboard.
On a desktop, also use Tab to move through links and fields, Shift+Tab to go back, and Enter to activate a focused link or button. You should be able to see where focus is and complete the main action without a mouse. Increase browser zoom to 200% and check that essential content and controls remain available. These are useful first checks, not a complete accessibility audit.
4. Try the form’s ordinary mistakes
Before a valid submission, try the two mistakes a real visitor is likely to make:
| Test | What should happen |
|---|---|
| Submit with a required field empty | The page identifies what needs attention and lets you correct it |
Enter not-an-email in an email field |
The page requests an email address instead of reporting success |
| Correct the input and continue | Previously entered valid information is retained where practical; you can reach the next step |
If the page accepts an invalid address and later loses the enquiry, a success message is misleading. Browser validation helps people correct input, but your form service must also validate what it receives. Do not switch validation off to make the test pass.
5. Send one valid test and find its result
Fill the form with synthetic details, your controlled email address and LAUNCH-01 in the message. Submit once and note the time.
First check the visitor’s result: the page should make it clear whether the enquiry was accepted and what happens next. It should not expose another person’s information or leave you wondering whether to press the button again.
Then open the place where you expect to handle enquiries—the form dashboard, CRM or destination inbox. Find LAUNCH-01 and compare its fields with what you entered. If email notification is how you discover new enquiries, confirm the actual notification arrives too. A stored entry with no notification may still leave the business unaware of it.
If the entry is missing, leave the checklist item open. Check the form’s configured destination, submission history and any delivery error. If the entry exists but the email is missing, check the recipient address, spam folder and the provider’s delivery status. Do not ask visitors to submit repeatedly while you investigate.
Where the page promises a confirmation email, check that message in your controlled inbox and open its intended link. A confirmation promised to the visitor is part of the result, not an optional extra.
6. Record a launch decision
Keep a short record you can repeat after the next edit:
| Check | Result to record |
|---|---|
| Public address | Final HTTPS URL; opens while signed out |
| Links and copy | Main action and destinations match the offer |
| Narrow screen and keyboard | Main action remains usable |
| Empty and invalid form input | Helpful correction; no false success |
| Valid test | Test label, time, stored enquiry and required messages received |
Use pass, needs a fix, or not checked, not a single overall tick. Fix a broken main action or missing enquiry before driving visitors to the page, then repeat the affected test. Keep the previous working version available through your builder or hosting service’s supported recovery method.
If you intend the page to appear in search, check your builder’s search-visibility setting before launch. A noindex instruction asks search engines not to include the page; removing it is a deliberate publication decision and does not guarantee indexing. A private campaign or review page may correctly stay out of search.
You are finished when a visitor can open the intended page, understand the offer, complete the action and receive the promised result—and you have checked the corresponding result on your side. That is more useful than a long checklist full of unchecked assumptions.
If the custom domain is the part that is not ready, start with DNS records explained to prepare the website change while protecting existing email.
Sources and useful links
- W3C’s first accessibility checks — a starting point for keyboard, form and page checks, with links to deeper evaluation.
- MDN: form validation — the difference between helping a visitor correct input and checking it on the server.
- Chrome’s mobile viewport tools — how to inspect a narrow layout and what emulation cannot establish.
- Google’s noindex documentation — how a page’s indexing instruction differs from simply being available online.