If your WordPress homepage shows a database error but you can still sign in to the admin area, the site is not necessarily suffering a complete database outage. The homepage may be triggering a particular query, cache lookup, plugin, Continue reading or theme function that the admin does not use. That distinction can save time—and help you avoid risky changes during an outage.
Start with the fastest reversible checks. Record the exact error and when it appeared, check whether the problem is limited to the homepage, and preserve a backup before changing files or settings. Then work through hosting health, database credentials, caching, and plugin or theme conflicts in a controlled order.
First, Record the Error and Scope
Before refreshing repeatedly or changing anything, capture the exact message, the URL, and the time it appeared, including the time zone. Take a screenshot if possible. Error wording matters: “Error establishing a database connection” points in a different direction from a WordPress database query error that names a table or SQL operation.
- Record the homepage URL and whether the error appears on mobile and desktop. Check one or two inner pages, such as a service page or blog post. Test a private browser window or a second device to rule out a browser-specific issue. Note whether the admin dashboard loads, saves a test change, and displays the site normally in its preview. Write down recent changes: plugin or theme updates, content edits, hosting changes, migrations, or traffic spikes.
Keep a small incident scratchpad. For example: “2026-10-15 09:20 UTC — homepage displays ‘Error establishing a database connection’; /wp-admin loads; inner pages load.” Add each test and result. This prevents repeating checks and gives your host or developer useful evidence.
Rapid, Reversible Checks
Check the public site from another network. A local browser or DNS issue can look like a site outage. Open a known inner page. If it loads, the database and PHP service are probably not wholly unavailable, though a server problem is still possible. Check the hosting provider’s status page and account notices. Look for database maintenance, resource limits, or an incident affecting your server. Review recent changes. If the homepage failed immediately after an update or deployment, identify that change before making another. Check the homepage cache. If you use a CDN or page-cache service, purge only the homepage or its specific cache entry first, if the tool allows it.Do not repeatedly purge every cache, update all plugins, or install a “database repair” plugin as a first response. Those actions can hide evidence, introduce new variables, or make recovery harder.
What the Homepage-Only Pattern Can Mean
When the admin works, WordPress can usually connect to the database for at least some requests. That does not prove that every database operation is healthy. The homepage may run different queries to fetch recent posts, featured content, menus, custom fields, or page-builder data. A database query error can therefore occur only on that route.
Other common causes include a stale or corrupted object cache, a plugin conflict, a theme function, a damaged homepage setting, a database table problem, or a server resource limit. A cached homepage may also show an old error—or an old working page—while uncached requests behave differently.
What you observe Possible direction Useful next check Homepage fails; inner pages and admin work Homepage query, plugin, theme, or route-specific cache Compare cached and uncached results; review recent changes Multiple pages fail intermittently Database or server load, connection limits, hosting incident Check hosting resource and database logs Error names a table or SQL query Specific query, missing table, incompatible code, or data issue Preserve the full error and check logs before repairing anything Only one browser or network sees the problem Local cache, DNS, CDN, or proxy behavior Test another network and inspect edge-cache statusCheck Hosting and Server Health
A homepage can use more PHP memory or database time than the admin dashboard. A large query, busy traffic, or a resource limit can cause a database query error on the public page while a lighter admin how to export mysql database request still succeeds.
- Check the host’s service status and account dashboard for database restarts, disk-space warnings, CPU or memory limits, and connection limits. Review PHP and database error logs around the timestamp in your scratchpad. Look for the first relevant error, not just later cascading messages. Check whether a recent traffic spike, backup job, import, or scheduled task coincides with the failure. Ask the host to confirm whether the database server was reachable from the website account and whether the account hit connection or resource limits.
If you need hosting support, send a precise request rather than just saying “the database is broken.” For example: “At 09:20 UTC, the homepage at example.com returned ‘[exact message]’. The admin and /about/ still load. Please check PHP and database logs for this account between 09:15 and 09:30 UTC, including connection limits, resource throttling, and database availability.”
Verify wp-config.php Carefully
WordPress stores its database connection settings in wp-config.php, typically in the site’s document root. The key constants include DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. If these values are wrong, the entire site often fails to connect. Since your admin works, a global credential mismatch is less likely—but it is still worth checking if credentials or hosting settings changed recently.
Make a full file and database backup, or at minimum download a copy of wp-config.php before editing it. Open the file using your host’s file manager or secure file transfer. Do not paste database passwords into email, chat, or public support tickets. Compare the four database values with the current details in the hosting control panel. Pay particular attention to a changed database host, renamed database, or password rotation. Check for accidental edits, missing quotation marks, or stray characters around the constants. Do not replace the whole file with a template. Save only a confirmed correction, then test the homepage and admin separately.Some hosts use a database host value other than localhost. Do not change DB_HOST based on a guess; confirm the correct value with the hosting panel or provider.
Fix: Correct a Confirmed Credential or Host Value
What changed: One verified database setting in wp-config.php was corrected to match the hosting account.
How to roll back: Restore the saved original file if the correction makes the site worse, then ask the host to confirm the active database values.
Investigate an Object Cache Issue
An object cache stores database query results so WordPress can reuse them. If cached data becomes stale or inconsistent, the homepage may fail while other routes continue to work. This is especially plausible after a migration, database change, or cache configuration update. A page cache or CDN can also serve a different result from a direct request, so distinguish those layers where possible.
- Check whether the homepage failure changes in a private window or after bypassing the CDN, using your host’s approved method. If a persistent object-cache service is enabled, review its status and logs in the hosting panel. Purge only the relevant cache if the tool supports targeted purging. Record what you purged and retest. Do not delete cache files or disable Redis/Memcached settings blindly, especially on a live site.
Fix: Purge a Targeted Homepage or Object Cache
What changed: The affected cached entry or configured cache was cleared, without changing WordPress content or database credentials.
How to roll back: Cache contents are normally regenerated as visitors load the site. If behavior worsens, stop further cache changes and restore the previous cache configuration from the host’s settings or deployment record.
Test for a Plugin Conflict
A plugin conflict can appear as a database query error if a plugin alters the homepage query, adds custom fields, or expects a database structure that is not present. The admin may use a different code path and remain available. Do not update or deactivate plugins at random during an outage.
First, review the error log and recent update history for a likely plugin. If you can use a staging site, reproduce the homepage issue there. If not, coordinate a short test window and make a backup before changing plugin state. A health-check tool that isolates plugins for your logged-in session can be useful, but do not install new tools on a fragile production site without a reason.
List plugins updated or configured shortly before the first failure. Test the likely plugin on staging, if available. If testing on production is unavoidable, disable one suspected plugin at a time and check the homepage immediately. Record the exact plugin and result. Re-enable it if the test does not change the error. If the homepage recovers, confirm the result and seek a compatible update or vendor fix before leaving the plugin disabled.Fix: Disable One Suspected Plugin for a Controlled Test
What changed: One identified plugin was temporarily deactivated to test whether it triggers the homepage query error.
How to roll back: Reactivate the plugin immediately if the error remains or another feature breaks. If it resolves the issue, keep a record of the disabled state and arrange a tested replacement or correction.
Check the Theme and Homepage Configuration
The active theme may run custom database queries or render homepage widgets that do not appear elsewhere. If a theme update or custom-code change preceded the outage, compare the change with a known-good backup or staging copy. Avoid editing theme files directly on production; a typo can turn a limited error into a full-site failure.
Also confirm that the selected homepage still exists and that WordPress is set to use the intended page under Settings > Reading. If the issue began after changing the homepage or its content, restore the previous selection or content from a known-good revision after taking a backup.
Fix: Restore a Confirmed Homepage or Theme Change
What changed: A specific homepage setting, theme file, or recent deployment was returned to its known-good version.
How to roll back: Reapply the saved version only if the restored state causes a verified problem, and keep the original files and database backup until the incident is resolved.
Database Repair Is Not the First Step
Do not run a database repair just because the message contains the word “database.” Repair tools can change tables and may not address a plugin query or cache issue. If logs identify a damaged table, take a complete backup first and ask the host or a qualified WordPress technician to review the specific evidence. Use the repair method recommended for that database and preserve the original backup.
Likewise, avoid turning on public error display. Detailed errors can expose file paths, queries, or other sensitive information to visitors. If debugging is necessary, use protected logs and follow the host’s guidance; disable diagnostic settings after the investigation.
When to Escalate
Escalate promptly if the error spreads beyond the homepage, the database becomes unreachable, logs show repeated connection failures, the site is losing orders or leads, or you cannot make a reliable backup. Send the support team the exact error, timestamp and time zone, affected URLs, what still works, recent changes, and tests already performed. Keep credentials private.
Once the homepage is restored, verify key actions: load the homepage and inner pages, submit a contact form, check any booking or payment flow, and confirm the admin still works. Record the cause and the successful fix so the next incident is faster and safer to handle.