Yesterday the site had your colours, your fonts, a header across the top and neat columns. Today it opens as a long white page of plain text: the menu is a bulleted list, links are blue and underlined, images are stacked one under another at odd sizes, and the footer has wandered up into the middle. It looks the same on your laptop, your phone and your colleague’s computer.
That pattern, where the styling has gone everywhere at once, nearly always means the browser is getting the page content but not the stylesheets that dress it. The content is still there. Your posts, products and pages are not lost. Something between WordPress and the browser has stopped the design files arriving or applying. If instead the desktop view is fine and only phones look wrong, you are dealing with a different fault, and our page on repairing a WordPress site that breaks only on phones is the right one. Both sit within our wider guide to common WordPress errors.
What “the layout is broken” usually means
Owners describe this in a few different ways, and the description helps narrow down the cause.
- Completely unstyled. Plain text, default fonts, no colours. The main stylesheet is not loading at all.
- Half styled. Colours and fonts are right, but sections built in a page builder have lost their spacing, backgrounds or columns. The builder’s own generated CSS is missing or out of date.
- Styled but wrong. The design has shifted: a different header, widgets in odd places, buttons in the wrong colour. This tends to follow a theme update or a theme being switched.
- Broken only for visitors. When you are logged in it looks fine, but logged out it falls apart. That points firmly at caching or optimisation.
The common causes, roughly in the order we find them
A cache or minification plugin serving files that no longer exist
Performance plugins often combine your stylesheets into one or two new files and point every page at them. If the cache of pages is kept but the combined files are cleared, or a plugin update changes where they are stored, cached pages keep asking for CSS files that are gone. The browser gets a 404 for the stylesheet and shows the raw page. Clearing all caches, in the plugin, at the host and at any CDN, fixes this more often than anything else. Our post on clearing each layer of WordPress caching explains the order to do it in.
The site moved to HTTPS, a new domain or a new host
If the WordPress Address and Site Address under Settings, General still point to the old domain or to http rather than https, stylesheets can be requested from the wrong place. Browsers also block stylesheets loaded over http on a page served over https. That is called mixed content, and our article on mixed content warnings after switching to HTTPS covers it in detail. Layouts that collapse right after a move often come with other faults too, such as broken internal links or images pointing at the old domain.
A theme update overwrote direct edits
When someone edits a theme’s style.css or template files directly instead of using a child theme, the next update replaces those files with fresh copies and every change disappears. The site still has styling, just not yours. This is one of the most avoidable causes, and the fix is to rebuild the changes in a child theme so updates can run safely again. If the breakage appeared the moment an update finished, see our page on sites that break after an update.
The page builder’s CSS needs regenerating
Elementor, Divi and similar builders save design settings in the database and write CSS files from them. After a migration, a URL change or a cache clear in the wrong order, those files can be missing or still point to old addresses. Many builders have a setting to regenerate their CSS; Elementor, for example, has one under its Tools screen. When that does not help, we look at how the builder is set to output CSS and whether a plugin is interfering. There are separate pages for Elementor faults and for Divi, WPBakery and other builders.
Files the server refuses to hand over
Wrong file permissions after a restore, a security plugin rule, hotlink protection at the host or a CDN setting can all block requests for CSS files while the pages themselves load. The browser receives a 403 instead of the stylesheet. Our post on WordPress file and folder permissions explains what correct permissions usually look like.
Web fonts and icon fonts blocked
If the layout is mostly intact but icons show as squares and headings fall back to a plain font, the font files are the issue rather than the stylesheet. That usually comes down to how the font files are served, or a security or CDN rule blocking them from another domain.
What you can check before anyone touches the site
These checks only look; they change nothing.
- Log out, or use a private window. If the site looks fine logged in and broken logged out, tell whoever fixes it. That one detail usually points straight at caching.
- Open the browser console. In Chrome or Firefox, right-click the page, choose Inspect, and look at the Console tab. Red lines mentioning a .css file with 404, 403 or “mixed content” tell you which kind of fault it is. A screenshot of that panel is very useful to a developer.
- Check Settings, General. If you can reach the dashboard, look at the WordPress Address and Site Address. Do not change them unless you are sure; a wrong value there can lock you out of wp-admin. Just note what they say.
- Note the last change. An update, a new plugin, a hosting move, an SSL certificate installed, a CDN switched on. Most layout breakage starts at a specific moment.
- Clear caches you know how to clear. If you have a caching plugin with a clear-all button, use it, then check again in a private window. That is low risk and often enough.
If that does not bring the design back, stop there. Reinstalling the theme, switching themes to “test”, or deleting the optimisation plugin can each make things worse: switching themes changes widget and menu assignments, and reinstalling a theme without a child theme wipes any direct edits that were still there. Copy the whole site, files and database, before anything more involved is tried.
How we fix a broken layout
The first step is reading what the browser says. The network panel shows every stylesheet the page asks for and what the server returned for each. A missing file, a blocked file and a file served from the wrong domain look different there, and each leads to a different fix. That usually tells us more in a few minutes than trying things one by one.
Then we confirm where the fault sits. We compare a cached page with a fresh one, check the site URLs in the database, check whether the theme files match an untouched copy of that theme, and see whether the builder’s generated CSS exists and is current. Where the site has a staging copy, or we can make one, we test the fix there first.
The repair itself depends on the cause. Caches get cleared in the right order and the optimisation settings that produced dead file references get corrected. Mixed content gets fixed at the source, in the settings and the database, not hidden behind a plugin that rewrites addresses on every page load. Lost theme edits get rebuilt in a child theme. Builder CSS gets regenerated, and if it keeps going missing we look for the plugin or setting that removes it.
Afterwards we check the main templates logged out, on desktop and phone: home, a standard page, a blog post, and for a store, the shop, product, cart and checkout pages. You get a plain explanation of what broke and how to avoid it next time.
When a broken layout is more than a styling fault
Now and then, unstyled pages arrive together with other strange signs: unfamiliar text or links at the top or bottom of pages, redirects to other sites, or new admin users. Injected code can break page structure as a side effect, and in that case the job is a cleanup, not a layout repair. We would tell you if we saw that, and point you to our hacked website repair work.
If the layout breaks every time something is updated, the site likely has a fragile setup underneath, such as direct theme edits or an old builder add-on. A one-off fix under our WordPress bug fixing service covers the immediate problem, and we will say plainly if a sturdier setup would save you from the next one.
To get started, drop us a WhatsApp message (the contact form works too) with the site address, a screenshot of the unstyled page and, if you managed it, the console panel. We will look first, be straight about what we find and when we can begin, and copy the site before touching a file.