How to test a web page on mobile and desktop
Test a page on mobile and desktop by checking the viewport and returned HTML, opening the same URL at both widths, reviewing headings and controls, and recording any layout or interaction issue with the exact page and device width.
Updated 7 October 2026. Keep the output and the verification step together.
Steps
- Choose the exact public URL and the primary action a visitor should complete.
- Check for a mobile viewport in the returned HTML.
- Open the URL at a narrow and wide width and inspect headings, tables, forms and buttons.
- Test keyboard focus and the main action at both widths.
- Record the viewport, browser, URL and issue, then retest after the fix.
What the audit can and cannot check
The Website Audit can report the viewport and other returned HTML signals. It does not simulate every device, measure Core Web Vitals or guarantee that a layout works across browsers. Use a real browser check for visual and interaction issues.
Keep the task in view
A page can look tidy and still hide its primary action below a wide table or make a form impossible to use. Start with the action the visitor needs, then check the supporting content.
Record exact evidence
Use the URL, width, browser and a short description. Screenshots help, but a repeatable text record makes a fix easier to verify after deployment.
Do not turn a viewport into a score
A viewport meta tag is one signal. It does not prove responsive design, accessibility or performance by itself.
Questions
Does a viewport tag prove mobile usability?
No. It is one returned HTML signal. Visual and interaction checks still matter.
Can the audit test a private preview?
It reads public pages. A protected preview may require a separate local test and a production check after deployment.