A button stops working. A slider will not load. The block editor refuses to save. Nothing in the WordPress dashboard explains why. The answer is usually sitting in your browser console, and it takes about five seconds to open.<\/p>\n
This guide shows you how to open the console, how to read what it says, and which WordPress problems it solves. You do not need to write code to use it. You only need to know what you are looking at.<\/p>\n
Every page on your site runs code inside the visitor’s browser. That code powers menus, sliders, pop-ups, form validation, cart updates and the block editor. When a piece of that code fails, the browser writes a note about it in a log. That log is the console.<\/p>\n
The console lives in your browser’s developer tools. It is built in, so there is nothing to install. It is also read-only until you type in it, so opening it cannot break your site.<\/p>\n
This matters because WordPress hides these failures from you. A broken script does not show a WordPress error message. The page simply loads with something missing or frozen. You are left guessing which plugin, theme or setting caused it.<\/p>\n
The console removes the guessing. It names the error, and it names the exact file that produced it. Because WordPress keeps plugins in One more thing worth knowing. The console shows problems in the browser, not on the server. For server-side faults you need a different log, which the last sections of this guide cover.<\/p>\n There are three ways in, and all three land in the same place. Use whichever you remember.<\/p>\n The keyboard shortcut.<\/strong> On Windows and Linux, press F12<\/strong>. On a Mac, press Cmd + Option + I<\/strong>. Developer tools open in a panel at the side or bottom of the window. Click the Console<\/strong> tab.<\/p>\n The right-click route.<\/strong> Right-click anywhere on the page and choose Inspect<\/strong>. This opens developer tools with the clicked element highlighted, which is handy when a specific button is misbehaving. Then switch to the Console tab.<\/p>\n Straight to the console.<\/strong> Most browsers have a shortcut that skips the other tabs. On Windows it is usually Ctrl + Shift + J<\/strong>, and on a Mac Cmd + Option + J<\/strong>. Some browsers use K instead of J, so try both.<\/p>\n If the Develop menu is hidden.<\/strong> A few browsers keep developer tools switched off until you enable them in preferences, usually under an Advanced section with a label about web developer features. Turn that on and the console becomes available from the menu bar.<\/p>\n On a phone or tablet.<\/strong> Mobile browsers have no console. The usual workaround is to reproduce the problem on a desktop browser and shrink the window, or use your desktop browser’s device toolbar to emulate a phone screen.<\/p>\n The console can look intimidating at first. It is mostly noise you can ignore. Focus on the red lines and you have already done the hard part.<\/p>\n Messages come in three levels. Red<\/strong> means an error: something failed. Yellow<\/strong> means a warning: something worked, but not cleanly. Plain grey or white lines are informational and usually harmless. Many sites show a handful of warnings and run perfectly.<\/p>\n Each red line has two useful parts. On the left is the error type and message. On the right is the file that caused it, plus a line number. A typical line reads like this:<\/p>\n The message tells you what went wrong. The file name and the number tell you where. Click the file name and the browser opens the code at that exact line.<\/p>\n Read the file path first.<\/strong> It is the fastest clue you will get. A path containing Ignore errors from extensions.<\/strong> Lines that begin with a browser extension address come from software in your own browser, not from your site. Test in a private window to filter them out.<\/p>\n A small set of errors covers most real WordPress problems. Learning these few saves a lot of time.<\/p>\n Uncaught ReferenceError: jQuery is not defined.<\/strong> A script ran before the jQuery library was ready. It usually means a plugin or theme loaded its script in the wrong order, or that jQuery was removed or replaced somewhere in the site.<\/p>\n Uncaught TypeError: $ is not a function.<\/strong> WordPress loads jQuery in a protected mode where the Failed to load resource: 404 (Not Found).<\/strong> A file the page asked for does not exist at that address. Common causes are a deleted plugin that left references behind, a renamed image, or a moved site with old paths still in the database.<\/p>\n Failed to load resource: 403 (Forbidden).<\/strong> The file exists, but the server refused to serve it. This is usually a permissions problem or a security rule blocking the request. Our guide to file and folder permission errors<\/a> covers the correct values.<\/p>\n Mixed Content warnings.<\/strong> Your page loads over HTTPS but asks for an image, script or stylesheet over plain HTTP. Browsers block the insecure request. This is very common right after moving a site to HTTPS.<\/p>\n Uncaught SyntaxError: Unexpected token ‘<‘.<\/strong> The browser asked for a script and got HTML instead. Nearly always this means a PHP error page was returned where a JavaScript file should have been, so the real fault is on the server.<\/p>\n The Console tells you that something failed. The Network tab, right next to it, tells you what the server actually sent back. Together they solve most cases.<\/p>\n Open the Network<\/strong> tab and reload the page. Every request appears as a row: the file name, its status code, its type, its size and how long it took. Sort or scan for red rows and non-200 status codes first.<\/p>\n Tick Preserve log before you reload.<\/strong> Without it, the list clears on every page change. That makes login redirects and form submissions almost impossible to trace, because the evidence disappears the moment the page moves.<\/p>\n Tick Disable cache too.<\/strong> This forces the browser to fetch fresh files while developer tools are open. Otherwise you may be debugging a cached copy of a file you already fixed.<\/p>\n Filter to XHR or Fetch.<\/strong> This hides images and stylesheets and shows only the background requests WordPress makes. Two names matter here. Requests to Read the status code.<\/strong> A 500 means the server crashed handling that request. A 401 or 403 on a Click any row for detail.<\/strong> The Response tab shows exactly what came back. A PHP warning sitting in that response is often the real answer.<\/p>\n Finding the error is half the job. Proving what caused it is the other half. Work through these steps in order.<\/p>\n Step 1: read the file path.<\/strong> The error line already names a folder under Step 2: rule yourself out.<\/strong> Open the page in a private window and test again. If the error vanishes, a browser extension or a stale cache caused it, not your site.<\/p>\n Step 3: clear every cache.<\/strong> Clear your caching layer, then hard reload with Ctrl + Shift + R<\/strong> or Cmd + Shift + R<\/strong>. Old combined script files cause errors that no longer exist in the source.<\/p>\n Step 4: test on a copy, not the live site.<\/strong> Before you deactivate anything, take a backup and work on a duplicate. Our guides on backing up and restoring WordPress<\/a> and setting up a staging site<\/a> cover both steps.<\/p>\n Step 5: deactivate the suspect.<\/strong> Turn off the plugin the path named, then reload with the console open. If the error is gone, you have your answer.<\/p>\n Step 6: if the path was unclear, test in halves.<\/strong> Deactivate half your plugins at once, then narrow down. Our guide to WordPress plugin conflicts<\/a> explains the method in full.<\/p>\n Step 7: switch to a default theme.<\/strong> If no plugin is responsible, activate a default WordPress theme and test once more. An error that only appears with your own theme active belongs to the theme.<\/p>\n The console only sees the browser. A large share of WordPress problems never reach it, so knowing its limits stops you searching in the wrong place.<\/p>\n PHP errors are invisible here.<\/strong> Fatal errors, missing functions and version mismatches happen on the server before the page is sent. Turn on debugging to capture them instead. Our explainer on what WP_DEBUG is and how it works<\/a> shows how, and the log lands in Database faults are invisible too.<\/strong> A connection failure or a corrupted table stops WordPress before any script runs. See our fixes for error establishing a database connection<\/a> and repairing a WordPress database<\/a>.<\/p>\n Scheduled tasks leave no trace.<\/strong> Missed emails, unpublished scheduled posts and stalled imports are WP-Cron problems. They run on the server with no browser involved.<\/p>\n Environment problems need another screen.<\/strong> Outdated PHP, missing modules and failing loopback requests show up under Tools \u2192 Site Health<\/strong>. Our Site Health guide<\/a> explains what each warning means.<\/p>\n\/wp-content\/plugins\/<\/code> and themes in \/wp-content\/themes\/<\/code>, that file path usually tells you the culprit straight away.<\/p>\nHow to Open the Console on Windows and Mac<\/h2>\n
How to Read an Error Line in the Console<\/h2>\n
Uncaught TypeError: $ is not a function\r\n slider.js?ver=2.4:118<\/code><\/pre>\n\/wp-content\/plugins\/<\/code> followed by a folder name points at that plugin. A path containing \/wp-content\/themes\/<\/code> points at your theme. A path pointing at a domain that is not yours points at an external script.<\/p>\nThe Console Errors WordPress Sites Throw Most Often<\/h2>\n
$<\/code> shortcut is not available globally. Code written for other platforms often assumes it is. The plugin or theme author needs to use jQuery<\/code> in full instead.<\/p>\nHow the Network Tab Fills In the Gaps<\/h2>\n
admin-ajax.php<\/code> handle older plugin actions. Requests under \/wp-json\/<\/code> handle the REST API, which the block editor relies on.<\/p>\n\/wp-json\/<\/code> request often explains why the editor cannot save. Our roundup of common block editor problems<\/a> covers those cases.<\/p>\nHow to Trace an Error Back to a Plugin or Theme<\/h2>\n
\/wp-content\/<\/code>. That is your first suspect, and it is right more often than not.<\/p>\nWhat the Console Cannot Show You<\/h2>\n
wp-content\/debug.log<\/code>. Add debug settings to wp-config.php<\/code> only with a backup of that file saved first, because a typo there takes the whole site down.<\/p>\n