Kadence Fonts Not Loading: Theme Fonts, Block Fonts and the Local Copy

When a Kadence heading slips into a system font

Font failures rarely announce themselves with an error. The page just looks slightly cheaper than it did yesterday. Collect the exact symptom first, on a logged-out browser and a phone, because each points at a different part of the Kadence stack.

• Everything renders in a system font: the theme's font request is failing or blocked.
• Body text is right, but headings or buttons inside certain blocks are wrong: a block-level font is not loading.
• Bold text looks smeared or too wide: the browser is faking a weight that was never downloaded.
• Fonts are right in the editor and wrong on the live page: the front end is requesting different files.
• Fonts broke the day you switched on local loading: the local copy is missing, stale or unreachable.
• Text appears in one font, then jumps to another: the font arrives late and shifts the layout.

Note one more detail: whether the editor and the live page agree. The block editor loads fonts its own way for the editing screen, so a font that looks right while you type proves only that the editor found it. Visitors get whatever the front end requests. Judge every font fix on the published page, logged out, with the browser tools open.

Two pipelines feed type to a Kadence page

Theme typography lives in Appearance > Customize > Colors & Fonts > Typography. The Base Font covers paragraphs, navigation and breadcrumbs. Heading Font Family covers H1 to H6, and individual heading levels default to Inherit. Kadence turns those choices into CSS and loads any Google Font you pick, from Google's servers by default or from your own when the Performance setting says so.

Kadence Blocks keeps its own typography controls on headings, buttons, info boxes and other blocks. Pick a font there and the plugin prints its own Google Fonts stylesheet link for it. Its source code checks a local-loading setting of its own rather than the theme's toggle, so turning on local fonts in the Customizer may not cover a font chosen in a block. One wordpress.org thread shows how far this reaches: a site on a different theme traced stubborn Google Fonts requests to Kadence Blocks, not to the theme it was blaming.

What stops a Kadence font, ranked by how often

1. The local copy is stale or incomplete

With Load Google Fonts Locally on, Kadence makes a one-time request to Google and stores the files on your server. Change a font or add a weight afterward and the stored set can lag behind. Check the network tab, filtered to Font: local files should come from your own domain with status 200. A 404 there means the page asks for files that are not on disk.

2. A block font outside the theme's control

If the wrong text sits inside a Kadence block, select the block and read its typography panel. A family set there overrides the Customizer. In the network tab, requests to fonts.googleapis.com on a site that is meant to be local usually come from a block.

3. The weight was never requested

Choosing 700 in a block does not download 700 if the family loaded only 400. The browser fakes the bold. Confirm each weight you use appears as its own file in the network list.

4. Something is blocking the request

Privacy and consent tools, Google Fonts removal plugins, a strict Content Security Policy and optimization plugins that delay or rewrite font links all stop fonts quietly. The browser console names a blocked request. Disable one tool at a time on staging.

5. A CDN serves fonts from another domain

Font files fetched from a different domain need an Access-Control-Allow-Origin header. Without it the browser refuses the file, and the console says so in plain words. Allow your site's origin on the CDN, or serve fonts from the main domain.

Bringing the right type back, step by step

1. 1

   Inventory every font in use

   List the families and weights in Colors & Fonts > Typography, then in the blocks on your key pages. Most sites need two families and three weights. Starter templates often leave more.

2. 2

   Point blocks back to the theme

   Where a block's font matches the Customizer anyway, set it to inherit. One less family to load, one less place to edit later.

3. 3

   Refresh the local copy

   In Customize > General > Performance, use Flush Local Font Files. Kadence deletes the stored files and downloads them again from Google on the next request.

4. 4

   Keep preload modest

   If Preload is on for local fonts, it should cover the one or two files the first screen needs. Preloading every weight competes with the hero image.

5. 5

   Purge every cache

   Clear the optimizer, the page cache, the host cache and the CDN, so no cached page still points at files that were just replaced.

6. 6

   Verify logged out

   In a private window, check the network tab: every font file returns 200, from the domain you expect, with no request to Google if you meant to go fully local.

Fonts that arrive late can shift a page as they swap in. If that is the remaining complaint, layout shift in WordPress themes covers fallback sizing, and the Kadence speed guide covers the Performance panel as a whole.

Choosing type so it keeps loading

The cheapest font fix is fewer fonts. Set families once in the Customizer and let blocks inherit. Use the theme's global settings for headings rather than styling each heading block by hand. After any font change, flush the local files and purge caches as one routine, not two chores remembered on different days.

After a Kadence Blocks or theme update, open one key page logged out and look at the network tab for font 404s or new requests to Google. A minute of checking beats a week of customers seeing Arial. If the update did more damage than fonts, Kadence slow after an update and Kadence CSS not updating cover the neighboring problems, and the Kadence repair hub collects the rest.

Fonts as part of the build, not a runtime fetch

On WordPress, a font is a request that can fail on any page view: from Google, from a local folder that needs refreshing, or from a block plugin with its own rules. The mechanism behind it, across themes, is in WordPress theme fonts not loading. Kadence handles it better than most free themes. It still asks two products to agree.

Next.js treats fonts as part of the build. The next/font module downloads and self-hosts the files when the site is built, so the live site never asks Google for anything and a font cannot go missing between deploys. It costs a developer's time up front. Kadence vs Next.js lays out the trade honestly, and moving from Kadence to Next.js describes the migration. For a site that only needs its fonts fixed, our WordPress theme repair team does that, and the troubleshooting section and Kadence review cover the rest.