WordPress CSS Not Loading? How to Fix a Broken Layout After an Update

Your site suddenly looks like a document from 1995: plain text in a default font, images at full size, navigation menus displayed as bulleted lists of links, and no colors or layout. The content is all there. The styling is gone.

CSS (Cascading Style Sheets) is the set of files that tells the browser how everything should look. When a page loses all its design at once, one or more of those files is not arriving. The cause is almost never the content itself. It is a cache serving references to files that no longer exist, a wrong address, a permissions problem or a rule blocking the request. The fastest fix is to find exactly which file fails and why.

Before you start

• Access you need: a desktop browser with developer tools, WordPress admin, your caching plugin and CDN dashboards, and SFTP or SSH (WP-CLI helps).
• Test in a private window throughout, so your browser’s cache does not hide your progress.
• Note what changed: a plugin or theme update, a new optimization setting, a migration, a CDN change.
• Where to run the commands. Commands in gray boxes (wp, find, ls) run in an SSH terminal, from the site’s folder: the one that contains wp-config.php and wp-content. Most hosting panels offer a terminal or SSH access; on some hosts the command is wp-cli instead of wp. Replace example.com with your own domain wherever it appears.

Step 1: Find the CSS file that fails

Open the broken page, press F12 to open developer tools, choose the Network tab, click the CSS filter and reload. Every stylesheet the page requests is listed with a status code:

• 404 Not Found: the HTML references a file that does not exist. Usually a stale cache pointing to an old combined file, or files lost in a migration. See Steps 2 and 3.
• 403 Forbidden: the file exists but the server refuses to send it. Permissions, ownership or a security rule. See Steps 5 and 6.
• (blocked:mixed-content): the page is HTTPS but the CSS is requested over http://. See Step 3.
• 200 but still unstyled: check the response. If the Console shows Refused to apply style … because its MIME type (‘text/html’) is not a supported stylesheet MIME type, the server returned an HTML page (often a 404 page, login page or security challenge) instead of CSS. Click the file and look at the Response tab to see what came back.

Look at the failing file’s full URL. Is it on the right domain? Does it use https? Is it a combined or minified file with a long random name, or a builder-generated file? Those details tell you which step applies.

Step 2: Purge stale caches together

This is the most common cause after an update. Optimization plugins combine and minify CSS into new files with generated names. The page cache stores HTML that references those names. When the plugin regenerates its files (after an update or a cache purge) but the page cache, server cache or CDN still serves old HTML, the HTML points at files that no longer exist, and you get 404s.

Purge everything at once, in this order:

1. The optimization plugin’s combined and minified files.
2. The page cache (caching plugin and any server-level cache your host runs).
3. The CDN.

Then test in a private window. If the site comes back but breaks again after a while, turn off CSS combining and minifying in your optimization plugin and test again. On modern HTTP/2 hosting, combining files gives little benefit and causes much of this trouble. “Remove unused CSS” features can also strip styles that are only used on some pages or after interaction.

Step 3: Check the site address and mixed content

WordPress builds stylesheet URLs from its own address settings. If those are wrong, every CSS link points to the wrong place. With WP-CLI:

wp option get siteurl
wp option get home

Type these as shown: siteurl and home are the names of the settings, and each command prints one address. Both should be your real, current address, usually https://example.com. If they show an old domain, a staging address or http://, fix them in Settings, General, or with wp option update siteurl 'https://example.com' and wp option update home 'https://example.com', replacing https://example.com with your real address (no slash at the end) and keeping the quote marks. Check wp-config.php too: WP_HOME or WP_SITEURL constants override the database.

If the site address is right but individual stylesheet URLs still use the old domain, those URLs are stored in the database or in generated files. Run a search and replace with a dry run first (see FG-08 for the exact commands), then regenerate builder CSS.

Step 4: Regenerate builder CSS

If the failing file is generated by your page builder, it may be missing or out of date. Builders write their CSS under wp-content/uploads (for example, Elementor uses wp-content/uploads/elementor/css/) or a cache folder such as Divi’s wp-content/et-cache/. Regenerate from the builder’s tools screen: Regenerate CSS Cache in Breakdance, Regenerate CSS & Data (or Clear Files & Data) in Elementor, or the Static CSS File Generation clear button in Divi. FG-07 covers this in detail. If regeneration does not create the files, check that the folder is writable (Step 5) and that the disk is not full.

Step 5: Check file permissions and ownership

If CSS files return 403, the web server may not be allowed to read them. This often happens after files were uploaded or restored by a different user (for example root on a VPS). On most Linux hosting, the standard permissions are 644 for files (owner can write, everyone can read) and 755 for folders. To reset them inside wp-content over SSH:

find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Type both lines exactly as shown, from the site’s folder. -type d picks folders and -type f picks files; -exec chmod ... {} \; runs chmod on each one, with {} standing for each path and \; marking the end, so keep the backslash and semicolon. No output means it worked. Limit this to wp-content; some hosts deliberately set stricter permissions on wp-config.php. Ownership matters as much: files should belong to the site’s own system user, not root. Run ls -l wp-content (or the folder holding the failing CSS) and read the third column, which is the owner. If it shows files owned by a different user, ask your host to fix ownership, or do it yourself if you manage the server. Never set files to 777; it allows any process on the server to modify them.

Step 6: Check security rules and hotlink protection

A 403 with a styled error page, or a response that mentions a firewall or ModSecurity, means a security layer blocked the request. Common culprits are web application firewall rules (the server’s ModSecurity, a security plugin, or the CDN’s firewall), hotlink protection that only allows your main domain (so CSS on a CDN hostname or the www variant is blocked), and .htaccess rules that deny certain folders. Your host can look up the rule that fired in the server logs if you give them the exact URL and time. Do not turn off a firewall entirely to test on a live site; ask for the specific rule to be adjusted.

Step 7: Check where custom CSS lives

If the layout is mostly fine but your custom styles vanished after a theme update, the CSS was probably added to the parent theme’s style.css, and the update overwrote it. Theme updates replace the theme’s files completely. Restore the lost CSS from a backup and move it to a child theme, the Customizer’s Additional CSS, or your builder’s global styles, all of which survive updates.

Step 8: Check the CDN

If the failing files load from a CDN hostname, request one directly from the origin by replacing the CDN hostname with your site’s own. If the origin copy works, the CDN is the problem: purge it, check that its origin setting points to your current server, and confirm any CDN rewrite plugin uses the right CDN hostname.

When to contact your host

Contact your host when CSS returns 403 and permissions look right, when you suspect a server firewall rule, when files cannot be written or regenerated, or when the disk may be full. Send them:

• The exact URL of the failing CSS file and the status code it returns.
• The time you reproduced it, with your time zone.
• Any console messages, such as MIME type or mixed content errors.
• What you already tried: cache purges, combine and minify turned off, CSS regenerated, permissions reset.