WordPress website not loading in mobile: 3 causes

A WordPress page reaches a phone in three stages: the server builds it, the phone downloads it, and the browser runs the scripts that can hold back the text. A failure at the first stage gives a blank screen. A slow download, a large image or a third-party script that never answers can hold the page at the second or third stage, so the visitor sees a grey header and a spinner. A fast office or home connection hides all three. The owner refreshes, sees the page, and concludes the phone visitor has a bad connection.

• Load the homepage on a phone over mobile data, not office Wi-Fi, and note what appears first.
• Open the network list in the browser's developer tools. Look for a request that stays pending for a long time.
• Check the status code of the first request. A 500 means the server failed while building the page.
• Look for a chat widget, map or tag script that the page waits on before it draws the text.
• Compare each image's file size with the width of a phone screen. A desktop-size hero photo slows every phone.

A blank white page usually means the server failed while it built the page. A PHP error can stop a WordPress page from rendering, and the visitor then sees nothing but a blank screen. The failure can be specific to phones: a template or plugin branch that runs only for a small screen, a copy cached from a broken build, or a feature that uses more memory on a phone. The first request shows whether the server answered at all, and a server error comes back without the page text you expect.

The error itself is usually written to the site's error log, which the host keeps for the owner. Turn it on, reload the homepage on a phone, and read the newest entry. The message names a file and a line, so the fix is often a plugin, a template or a setting that changed in the last release. Revert the most recent change first and test again. That is faster than guessing which line caused the failure.

When the header draws and the text does not, the browser is waiting for something. A page builder or theme can hold the content until a script finishes, and a third-party script such as a chat widget, a map or a tag manager can take a long time to answer on a weak connection. Heavy images make it worse. A hero photo uploaded at desktop size and shown full width on a phone can take longer to download than the rest of the page combined. Move the third-party script after the text, and resize the image for small screens.

Open the browser's network list in phone view with a slow connection selected, reload the page, and read the list from the top. The first document request should return a success status and a size that matches a real page. If it is missing or red, the server is the problem. If it returns quickly but a second or third script keeps pending, that script is the problem.

A simulated visitor loads the homepage in a real browser at phone width and records what is on the screen after it waits. If the page stays blank or stuck, the report gives the step, a screenshot at that moment, and any failed or slow app request the browser logged there. The run does not measure how your host performs for every visitor, and it cannot read your server's error log, so it does not replace that check. It shows the phone path a stranger takes and the step where that path stopped.

Phone load time moves with every new script, image and plugin, and a hosting change can alter how fast the server builds a page. A chat widget added for a sales push or a larger hero image can slow the first screen for every phone visitor. Keep a phone run of the homepage with each release, and check that the text appears before the third-party scripts finish.