Set the scope before you start
A smoke test is a quick check that the most important parts of a newly launched website work in its live environment. It is not a full audit or a substitute for testing before launch. Its purpose is to catch obvious problems that could prevent visitors from finding information or completing a key task.
Start with the project brief or launch checklist. Identify the pages and actions that matter most: perhaps a home page, a services page and a contact form for a freelancer; an event page and registration link for a student project; or product information and an enquiry route for a small team. Write these down as a short list of tasks a visitor should be able to complete. This keeps the test focused when time is limited.
Test the public website address, not an editor preview or a staging copy. If possible, ask someone who did not build the site to follow the task list. A fresh pair of eyes may spot confusing labels or missing context that the project team has learned to overlook.
Walk through the main visitor journeys
Open the live site as a visitor would. Use the main navigation to reach each priority page, then try to return to the home page. Follow prominent buttons and internal links rather than assuming their destinations are correct. Check that page titles, headings, images and essential text appear, and watch for old placeholder content or links that still point to a preview site.
Next, complete each important action from beginning to end. For a contact form, submit a clearly marked test message and confirm what happens on screen. Then check whether it reaches the intended inbox or dashboard, if you have access. If the site offers a downloadable file, open it and confirm that it is the right version. If a journey leads to a service managed by another provider, confirm that the handoff takes the visitor to the expected place.
Look at a few less prominent pages too, especially those linked from the footer. You do not need to inspect every sentence during a smoke test, but visitors should not encounter an empty page, an unreadable document or a dead end while following a common path.
Check more than one screen and input method
A page that works on a desktop monitor may be difficult to use on a phone. Check the home page and key task pages at both narrow and wide screen sizes. Look for text that runs off-screen, menus that cannot be opened or closed, buttons that overlap, and forms whose labels or error messages are hard to see. If you can, use a real phone as well as a resized desktop browser.
Make a basic keyboard pass through the main journey. Use the Tab key to move between links and controls, and check that you can tell where focus is. Try submitting a form with a required field empty: the page should explain what needs attention. These checks do not amount to a complete accessibility review, but they can reveal barriers worth fixing promptly.
Test in another browser if one is available. If you cannot cover several devices or browsers, note what you did test rather than treating the result as universal. A short, honest test record is more useful than an unchecked claim that the site works everywhere.
Record problems and decide what happens next
Keep a simple log as you test. For each issue, note the page address, what you tried, what you expected, what happened instead, and the device or browser used. A screenshot can help when a layout problem is difficult to describe. Give each issue an owner so it does not get lost in a chat thread.
Prioritize by visitor impact. A broken contact route, an inaccessible main menu or a missing key page deserves attention before a minor spacing difference. Distinguish between a launch blocker, a problem to fix soon and a cosmetic improvement to schedule later. If a fix affects a shared component, such as navigation or a form template, check the other places where that component appears.
After a change goes live, repeat the failed task on the public site. Also make a quick check that the fix has not disrupted the surrounding page. Record the result and, when necessary, tell the project owner what remains unresolved. This creates a clear handoff for a freelancer, a student team or a small organization.
Turn the test into a reusable delivery routine
The most useful smoke test is one that is easy to repeat. Save the priority-page list, key visitor tasks and issue log alongside the project’s delivery notes. Include who receives test form messages, where downloads are stored and which external services are part of the journey. Avoid putting passwords or private visitor information in the checklist.
Run the same short test after significant updates, such as changing navigation, replacing a form or publishing a new page template. The checklist can evolve as the website changes. Over time, it becomes a practical record of what “working” means for that particular site, rather than a generic set of boxes to tick.
