How to fix a site that loads without styling

The page has loaded, but nothing about it looks right. Text is stacked top to bottom in one column, everything is black on white, links are the default underlined blue. That is not a broken website — it is a website whose HTML loaded successfully and whose CSS did not. The browser rendered exactly what it was given, and what it was given was structure with no styling attached to it.

This is one of the easier problems to diagnose precisely, because the browser itself will tell you which file failed and why, if you know where to look.

Confirm what's actually failing

Open the page and press F12 (or right-click and choose Inspect) to open developer tools, then switch to the Network tab and reload the page with that tab open. Filter by CSS. You are looking for one of two things:

• A stylesheet request with a red status — 404 (not found), 403 (forbidden), or it never completes at all.
• No CSS request listed whatsoever, which means the page never asked for the stylesheet in the first place.

Click the failing request and note the exact URL and status code. That single detail points straight at the cause.

The usual causes, in order

1. Mixed content — an HTTP stylesheet on an HTTPS page

This is the single most common cause after a site moves to SSL. If your page loads over https:// but a stylesheet is linked as http://yourdomain.com/style.css, the browser refuses to load it and gives no visible error on the page — only a console warning. Search your theme or template files for hardcoded http:// links and change them to https://, or better, to a protocol-relative or root-relative path such as /wp-content/themes/yourtheme/style.css.

On WordPress specifically, this is frequently caused by an old value in the Site Address setting, or by content saved with absolute HTTP URLs baked into the database before the SSL migration happened.

2. The stylesheet's path is wrong or the file has moved

A 404 on the CSS request means the browser asked for a file at a specific address and nothing was there. This happens after a theme change, a migration, or a manual reorganisation of files. Check the exact path in the failing request against what actually exists in your file manager — a single renamed folder or a changed file name is enough to break every page on the site at once.

3. A caching layer is serving a page that references a build that no longer exists

Sites using a build process or a caching plugin often name their compiled stylesheet with a version hash, such as style.a1b2c3.css. If the page HTML is served from a cache that predates a theme or plugin update, it can reference a hash that has since been replaced. The fix is to clear the site's cache — from within the caching plugin or your control panel's caching tools — so the page and its asset references are regenerated together.

4. File permissions are blocking the request

A 403 Forbidden on a CSS file specifically (rather than on the whole site) usually means the file's permissions do not allow the web server to read it. CSS and other static files should be 644 — owner can write, everyone else can read. Anything more restrictive blocks the request; anything looser, such as 777, is a security risk many servers will refuse outright. Check the file's permissions in your control panel's file manager and correct them if they are wrong.

5. A rule in .htaccess is blocking the file or its folder

A security rule intended to block direct access to a sensitive folder can accidentally catch your assets folder too, especially after copying a rule from a different site. Look through .htaccess for any Deny, RewriteRule or <FilesMatch> block that mentions .css or the folder your stylesheet lives in. Our guide on fixing a broken .htaccess file covers how to isolate a bad rule safely.

6. Case sensitivity

Linux servers, which is what almost all web hosting runs on, treat file names as case-sensitive. A stylesheet linked as Style.css will not be found if the actual file on disk is style.css. This passes unnoticed on Windows or Mac development machines, where the file system is not case-sensitive, and then breaks the moment the site is uploaded to a live server.

If the site works for you but not for a visitor

This points at caching rather than a genuinely broken stylesheet — either their browser holding an old copy, or a CDN or caching layer serving a cached version of the page from before a fix was applied. Ask the person seeing the problem to try a hard refresh (Ctrl+F5 on Windows, Cmd+Shift+R on Mac) before assuming the fix has not worked.

If you're still stuck

Send us the exact URL of the failing stylesheet from the Network tab, along with its status code, and the page it was meant to load on. That is enough for support to check server-side logs and file permissions directly rather than guessing from a description of "the site looks wrong".

You can raise this with our support team at any time, and if you are unsure how to describe what you're seeing, our guide on reporting a problem so it gets fixed fast walks through exactly what to include.