A practical mobile website review checklist

A mobile website review should test whether someone can understand the page, navigate it, read its content, and complete the main task on a real phone. Check the layout at narrow widths, but also test touch interactions, the on-screen keyboard, scrolling, orientation, and loading behaviour. A page that fits inside a phone-shaped rectangle is not automatically a usable mobile experience.

Begin with the most important visitor journey. That might be sending an enquiry, booking an appointment, comparing services, or signing into a product. Complete the journey from its natural entry point rather than opening each page in isolation. Mobile problems often appear between screens, when a menu changes state or a form loses information after navigation.

Choose a realistic test setup

Use at least one real phone alongside browser responsive tools. Responsive tools are useful for checking widths quickly, but they do not perfectly reproduce every device's browser controls, keyboard, touch behaviour, or performance. A real-device pass can reveal issues that a desktop preview makes surprisingly easy to miss.

Record the device, browser, orientation, and page URL when reporting a problem. You do not need to test every phone ever manufactured. Start with the devices relevant to the audience, then add coverage based on actual reports or analytics when available. Avoid claiming universal compatibility from a single successful test.

Test a fresh visit as well as a return visit when the site has account or consent states. A banner may appear only once, and saved preferences can hide a problem from the developer's everyday browser. Use approved test accounts and safe data. Do not expose customer records simply to make a review look realistic.

Check the first screen

The opening screen should explain what the site offers and provide a clear next step. Look for headings that become too tall, images that push useful content far below the fold, and fixed elements that compete for attention. The goal is not to force everything into one screen; it is to make the beginning understandable and purposeful.

Read the heading aloud. Does it still make sense when wrapped into several lines? A deliberate desktop line break can produce awkward mobile spacing or leave a single word stranded. Check whether the message remains clear without relying on a decorative image or animation that loads later.

Inspect the primary action. It should be recognisable as an action and describe what happens next. If several buttons compete equally, ask which one supports the main visitor task. A phone screen has limited space, and five equally enthusiastic buttons can feel like five people giving directions at once.

Test navigation with your thumb

Open the mobile menu, select an item, return to the page, and open it again. Check submenus, close controls, and links that scroll to sections. Confirm that the menu does not remain over the destination or trap the page in a non-scrolling state after closing.

Targets should be comfortably tappable without accidental activation of neighbouring controls. The WCAG 2.2 minimum target-size criterion uses a 24 by 24 CSS pixel threshold with defined exceptions; a comfortable design may use larger targets. Treat the standard as a reference, not a reason to make every control as small as technically possible. Consult the official W3C guidance when assessing conformance.

Look for hover-only behaviour. A tooltip, submenu, or explanatory label that depends entirely on hovering may not work as intended on touch devices. Check that essential information and actions remain available through touch and keyboard interaction. Decorative hover effects are fine when the underlying task does not depend on them.

Read the content without zooming

Body text should be legible at the normal page scale. Check line length, spacing, contrast, and the relationship between headings and paragraphs. A large heading can still be readable while overwhelming the page; the review should consider rhythm and hierarchy as well as raw font size.

Inspect lists, tables, captions, and long words. A comparison table may need a clearly usable horizontal scroll region or a different mobile presentation. It should not force the entire page to slide sideways. Long URLs and unbroken labels can also create overflow even when the main layout looks correct.

Try browser text enlargement where available. Check that important content and controls remain usable rather than clipping or overlapping. Do not disable user zoom to conceal layout problems. Accessibility and responsive design work together when the interface can adapt to different reading needs.

Inspect images and video in context

Check that important subjects remain visible when images crop. A landscape photograph may work beautifully on desktop and cut off the product on mobile. Identify the actual problem in your feedback: the subject is missing, the text is unreadable, or the image takes too much vertical space. That gives the designer a meaningful target.

For video, check both its framing and its effect on the page. A tall video can dominate the first screen, while an overly small one may lose its purpose. Preserve the intended visual quality and test whether the page remains responsive during loading. A performance fix should not silently turn an important demonstration into an unreadable thumbnail.

