jQuery $ Is Not Defined | Fix Load Order And CDN Fails

This error can feel random. One refresh works, the next refresh breaks. A page works in staging, then breaks in production. That pattern is common with script timing, caching, and “smart” script movers.

The fix is usually small. You just need to prove which of these happened: jQuery never loaded, jQuery loaded after your code, or the $ shortcut got removed. Once you pin down that one cause, the rest is straightforward.

Why You See jQuery $ Is Not Defined On Your Page

In jQuery, $ is a shorthand name for jQuery. When the jQuery file loads, it attaches those names to the page. If the file doesn’t load, loads late, or gets changed by another script, the shorthand isn’t there when your code calls it.

Start by checking what the page actually has. Open DevTools, go to Console, and run typeof jQuery and typeof $. Those two results tell you a lot without guessing.

What The Results Usually Mean

• jQuery is missing — typeof jQuery returns "undefined", so the file didn’t load.
• $ is missing only — typeof jQuery returns "function" but typeof $ returns "undefined".
• Timing is wrong — jQuery exists after load, yet your script ran earlier and crashed before it could continue.

Common Causes That Lead To The Error

• Script order is wrong — Your custom file is placed above the jQuery file in the page output.
• The jQuery URL fails — The request 404s, gets blocked, or points to the wrong path.
• Two jQuery copies load — A theme loads one copy and a plugin loads another copy, then something breaks.
• noConflict is active — A script calls jQuery.noConflict(), which can remove $ from the global scope.
• Async timing changes — async or a loader changes execution order in a way your code can’t handle.
• Optimization plugins move files — Delayed JS and “combine” features can change load order.

Fixing The jQuery Dollar Sign Is Not Defined Error In Minutes

Work from highest payoff to lowest payoff. Your goal is to confirm one clear failure, then fix that one failure, then retest with caches cleared.

Confirm jQuery Loaded In The Network Tab

Open DevTools, go to Network, reload the page, and filter for “jquery”. Click the jQuery request and verify it returns JavaScript, not an error page.

• Verify a 200 response — A 404 or 403 means the file didn’t load, even if the page “looks” fine.
• Open the request body — If the response is HTML, you might be loading a blocked or redirected URL.
• Check the initiator — It shows which file or tag tried to load jQuery, which helps when a plugin prints it.

Fix Script Order So Dependencies Load First

If you add script tags by hand, the safest order is simple: jQuery first, then jQuery plugins, then your site script. Keep that order in the final HTML output, not just in a template you think is being used.

1. Load jQuery first — Place the jQuery script tag above any script that uses $ or jQuery.
2. Load plugins next — Sliders, galleries, and validation plugins should come after jQuery.
3. Load custom code last — Your code should come after everything it calls.

Wrap Your Code So $ Exists When It Runs

If jQuery is present but your code fires too early, the safest pattern is the jQuery ready wrapper. It waits until the DOM is ready, and it gives you a local $ even on pages that avoid the global shortcut.

jQuery(function ($) {
  // Your code that uses $ goes here
});

Don’t Use async On jQuery

async can change execution order. If a dependent file loads before jQuery, you’ll get the error even though both files load eventually. If you want non-blocking behavior, prefer defer for a set of scripts that must keep order.

1. Remove async from jQuery — Keep jQuery loading in a predictable order.
2. Match attributes across the chain — If you defer jQuery, defer the dependent scripts too.
3. Hard refresh after edits — Use a hard reload to bypass stale cached HTML and script tags.

WordPress Traps That Commonly Cause The Error

On WordPress, you can get this error even when jQuery exists, because WordPress often avoids putting $ in the global scope. A theme might print scripts directly, a plugin might load a second copy, or an optimizer might delay the wrong handle.

Enqueue jQuery Instead Of Hard-Coding Tags

If you control theme or plugin code, enqueue scripts through WordPress. That helps WordPress manage ordering and prevents duplicates.

1. Enqueue the core handle — Use wp_enqueue_script('jquery') to load WordPress’s copy.
2. Declare dependencies — Enqueue your script with array('jquery') as a dependency.
3. Load in the footer when safe — Many site scripts can load in the footer for cleaner timing.

Use The Safe Wrapper In WordPress Theme Scripts

If your theme script uses $ at top level, switch it to the wrapper pattern so $ is passed in as a parameter.

jQuery(document).ready(function ($) {
  // $ works here on WordPress
});

Check For Duplicate jQuery Loads

Duplicates can show up when a theme loads a CDN copy and WordPress loads its own copy too. You might not notice until a plugin expects one version and sees another.

