Mobile site not working: what changed?

After a change, the owner reopens the site on a laptop, sees it working, and ships. Phones take a different route. Some sites send phone visitors to a separate mobile address or template, and a rule written in the last release can send them into a loop. Some caches keep the old phone page, which asks for a script the new release removed. Some scripts load only on small screens, such as a menu or a chat widget, and one error in them can stop the rest of the page. The laptop runs none of this, so the change looks safe.

• Open the same address on the last version that worked, on a phone, and note the first step that differs.
• Follow the address bar on a phone. A loop, or a 404 after a redirect, is a routing fault.
• With Safari's or Chrome's remote debugger attached to the phone, look for a request that returns 404 or never finishes.
• Does a script that only phones load, such as a menu or chat widget, throw an error on load?
• Check the page's script names against the files on the server. A cached page can ask for files that no longer exist.

Phone-only faults hide from the usual check, so compare the phone path between two versions, not just whether the homepage loads. Deploy the last version that worked on a phone to a preview address, if your platform allows it. Record the phone's requests on the same path in each version: the redirect chain, the scripts and the first call that fails. The first request that appears in one list and not the other is where to look. A GitHub Action can run visitors on each preview and keep one comment on the pull request, so the comparison happens before the change ships.

GitHub Actions

Many sites decide what a visitor sees by their device. A rule may send phone visitors to a mobile address, a mobile template or a page the release moved. The redirect can loop when a rule for phones sends the visitor back to the page it came from. The browser stops after too many redirects and shows an error that looks like a server fault. Follow the chain in the address bar or the Network tab, and read each status code. A 301 or 302 that points back at the start is a loop, and a final 404 means the destination was removed in the change.

A content delivery network can keep separate copies for phones and laptops when its cache varies by device. If the cached phone copy was built before the change, it asks for script files the release has renamed or removed. The page loads, the script requests return 404, and the buttons do nothing. Clear the cached phone copy, load the page again on a phone, and check that the script names in the page match the files the server holds. The same mismatch appears when a browser keeps an older file that the new page no longer needs.

A change that adds a third-party script, such as a chat widget, a consent tool or an analytics tag, adds one more request the phone has to finish. On a slow mobile connection that request can hold up the rest of the page while everything waits behind it. Look at the Network tab with throttling set to a slow mobile connection, and see which request holds the page. A simulated visitor on a phone browser records the slow request on the step where it happened.

Checkout flow testing

A redirect rule, a cache setting or a new script added in a later release can bring the phone fault back, even after you fixed it once. Rerun the same simulated visitors on a phone after each release, on the same path. If the site sits behind a login, test it with a test account, and check each preview deploy before it reaches the live site.