Website Fonts Showing as Times New Roman? How to Fix Missing Fonts

Your headings and body text suddenly appear in Times New Roman, or another plain serif font, instead of your brand fonts. Sometimes it happens on every page after a migration, sometimes only in one browser, sometimes only on some devices.

Times New Roman is the default font in most desktop browsers. When you see it where your brand font should be, the browser tried to load your font file, failed, and had nothing else to use. Your design is intact. One file is not arriving, or the CSS is asking for a font by a name that does not exist. The steps below find which.

Before you start

• Access you need: a desktop browser with developer tools (Chrome, Edge, Firefox or Safari), WordPress admin, your caching plugin and CDN dashboards, and SFTP or SSH for server-side fixes.
• Back up the database before running any search and replace (Step 3).
• Test in a private window so a cached copy does not hide your progress.
• Where things are done. Steps 1, 4 and 5 happen in your browser’s developer tools (press F12). Commands that start with wp run in an SSH terminal from the site’s folder (the one that contains wp-config.php); on some hosts the command is wp-cli instead of wp. Blocks of server rules go into the .htaccess file or the Nginx config, which you edit with the file manager, SFTP or your host’s help. CSS blocks show what your stylesheet should contain, not commands to run.

Step 1: Find the failing font file

Open the affected page, open developer tools (F12), go to the Network tab, click the Font filter and reload. Every font file the page requests appears here. Look at the Status column:

• 200: the file loaded. If the text still looks wrong, skip to Step 5 (name mismatch).
• 404: the file is not at that address. Usually an old URL after a migration or a missing folder. See Step 3.
• 403: the server refused. Hotlink protection, a security rule or file permissions. See Step 6.
• (blocked) or CORS error: the browser refused to use the file. See Step 2 or Step 4.
• No font requests at all: the CSS that declares the font never loaded or was removed. Check the CSS filter too, and see Step 6.

Now open the Console tab. Font problems usually leave a clear message there.

To confirm what the browser is actually drawing, right-click the text, choose Inspect, open the Computed tab in the Elements panel and scroll to Rendered Fonts (Chrome and Edge). Firefox shows the same thing in its Fonts tab.

Step 2: Fix CORS errors

Browsers apply a security rule to fonts: a font loaded from a different origin (a different domain, subdomain, protocol or port) is only used if the server sends permission in an Access-Control-Allow-Origin header. Without it, the console shows something like:

Access to font at 'https://cdn.example.com/fonts/brand.woff2' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

That is an example of the message to look for; your own will name your font and domains. This often catches people out in two situations: fonts served from a CDN hostname, and fonts on www.example.com while the page is on example.com (or the reverse). www and non-www are different origins.

The cleanest fix is to load fonts from the same address as the page: make sure your site address settings use one hostname, and regenerate builder CSS so font URLs match. If fonts must come from another origin, add the header where the font files are served. On Apache or LiteSpeed, in .htaccess:

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

Add it to the .htaccess file in the folder the fonts are served from (usually the site’s main folder), outside the # BEGIN WordPress and # END WordPress lines so WordPress does not overwrite it. Paste it as shown. The "*" lets any site use the fonts; to allow only your own site, replace it with your address, such as "https://example.com".

On Nginx, inside the server block (this needs server access, so ask your host if you do not have it):

location ~* \.(woff2?|ttf|otf|eot)$ {
    add_header Access-Control-Allow-Origin "*";
}

Paste it as shown. Nginx only picks up the change after its configuration is reloaded, which whoever manages the server does.

If you use a CDN, it may need its own setting to pass or add this header, and you must purge the CDN afterward, because it cached the responses without the header.

Step 3: Fix old URLs after a migration

If the 404 font URL contains your old domain, a staging address or http://, the move did not update every reference. Page builders and theme options store full URLs in the database, often inside serialized data (a PHP storage format that breaks if you edit lengths by hand). Use a tool that handles it, such as WP-CLI. Always preview with --dry-run first:

