Font problems in Elementor in published site

Having built a beautiful site in a staging environment, I pushed it live to a new domain and changed the old URL to the new one using Search and Replace. As I have done hundreds of times. But on this occasion, the Google fonts weren’t changing as they should have.

This was the first time (I think) that I’ve tried a wholesale rebuild in Elementor. I’m aware that I have to do an Elementot> Tools > Reset Files and Data every so often. But even that didn’t do the trick. Clearing the cache was similarly ineffective.

Eventually, I tried using Elementor’s own Replace URL function in Tools. As expected, it told me that 0 rows were changed in the database. Naturally. But I then regenerated data and files. And that worked! A bit of investigating explained why, if you’re interested.

The Elementor Cache and File System Lock

When Elementor builds a page, it saves the design data (which includes font selections) in two places:

  1. The Database (wp_postmeta table): This is the serialised data where the raw Elementor design settings live.
  2. Generated CSS Files (Disk Cache): For performance, Elementor takes the styling from the database and compiles it into static CSS files, often stored in the wp-content/uploads/elementor/css/ directory. These files contain the absolute URLs (http://temp-domain.com/...) for self-hosted fonts or font-related CSS imports.

What Happened For It To Work:

  1. Search & Replace: The plugin only modifies the database (the serialised data). It successfully updated the database records to the new domain. This is why the Elementor tool reported 0 changes—the database was already clean.
  2. Elementor Replace URL (The Fix): The function of Elementor’s Replace URL tool isn’t just to update the database (which was already done); it’s to trigger the regeneration logic for its internal files. When you run this tool, even with 0 database changes:
    • It calls the function to clear or invalidate Elementor’s file cache.
    • The subsequent Regenerate CSS & Data step forces Elementor to look at the now-correct URLs in the database and write new CSS files to the disk using the correct live domain (https://your-new-domain.com).

The old, broken font references were locked away in those static Elementor CSS files on the server, and only Elementor’s internal regeneration process could unlock that and write the corrected files.