Sybqa

Guide · mobile check

Manual mobile-friendly check before an automated run

First published · Facts checked

Short answer

Before an automated run, check the viewport tag, one phone-width layout, tap targets and one short journey by hand, and write down what you saw. That record tells the automated plan what to repeat. It is not a Google mobile-friendly verdict and it does not cover every phone.

On this page
Context and limits

Before you start an automated layout run, look at the page yourself at one phone width and write down what you see. That note becomes the expectation the automated plan should repeat. A manual look is a few minutes with a browser. It is not a verdict from Google, and it does not cover every phone.

Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.

Look yourself before you automate the same question

An automated run repeats a plan. If the plan says “the page fits a phone” and you have not said what “fits” means, the run can only report whatever its checks measure. A short manual pass gives you that sentence: which width, which content must stay visible, and which control you could use.

Use the browser’s device toolbar, or resize the window and read the width it reports. Write the width in CSS pixels. “It looked fine on my phone” is not a width the next run can repeat.

The mobile-friendly guide covers the tools people use now that Google’s Mobile-Friendly Test is retired, including PageSpeed Insights and Lighthouse. This page is only the manual step you take before an automated run. The responsive design guide is the wider width-by-width list.

Four things to check by hand

  1. Viewport. View source or the elements panel and find the viewport meta tag. You want a width that follows the device, not a fixed desktop width. If the tag is missing, write that down. Do not treat a missing tag as a pass.
  2. One phone width. Pick one width, such as 390 CSS pixels, and reload. Read the page. Note text that overflows, controls that sit off screen, and content that overlaps.
  3. Tap targets and text. Try the primary control with a finger or the toolbar’s touch cursor. Note any control you cannot hit without hitting its neighbor, and any text you cannot read without zooming in a way the page then breaks.
  4. One short journey. From that width, follow one path a visitor needs, such as home page to pricing. Stop before you submit real data, pay, or create an account. Write the expected screen and the screen you actually got.
These four checks are a manual script, not a completed test. Fill in what you saw on your URL. An empty note is not a pass.

WCAG’s reflow guidance is about content remaining usable when the viewport is narrow, and its target-size guidance is about how large a pointer target is. Those documents define the criteria. Your note records what you observed. A manual look does not certify either criterion for the whole site.

Hand the note to the automated plan

Put the width, the route, the journey and the expected visible result into the plan you review. Ask the run to repeat that, not to invent a new definition of mobile-friendly. If the plan visits other pages, those pages were not part of your manual check. Mark them as extra coverage, not as something you already saw.

Keep the manual note with the later report. If the run fails, you can see whether it failed the thing you looked at or something you never checked. If you never wrote the note, you cannot tell those apart.

Sybqa’s free plan includes 10 runs a month after you sign up, with no card and no AI review. Nothing starts until you review the plan. The pricing page has the current figures. Opening this guide does not start a run.

What this manual check does not prove

For scores rather than a layout look, read Lighthouse and PageSpeed versus website QA. A performance score is a different question.

Common questions

Why check a phone layout by hand before an automated run?

So the automated plan repeats a width and an expected result you have already seen. Without that note, a later failure is harder to match to a real observation.

Is this the old Google mobile-friendly test?

No. Google retired that test. This is a manual look in your own browser, plus a written note for the run that follows.

Does a phone-sized browser window prove every phone works?

No. It checks one width in one browser. Devices still differ in browsers, keyboards and operating-system behavior.

Sources

Related reading

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.

Use a site you own or may test. Nothing runs until you review the plan.