When a WordPress site looks broken—unstyled text, stacked layout, missing icons, or a theme that “vanished” after an update—the HTML is often still loading. What failed is usually one or more stylesheets (or fonts/scripts the theme needs). That feels like a total outage to visitors, but it is a different problem from a blank page or a 404 on every post.
Work this checklist in order. Prefer staging when you can reproduce the unstyled view there. Take a backup before changing Site URL options, minifier settings, or theme files on production. If browser tools show active mixed-content blocks after an HTTPS change, finish that branch with the mixed content / SSL checklist—this article stays symptom-led and only points there. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Confirm the page returns content (you can read text) but layout/styles are missing—not a white screen, not a redirect loop, not every URL 404ing.
- Note when it started: after a theme/plugin update, a cache/CDN change, an SSL/HTTPS cutover, or a migration.
- Check whether Admin looks normal while the front is broken (or both). Admin-only vs front-only narrows cache and theme enqueues.
- If pretty URLs 404 while the homepage “looks” odd, fix rewrites with posts 404 / permalinks first. If the browser reports a redirect loop, use too many redirects.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Unstyled HTML; Network shows CSS 404, blocked, or a 200 that is not real CSS | Asset URL / HTTPS / wrong response body | DevTools → Network → CSS; confirm status, text/css, and CSS in the response body; check Console |
| Broken in one browser, fine in incognito | Local or page cache | Hard refresh; purge page cache/CDN; retest logged out |
| Started right after HTTPS or domain change | Site URL or mixed content | Confirm siteurl vs home with your host; then mixed-content checklist if CSS is HTTP on HTTPS pages |
| Started after theme update or “optimize CSS” plugin | Theme build / minify | Disable minify/concat as a test; reinstall/recompile theme assets on staging |
| CSS URL points at old domain or wrong subdirectory | WordPress Address / Site Address mismatch | WordPress Address (siteurl) = core files location; Site Address (home) = public URL—confirm both with host before changing |
Safe diagnostic order
- Treat the browser Network tab and Console as ground truth. Open the broken page → DevTools → Network → filter CSS (and Fonts if icons/type are wrong). Reload. Note each stylesheet URL, status, and Content-Type. Open the response body: confirm the stylesheet response contains CSS and is served as
text/css. An HTML error or login page can return HTTP 200 and still break the layout. Check Console for blocking errors (mixed content, CORS, failed modules).
- Hard-refresh and retest in a private/incognito window logged out. Rule out a stale local cache or an Admin bar / logged-in cache variant before you change the server. Verify the layout is restored while logged out before you declare a fix.
- Purge layers one at a time. Purge the page cache plugin, then the host cache, then the CDN—retesting the front after each. Do not flip every cache switch at once or you will not know what fixed it.
- If CSS requests are blocked as mixed content, stop expanding this checklist and use mixed content and SSL errors for leftover HTTP asset URLs and certificate issues. Come back here only if styles still fail after HTTPS asset URLs return real CSS.
- Verify WordPress Address and Site Address carefully. WordPress Address (siteurl) must match where the WordPress core files live; Site Address (home) must match the public site URL. They can differ when WordPress lives in a subdirectory. Confirm both paths with your host before changing them; back up first. Purge caches after any change. Redirect loops from URL fights belong on too many redirects.
- Turn off CSS/JS minify or “combine” plugins as a test. On staging first when you can. Aggressive concat/minify can point at missing hashed files after a theme deploy. Leave the minifier off until the theme’s raw CSS returns a real
text/css body (not merely status 200), Console is clear of blocking asset errors, and the layout is restored while logged out—then re-enable carefully.
- Check the active theme’s assets after an update. A theme update or failed deploy can omit
style.css, a built dist/ CSS file, or a child-theme enqueue. On staging, switch to a default theme briefly only as a diagnosis (expect layout change); if default themes style correctly, repair or reinstall the broken theme’s files from a trusted package—do not hot-edit production build artifacts without a backup.
- Retest the full path. Homepage, a post, a template that looked worst, and Admin. Confirm the stylesheet response contains CSS and is served as
text/css, check Console for blocking errors, and verify the layout is restored while logged out. Purge CDN once more so visitors are not still on the unstyled cache.
Common causes
- Page cache or CDN still serving HTML that points at purged or old CSS hashes.
- HTTP stylesheet URLs on an HTTPS site (mixed content)—see the dedicated SSL article.
- WordPress Address / Site Address pointing at the wrong core path or public URL after migration (including subdirectory installs).
- A “CSS” URL that returns 200 with an HTML error or login body instead of
text/css.
- Theme update or build pipeline missing compiled CSS.
- Minify/concat plugins referencing files that no longer exist.
- Security or hotlink rules blocking
/wp-content/themes/…/*.css.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help restoring styles on one WordPress site where the HTML loads but stylesheets fail—identifying the failing CSS URL, confirming the response is real CSS (text/css, not an HTML 200), clearing the right cache layer, correcting WordPress Address / Site Address with host confirmation, or fixing a bounded theme/minifier break until Console is clean and the layout is restored while logged out. Paste what changed just before the break and one failing CSS URL from DevTools if you have it. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full redesigns, custom theme rebuilds, account-wide CDN redesigns, and unrelated feature work are outside this offer. Certificate and mixed-content remediation details live on mixed content and SSL errors.
Related checks
If styles still fail after these checks, send your host one failing CSS URL, its status and Content-Type from DevTools, whether the response body is CSS or HTML, whether the page is HTTPS, and the start time. Suspected compromise needs a security investigation as well as restoring theme assets.