• Search page source for jquery — Look for multiple script URLs that contain “jquery”.
• Remove the extra copy — Keep one source of jQuery, not two competing sources.
• Retest plugin features — Sliders and menus can break when versions change.

Watch Script Delay Features In Speed Plugins

“Delay JavaScript” and “load JS after interaction” options can break libraries and their dependents. If the error started after you enabled delay features, exclude jQuery and any dependent scripts, then test again.

1. Exclude jquery by handle — Many plugins let you exclude by WordPress script handle.
2. Exclude dependent plugin files — If a slider depends on jQuery, exclude that slider file too.
3. Disable combining as a test — Combine features can wrap code in ways that break assumptions.

Bundlers And noConflict Issues In Modern Front Ends

If you use Webpack, Vite, Parcel, or similar tools, your code might assume a global $ while the page doesn’t provide one. Or the page provides jQuery, yet your bundle runs before it appears on the page.

Pick One Ownership Model For jQuery

You’ll get fewer surprises if you choose one approach and stick to it: either load jQuery globally in the page, or include jQuery inside your bundle. Mixing both often creates subtle bugs.

• Bundle jQuery — Import it in your build so your code always has it.
• Use a global copy — Load jQuery once in the page, then keep bundles from shipping another copy.
• Audit third-party plugins — Some plugins expect a global jQuery object.

Use noConflict Safely

jQuery.noConflict() can remove $ from the global scope so other libraries can use it. That’s fine if you use jQuery directly or use a wrapper that receives $ as an argument.

1. Replace top-level $ calls — Use jQuery(...) in files that run outside a wrapper.
2. Wrap plugin code — Wrap the file with jQuery(function($){ ... }) to keep $ local.
3. Check other libraries that use $ — If another library claims $, you’ll see conflicts.

Fast Debug Checklist With One Table

When you’re stuck, avoid guessing. Prove what’s true. These checks quickly narrow down where the break is happening.

Check	What It Tells You	What To Do Next
Console: typeof jQuery	Whether jQuery exists on the page	Fix the request or enqueue if it’s missing
Console: typeof $	Whether the shorthand exists	Use a wrapper or avoid global $
Network: jQuery request	Whether the file loaded cleanly	Correct the URL, CDN, or mixed-content issue
View page source order	Whether your code loads before jQuery	Move scripts or fix dependencies
Search for duplicates	Whether two versions load	Remove one copy and retest

Use The Stack Trace To Find The Real Offender

Click the error line in the Console. The stack trace points to the file that first tried to call $. That’s your starting point, not the symptom file that loads later. If the source is minified, look for a source map in DevTools, or open the unminified vendor file when you have it.

1. Jump to the failing file — Click the file name and line number shown in the error.
2. Check window values — In Console, test window.jQuery and window.$.
3. Pause with a breakpoint — Break just before the failing line and see what’s defined.

Keep The Fix Stable After Updates

Once you clear the error, keep it from returning when a plugin updates or a cache setting changes. Most repeat breakage comes from loading jQuery in multiple places, delaying scripts, or pasting jQuery-dependent code into templates that don’t load jQuery.

Choose A Reliable Source And Stick To It

If you want fewer moving parts, host jQuery locally and version the file. If you use a CDN, pick one you trust and add a fallback so your page still works when a request fails.

• Host a local copy — Keep one file under your domain and update it intentionally.
• Add a fallback loader — If the CDN fails, load a local copy before your site script runs.
• Clear caches after changes — Purge page cache, CDN cache, and minify cache after script edits.

Write jQuery Code That Survives Real Pages

Write as if your code might run in a builder page, a product template, and a blog post with different scripts. A wrapper and clean dependencies keep you safe across layouts.

1. Keep code inside a wrapper — Use jQuery(function($){ ... }) for any jQuery work.
2. Avoid inline event handlers — Inline onclick can fire before your scripts are ready.
3. Group related scripts — Keep jQuery and its dependents near each other in the final output.

If you’re still seeing the message after fixes, search your logs for the exact text “jquery $ is not defined”. It often shows up when a third-party widget loads on some pages and not others. Fix the first failing script, then retest.

Reference pages that can help during deeper debugging include the official jQuery API docs, WordPress developer docs on enqueueing scripts, and MDN pages on script loading attributes like async and defer. You can find them quickly by searching for “jQuery API”, “wp_enqueue_script jquery”, and “MDN defer async”.

Once this is fixed, you’ll usually notice other small issues vanish too: fewer console errors, fewer broken interactions, and fewer “works on my machine” surprises. That’s a nice side effect of clean script order.