A JavaScript error is breaking your page

First, open Developer Tools to see the failing file

If you checked your domain on kortaga.com/check, our check tests whether your home page's scripts and stylesheets actually load; otherwise you can see both missing files and runtime script crashes in your browser's Developer Tools.

1. Test your page in a private or incognito window (or in a second browser) first, so a browser extension such as an ad blocker or privacy tool is not what blocked the script.
2. Open Developer Tools and select the Console tab: press F12 (or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac, or Ctrl+Shift+K in Firefox). In Safari, first enable Settings → Advanced → Show Develop menu (or Show features for web developers), then open Develop → Show JavaScript Console.
3. Reload the page while Developer Tools is open. Some errors and network requests only appear during page load, and the Network panel only records activity while DevTools is open.

If a script or stylesheet failed to download (Network tab)

Use the Network panel when you need to make sure that resources are actually being downloaded as expected and to inspect the HTTP headers and status of each individual resource.

1. In Developer Tools, click the Network tab and reload the page so the Network Log records every resource the page requests in chronological order.
2. Look at the Status column (the HTTP response code) and the Initiator column (what caused the resource to be requested).
3. Hover over a cell in the Name column to see the full URL of the resource, or right-click the header of the Network Log table and select Domain to show the domain of each resource.
4. Click the link in the Initiator column to jump straight to the source code that caused the failing request so you can fix or remove that reference.

If a script crashed while running (Console tab)

Each JavaScript error in the Console tab has a name (the type of error), a message, and on the right side the file name and line number where it occurred (for example, jquery.js:2). Expanding the error shows the full stack trace.

1. Read the error type and file path

1. In JavaScript, each error object has a name and a message that provide the starting point for resolving the error:ReferenceError: "x" is not defined TypeError: "x" is not a function TypeError: null/undefined has no properties
2. Note the file name and line number of the error (for example, jquery.js:2), and copy the full error message and stack trace (not just the line number).
3. Compare the behavior in at least two browsers: if the issue only occurs in one browser, it may be browser-specific (such as an extension conflict); if it occurs in all browsers, the file name and stack trace point to the JavaScript, plugin, or theme error.

2. In WordPress, test with SCRIPT_DEBUG enabled

1. WordPress uses minified JavaScript and CSS files by default. Enabling SCRIPT_DEBUG in wp-config.php forces WordPress to load the full, uncompressed ("dev") versions of core CSS and JavaScript files instead, which makes errors easier to trace:define( 'SCRIPT_DEBUG', true );
2. Insert that line in wp-config.php before /* That's all, stop editing! Happy blogging. */, reload your site, and check whether the error still occurs.
3. If the issue is fixed with SCRIPT_DEBUG enabled, turn SCRIPT_DEBUG off again and include that detail (along with the browsers tested, full error message, stack trace, file name, and line number) when reporting the issue to the plugin or theme author.

These steps follow the WordPress Developer Handbook's guides on Using Your Browser to Diagnose JavaScript Errors and Debugging in WordPress (SCRIPT_DEBUG), MDN's JavaScript error reference, and Chrome DevTools' guide to Inspect network activity, all read 27 October 2026.

If you would rather we write it or repair it for you