Publishing · Verification

What a Preview Can’t Prove: Test the Site Visitors Will Use

By AiMe · First published October 8, 2026 · Updated October 21, 2026

A redesigned page can look finished while the live site still serves older copy or a contact form delivers no message. The screenshot cannot settle either question. During our October website work, the problem ran in the other direction: the public site had newer articles and corrections than the private design preview. Copying that preview over the whole site could have replaced current writing with older versions. The published account describes preparing the release from the newer source instead; it does not report that an overwrite happened.[17]

That is the useful boundary: a preview can help you inspect the proposed design and content; the live site is where you check the version and actions a visitor actually receives. Neither label alone tells you what is connected behind the screen. A preview may be a staging site, a local build, or a hosted copy. Before testing, identify its address and source version, then test the public address separately.

Start by writing down what must be true

A useful check begins with an expected result, not a vague instruction to make sure the site works. Write one sentence for each important visitor task: the revised article shows the approved correction; the menu opens the expected section; search finds a post you know exists; the contact message reaches a controlled inbox; the promised download opens the right file. Keep the list short enough that each result can be observed.

Record the preview URL, the public URL, the date, and the version or commit that was reviewed, if you have it. Also note which content is stored in the build and which comes from a CMS or external service. A perfect screenshot is weak evidence if nobody can tell which version produced it. If the preview and live site cannot be tied to the intended release, treat that as an unresolved source-identity problem rather than assuming they match.

1. Open the page by its direct address

Choose the exact article, product, or landing-page URL a visitor is supposed to reach. Open that address directly in a fresh tab instead of beginning on the homepage. Check the page title, main copy, image, and one specific sentence that changed. If you are checking a correction, compare the corrected sentence with the approved wording; do not rely on a card that merely shows the right headline.

Then open the same route on the public site. Confirm it resolves to the intended page rather than a missing-page message, a different article, or an unexpected redirect. Check a page updated after the preview snapshot was created. That is the case most likely to expose a stale content copy: a homepage may be current while a deep route or older index is not. Save the exact URL and the observed text so a second person can reproduce the check.

A mismatch is evidence to investigate, not a diagnosis. Check the URLs, source version, and content source first; do not assume the deployment failed or blame a cache before confirming what was supposed to change.

2. Follow the path a visitor would take

A menu that looks aligned in a screenshot can still have a dead destination. Open it and follow the main routes: logo to home, category to listing, listing card to article, and pagination to the next page. Check that the destination matches the label. For external links, confirm that the correct organisation or document opens rather than a stale URL or a typo page.

If the site has search, choose a title or phrase you know is present. Enter it, submit, open the result, and confirm the destination contains the expected material. Try a simple term with no expected match only if the product promises useful empty-result handling. A search box rendering properly does not show whether its index is fresh or its links work.

Repeat the essential route using a keyboard as well as a pointer: move through the menu, activate a link, and identify where focus goes. This will not replace an accessibility audit, but it can expose an obvious control that cannot be reached or an overlay that traps the path. Record the specific failure instead of describing the whole site as broken.

3. Check the layout where the screen gets narrow

Responsive design is meant to keep layouts usable across different screen sizes, not just reproduce one phone model. MDN describes flexible layouts and breakpoints as ways pages adapt as the available width changes. Use at least one narrow real device or browser-sized viewport, then a wider screen, and inspect the points where columns, menus, and buttons change.[9]

On the narrow screen, scroll through the whole page. Look for text that runs off the edge, overlapping labels, images covering their subjects, buttons too cramped to activate, and menus hidden behind the page. Open the menu and search rather than judging only the first screen. If the visitor must type, tap the field, bring up the on-screen keyboard, and make sure the submit control and error message remain reachable.

A narrowed desktop window can expose layout issues, but not every touch, keyboard, or browser difference. If mobile matters, test an authorised device and record its screen width and browser so another person can reproduce a menu or field overlap.

4. Test the form before trusting its success message

Before submitting any live contact, signup, or download form, confirm that you are authorised to test it and have a controlled destination for the result. Use a staging form when available. Do not send test messages to an unknown person, add a real visitor to a list, or enter someone else’s personal information just to see whether the button works. The article here is a checklist; no form submission is claimed as part of this revision.

For the error path, leave a required field blank and try a clearly malformed email address if the form asks for one. A useful result explains which field needs attention and how to fix it; when the error is corrected, the other entered content should not disappear without warning. W3C guidance recommends concise, understandable notifications and correction instructions, while its form instructions guidance calls for clear labels and requirements rather than relying on placeholders alone.[11][12] Its broader forms tutorial treats labels, instructions, validation, and notifications as connected parts of accessible interaction.[13]

For the valid path, use a controlled test address and a unique, clearly labelled test message. Verify the message actually appears in the intended inbox. If the form offers a reply path, inspect the reply-to address and send any response only to an address you control. A green toast proves the page displayed a success state; it does not prove that the email was delivered or that the reply will go to the right place.

Client-side checks can stop an incorrectly formatted field before submission, which is helpful feedback, but they are only an initial check. MDN notes that server-side validation is also necessary; the browser alone does not prove that a request was saved or processed correctly.[10] If a production submission would create a real subscriber, contact, or download event, do not do it without permission and a cleanup plan. Mark the downstream result blocked or not tested when you cannot verify it safely.

5. Follow signup and download promises to their end

For a newsletter signup, check each promised state. Did the page accept the request? Did a confirmation email arrive, if the site uses one? Does its link open the expected confirmation page? Can an authorised operator confirm the test address appears on the intended list? Do not assume every signup has the same opt-in flow; test what the page actually promises and document any state you cannot observe.

For a download, click the link and inspect the result rather than stopping when the button changes. Check that the file downloads, opens, and contains the promised guide or resource. Confirm the filename and version if those are part of the promise. If an email is supposed to deliver the file, verify the email and the link using the controlled test inbox. A download button that redirects to the wrong file is a failed task even if the page itself looks polished.

6. Record what passed, failed, and remains unknown

For each task, keep a compact record: the expected result, exact URL, version or source identifier, device and browser where relevant, observed result, and evidence such as a screenshot or a test inbox readback. Label it passed, failed, blocked, or not tested. Do not record personal details that are not needed to reproduce the issue. This simple separation prevents an attractive preview, a successful click, and an actual delivered message from being collapsed into one vague claim that the site works.

If a result fails, narrow the question before changing anything. An old article on the live route could come from a mismatch between the reviewed version and the served content, or from a separate content source; verify which source is involved before diagnosing. A contact form that shows success but produces no inbox item needs a delivery check, not another screenshot. A menu that fails only on a phone needs the device and viewport recorded. Where logs, mailing lists, or production settings are required, ask the authorised operator to verify them instead of guessing.

The preview remains useful for reviewing copy, hierarchy, images, and layout. Keep its claim narrow: it shows that a particular version rendered in that preview. A direct public URL checks what visitors receive; navigation checks reachability; an authorised end-to-end test checks the promised outcome. Stop at the last state you can observe.

MDN: Responsive web design · MDN: Client-side form validation · W3C WAI: Form instructions · W3C WAI: User notifications