Respect motion preferences and avoid making essential information depend on animation. If a carousel or animated demonstration runs automatically, the content should still be understandable without waiting for a particular frame. Check that motion does not cause layout jumps or obscure controls during interaction.

Complete every important form

Tap into each field and observe the on-screen keyboard. Does it cover the active field, validation message, or submit button? Can you scroll to the remaining controls? Does the page jump unexpectedly when the keyboard opens or closes? These problems often appear only on a real device.

Check labels, instructions, and error states. Placeholder text should not be the only explanation of a field because it disappears as the user types. An error should identify the problem and help the person correct it. Test both missing values and plausible invalid values using safe test data.

• Complete the form with valid information and confirm the visible outcome.
• Submit with a required field empty and check the message and focus behaviour.
• Correct an error without losing unrelated entries.
• Navigate back and confirm the expected state is preserved or clearly reset.
• Check any dropdowns, date controls, consent controls, and file inputs.
• Verify that the success message is readable and does not disappear too quickly.

Check fixed and floating elements

Sticky headers, cookie banners, chat controls, and floating support buttons can each seem harmless alone. Together they may cover a significant part of a small screen. Review the combined state rather than checking each component separately. Pay particular attention to the bottom of forms and the final lines of articles.

A floating control should not block navigation, a primary action, or important content. If it is intended only for the landing page, verify that it does not follow users into dashboards or other application screens. Placement rules are part of the feature, not just a styling detail.

Scroll slowly and quickly through the page. Some sticky elements change size or appear after a threshold. Check the transition and the space they occupy. If a layout jumps, capture the point where it happens and describe the scroll direction so the developer can reproduce it.

Review loading and responsiveness

Use PageSpeed Insights to examine a representative public page, then interpret the result alongside real-device testing. Lab scores can reveal opportunities, but they vary and do not replace evidence from actual visitors. A low-traffic site may have no field data, which means the report cannot establish real-user Core Web Vitals performance.

Pay attention to when the main content becomes visible and whether the interface responds to taps while loading. Images should reserve space so the page does not move beneath the user's finger. Important content should not remain hidden indefinitely because a decorative animation or reveal script has not started.

If performance feels inconsistent, record the conditions rather than assuming the site is always slow. Network quality, device capability, and cached resources affect the experience. The team can use measured results and repeated observations to decide which changes are worthwhile without sacrificing important media quality unnecessarily.

Turn observations into actionable notes

Capture the relevant screen, pin the affected element, and explain the visitor impact. “On this phone, the keyboard covers the confirmation action and I cannot scroll it into view” gives the developer a clear problem. “Mobile looks weird” does not identify an outcome to fix.

In JotPins, keep the screenshot or page annotation with the discussion and revision progress. Record the device and state in the note even if the capture itself looks obvious. The same visual layout may behave differently when the keyboard is open, when a menu is active, or after the user has scrolled.

After a fix, repeat the original test and one nearby case. If the button is now visible with the keyboard open, check that it also remains usable after the keyboard closes. A responsive change should solve the reported problem without creating another overlap at a slightly different width.

Frequently asked questions

Is browser responsive mode enough for a mobile review?

It is useful for layout coverage, but a real phone adds evidence about touch, browser controls, keyboard behaviour, and device performance. Use both when possible. A desktop simulation alone cannot prove that every interaction works correctly on the devices your audience uses.

Should everything fit on the first mobile screen?

No. The first screen should communicate the offer and a sensible next step, while longer content can continue below. Avoid unnecessary height that hides the purpose of the page, but do not compress useful information into an unreadable arrangement just to eliminate scrolling.

How should I report horizontal scrolling?

Include the page URL, viewport or device, and the point where sideways movement becomes possible. Capture the element that extends beyond the screen if you can identify it. Distinguish an intentional scrollable table from unintended overflow affecting the whole page.

What is the best order for mobile checks?

Start with the main journey, then navigation, content readability, forms, floating elements, and performance. This prioritises failures that prevent visitors from completing their task. Finish by verifying fixes under the same conditions in which the problems were originally observed.

Further reading

The W3C explanation of Target Size (Minimum) describes the criterion and its exceptions. Use PageSpeed Insights for measured performance diagnostics alongside hands-on testing.