Mobile website testing before launch

Mobile website testing is more than making a desktop layout narrower. Check that the page still shows the right information and lets people finish the main task on a small screen.

Use a real narrow viewport and follow the main path. Note anything that makes you zoom, search, guess, or go back.

Test the task, not just the layout

Start at the public URL in a clean browser session. Do not review only a screenshot. Follow the page in this order:

1. Read the first screen.
2. Open and close navigation.
3. Find the primary action.
4. Complete or begin that action.
5. Return to the page and use the footer or secondary route.

This finds problems that a static preview cannot show: a menu that traps focus, a form that loses its value, a button that moves after loading, or a route that works only after a hard refresh.

Use more than one narrow width

A phone screenshot is only one test. Check at least one small phone width and one larger phone width. If you can, use a real device for the final pass because browser chrome, safe areas, zoom, and touch precision affect the result.

Ask this at each width:

What should the visitor notice first, and is it still clear at this width?

If the answer changes between widths, fix the layout order before adding another breakpoint.

Look for structural breakage

Check each section for horizontal overflow, clipped text, and controls that collide with the fixed navigation. Pay special attention to:

• Long URLs, code samples, prices, and error messages.
• Cards with minimum widths that force the whole page wider.
• Dialogs that extend below the viewport without a scroll path.
• Sticky elements that cover headings or form errors.
• Images and videos that ignore the content column.

The browser can hide overflow while content is still unreachable. Scroll horizontally with a trackpad or touch gesture and inspect the widest element if something looks wrong. Use the horizontal overflow CSS debugging guide to trace the offending element and fix flex, grid, text, or media sizing.

Check touch and keyboard together

Touch-friendly controls also need to be keyboard-friendly. Every interactive element should have a visible focus state, a sensible order, and a label that describes the action. Do not rely on an icon or color alone to explain what a control does.

For the primary path, verify:

• The target is large enough to tap without precision work.
• Pressed, disabled, loading, and error states are distinguishable.
• Form labels remain visible when the field has a value.
• Validation text sits next to the field it explains.
• A user can recover without losing the rest of the form.

Measure the first screen's weight

Mobile visitors should not wait for decorative content before they can understand the page. Watch the first load with the network panel open and note layout shifts as fonts, images, or client-side data load.

Do not invent a performance score from one device. Instead, record the conditions: viewport, connection profile, cache state, and what was observed. The same discipline applies to browser findings in a broader website launch checklist.

Set the mobile layout

Responsive CSS should define the layout clearly. Let the content column control the width and add a breakpoint only when the reading or interaction order needs to change:

.content-column {
  width: min(100% - 2rem, 46rem);
  margin-inline: auto;
}

@media (min-width: 48rem) {
  .content-column {
    width: min(100% - 4rem, 62rem);
  }
}

The values will vary by site. Keep the text width, spacing, and action order clear without creating a separate mobile page.

A useful mobile sign-off

Before launch, write down:

• The smallest viewport tested.
• The primary path completed.
• Any browser or device limitation.
• The one issue that would most affect a first-time visitor.

That last answer is more useful than “looks good.” For a public check across mobile and desktop, run an audit and use the screenshots and findings in the handoff.