Why Fonts Break After a Website Migration (How to Fix It)

Migrating a WordPress site to a new domain or server can be exciting—but it’s not without hiccups. One common issue developers and site owners face post-migration is broken fonts or missing icons. Fonts may be replaced by strange symbols, or icon fonts like Font Awesome may disappear altogether.

In this post, we’ll explain why this happens, how to identify the issue, and how to fix it effectively.

Symptoms of Broken Fonts After Migration

After a site migration, you might notice:

• Custom fonts no longer loading
• Icons replaced by boxes, squares, or question marks
• Random characters appearing in place of navigation icons
• Console errors referencing .woff, .woff2, or .ttf files (404 errors)

These are strong signs that your site is failing to load font files correctly.

Why Fonts Break During Site Migration

Here are the most common causes:

1. Wrong File Paths or URLs
   • The migration may result in broken links to your font files (e.g., /oldsite/wp-content/themes/fonts/font.woff2 no longer exists).
   • Font files may still point to the old domain or incorrect subdirectory.
2. Missing Font Files
   • Some migration tools skip non-essential or non-WP core files like fonts or icons.
   • Files in folders like /wp-content/themes/your-theme/fonts/ may have been left behind.
3. MIME Type or CORS Policy Restrictions
   • Your new server may block font loading due to MIME type misconfiguration or CORS headers.
4. Caching Issues
   • The browser might still be referencing cached paths or outdated resources.

Step-by-Step Troubleshooting Guide

1. Clear Cache and Reload

Before jumping to conclusions, do a hard refresh:

• Press SHIFT + F5 or CMD + SHIFT + R to bypass the cache and reload the page.

Also, clear any server-side or plugin-based cache (e.g., WP Super Cache, W3 Total Cache).

2. Open the Developer Console

To inspect what’s actually failing:

• Right-click anywhere on the page → click Inspect
• Navigate to the Console tab
• Look for any errors in red, especially ones that mention .woff, .woff2, .ttf, or .eot

Also check the Network tab (filter by “Font”) to see if any font requests are returning 404 Not Found or 403 Forbidden.

3. Verify Font Files Exist on the Server

Using FTP (like FileZilla), your hosting control panel, or a WordPress File Manager plugin, navigate to:

/wp-content/themes/your-theme/fonts/

Are the font files there? If not, they may have been skipped during migration.

Solution: Re-upload missing font files from your original site backup or theme zip file.

4. Check URL and Path Settings

Ensure font files are being called from the correct location.

If the site URL or theme path changed, hardcoded links to font files may now be incorrect.

Fix: Search your theme’s CSS files (e.g., style.css, custom.css) for any font URLs and update them to use get_template_directory_uri() or relative paths instead of hardcoded ones.

Example before:

@font-face {
  src: url('http://oldsite.com/wp-content/themes/theme/fonts/customfont.woff2');
}

Update to:

@font-face {
  src: url('../fonts/customfont.woff2');
}

5. Temporarily Switch Fonts (Font Refresh Hack)

Sometimes WordPress or your theme stores fonts in generated folders. Here’s a clever way to trigger a font refresh:

a. Temporarily Change Fonts:
Go to:

Appearance → Customize → Typography

Temporarily switch to a different font. Save & publish.

b. Remove Old Font Files:
Using your file manager, navigate to your theme’s /fonts/ folder.
Delete the old font folders.

c. Switch Back to Your Original Fonts:
Go back into the customizer, select your original font again, and save. This will regenerate the correct font files.

6. Check MIME Types or CORS Headers (Advanced)

If fonts still aren’t loading, your server may be blocking them.

Make sure your .htaccess file (on Apache) or NGINX config includes the correct MIME types:

AddType application/font-woff .woff
AddType application/font-woff2 .woff2

And for CORS:

<IfModule mod_headers.c>
    <FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

This allows font files to be loaded across different domains or subdomains.

Broken fonts post-migration can be annoying, but they’re rarely permanent. In most cases, it’s a simple file path, caching, or missing file issue.

Quick checklist to fix broken fonts after migration:

• Clear all caches (browser, server, CDN)
• Check for missing .woff/.woff2 files in /fonts/
• Use browser console to spot 404/403 errors
• Temporarily change and reapply fonts
• Ensure correct MIME types and CORS headers are set

By following the steps above, your fonts should be restored quickly and reliably.

Have you experienced this issue after migrating your site? Share your experience or drop any questions in the comments below 👇