A mobile friendly website helps people do what they came to do on a phone. They should be able to read your offer, find the right service and get in touch. A page that looks neat in a small screenshot can still fail these tasks.
Start with your homepage, one service page and your contact page. Use a real phone if you have one. This guide gives you a short task card so you can turn vague concerns into clear fixes.
The short answer
- Test real customer tasks on a phone, not just the look of one screen.
- Keep important service content available in the mobile version.
- Check zoom, menus, nearby controls and forms with the keyboard open.
- Record the device and failed task so the builder can repeat and fix it.
How this guide was made
The checks draw on web.dev, Google mobile indexing guidance and W3C guidance on reflow and target size. The task records and defect examples are suggested tests. No device audit was performed for this article, and this checklist is not a full accessibility assessment.
Sources checked .
Pick three jobs a visitor needs to do
Put yourself in the place of someone who has never seen your business. They may be standing outside, using one hand or reading in bright light. They will not know where you put the price or which menu label means services.
Write down three jobs before you open the site. For a local cleaning business, these might be finding the service area, checking what a clean includes and asking for a quote. Choose jobs that match your own business.
Try each job from the homepage. Do not use a saved link that skips the hard part. Note where you stop, guess or have to go back. Those small notes make a better fix request than saying the site feels wrong.
Check text and page width
Check the homepage, a service page and the contact page in both phone orientations. Long names, prices and buttons often reveal a layout fault that short sample text hides.
Width and zoom
web.dev recommends flexible layouts that fit the screen and allow zoom. Increase the text size or zoom in, then try to read and use the page. Ask the builder to fix content that is cut off or covered.
For a technical check, W3C reflow guidance expects ordinary content read vertically to work at a width of 320 CSS pixels without scrolling in two directions. Some content that needs two dimensions has exceptions.
Sources for this section: [1] Responsive web design basics from web.dev; [4] W3C guidance on reflow
Text and tables
Read a whole paragraph, not just the heading. You should not need to drag each line sideways. Check that longer words wrap and that an image does not cover the text.
A wide data table may need its own scrolling area. Its headings and values should remain understandable, and the rest of the page should still fit. Ask the builder to check the type of content before treating every sideways scroll as the same problem.
Source for this section: [4] W3C guidance on reflow
Keep useful details on the phone
Google uses the mobile version of a page for indexing. Keep the main content and useful details available there. Compare the service scope, contact details and important links with the desktop version.
Google also warns against loading primary content only after a user action. Ask the builder whether the text is already in the page or is fetched only when someone taps. An accordion with its text already loaded is not the same as text that is absent until a click.
Open tabs and expandable sections as a visitor too. The heading should explain what is inside. A label such as What is included gives a clearer clue than an unnamed icon.
Source for this section: [2] Google guidance on mobile content and indexing
Try menus, buttons and the form
Start at the homepage and try the same route a new visitor would take. Do not skip a difficult menu by using a saved link.
Tap targets
Try links and buttons that sit close together. Note any place where the wrong action opens. W3C WCAG 2.2 sets a minimum target rule of 24 by 24 CSS pixels, with spacing and other exceptions. It does not mean every control must be 44 pixels wide.
Ask the builder to check the rule and its exceptions, then test whether the controls are comfortable on the phone. Meeting a size measurement is only one part of a usable task.
Source for this section: [3] W3C guidance on minimum target size
Form with the keyboard open
Tap each form field and keep the phone keyboard open. You should be able to reach the next field and the Send button by scrolling or closing the keyboard. Check that a fixed bar does not cover the active field.
On a site you control, send a marked test request. Check both the saved record and the intended inbox. The screen result alone cannot prove delivery.
Use this phone task card
The cleaning tasks below are fictional examples. Use one record per task. A narrow desktop browser is useful for an early check, but it does not replace a physical phone with touch input and an on screen keyboard.
| Task | What to check | Result to record |
|---|---|---|
| Find service in Maple Park | The service area is easy to find | Found it, could not find it, or unclear |
| Check a standard clean | Included work is readable on the phone | Missing fact or hard text to read |
| Request a quote | Fields, send button and delivery work | Page result and where the inquiry arrived |
Record enough to repeat the test
| Record | Detail to save |
|---|---|
| Page and date | Exact URL and test time |
| Device and browser | Phone model, browser and version if available |
| View and text | Orientation, viewport if known and text size or zoom |
| Network | WiFi or mobile data, with any known weak connection |
| Expected result | What completing the task should look like |
| Actual result | Where it failed, with a screenshot if useful |
| Fix and retest | Owner, change and result of the repeated task |
Fix the blocked task first
Fix a blocked customer task before a color preference. These fictional defects show how to turn a vague complaint into a pass rule.
| Defect | Why it matters | Pass condition |
|---|---|---|
| Menu will not close | It blocks the page | Menu closes and page scrolling works again |
| Sticky button hides a form field | Visitor cannot see what they type | Field and its error can be reached with keyboard open |
| Service limits missing on phone | Visitor cannot judge whether the service fits | Same essential scope is available in the mobile page |
A short note for the developer
Use the saved device and view settings to repeat the problem. Inspect the viewport setup, fixed controls and layout rules that affect the failed task. Preserve zoom and useful page content.
After the fix, repeat that task and one nearby action, such as moving to the next form field. Record the result. A clean screenshot or one passing phone check does not establish that every device works.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview