Website audit checklist
Automated checks find repeatable technical signals. This checklist covers the parts that still need a person: whether the offer is understandable, a mobile task can be completed, a real inquiry arrives, and the finished page deserves to be indexed.
How to use this checklist
Choose one important journey before you begin. For a service business, that might be finding a service, checking the location, and sending an inquiry. For a shop, it could be finding a product, understanding delivery, and completing checkout. Review that journey on a phone first, then repeat it on a desktop browser.
Mark an item only after you have observed it working on the public website. Your progress is stored in this browser and is not sent to the scanner. A completed checklist is a record of one review, not a permanent certificate.
1. Purpose and essential visitor paths
A visitor should understand what the organization offers, who it is for, and what to do next without decoding slogans. Start on the page where search or advertising traffic is most likely to arrive, not only on the homepage.
Do not count a link merely because it exists. Open it and confirm the final page answers the question suggested by the link label. If a call-to-action says "Book an appointment," it should not end on a generic contact page with no booking path.
2. Mobile usability
Use a real phone when possible. Browser emulation is useful for widths and layout, but it does not reproduce every keyboard, browser toolbar, permission prompt, or network condition. Test with the phone held normally and increase text size once to reveal fragile layouts.
Pay special attention to the bottom of the screen. Cookie panels, support widgets, browser controls, and sticky purchase buttons often compete for the same space. The visitor must always retain a clear way to continue or dismiss an overlay.
3. Forms and conversion actions
A structural scanner cannot prove that an email reached the recipient. Use a test address outside the receiving mail system and complete the same action a customer would. Keep the test message recognizable and remove it from production systems after verification.
Record the time of the submission and delivery. A delayed message can be almost as harmful as a failed one when the website promises a fast response. The contact form testing guide covers delivery, spam protection, validation, and failure states in more detail.
4. Performance and visual stability
Test once on a normal connection and once with an empty browser cache. Watch the page while it loads instead of looking only at a score. The main content should appear promptly, controls should respond, and text should not jump because media or banners claim space late.
When a metric fails, diagnose that metric rather than installing several optimization tools at once. The Core Web Vitals guide separates loading, interaction, and layout-shift causes.
5. Search visibility and maintenance
Search metadata should accurately preview visible content. A unique title is useful only when the page itself offers enough original detail to satisfy the query. Check the final public HTML after templates, plugins, and deployment rules have finished modifying it.
After a release, repeat the main journey, inspect the monitoring dashboard, and scan the affected URL again. Keep the previous result so you can distinguish a real regression from normal measurement variation.
Finish with evidence
Record the reviewed URL, device, browser, date, test account, and result. For a form, keep the delivery timestamp. For a broken link, keep the old and replacement destination. For a performance repair, compare the same page and test method before and after deployment.