Mobile Website Checks for Contractors: A Field-Test Checklist

Begin with a real customer task

Choose a specific scenario, such as ‘I need a furnace repair in the service area’ or ‘I want a roof replacement estimate.’ Start from the home page and see whether you can identify service fit, location coverage and the correct next action without hunting through menus.

Try the journey as a new visitor who does not know the company’s internal terminology. If a customer must understand campaign names, team titles or a software label to request service, the page is making the visitor do office work.

Check the first screen and navigation

Confirm that the company name, core service, service area and next step are visible at a sensible scale. A phone number should be easy to tap and should call the correct monitored line. A sticky action bar can help, but it must not cover content, form controls or the browser’s bottom edge.

Open and close the mobile menu using both touch and keyboard controls. Check its focus order, close behavior and contrast. When the menu closes, focus should return predictably; the visitor should not lose their place or encounter an inaccessible overlay.

Test the service-area explanation

Look for a plain statement of the towns or coverage rules, not an unexplained list of dozens of places. If the business qualifies calls by ZIP code or travel distance, make that clear before the visitor invests time in a long form. Do not imply the company has a staffed office in every location it serves.

Try an address the company does not serve. The page should help the visitor understand the limit and avoid implying that an appointment exists. This test protects the office from poor-fit inquiries and helps the customer choose a more suitable next step.

Complete every contact path

Tap the phone number, start the form, move between fields and submit a test entry only in an approved non-production test flow. Verify that the mobile keyboard uses a sensible layout, labels remain visible, validation messages are understandable and the success state is not obscured by the keyboard.

If the site offers chat or booking, test those independently. Confirm that a calendar does not display unavailable slots as bookable and that a chat prompt does not cover the main call button. A tool appearing on the page does not prove that a message reached a monitored person.

Check legibility and interaction

Read headings, body text and disclaimers at the phone’s default browser size. Test links and buttons with a thumb, including close controls and any consent settings. Avoid tiny inline links or tightly packed controls. Make sure focus indicators remain visible when using a keyboard or assistive technology.

Check contrast over photos and colored panels, image cropping, line breaks and horizontal scrolling. Tables should reflow or offer a way to compare content without pinching across a very wide layout. Avoid presenting important details only in a decorative graphic that is difficult to read on a small screen.

Test loading under ordinary constraints

Reload on mobile data or a throttled connection if your test setup allows it. Notice whether a hero image delays the main message, whether fonts cause a large layout shift and whether third-party widgets delay the form. Optimize images and defer nonessential scripts where appropriate, then recheck the visitor journey.

Google’s page-experience documentation describes usability signals but does not promise a ranking outcome from any single performance score. Treat speed as a user and operations concern: a slow contact path can frustrate a customer even before it becomes a search issue.

Verify the handoff after the tap

Trace a test request from the page to the inbox or CRM record. Confirm the service type, source and any consent choice are preserved and that an owner can see the next task. Ensure a form start, submit-button click and verified successful lead are tracked as different events.

Do not count a click as a completed lead. If the form is embedded, use its supported success signal or confirmed thank-you behavior and verify the event in the existing analytics flow. Never send a real lead to production as a test without an approved test record and process.

Record defects so fixes can be verified

Keep a short log with phone model or browser, page URL, starting conditions, task, result and a screen recording or screenshot where appropriate. Label the issue as content, interaction, loading, measurement or CRM handoff. Re-test after the change on the same device and one other common mobile width.

Google recommends responsive design as a maintainable mobile approach, but the key proof is whether the same meaningful information and actions remain usable across the actual experience. A successful desktop check does not replace a mobile test.

Use a repeatable device-and-task matrix

• New customer on iPhone: find a repair page, tap the monitored number, return and request service.
• Returning customer on Android: find the existing-job contact path without entering a duplicate lead.
• Keyboard-only desktop emulation: open the menu, tab through controls, correct a validation error and close the menu.
• Slow connection: load the primary page, check whether the message and contact action are available before large images.
• Small viewport: complete the form with the keyboard visible and confirm the success state can be read.
• Out-of-area test case: verify service coverage is explained before the customer completes unnecessary fields.

Distinguish a design issue from a business rule

A mobile page may be visually clear while the call still goes to an unmonitored line. Record the destination number, notification recipient, office hours and form owner separately from font size or spacing. Fix the responsible layer; changing the button color cannot repair an unanswered handoff.

When the office wants a tighter intake, ask whether the extra field improves routing enough to justify the added effort. Compare several real customer conversations with test submissions, while respecting consent and privacy. A shorter form is not automatically better if it leaves dispatch unable to determine who owns the next step.