If a custom WordPress font works in the editor but not on the live site, check the public page's active CSS and actual font request. Installing a font is not the same as applying it, and an editor can load a different stylesheet from the frontend.
Inspect one piece of text
Choose a heading or paragraph that clearly uses the wrong typeface. Open developer tools on the public page, inspect that element, and note its computed font family, weight, and style. Where the browser exposes rendered fonts, check which font actually drew the text.
If the computed family is already the fallback, the first problem is the CSS selection. A block-level style, builder setting, or theme rule may override the global typography. Changing the font file will not repair a rule that never selects it.
Find the font request
Keep Network open, filter for font resources, and reload the page. Compare the requested URL with the expected installed font. Record its status, response type, and any console error.
| Observation |
Investigate next |
| No font request |
Active CSS, family name, or already available local font |
| 404 |
Missing file or stale generated URL |
| 403 or CORS error |
Delivery policy for the font's actual origin |
| Successful file, wrong appearance |
Weight, style, glyph coverage, or competing rule |
Successful delivery alone does not prove the desired text is using that file. A font may lack the requested characters and fall back for only part of a heading.
Computed rule: Which family and weight are selected?. Network response: File, status, origin, and console errors. Rendered face: Confirm the actual glyph source. Readable fallback: Test slow loading and mobile layout. Explanatory checklist, not a customer test result.
Match family, weight, and style deliberately
A regular face registered as weight 400 does not automatically supply a genuine bold face at 700. Review the font registration and the weights your templates request. For variable fonts, check the supported range instead of treating the file like a single static weight.
Verify the family name used by your theme or builder, especially after importing a design. A label in a settings panel may not be the same string used in the generated CSS. Do not stack multiple font plugins to compensate for an unidentified registration problem.
Repair delivery at its source
If the URL points to an old domain or insecure scheme, correct the generating configuration and rebuild the relevant styles using supported controls. Follow the mixed-content diagnosis when HTTPS pages request HTTP resources.
For a font served from another origin, inspect the actual CORS error and configure only the required delivery policy. Disabling browser security is not a fix. Check that any CDN caches the corrected response and that its origin serves a real font rather than an HTML fallback.
Verify readability and performance
Test signed out, then on a narrow screen and a second browser. Confirm body copy, bold text, italic text, and any non-English characters used by the business. Watch for layout shifts and text that stays invisible while a font loads.
Do not preload every weight as a default remedy. First remove unused registrations and identify the small set needed on the page. Keep readable fallback fonts even after the custom face works. HandL WP can trace a font delivery problem across the builder, generated CSS, and hosting layers.
References: CSS font-face registration and cross-origin resource sharing.
References reviewed October 2, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.