Mobile SEO Checker

Start with the page

The useful question is not whether a page earns a green badge. It is whether someone on a phone can reach the same useful information and finish the same important task. A booking page that loses its prices on mobile has a content problem. A booking button hidden behind a fixed banner has a layout problem. Those need different evidence.

Supply a full mobile HTML or DOM snapshot. Add the corresponding desktop document when you need a comparison. Keep the language, login state, consent choice and selected product or location consistent. Otherwise, a difference may come from the session rather than the device.

Keep useful content

Google uses the mobile version of content for indexing and ranking. For sites that serve different desktop and mobile documents, check that the main information remains equivalent. Compare meaningful headings, descriptions, important media and structured data. Responsive sites often serve the same HTML to every device, which makes a separate layout check especially important. Google’s mobile-first guidance explains the different configurations.

A closed accordion is not automatically missing content. This checker retains hidden and collapsed HTML in its parity comparison. Content fetched only after a click may still be absent from the captured document. Unmatched passages are a starting point for review, not a demand for identical wording or an automatic penalty.

Check the viewport

A device-width viewport is a useful foundation, not proof that the layout fits. Wide tables, fixed-width media and menus can still spill off screen. Test the actual page at narrow widths, in both orientations, and with larger text.

Keep zoom available. A restrictive user-scalable or maximum-scale declaration can make text harder to read, even if some browsers override it. MDN’s viewport reference explains the declaration and its accessibility implications. HTML inspection does not measure the final size or spacing of controls.

Read browser evidence

A mobile Lighthouse report adds observations from a particular browser run. Keep its date, final URL and device settings with the findings. An absent audit is unknown, not passed; Lighthouse versions do not all contain the same checks. Reproduce a reported issue before changing the template.

For small controls, inspect the complete interaction. Target dimensions, spacing, inline links and equivalent controls affect the interpretation. WCAG’s target-size guidance includes exceptions, so a single size measurement is not an accessibility certificate. Real-device testing should include menus, zoom, keyboard focus and form completion.

Handle separate URLs

A corresponding mobile URL is not the same case as an unrelated page. For a separate-URL setup, review the desktop canonical, the mobile canonical pointing back to that desktop page, and the desktop’s mobile alternate link. The checker lists the declarations it finds; it does not test device redirects, response headers or Google’s selected canonical.

Use the Canonical Tag Checker for declaration checks, the JavaScript SEO Checker for original-versus-rendered evidence, and the Core Web Vitals Checker for performance reports. Keeping those questions separate makes the next fix clearer.