Pre-traffic website QA for a startup launch

State the intended visitor and the action this page asks of them: join a waitlist, book a demo, start a trial, or read enough to understand an unfamiliar offer. Then open the public URL as a new visitor. Can you identify that job in the first screen without reading a founder's social post for context? If the hero tries to serve investors, customers, press, and job candidates at once, decide which audience this launch traffic is for.

Record the URL, test date, device or browser, viewport, and expected action. That small note lets another teammate repeat the check after a late copy or design edit.

Mark the page's important claims and find the material behind each one. Use a real product screenshot for a visible feature, a short demonstration for a task, an approved beta quote for that person's experience, or a sourced number with the time period and method that produced it. Check that the business has permission to publish images and customer names.

A polished page without support can still mislead. If you cannot substantiate a result or security promise, revise the sentence rather than filling the gap with a logo row. The aim is for a visitor to understand what exists now.

Start on the published page at desktop width, then resize that same page to a recorded phone viewport such as 390 × 844 px. Read the headline, open the navigation, follow the main action, and inspect each screenshot crop. Look for text hidden behind a sticky bar, horizontal overflow, and a proof section that appears only after a long run of decorative cards.

Note the viewport, browser, zoom, and page state. A screenshot taken on a different build cannot prove that this published page works on mobile. W3C's quick accessibility checks also cover keyboard focus, headings, image alternatives, and form labels; add those to the pass rather than treating visual neatness as the whole test.

Use a safe test address on the public page. Submit the form, read the confirmation, and check where the record arrives. Enter one invalid value and confirm the error names the field and tells you how to fix it. If the action leads to a calendar or checkout, follow it far enough to verify the destination and next step without creating an unwanted real booking or charge.

Test the navigation and every main call to action. Record the expected destination and actual result. W3C's form tutorial calls for labels and clear success or error feedback; a button label or integration badge does not establish that the path works.

Inspect the published HTML for a specific title, useful description, canonical URL, social image, and crawlable links. Read the visible heading order too. Confirm that the sitemap lists the final URL and that robots rules do not block the page or the resources needed to understand it. Google's SEO starter guide treats these as ways to help people and search systems understand content, not a promise of ranking.

Finally, rerun the failed checks after the last edit. A fixed form and an updated hero image are not done until the current public page shows both. Keep the result short: URL, test conditions, what failed, who changed it, and the passing retest.