Mobile Layout Broken After an Update: Causes and the Fix

#The call

"The website looks fine on my computer but on my phone the menu has disappeared and the text is over the pictures." Something was updated last week. Nobody changed the design. Yet the phone layout is wrong, and since most visitors are on phones, most visitors are seeing it.

This is a common rescue and it has a short list of causes. Here is how to tell them apart and what the fix looks like for each.

#First, rule out your own phone

Before anything else, open the site in a private or incognito window on the phone, or on a different phone. If it looks right there, the problem is a cached copy on your device, not the site. Clear the browser cache or wait; it resolves itself.

If it is wrong in a private window on two phones, it is real.

#Cause 1: a stale cached stylesheet

The most common cause after an update. The update changed the site's CSS, but a caching layer, a plugin, the host or a CDN, is still serving the old version to some visitors, or is serving the new HTML with the old CSS. The two no longer match, and the phone layout, which depends on the most CSS rules, breaks first.

Confirm: the problem is inconsistent, some pages or some devices fine and others not, and it appeared immediately after an update.

Fix: clear every cache. The caching plugin, the host's cache, the CDN. Then reload in a private window. If that fixes it, the update itself was fine; the cache just needed clearing, which should have happened automatically and did not. Check the caching plugin's settings so it purges on update in future.

#Cause 2: the theme was updated and lost customisations

If the site's customisations were made directly to the theme's files rather than in a child theme, a theme update overwrites them. The desktop layout may survive because it is mostly the theme's default; the mobile tweaks that were added by hand are gone.

Confirm: the theme was updated recently, and the site looks like the theme's demo on a phone rather than like your site.

Fix: restore the customisations, properly this time, in a child theme or in the customiser's additional CSS, so the next update does not remove them again. If there is a backup from before the update, the old theme files show what was changed. This is an hour or two for a competent developer.

#Cause 3: a plugin's stylesheet is fighting the theme

A plugin update shipped new CSS that applies more broadly than it should: a form plugin restyling all buttons, a gallery plugin setting the width of every image, a cookie banner pushing the header down. Desktop may absorb it; mobile does not.

Confirm: in the browser's inspector, the broken element's styles come from a plugin's CSS file. Deactivating that plugin on a staging copy fixes the layout.

Fix: narrow the plugin's CSS to its own elements with a few lines of override, or roll the plugin back and report it to the author. Do not deactivate a plugin the site needs as the permanent fix.

#Cause 4: a page builder or block update changed how it renders

Elementor, Divi, WPBakery and the block editor itself change their output over time. An update can change how columns stack on mobile, how spacing is calculated, or which breakpoints exist, and a layout built by hand for the old behaviour comes out differently.

Confirm: the builder was updated; the builder's own changelog mentions responsive or layout changes; the problem affects pages built with it and not, say, the blog.

Fix: open the affected pages in the builder and correct the mobile settings, which usually means re-setting column behaviour and spacing at the mobile breakpoint. Tedious across many pages. Sometimes the builder offers a compatibility setting that restores the old behaviour.

#Cause 5: something new was added to the header

A new script, banner or widget, a chat bubble, an announcement bar, a consent banner, was added around the same time and it is what is covering or pushing the content on small screens. Not an update in the strict sense, but it arrives the same way.

Confirm: the problem is at the top of the page, and removing the new element on staging fixes it.

Fix: position or size the new element correctly for phones, or move it.

#Cause 6: a PHP or WordPress core update changed markup

Rarer. A core update changes the HTML output of a block or a menu; a PHP update triggers an error that stops part of the page rendering, and the phone layout, being the more fragile, breaks visibly.

Confirm: the error log shows a warning or error at the time of the update.

Fix: address the error; update the theme or plugin that emits it.

#How a proper fix goes

1. Reproduce it on a staging copy.
2. Identify the cause from the list above, using the inspector and the error log rather than guessing.
3. Apply the fix on staging and check every key page on a real phone, not just the emulator.
4. Apply to live, clear caches, check again.
5. Do the preventative part: child theme, cache purge on update, updates on staging first.

Two to four hours for most cases, more if a page builder needs many pages re-set. And it is a strong argument for testing updates on staging before they go live, because every one of the causes above would have been caught there, on a Tuesday afternoon, rather than by a customer on a Saturday. If you are looking at a broken phone layout now, the private-window test and a cache clear are the two things to try before calling anyone, and a diagnosis is the next step if they do not resolve it.