wp search-replace 'https://old.example.com' 'https://example.com' --dry-run --skip-columns=guid
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid

Replace https://old.example.com with the old address exactly as it appears in the failing font URL from the Network tab, and https://example.com with your current address, with no slash at the end of either. Keep the quote marks. --dry-run shows how many replacements each table would get without changing anything; run the second line, which makes the changes, only when those numbers look sensible. --skip-columns=guid leaves the guid column alone, because WordPress uses it as each post’s permanent ID, not as a link. Some builders store URLs with escaped slashes (https:\/\/old.example.com), which a plain search does not match. To catch those too, repeat both lines with the escaped form, for example wp search-replace 'https:\/\/old.example.com' 'https:\/\/example.com' --dry-run --skip-columns=guid. Elementor has its own Replace URL option under its Tools screen for this. After replacing, regenerate the builder’s CSS (see FG-07) and purge every cache, because the generated CSS files still contain the old URLs until they are rebuilt.

Step 4: Check mixed content and security headers

If your site uses HTTPS and a font is requested over http://, browsers block it as mixed content. The Network tab shows it as blocked, and the console mentions mixed content. Fix the URL as in Step 3.

A Content Security Policy (a security header some hosts and plugins add) can also block fonts. The console then says it refused to load the font because it violates the font-src directive. Add the font’s origin to font-src in the policy, wherever it is set (a security plugin, .htaccess or the server config).

Step 5: Check the font name matches

If the file loads with status 200 but the text is still wrong, the CSS is asking for a family name that no @font-face rule declares. Find the @font-face rule (search the CSS in the Sources panel for @font-face):

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

This is an example; "Brand Sans" and the file path stand in for your own font’s name and file. The font-family name used on your headings and text must match the name in your @font-face rule exactly. Renaming a font in a builder’s custom fonts panel, or switching from a Google Fonts version to a self-hosted one with a slightly different name, is a common cause. Also check weights: if your headings use weight 700 and only a 400 file is declared, browsers fake a bold version, which looks off but is not Times New Roman.

Step 6: Check optimization and privacy plugins

Several kinds of plugin change how fonts load, and an update or setting change can break them:

• Optimization plugins that combine CSS, remove “unused” CSS, or delay CSS loading can drop @font-face rules or change file paths. Turn those features off one at a time and test.
• Plugins that host Google Fonts locally download copies to your server. If the copy is missing or the plugin’s cache was cleared, the font disappears. Regenerate or re-download from the plugin’s settings.
• Privacy and cookie consent plugins may block requests to fonts.googleapis.com until a visitor consents. That keeps visitors’ IP addresses away from Google, but can leave the page in a fallback font. Self-hosting the fonts avoids the conflict.

If the Network tab showed a 403, also check that font files have normal permissions (644 for files, 755 for folders) and that no hotlink protection rule blocks .woff2 files.

Step 7: If only some visitors see it

• One browser or device only: content blockers and some privacy extensions block web fonts. On iPhone, iPad and Mac, Apple’s Lockdown Mode blocks many web fonts by design.
• A flash of Times, then the right font: that is font-display: swap working as intended on a slow connection: text appears in a fallback and switches when the font arrives. Reduce the effect by self-hosting WOFF2 files and preloading the one or two most important fonts (see FG-11).

Make failures look intentional

Times New Roman appears only because the font stack gave the browser nothing else. Always end your stacks with similar fallbacks and a generic family:

font-family: "Brand Sans", system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif;

Replace "Brand Sans" with your font’s name and keep the rest. Set it wherever your fonts are chosen: the builder’s global typography settings, or your theme’s custom CSS. If the brand font ever fails again, visitors see a clean system sans-serif instead of a broken-looking page. Serve fonts as WOFF2, which every current browser supports, and drop the old EOT and TTF formats.

When to contact your host

Contact your host if font files return 403 and you cannot find a rule causing it, if you need a CORS header added in a server config you cannot edit, or if the files exist but the server returns errors. Send the font file URL, its status code, the console error text, and the page URL where you saw it.