If Settings > General is blank, stuck on a spinner, or refuses to save, first determine whether the fault is limited to your browser or affects the site. Try a private window and a second browser with extensions disabled. If the page fails everywhere, collect the browser Console error, check Site Health and the REST API, then isolate plugins and the theme. The same symptom can come from JavaScript, a REST or loopback failure, PHP, the database, or hosting configuration, so the error evidence matters more than repeatedly refreshing the screen.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
1. Classify the failure before changing the site
Use this short test sequence before deactivating anything. It prevents you from treating a browser extension as a server outage, or from changing production plugins when the browser cache is the only problem.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match| Test | What the result suggests | Next action |
|---|---|---|
| Reload Settings > General in your normal browser | The page is blank, spins forever, or saving never completes. | Continue with the isolation tests below; do not assume the database is damaged. |
| Open the same administrator URL in a private/incognito window | It works privately but not in the normal window. | Clear the site’s cached data and disable extensions one at a time. A browser add-on or stale cache is the likely boundary. |
| Try a different browser with extensions disabled | Only one browser fails. | Keep troubleshooting the affected browser profile, extension list, or cached JavaScript. |
| Try two browsers and a private window | Every browser fails in the same way. | Inspect the Console, REST requests, Site Health, PHP logs, and plugin/theme conflicts. WordPress’s browser guide says an all-browser failure is likely a JavaScript or plugin/theme error. |
| Open another admin screen, such as Posts or Tools | Only General Settings fails. | Concentrate on the settings screen’s JavaScript, REST request, URL configuration, and components that hook into settings. |
| Several admin screens fail or the whole dashboard is unavailable | The problem is broader than General Settings. | Check PHP/server logs, memory or database errors, and use FTP/SFTP fallback steps if you are locked out. |
Do not make several changes at once. A clean browser test followed by one controlled change gives you a result you can reverse and explain.
2. Know what the General Settings screen is supposed to do
General Settings controls the site title and description, the WordPress and site addresses, registration options, the site language, timezone, date and time formats, and related location behavior. A page that never finishes loading can therefore fail before you can see any fields, while a page that loads but will not save may be failing during the REST request or server-side validation.
When the URL field is intentionally not editable
If WP_HOME is defined in wp-config.php, WordPress displays that value on General Settings but does not let you change the URL in the screen. That is expected behavior, not evidence that the page is broken. Change the constant in wp-config.php only when you have confirmed the intended canonical URL and have a backup; an incorrect value can redirect the dashboard or front end to the wrong host.
3. Rule out browser and JavaScript faults
WordPress’s browser JavaScript troubleshooting guidance, updated September 23, 2026, recommends another browser, a private window or disabled extensions, and the browser developer tools. Follow the tests in this order.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems- Use a private window. Sign in again and open Settings > General. Private mode normally starts without most extensions and uses a separate cache. If the screen works, return to the normal profile and disable extensions until the failure disappears.
- Test a second browser. Use a current browser with extensions disabled. Record whether the failure follows your account and site or stays with one browser profile.
- Open Developer Tools. Press the browser’s developer-tools shortcut, select Console, clear old messages, and reload General Settings. Capture the complete error, stack trace, script filename, and line number. A single first error is often more useful than a long list of follow-on messages.
- Check the Network panel. Reload with the panel open and look for a settings request that is red, cancelled, unauthorized, or returning an HTML error page instead of the expected response. Save the status code and response text without posting credentials or cookies publicly.
- Temporarily enable unminified core scripts. In
wp-config.php, adddefine('SCRIPT_DEBUG', true);before the line that says WordPress has finished editing the file. Reload once and capture the clearer filename and line number. This setting is for diagnosis; remove it or set it back after the capture because it is not a production performance setting. - Compare normal and private sessions. If the Console error appears only in the normal session, investigate extensions, cached files, and browser policies. If the same error appears in every browser, move to the site-side checks rather than repeatedly clearing your local cache.
Do not paste a full Console dump into a public forum if it contains administrator URLs, email addresses, tokens, or internal hostnames. Redact those values while preserving the error type, script path, and line number.
4. Check REST API and Site Health
The General Settings interface depends on data represented by WordPress’s REST settings resource. The resource includes fields such as title, description, url, email, timezone, and date-format values. A failed request for that resource is a meaningful explanation for a screen that stays empty or never completes.
Use Site Health first
- Open Tools > Site Health in the dashboard.
- Review both the Status and Info views. Look specifically for REST API availability, loopback-request failures, blocked HTTP requests, and warnings about debug configuration.
- Open the details for each failed test and copy the test name, HTTP status or error text, and any component named in the message.
- Return to General Settings and reproduce the failure once. Correlate the time of the failure with the Site Health message and your server log rather than making unrelated changes.
A loopback test is WordPress asking the site to make an HTTP request back to itself. The WordPress Developer Resources guidance identifies plugin or theme conflict as the most common cause of loopback failures, but firewall rules, authentication, DNS, SSL, and hosting policy can also block the request. Treat the exact Site Health detail as the deciding clue.
Interpret a REST failure without guessing
- No request leaves the browser: a JavaScript exception may stop the settings screen before it calls the API. Fix or isolate the script error first.
- The request is unauthorized or forbidden: check the logged-in session, security rules, and any plugin that filters REST permissions. Do not disable security controls permanently just to make the page load.
- The request returns a server error: inspect
wp-content/debug.logand the host’s PHP error log at the same timestamp. - The request is blocked or times out: investigate loopback, firewall, DNS, SSL, or hosting HTTP-request restrictions with the host.
- The request succeeds but the UI still spins: return to the Console; a response-format or JavaScript compatibility problem may be preventing the screen from rendering.
5. Capture PHP and server evidence safely
When the browser points to a server error, enable WordPress debugging for one reproduction only. Edit wp-config.php above the line that says /* That's all, stop editing! Happy publishing. */ and use temporary settings like these:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);This writes WordPress debug messages to wp-content/debug.log while keeping PHP notices out of the public page. Load General Settings once, wait for the failure, and then inspect the newest entries. Note the timestamp, file path, line number, hook or function name, and whether the message identifies a plugin, theme, PHP incompatibility, database query, or memory problem.
Also check the hosting control panel’s PHP or web-server error log. A fatal error can occur before WordPress writes its own log, and a reverse proxy or firewall may record a blocked request only at the server layer. If you do not have log access, ask the host for the entries surrounding the exact reproduction time and provide the Console and Site Health evidence.
Rank #3
Debug output and logs can expose paths, database details, email addresses, request data, or other sensitive information. WordPress’s Site Health documentation warns that debug mode may contain information that should not be available on a public site. After capturing the evidence, remove the temporary constants or set debugging back to its previous state, and ensure public display remains disabled.
6. Isolate plugin and theme conflicts
The official Learn WordPress troubleshooting material lists plugin or theme incompatibility, JavaScript errors, deprecated functions, PHP errors, database problems, and exhausted memory among the common failure classes. A conflict test changes the active environment temporarily so you can identify the component without permanently altering visitors’ experience.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Preferred method: Health Check troubleshooting mode
- Install or open the official Health Check & Troubleshooting plugin if it is already available to you.
- Start Troubleshooting Mode. This mode deactivates plugins and switches to a default theme for your administrator session only; ordinary visitors continue using the normal site configuration.
- Open Settings > General in that session. If it now loads, the core screen and your browser are less likely to be the cause.
- Reactivate one plugin at a time, reload General Settings after each activation, and record the first component that brings the failure back.
- If all plugins are cleared, switch back to the original theme and test again. A failure that returns with the theme points to its code or to a theme-specific integration.
Do not reactivate several plugins between tests. The purpose of troubleshooting mode is a clean comparison, and changing multiple variables removes the information you need.
Manual deactivation when the dashboard still works
If the plugin is unavailable, use the normal Plugins screen to deactivate all nonessential plugins, test General Settings, and then restore them individually. Keep a written order and capture the first Console, REST, or PHP error that returns. Do not delete plugin folders as a diagnostic step; deactivation is reversible, deletion may remove settings or data.
FTP/SFTP fallback when wp-admin is inaccessible
If a fatal error prevents dashboard access, connect with FTP or SFTP and open wp-content/themes. Temporarily rename the active theme’s directory, for example by appending -disabled. WordPress will fall back to an installed default theme. This does not fix the theme; it confirms whether the active theme is involved and gives you a path back into the dashboard. Rename the directory back only after you have recorded the result and confirmed that a fallback theme is present.
If the failure remains with all plugins inactive and a default theme, restore the original names and move to the REST, configuration, PHP, database, and hosting branches. Do not leave a production site running a fallback theme longer than necessary.
7. Check configuration, PHP, database, and hosting layers
Verify URL constants and redirects
Review wp-config.php for WP_HOME. A defined constant makes the General Settings URL display-only, so an uneditable field is expected. Confirm that the value uses the correct scheme and hostname for the site and that it agrees with the site’s actual address. If redirects loop between HTTP and HTTPS or between hostnames, have the host verify proxy and SSL configuration before changing URL constants.
Look for PHP compatibility and fatal errors
A PHP fatal error, a deprecated function promoted to an error, or a plugin that assumes a different PHP version can stop the settings request. The useful evidence is the exact PHP message, the affected file, and the PHP version reported by the host. Do not “fix” a fatal error by suppressing it; update, replace, or configure the named component after confirming compatibility.
Check database and memory symptoms
If the log names a failed database query, connection error, or exhausted memory condition, involve the host or database administrator before repairing tables or changing limits. Back up the database first. A General Settings save touches site options, so a database problem can make saving fail even when the form itself renders correctly.
Check hosting HTTP-request controls
Security firewalls, authentication at the staging layer, blocked outbound HTTP requests, DNS failures, and SSL validation problems can break REST or loopback checks. Give the host the exact request time, Site Health test name, response code, and server-log line. Ask whether requests from the server to its own public hostname are allowed and whether a proxy is rewriting administrator responses.
Free tools Windows power users keep installed
One-click scans. No signup required.
8. Match the evidence to the next fix
| Evidence you captured | Most likely layer | Practical next step |
|---|---|---|
| Works in private mode; normal browser shows an extension-related Console error | Browser profile or extension | Disable the named extension, clear the site cache, and retest before changing WordPress. |
| All browsers show the same uncaught JavaScript error with a plugin or theme path | Plugin/theme script conflict | Use troubleshooting mode, then reactivate components individually until the error returns. |
| Console shows no settings request, but a script stops execution | JavaScript initialization | Enable temporary SCRIPT_DEBUG, capture the unminified file and line, and match it to the responsible component. |
| Settings request returns a REST permission or authentication error | Session, permission, security rule, or REST filter | Reauthenticate, inspect security-plugin rules, and verify the REST response while preserving access controls. |
| Site Health reports a loopback or blocked HTTP-request failure | Plugin/theme, firewall, DNS, SSL, or host policy | Run the conflict test, then ask the host to verify server-to-site requests if the clean session still fails. |
debug.log or PHP log names a file and line |
PHP or component code | Update, reconfigure, or replace the named component and retest with debugging disabled afterward. |
Only the URL field cannot be edited and WP_HOME is defined |
Intentional configuration override | Change the constant, not the form, only after confirming the correct canonical URL and taking a backup. |
| Failure persists with a default theme, all plugins inactive, clean browsers, and no REST response | Hosting, PHP, database, or infrastructure | Escalate with the complete evidence package rather than making blind configuration changes. |
9. A safe recovery sequence
Use this order when you need a compact runbook:
- Test a private window and a second browser with extensions disabled.
- Capture the first Console error, stack trace, filename, and line number.
- Enable
SCRIPT_DEBUGbriefly if minified scripts hide the source. - Review Tools > Site Health for REST, loopback, blocked HTTP-request, and debug warnings.
- Enable
WP_DEBUGandWP_DEBUG_LOGwith public display disabled, reproduce once, and inspect WordPress and host logs. - Run Health Check troubleshooting mode; if necessary, deactivate plugins and test with a default theme.
- If locked out, rename the active theme directory through FTP/SFTP to trigger a fallback theme.
- Check
WP_HOMEand any redirect or hosting restrictions before changing URLs. - Restore the original configuration, disable temporary debugging, and retest the screen.
10. What to send when escalating
A useful support request is specific enough for someone else to reproduce and correlate. Include:
- WordPress and PHP versions, the active theme, and the component list tested.
- Whether the failure occurs in every browser, a private window, or only one profile.
- The complete first Console error with stack trace, script filename, and line number.
- The REST request’s status and response summary, with credentials, cookies, and tokens removed.
- The exact Site Health tests that failed and their detail text.
- The relevant
debug.log, PHP, and web-server entries with timestamps. - Whether troubleshooting mode or a default theme makes General Settings load.
- Whether
WP_HOMEis defined and whether the site uses a proxy, staging password, firewall, or unusual SSL setup.
WordPress does not prescribe one universal fix for this symptom because the same spinner can originate in different layers. Matching the first reproducible error to the component that introduced it is the fastest route to a durable repair.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
