Mobile site not displaying correctly: why

Phones draw a page at a virtual width, and the page decides whether that width is the phone's own. When the page does not declare it, the phone uses a wide default and scales everything down, so headings look small and columns crowd together. An image, table or embed set to a fixed width runs past the right edge, and the visitor scrolls sideways to read it. A section sized to the full height of the screen can run under the phone's toolbar and cut off its bottom. The owner checks on a wide monitor, where none of this shows.

• Open the page source, not the Elements panel. Is there a viewport tag that sets the width to the device width?
• Does the page scroll sideways at phone width? If it does, something is wider than the screen.
• Scroll to the bottom on a phone. Is any button or line hidden under a bar or the browser toolbar?
• Tap the last form field with the keyboard open. Can you still reach the submit button?
• Do a banner, chat bubble or sticky bar cover any text or control on the phone?

A phone browser reads one tag before it draws anything: the viewport meta tag. A page with the tag set to the device width is laid out at the phone's real width. A page without it is laid out at a wide default width, and the browser shrinks the result to fit, so the text is small and the buttons are hard to tap. Check the raw source the server sends, not the Elements panel, because the Elements panel shows the page after scripts have changed it, and a tag added by a script may not count for the first draw. Check the final page too, since a template can override a tag set elsewhere.

A sideways scroll means something is wider than the screen. Open the Console at phone width and run a short check that lists every element whose right edge sits past the window's width: [...document.querySelectorAll('*')].filter(e => e.getBoundingClientRect().right > innerWidth). The first few results are the culprits. Common ones are a fixed-width image, a table with many columns, an embedded map or video with a set width, and a row of buttons that does not wrap. Give those a width that fits their container, with a maximum of the screen width, and let a wide table scroll inside its own box.

Full-screen sections sized to the full viewport height can misbehave on phones. The browser's own toolbar takes part of the screen, and on some phones the height the page calls full is taller than the area the visitor can see. The bottom of the section then sits under the toolbar, so the visitor cannot read the last line, or the button at the bottom cannot be reached until the toolbar hides. Size the section to its content, or use a height that allows for the toolbar. Then check the bottom of the page on a phone, with the address bar showing and again with it hidden.

A sticky bar, a cookie banner or a chat bubble fixed to the bottom of the screen can cover a form field or the submit button. The problem can get worse when the phone keyboard opens, because the visible area shrinks while the fixed element stays where it was. Tap the last field on a phone and check whether the submit button is still reachable with the keyboard open. A simulated visitor on a phone browser fills the form and records the step where it stopped, with a screenshot at that moment.

Landing page testing

A new banner, a larger image or a wide table added in a later release can push the page wider than the screen again. Rerun the same simulated visitor on a phone after each change, and check the bottom of the page and the form. If the page sits behind a login, test it with a test account, and check each preview deploy before the change goes live.