If your Elementor pages moved to a new host or domain and now show plain, unstyled HTML — content in the right order, but no design — the cause is almost always that Elementor's generated CSS still references the old site URL, or the site URL itself wasn't fully updated everywhere WordPress stores it. This is a known, well-documented side effect of migrating an Elementor site, and it's fixed without rebuilding anything.

Symptoms

  • Pages display their text and images in the correct structure, but with no Elementor styling applied — default browser fonts, no spacing, no colors.
  • The issue affects the whole site uniformly right after a domain change, host migration, or moving from a staging URL to the live URL.
  • Browser DevTools show 404 errors for CSS files under a path like /wp-content/uploads/elementor/css/, or those requests point to the old domain instead of the new one.
  • The Elementor editor itself still shows correct styling when editing a page, even though the live front end doesn't.

Likely causes, in order of how often they actually happen

  1. Elementor's per-page CSS files were generated before the migration and still reference the old site URL. Elementor caches generated CSS as static files (and/or inline, depending on your CSS Print Method setting) tied to the URL that was active when they were created; after a URL change, browsers request those cached files at paths that no longer resolve correctly.
  2. The site URL wasn't updated everywhere it's stored, only in wp-config.php or only in one of the two URL fields. WordPress stores the site URL in the wp_options table (siteurl and home), and some migration tools or manual processes update only one of these, or update the database but leave old-URL references inside serialized data (widget settings, Elementor's own JSON page data) unchanged.
  3. The CSS Print Method setting (external vs. inline) is mismatched with how your new host serves static files, which is a secondary, less common cause — external CSS files can fail to generate or serve correctly on hosts with stricter file-write permissions or different caching layers than the original host.

Fix it: lowest-risk steps first

Step 1 — Regenerate Elementor's CSS and cached data

This is the safest, most direct fix and resolves the issue in most migration cases on its own.

  1. Go to Elementor → Tools → Regenerate CSS & Data Files (labeled Regenerate Files on some Elementor versions, under the General tab of Tools).
  2. Click the button and wait for it to finish — Elementor will delete its existing generated CSS files and rebuild them fresh, using the site's current URL and settings.
  3. Reload the front end in an incognito/private window (to avoid your browser serving a cached copy of the broken CSS) and check whether styling has returned.

Step 2 — Confirm the site URL was updated everywhere, not just in wp-config.php

If Step 1 alone didn't fix it, the underlying URL references are likely still wrong somewhere Elementor's regenerated CSS is pulling from.

  1. Go to Settings → General in wp-admin and confirm both WordPress Address (URL) and Site Address (URL) show the correct new domain.
  2. If you used a migration plugin, confirm it actually ran a full search-and-replace across the database — not just updated these two option fields. Old URLs left inside serialized Elementor page data (stored per-page as _elementor_data) can cause broken image paths and, in some cases, styling that depends on dynamically generated CSS values (like a background image URL used in a widget's style settings).
  3. If you migrated manually (database export/import without a dedicated migration plugin), run a proper serialized-data-safe search-and-replace tool for the old-to-new URL change — a plain find-and-replace in a text editor can corrupt PHP's serialized data format and cause worse problems than missing CSS.
  4. After confirming the URL is consistent everywhere, repeat Step 1's CSS regeneration once more so the freshly corrected data is used to rebuild the CSS files.

Step 3 — Check the CSS Print Method setting

If styling is still incomplete or inconsistent after Steps 1 and 2:

  1. Go to Elementor → Settings → Advanced and find CSS Print Method.
  2. If it's set to External File, try switching it to Internal Embedding temporarily and reload the front end. If styling appears correctly with Internal Embedding but not External File, your new host has a file-write-permissions or static-file-serving difference from your old host that's preventing Elementor's CSS files from generating or being served correctly.
  3. If Internal Embedding fixes it, you can either leave it that way (it works reliably everywhere, at a small cost to page-load caching efficiency) or investigate your new host's file permissions on wp-content/uploads/elementor/ to restore External File mode, which is generally the better long-term option for performance.

Verify the fix

  1. Load several different pages across the site (home, a standard page, a Theme Builder template if you use one) in an incognito window and confirm styling is intact on all of them, not just one.
  2. Check DevTools' Network tab for any remaining 404s on CSS file requests.
  3. Clear any external caching (a CDN like Cloudflare, or a caching plugin) since those can continue serving the old broken CSS even after Elementor has regenerated it correctly on the server.

If you need to roll back

Regenerating CSS in Step 1 is non-destructive — it only rebuilds generated style files from your existing page designs, it does not alter your actual page content or Elementor data, so there's nothing to "undo" if it doesn't help. If a serialized-data search-and-replace tool in Step 2 was run and something looks wrong afterward (broken shortcodes, garbled widget settings), restore from the full backup taken before starting, since a bad search-and-replace is the one step here that can genuinely corrupt data if not done with a serialization-aware tool.

Related fixes

FAQ

Do I need to regenerate CSS after every migration, even if styling looks fine?

It's good practice to run it once after any domain or host change regardless of whether you've noticed a problem yet, since some CSS references (particularly ones involving dynamic values like background images) can be broken in ways that aren't immediately obvious on every page.

Will regenerating CSS affect my custom CSS added through Elementor's Custom CSS panel?

No. Custom CSS you've added per-widget, per-page, or globally through Elementor Pro's Custom CSS features is stored as page/site data, not as part of the generated cache files — regenerating only rebuilds the compiled output, it doesn't touch or remove anything you wrote.

I regenerated CSS and updated the URL, but a few specific pages are still unstyled — why?

Those specific pages likely still have a stale _elementor_data reference to the old URL (commonly inside a background image path or a dynamic tag) that a sitewide search-and-replace missed if it wasn't fully serialization-aware. Open each affected page in the Elementor editor, re-save it (even without changes), and it will often regenerate its own CSS correctly with the current URL.

Should I switch CSS Print Method to Internal Embedding permanently to avoid this in future migrations?

It's not necessary if you simply remember to regenerate CSS after every future migration — External File mode is generally better for page-load performance since browsers can cache a separate CSS file. Only stick with Internal Embedding permanently if your specific host has an ongoing issue serving Elementor's generated static files correctly.