Mobile website checklist

6 Mobile Website Mistakes That Get in Your Visitor’s Way

Your desktop page can look finished while a visitor on a phone struggles to read, navigate or reach the next step.

Take an ordinary task: compare two plans, read the conditions and find the contact button. On a phone, that can become a sideways-scrolling table, a hidden menu and a button covered by a floating banner.

This is a practical layout and interaction review, not a study of mobile conversion or AI visibility. The examples are hypothetical. The checks draw on W3C accessibility guidance and Google’s web-performance documentation. They are a starting point for finding specific problems, not a complete accessibility audit.

Illustrative interfaceGIST / FIELD NOTES
A plan comparison needs a reachable next step on a phone.

Two invented layouts of the same task. Page proportions are schematic; this is not a screenshot of a measured site.

A / The page runs beyond the screen

Compare plans
Contact the team
Promotion covers the action

The comparison extends outside the viewport. A floating layer covers the next step.

B / The task fits the screen

Compare plans
Plan A Scope and conditions
Plan B Scope and conditions
Contact the team

Readable cards and a visible action keep the comparison usable.

The example illustrates reflow and focus visibility. It is not a conformance test or evidence of a GEO effect.

1. The whole page needs sideways scrolling

A wide comparison table or fixed-width image can push an otherwise readable page beyond the screen. The visitor has to move left and right even to finish an ordinary sentence.

Ask your web team to make the surrounding text and controls fit the available width. A genuine data table may need its own horizontal scrolling region; that should not force the entire page to scroll in two directions.

W3C’s reflow guidance distinguishes content that can rearrange into a narrow column from content that needs a two-dimensional layout. Preserving the comparison matters more than squeezing every column into unreadable type. Reflow guidance.

Try this: open a key page in a narrow browser window. Read a paragraph and reach the main action without dragging the whole page sideways. Then test the table separately.

2. The menu depends on hovering

A desktop menu may reveal useful links when a pointer rests over a heading. A phone user has no equivalent reason to discover that hidden layer, and a keyboard user needs a working route too.

Give people a clear control for opening the menu and a predictable way to close it. If a heading is also a link, make the distinction between visiting it and opening its submenu understandable.

W3C’s menu guidance includes touch and keyboard interaction rather than assuming mouse hover is enough. A menu that happens to open on one tap is not finished until its contents and closing behavior work as well. Fly-out menu guidance.

Try this: reach a specific product page using touch, then repeat with a keyboard. Do both routes make sense without knowing the menu in advance?

3. The controls demand a precise fingertip

A tiny close icon can sit beside another link, or pagination can pack several small targets together. The visible symbol may look large enough while its actual clickable area is much smaller.

Give important controls usable target areas and space from competing actions. Test the full clickable region, not just the icon artwork. A larger hit area can help without turning every control into a giant button.

W3C’s target-size guidance addresses both size and spacing, with exceptions for situations such as inline text links. Treat the published minimum as a technical threshold, not a guarantee that the page feels comfortable to use. Target-size guidance.

Try this: use the page one-handed. If you repeatedly hit the neighboring control, record the two targets and show the problem to the designer.

4. Floating layers cover the thing someone needs

A sticky header, chat launcher and bottom promotion can each seem reasonable on their own. Together, they may cover a large part of a small screen. An on-screen keyboard can reduce the remaining space further.

Review these layers together. Check whether people can dismiss them, read the page beneath them and reach the active control. Do not solve the problem by removing necessary privacy choices; make the choices and the rest of the page usable.

W3C specifically identifies sticky headers, footers and notifications as potential obstacles when they obscure the control receiving keyboard focus. Focus-not-obscured guidance.

Try this: move through the page with Tab while the usual banners are visible. Keep checking where the focus indicator is, rather than assuming the page scrolled to a usable position.

Illustrative sequenceGIST / FIELD NOTES
Reserved space keeps a late image from moving the action.

Compare two schematic loading sequences. No loading time or shift score is being measured.

Without reserved space

Before image loads
Compare plans
After image loads
Compare plans

With reserved space

Before image loads
Image space reserved
Compare plans
After image loads
Compare plans

Illustration of reserving image space, based on Google’s layout-shift guidance. A separate mobile test is still needed.

5. The page moves while someone is about to tap

The visitor aims for a plan button. An image or promotion loads above it, shifts the page and puts another link under their finger.

Ask the web team to reserve space for images, embeds and other content that arrives after the first render. A screenshot taken after everything loads will not reveal the problem; watch the loading sequence as a person experiences it.

Google’s layout-shift guidance identifies missing image dimensions and unreserved space for ads or embeds among common causes. It also explains how reserving an appropriate area helps the browser keep the layout stable. Layout-shift guidance.

Try this: reload a page while watching the main action and surrounding text. Repeat under a slower connection in a test environment. Record what moved and what loaded just before it.

6. Enlarging the text breaks the layout

Small print may be technically present but difficult to read. Enlarging it should not clip the price, hide a condition or push the only action off the visible card.

Test the page with larger text and browser zoom. Check headings, navigation and comparison cards as well as body copy. If a card has a fixed height, its text may need more room than the desktop mockup allowed.

W3C’s text-resizing guidance concerns retaining content and functionality when text is enlarged. Its reflow guidance addresses how content fits a narrowed view. Passing one check does not automatically resolve the other. Text resizing and reflow.

Try this: enlarge the text, then complete the same task you used at normal size. Note any information or action that disappears, overlaps or becomes unreachable.

Test a task, not just a screen width

Choose a journey with a meaningful end: find a service area, compare a plan or reach a contact route. Try it on a real phone and with a keyboard, then check narrow layouts and enlarged text. Record the page, the obstructed action and the conditions that reveal the problem.

If the journey ends at a form, continue with the form-mistake checklist. The point is to make the complete task work, not merely to produce an attractive mobile screenshot.

Check the discovery side of that journey too. Start a free Gist Quick Scan to see how your brand appears in tested AI answers for a relevant topic. Use it alongside a separate mobile review; the scan is not a test of your page layout.