What the mobile-friendly test examines
The test fetches one public URL and examines the returned HTML for practical responsive-design signals. It checks for a device-width viewport, media queries, responsive media rules, and suspicious fixed-width declarations. The v1 report is intentionally a bounded markup heuristic: it does not execute the site's JavaScript, take a screenshot, or claim to observe the final rendered layout.
A passing result means the source contains several useful mobile-ready signals. It does not certify every device, browser, orientation, accessibility requirement, or search ranking factor. Responsive behavior can still change after scripts run or when consent state, login status, and feature flags alter the page. Treat the report as focused evidence and confirm important pages in a real browser and on representative hardware.
How to test a page
- Enter a complete public HTTP or HTTPS URL, including the page path you want checked.
- Start the test and allow the server to fetch the public HTML through its protected network client.
- Review each finding and its evidence, then inspect the same page at a narrow width in your own browser.
- Correct the source, publish the change, and run both the heuristic and hands-on browser test again.
Test a representative page rather than assuming the home page covers the whole site. An article, pricing table, checkout step, or documentation page can use templates and components that never appear on the home page. If a page requires authentication, use your own browser and device lab; do not place credentials, session tokens, or private preview keys in the submitted URL.
Reading common findings
Viewport and horizontal overflow
A responsive page normally declares a device-width viewport and avoids content wider than the visible area. Fixed-width tables, unbroken code, oversized images, and absolutely positioned banners commonly create sideways scrolling. Find the element that extends past the document width instead of hiding all overflow, because global clipping can make content or controls unreachable.
Text and tap targets
Body text should be readable without pinch zoom, and links or buttons need enough area and separation for a finger. A warning is a prompt to inspect the actual component, not an instruction to enlarge every element indiscriminately. Check line length, hierarchy, contrast, focus behavior, and whether sticky controls cover the item a visitor is trying to tap.
Concrete uses for the report
Run the test before releasing a landing page to catch a missing viewport or fixed-width source rule, then use a browser to check consent banners and navigation behavior. Use it after changing a design system breakpoint to sample pages that contain tables, forms, media, and long headings. It is also useful for quickly comparing the responsive signals emitted by several templates before deeper visual testing.
For a broader audit, combine this result with browser developer tools, real iOS and Android devices, keyboard navigation, screen-reader checks, and performance measurements over a slow connection. Mobile-friendly layout and fast loading are related but separate concerns. A page can fit perfectly while a large script delays interaction, or load quickly while placing essential controls outside the viewport.
Privacy and remote access
The URL is sent to PagesTools because the test must run on the server. The server requests the page, so the destination can observe the PagesTools server address and request timing. Only publicly reachable pages should be submitted. Private, loopback, link-local, and internal network destinations are blocked to prevent access to protected infrastructure.
Do not submit signed preview URLs, password-reset links, customer-specific pages, or addresses containing API keys. The tool does not need your website password and cannot see a page that is available only inside your office network. For confidential staging environments, run an equivalent browser test within infrastructure you control.