No Script

WP-CLI Search-Replace: Safe URL Changes, Dry Runs, and Verification

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

Use WP-CLI’s serialization-aware search-replace when you’ve confirmed URLs in your WordPress database need changing. Confirm which installation you’re targeting, keep a recoverable SQL backup, and approve the table scope with --dry-run. Then search the database for leftover references and load the pages visitors see. For WP-CLI, WordPress commands, and SSH, see how to run and verify WP-CLI commands.

The basic preview command is wp search-replace OLD NEW --skip-columns=guid --dry-run, with your old and new strings in place of OLD and NEW.

When WP-CLI search-replace is the right tool

wp search-replace fits when a domain, staging-path, or HTTP-to-HTTPS change leaves old URLs in your database. Absolute links can linger in posts, widget settings, or plugin options. The command edits the database data you select. It can’t move site files or change web-server redirect rules.

You know the database references: You have the old value, the replacement, database access, and a way to recover.
Only WordPress Address or Site Address is wrong: Fix the options or configuration that control the effective WordPress URL.
The whole installation is moving: Plan the file transfer, database transfer, destination configuration, and cutover as a full migration.
You have no usable CLI access: Use a supported hosting interface or a WordPress plugin.

Confirm the site and the exact strings before changing anything

On a server with several WordPress installations, correct syntax can still target the wrong database. WP-CLI’s global --path option names the installation to operate on. Don’t rely on the current shell directory.

For a single-site installation, these commands inspect the target without changing anything:

wp --path=/path/to/site core is-installed
wp --path=/path/to/site config get DB_NAME
wp --path=/path/to/site db prefix
wp --path=/path/to/site option get home
wp --path=/path/to/site option get siteurl

config get DB_NAME reads the configured database name from wp-config.php. The prefix shows how WordPress names its tables. It doesn’t prove that other applications or installations have no tables in the same database. On multisite, the selected site’s --url context also matters.

Find the exact old value in the records you want to change, including http or https, www, the hostname, and any subdirectory. http://example.com, https://example.com, and https://www.example.com are different strings.

One r/Wordpress poster planning a staging-directory test wrote, “I wish to test a manual migration process (from /staging to /test folder before moving to /root folder).” (r/Wordpress staging migration discussion) The path matters: replacing https://example.com/staging with https://example.com/test leaves the hostname alone.

A fragment like example can also appear in unrelated data, so search for the full literal as stored.

Back up the database before the replacement

A bulk database change needs a recovery point. wp db export, also available as wp db dump, writes the database to SQL using your WordPress database configuration. Unless you restrict the tables, the dump includes every table in the configured database, which matters when another application shares it.

wp --path=/path/to/site db export \
  /secure-backups/before-url-change.sql

The destination directory must already exist and be writable. Store the export outside the publicly served site directory with suitable access controls. Then confirm the file exists, finished successfully, and can be accessed through your recovery procedure.

Don’t confuse the SQL dump with a content export. wp db export creates an SQL database dump. wp export creates WordPress eXtended RSS (WXR), an XML file of content records, including posts, comments, terms, and attachment information. WXR omits site options and the actual media files, so it can’t serve as a complete database recovery snapshot. The WP-CLI WXR export reference documents that narrower purpose.

If you need a complete recovery, copy the WordPress files too: uploads, themes, plugins, and configuration.

Why serialized WordPress data needs a serialization-aware replacement

PHP serialized strings store their byte lengths beside their values. The sample URL https://old.example contains 19 ASCII bytes and can appear as s:19:"https://old.example";. A blanket SQL text replacement that changes the length can invalidate the stored value and damage plugin or widget settings. WP-CLI’s search-replace handles serialized data, using PHP processing where necessary alongside SQL processing for other values. The optional --precise flag forces PHP processing for all columns and is slower.

Select which tables and columns the command can change

Table selection decides what a URL replacement can change.

Selection	Covers	Use it when	Watch for
Default	Registered `$wpdb` tables for the selected site	The old URLs sit in the usual WordPress data	Plugin tables that aren’t registered are left out
Named tables	Only the tables you list	You know exactly where the old URLs are	Other tables holding the old URL stay untouched
`--all-tables-with-prefix`	Tables with the configured prefix	Plugin tables use your prefix	A matching prefix doesn’t prove the table belongs to this site
`--all-tables`	Every table in the database, regardless of prefix	Database-wide work is explicitly authorized	Unrelated applications or sites can be affected
`--network`	Registered tables across a multisite network	A network-wide change is approved	Arbitrary plugin tables aren’t included automatically

Pick the smallest scope that covers the data you need to change. --all-tables extends the operation to the whole database, which matters most on shared hosting or a shared database.

Protect GUIDs and know which tables get skipped

During a URL migration, use --skip-columns=guid. A WordPress guid can look like an old permalink, but it works as a persistent identifier, and changing it can disrupt feed identification. The WP-CLI search-replace command reference documents column exclusions and scope options.

WP-CLI skips tables that lack a primary key and never modifies primary-key values. Both rules apply on top of the guid exclusion. If a table you need is missing, check its ownership and schema. A DESCRIBE query shows whether it has a PRI key.

Run a dry run and read what would change

A dry run reports the replacements it would make and writes nothing to the database.

wp --path=/path/to/site search-replace \
  'https://old.example' 'https://new.example' \
  --skip-columns=guid --dry-run

The example assumes the single-site target from earlier and the default table scope. If default coverage doesn’t suit your site, add the approved table restriction to the preview.

What the preview shows	Cause	What to do
Zero replacements	The old string isn’t there, the scheme or host differs, or you targeted the wrong site or tables	Check the exact string and confirm `--path` points at the right site
More matches than expected	A broad string, widespread old links, or too many tables	Check which tables and columns the matches come from
Expected plugin table absent	It isn’t registered, you excluded it, or it has no primary key	Check who owns the table and whether it has a primary key
Unexpected table present	The scope covers data outside the job	Narrow the table list

Read the table and column names first, then the counts. Zero is correct when the old string isn’t in the database.

The preview can’t test rendered pages, and the real command runs against whatever the database holds at that moment.

Apply only the replacement you have reviewed

When the preview shows the tables and counts you expected, remove --dry-run. Keep the same installation, old and new strings, table restrictions or other scope flags, and column exclusions.

wp --path=/path/to/site search-replace \
  'https://old.example' 'https://new.example' \
  --skip-columns=guid

Record the command you ran, the installation, the values and scope, and the result.

Write transformed SQL to a file instead

With --export, wp search-replace writes transformed SQL to a file and leaves the source database unmodified.

wp --path=/path/to/site search-replace \
  'https://old.example' 'https://new.example' \
  --skip-columns=guid \
  --export=/secure-backups/transformed.sql

This file doesn’t replace the pre-change backup. The output directory must exist and accept writes. The official command reference describes --old and --new as options outside a stable release, so these examples use the established positional strings.

Look for old URLs that remain in the database

After the replacement, search the database for old references that remain. wp db search does this without writing anything:

wp --path=/path/to/site db search \
  'https://old.example' --stats

By default it searches registered WordPress tables and is case-insensitive, so a match can differ in letter case from your input. Look at the stored value before deciding which reference survived.

If the replacement covered a wider authorized scope, extend the search with --all-tables-with-prefix, --all-tables, or --network, as applicable.

You’re done when no unwanted old URLs remain. A leftover match points to one of these:

Active content or option: A page, link, or setting still uses the old location.
Plugin storage outside the first scope: A table you intended to change wasn’t part of the first run.
Preserved identifier: An old-looking guid stays valid because it identifies the post.
Historical or unrelated record: A log or archived value correctly refers to the former address.

Check the live pages, admin area, and generated files

Check the site as visitors see it. Open representative pages at the new address, including pages that had internal links or media, and test navigation, images, and the WordPress administration area.

search-replace can’t modify file-based URLs or generated CSS, so page builders need their own check. A migrated Elementor page, for example, can show correct database values and still load a background image from the old hostname through generated CSS. If the next step involves WordPress backups, updates, and migration, see how to plan WordPress maintenance and recovery.

Elementor: Elementor documents a Replace URL tool and a Clear Files & Data operation for URL and generated-file problems. On an Elementor site, run those tools and do a targeted generated-asset cache refresh before checking the affected page again.

If the old domain still appears, locate its source

If the site redirects to its development domain after the database update, find the cause before running anything else. A wider replacement can change unrelated records without touching the redirect source.

After moving a development site to production on shared hosting, another r/Wordpress user described this exact symptom: “However, whenever I try to access the site, it keeps redirecting to the development URL.” (r/Wordpress development URL discussion)

WordPress supports WP_HOME and WP_SITEURL constants in wp-config.php. When defined, they override the corresponding database-stored URL options.

The browser sends visitors to the former domain: Find out whether WordPress configuration, the web server, or the hosting platform issues the redirect.
The page loads but its assets refer to the former domain: Trace each asset to its content or generated-file source.
Database references are already fixed: Inspect the configuration and delivery mechanisms behind the remaining symptom.

When a hosted tool or plugin is the better route

If you can’t open an SSH session, your hosting account can still offer search-and-replace controls. WP Engine and Kinsta describe provider-specific interfaces, and WordPress plugins are another route where the installation permits them.

WP-CLI needs authorized CLI access. A host tool needs a supported function in your hosting account, and a plugin needs WordPress and plugin permissions. WP-CLI gives you documented table and column options, documented handling of serialized values, --dry-run, and an SQL backup you control. Before using a host tool or plugin, confirm that it offers the same four things.

Restore deliberately if the change has caused damage

Before you restore, consider what changed after the backup was taken. wp db import imports SQL into the configured database, and restoring an earlier dump can overwrite valid later orders, comments, registrations, or edits on an active site.

If you know the mistake and the affected records, a targeted correction can preserve later changes. Otherwise, restore under the site’s recovery procedure and bring the database and files into a consistent state.

How to Update WordPress Safely Without Breaking Your Site

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

Check compatibility and make sure you have a backup you can restore. Test PHP changes, uncertain plugins, and anything involving live customer data on staging first. After updating, test what your visitors use, and stop if a check fails.

Choose an update path that fits your site

Before you click Update, work out what will change and what a failure would interrupt. A routine plugin update on an informational site needs less preparation than a PHP upgrade on a store that is processing orders. Record which version you will return to if the release fails.

Read the release notes for the component and see whether the update fixes a security issue or is routine maintenance.

Situation	Update approach	Reason
Routine, known-compatible component update	Monitored update after basic preparation	Few parts of the site are affected
Major WordPress change or multiple dependent updates	Supervised update, with staging when needed	More interactions to test
PHP upgrade or aging custom code	Dependency review, then staging before production	Code written for the old PHP version can fail on the new one
Store, membership site, or other transactional website	Staging plus a plan to preserve live data	Orders, accounts, and submissions keep arriving
Time-sensitive security fix	Prompt patching with a recovery point ready	Waiting also carries risk

On a brochure site, the contact form can be the most important feature. The plugin that runs it deserves close attention even when its update looks small.

Check compatibility across WordPress, plugins, themes, and PHP

WordPress core, your active plugins, the theme, custom code, PHP, and the database server all have to work together after the change. An update notice only tells you a new release exists. You still have to check whether it fits the rest of your installation.

The WordPress requirements page recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS.

WordPress core’s PHP compatibility matrix covers core only. Plugins, themes, and custom PHP code have their own requirements and can fail even when core supports your PHP version.

WordPress core: Record the installed and proposed versions and read the release notes.
Plugins: Check each active plugin affected by the change for its version requirements and dependencies.
Theme and custom code: Look for vendor compatibility statements, direct customizations, and code that relies on older PHP behavior.
Server stack: Record your PHP and database versions and the versions your host or administrator proposes.

A self-hosted site owner facing a host-driven PHP 8.2 to 8.3 change wrote on r/Wordpress, “I’m not sure where to go from here – I can see that some of the error messages have to do with specific plugins, but I’m not sure what to do about that.”

Error messages that name a plugin, like the ones this owner saw, only tell you where to look, and so does a scanner flag. Compare the reported location with the plugin’s or theme’s requirements and changelog, then separate deprecation or compatibility warnings from fatal errors you can reproduce. An abandoned commercial theme can need repair or replacement before a runtime change can go ahead.

Hold the production change until you resolve any fatal compatibility problem you have reproduced. Test warnings with unclear effects on staging.

Create a recovery point you can use

Before a production update, secure a recovery point that covers both your files and your database. The WordPress backup documentation treats them as separate components. For WordPress files, database, and backup archives, use the procedure to back up WordPress files and the database.

A database export without those files can leave the recovered site incomplete. A folder of plugin files cannot restore the database.

Database: Confirm the backup includes your site’s database.
Files: Include uploads, themes, plugins, and the configuration the installation needs.
Timestamp, storage, and access: Know when the backup was taken, where it is held, and who can retrieve it.
Restore path: Know the process and credentials you need to recover the site, and check whether you have ever tested a restore.

The timestamp matters on any site that accepts new data. Restoring an older database can erase orders, contact submissions, registrations, and other records created after the backup. A store restored from yesterday’s database needs a separate way to preserve today’s orders.

Test risky changes without overwriting live data

Staging gives you a separate copy of the site for testing uncertain changes.

A Hostinger VPS operator described the setup on r/Wordpress: “I’m running a WordPress site on a Hostinger VPS and currently have a staging environment on a subdomain (staging.domain.com) and the live site on domain.com.”

While you update the staging copy, the live site keeps receiving orders, registrations, and form submissions in its own database. A full database push from staging can replace those newer records with older data. Kinsta documents this risk in its own staging deployment workflow.

What changed	State involved	Deployment decision
Plugin, theme, or core files	Application code	Deploy the changed files at the versions you tested
Configuration	Files or database options	Find where the changed settings are stored and move them from there
Database schema or plugin data	Persistent structure or records	Run the required migration or a controlled transfer
Orders, accounts, and submissions	New live production records	Keep everything created since you copied staging
Generated output or caches	Environment-specific derived content	Check the output on production after deployment

A file-only deployment suits a code change that leaves persistent data alone. Some plugin updates also change tables or stored settings, and those need a data migration too. For work involving WordPress backups, updates, and migration, follow the steps to plan WordPress maintenance and recovery.

Update WordPress core, plugins, and themes

WordPress 7.2 Beta 1, released on October 20, 2026, is a testing release meant for testing environments, not for normal stable production updates.

With the checks done and a recovery point in place, apply each update through the supported WordPress dashboard, your host’s controls, or WP-CLI. Note which component you changed and whether its updater reported an error.

Use the WordPress dashboard

Update core: Sign in to wp-admin, open Dashboard → Updates, and use the WordPress update button for the stable release you are installing.
Update a plugin: Open Plugins → Installed Plugins and click Update Now next to any plugin with an update. Dashboard → Updates also lists plugin updates.
Update a theme: Open Appearance → Themes, select the theme, and use its update control.
Complete a database update: If WordPress prompts for a database upgrade after a core update, follow the on-screen action and wait for it to finish.
Clear caches: If the site uses page or other caches, clear them through your caching controls so later checks show fresh output.

The WordPress updating guide covers the core dashboard flow and the related completion steps.

Let dependencies set the order. A plugin with a stated WordPress version requirement, for example, can need the core update first.

Updates can replace the original software files, so direct edits to WordPress core or to an updated parent theme’s files can be lost. Account for those customizations before updating.

Use WP-CLI when you administer the installation

If you have the right access and permissions on the installation, WP-CLI offers matching commands:

WordPress core: wp core update
A selected plugin: wp plugin update
A selected theme: wp theme update

If a core update requires a database upgrade, run wp core update-db in the target installation.

Handle PHP as a separate server change

Changing PHP is a hosting or server-administration task. Updating core, plugins, or themes through the dashboard does not change the PHP version your server runs.

Where their requirements allow, bring WordPress core, plugins, and the theme to versions that support the new PHP before switching.

For a PHP 8.2 to 8.3 move, use your compatibility inventory to find the plugins, themes, or custom code that need attention. On managed hosting, look for the PHP selector in the provider’s control panel. A self-managed VPS can need a qualified administrator who works with the installed PHP and web services.

Write down the current PHP version and find out how your host supports switching back.

Make the change through the documented hosting or server control, then confirm which PHP version WordPress is running on.

Test what visitors use

An updater can report success while something visitors rely on is broken. Once the updates are done, test the site’s actual functions.

On r/Wordpress, a maintainer with two small-business clients wrote, “I’ve never had a good nor time-efficient method of checking to ensure nothing is broken after a pass of plugin updates.”

A short, repeatable checklist fixes that. Build yours from the features your site actually has:

Function	What to test	Pass condition
Public content	Open the homepage and a typical internal page	Content and navigation load as expected
Administration	Sign in with an authorized account	The dashboard and the controls you need open
Contact or lead capture	Send a safe test form submission	The message or record reaches its destination
Customer accounts	Log in or use account functions	The account flow completes
Store functions	Run cart and checkout without creating a real charge	Each stage works
Updated plugin feature	Use the function the changed plugin provides	The feature behaves as it did before
Error signals	Review error messages or logs	No new fatal failure in the flows you checked

A company brochure site needs its contact form, navigation, and administrator sign-in tested. A WooCommerce store adds cart, checkout, and customer-account paths. Include the updated plugin’s central function when the site relies on it.

Record the checks you ran, whether each passed or failed, and the components and versions you changed. A pass covers only the flows you tested, on the day you tested them.

Identify the failure before choosing recovery

If an update fails or a feature breaks, stop making changes until you know which kind of failure you have.

One maintainer working on a live client store posted this on r/Wordpress: “Unfortunately after updating Yoast SEO plugin the website crashed and it returned a white screen.”

A white screen like that belongs in the last row below.

What you observe	Likely cause	First response
Update operation remains active	Normal installation or maintenance work	Let it finish and do not interrupt it
Maintenance notice persists after the updater stops	Stale `.maintenance` file	Confirm the updater is inactive, then use the documented maintenance recovery
Plugin or theme installation fails	Installer failure that can qualify for supported rollback	Check the update status and the available recovery mechanism
Installation finishes but a feature fails	Application regression or compatibility fault	Investigate the affected feature and its errors
Site or dashboard becomes inaccessible	Critical error or access problem	Use the administrator and hosting recovery path

WordPress 6.3 introduced rollback protection for certain failed manual plugin and theme updates. The WordPress 6.3 rollback explanation covers that installation-time protection. It does not cover completed updates that later break functionality, custom-code changes, or persistent database changes.

A “Briefly unavailable for scheduled maintenance” message that won’t go away can point to the .maintenance file. Do not remove it or touch update files unless the updater has stopped.

Use the updater’s result and any error logs to choose between supported component recovery, targeted troubleshooting, and restoring a complete backup.

Regain access when wp-admin is unavailable

A critical error can lock you out of wp-admin and tell you that recovery instructions went to the site’s administrator email. You can lack control over that inbox or the hosting account. Find out who owns the administrator email and the hosting access, follow the recovery instructions or ask hosting support, and give any plugin or theme problem to an authorized administrator for targeted critical-error troubleshooting. For WordPress, fatal errors, and plugin recovery, use the procedure to recover from a WordPress critical error.

Decide which updates to automate

Automatic updates work when the site has dependable recovery and someone can respond to failures. Supervised updates give you more control over staging and the timing of high-stakes changes. Which components are affected, what the business relies on, and how well the site is monitored set the right mix.

Plugin auto-update controls sit under Plugins → Installed Plugins, where each entry offers Enable auto-updates or the matching disable control. For themes, open Appearance → Themes, select the theme, and use its automatic-update setting.

Your installation’s configuration and your host’s policy set core update behavior. A managed provider can apply or defer certain WordPress releases through its own controls, so check your host’s settings too.

On a simple brochure site with recovery access and monitoring, automated updates cut manual work. A transactional site, or one that runs a plugin you are unsure about, can warrant supervised updates and staging for major releases. Security fixes need prompt attention either way.

Coverage: Decide which core, plugin, and theme updates run automatically and which you supervise.
Ownership: Assign a person or team to receive failure notices and respond.

How to Fix WordPress Cron Jobs That Aren’t Running

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

Check whether the event was scheduled, whether anything ran it, and whether the task finished. Fix the layer that failed. If waiting on visitors causes the delay, move to a monitored server cron job.

A scheduled post can miss its publication time while other WordPress jobs run as expected. A backup plugin can register an event and still produce no backup. WooCommerce can accumulate pending actions while the store’s pages stay accessible.

Find the failing task before changing WP-Cron

Open Tools → Site Health and note any scheduled-event warning. For a missed post, compare the scheduled publication time with the site’s timezone under Settings → General, then check the post status and the public URL. A stale cache can also make an updated page look unchanged. The presence of an event in WP-CLI does not prove the server invoked it at the intended time.

What you see	What to check first	Likely cause
One post says `Missed Schedule`	Post status, scheduled time, timezone	Timing or publishing callback
Several events are overdue	Overdue events and what is running them	WP-Cron triggering or server cron job
An expected plugin event is absent	Plugin state and list of registered hooks	Event registration
`wp cron test` reports disabled	Cron constant and host job	Server cron job setup
Manual execution works, automatic execution fails	Loopback response and server cron job logs	Loopback request or server cron job
Backup event runs but no file appears	Plugin and PHP logs, expected file	Plugin callback
WooCommerce actions pile up	Action status, age, hook, logs	Action Scheduler queue

Site Health and a Missed Schedule label flag a problem without naming the cause. If unrelated scheduled jobs succeed, inspect the affected task before changing any site-wide setting. When WordPress backups, updates, and migration need a separate check, see how to plan WordPress maintenance and recovery.

A publisher whose newsletter linked to a scheduled article described the failure in an r/Wordpress discussion: “This morning, our newsletter led to a 404, so I checked and found out that it was scheduled correctly but didn’t post.”

Write down the hook or post name, the expected local time and timezone, the warning’s exact wording, the visible result, and whether other scheduled jobs work.

How WP-Cron gets triggered and what a server job changes

WordPress registers scheduled hooks and checks for due ones when someone loads a page. On a quiet site, due events wait for the next visit. The HTTP spawning path uses a doing_cron transient lock. A server cron job starts the check on a fixed schedule whatever the traffic, but the callback registered for each event still decides whether the task succeeds. WordPress 6.9 moved the ordinary wp_cron() call to shutdown, except when alternate cron is enabled.

Check scheduled events in Site Health, WP Crontrol, or WP-CLI

WordPress can only run a registered event. An event list shows which hooks exist, when they are due and whether they repeat.

For a dashboard view, WP Crontrol 2.0.0 documents Cron → Cron Events, and the earlier Tools → Cron Events route remains available in its documentation. Its expanded event logs are opt-in: enable logging for the event you care about, then look under Cron → Cron Logs.

With SSH and WP-CLI access, run this from the intended WordPress installation:

wp cron event list

The default listing includes the hook, next run time and recurrence. To see arguments and registered actions too, use:

wp cron event list --fields=hook,next_run_gmt,recurrence,args,actions

The hook links the event to its callback, and the next run time shows whether the event is overdue. Recurrence tells you if it repeats. Arguments separate instances that share a hook name. Actions list the callbacks registered in the command’s execution context.

The list shows what is scheduled and when. It can’t tell you whether the task finished.

When the expected event is missing

The plugin can be inactive, or its code can register the hook only under certain conditions. Find which plugin owns the hook before changing anything about how cron runs. Developers can call wp_next_scheduled() to check for an existing hook and argument combination before scheduling recurring work.

When WP Crontrol shows no action

A hook can have no callback in the context where the inspection tool runs, even though the callback loads in another one.

Check DISABLE_WP_CRON and test the actual trigger

The DISABLE_WP_CRON constant turns off request-triggered spawning.

The line in wp-config.php looks like this:

define('DISABLE_WP_CRON', true);

WP-CLI can test HTTP spawning:

wp cron test

With DISABLE_WP_CRON set to true, the test reports spawning as disabled. That result is normal when a server cron job runs your events, so read it against your own setup.

On a site that relies on page requests, investigate any failure the HTTP test returns. On a site with a server cron job, check the hosting panel or system job: the account it runs under, the WordPress installation or multisite URL it targets, and its execution logs. The job log shows whether the server cron job fired.

ALTERNATE_WP_CRON is a separate mode, so treat it separately from the disabling constant when you work out how your site schedules events.

Trace blocked loopback requests and wp-cron.php HTTP errors

WordPress can start due work with an HTTP request back to its own installation. A blocked or misdirected loopback request breaks that automatic path. WP-CLI takes a different route to the callbacks.

The error code tells you where to start:

Response	What it means	What to inspect
cURL `6`	DNS resolution failure	DNS resolution of the site’s configured hostname
cURL `7`	Connection failure	Listener, target port, route and firewall
cURL `28`	Timed-out loopback request	Request timeout and network path
cURL `35`	SSL connection failure	TLS negotiation and certificate configuration
HTTP `401` or `403`	Access restriction	Authentication, WAF and access-control logs
HTTP `404`	Missing or inaccessible cron endpoint	Effective request URL and `wp-cron.php` path
HTTP `500`	Server-side error	Web server and PHP error logs

WP Crontrol’s spawning-error guide documents these categories.

Manual WP-CLI execution works, but scheduled spawning fails

A maintainer who saw Site Health failures despite successful manual WP-CLI runs wrote in a WordPress.org support thread: “My server is configured to work only over HTTPS and does not accept HTTP requests, so the cron trigger was failing silently.” Correcting the scheme resolved that case.

If you see the same symptom, match the loopback request’s URL, scheme, time, and status or cURL response against the access, security and PHP logs.

Never disable TLS certificate validation or weaken authentication to make a cron request pass. Fix the URL, access-control, network or server fault the logs point to.

Diagnose callback errors, duplicate hooks, and tasks that run only manually

A cron request can reach WordPress and the task can still fail inside its callback. The owning plugin or custom code can hit a PHP error, an execution limit, a missing permission or an unavailable external service.

Take a backup plugin whose hook is registered but whose backup file never appears. The callback and what it uses are the place to look, even when other scheduled tasks work.

Read the callback’s evidence

Find the plugin, theme or custom code that owns the hook.

PHP error: Look for the exception or fatal error tied to the operation.
Remote dependency: Look for a failed API request or an unavailable service the callback uses.
Missing artifact: Compare the logged attempt with the output it should have produced, such as a backup file.
Duplicate event: Compare hook names and argument sets.
Inactive integration: Check whether the callback code loads in the context where the event runs.

Understand the consequences of manual execution

wp cron event run --due-now executes every event that is currently due, and --all widens the scope further. Both can send messages, create files, call webhooks or trigger other operations. On a production site, work out what the events will do before you run them.

Fix the proven cause or switch to monitored server cron when needed

Task deadlines and the scheduling tools your host provides decide whether a server cron job fits.

What you found	What to do
Default WP-Cron finishes tasks within an acceptable delay	Keep it
Normal spawning is disabled and no external job runs	Set up a server cron job so events don’t go unrun
HTTP spawning fails because of an identified configuration problem	Fix the request path the error and logs point to
A single callback fails after it starts	Fix the plugin or application error shown in the task logs
Visitor-dependent spawning makes tasks late, such as overdue hooks on a quiet site whose callbacks otherwise work	Use a monitored host or system cron job
WooCommerce background actions fail or accumulate	Investigate Action Scheduler (next section)

A documented hosting-panel example

SiteGround documents the path Site Tools → Devs → Cron Jobs. Its example schedules wp cron event run --due-now from the WordPress installation directory through the hosting panel.

Kinsta’s published managed example runs every 15 minutes, SiteGround’s every 30. Pick an interval based on how late a task can run and what your host allows.

Some vendor examples send command output to /dev/null. While you diagnose, keep a job log or error file so failures show up.

Switch to a server cron job in a safe order

Set up the new job for the correct WordPress site and account. Wait for at least one run started by the host schedule and confirm it in the job log or in the expected task result. Then, if your setup calls for it, turn off request-triggered WP-Cron and keep a way to restore the old configuration.

On Multisite, each site has its own execution context, and every extra WordPress launch adds overhead. A single-site job copied unchanged across a network can miss the subsites you want.

Separate WooCommerce Action Scheduler backlogs from WP-Cron failures

WooCommerce uses Action Scheduler for background jobs, each with its own status and log. WP-Cron can start the queue.

Open WooCommerce → Status → Scheduled Actions and check the affected hook, the owning integration, status, age and failure messages. A pending action can be normal queued work. A failed action has a logged cause.

One merchant running a mid-size store described the symptoms in an r/woocommerce discussion: “Checkout and admin felt randomly slow. PageSpeed still looked fine.”

Action Scheduler has its own WP-CLI tooling for queue operations, including wp action-scheduler run. For WP-CLI, WordPress commands, and SSH, see how to run and verify WP-CLI commands.

Never bulk-delete or blindly rerun pending and failed actions on a live store. Orders, renewals, webhooks and payment integrations can rely on them.

If the fault belongs to one integration, recover it through that plugin or a dedicated Action Scheduler procedure.

Verify automatic scheduling by checking the real result

The next automatic run is your test. Let WordPress or the server cron job reach the event, then check what the task actually produced and whether the Site Health warning is gone.

Scheduled work	Evidence of completion
Scheduled WordPress post	Published status and a post URL that loads publicly
Automated backup	Backup file exists and passes validation
Plugin background task	Logged success or the expected output
WooCommerce action	Completed status and log
Recurring maintenance job	Expected result at the next interval

Compare the completion time with the delay your site can accept.

For recurring tasks that matter, watch several more cycles at the job’s own interval. Add the automatic run’s timestamp, what started it, the result and any new errors to the notes you made at the start.

How to Fix the Critical Error in WordPress

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

Use the WordPress Recovery Mode link if the admin email arrives. If it doesn’t, find the relevant PHP fatal error in your hosting or WordPress logs, then repair or reverse the change it points to. If you lack access or the evidence points to a server-level problem, send your host or developer the error details, and treat the repair as done once the original failing action works again.

What the WordPress critical error message means

The message “There has been a critical error on this website” means WordPress hit a serious failure in PHP. It doesn’t tell you what caused it. The error can appear on the public site, throughout wp-admin, or only during one action. Write down the exact wording and the failing URL or action before changing anything. A blank page, a standalone HTTP 502 response, or “Error establishing a database connection” is a different problem with a different fix.

Find out what still works before choosing a recovery route

An admin described a typical split in an r/Wordpress thread on March 5, 2026: “My site is live, but trying to access admin is giving the “There has been a critical error on this website.” message for all pages in admin.” Match your own access to a route:

Access or evidence available	Recovery route
Valid WordPress recovery email	Enter the protected Recovery Mode session
Hosting files or PHP logs, but no recovery email	Identify the relevant fatal error
Identified faulty extension or recent edit	Make a targeted reversible change
Server fault or insufficient technical access	Give the evidence to an authorized administrator

Before you touch site files or plugin state, work in a staging copy or make sure you have a backup you can restore. WordPress keeps its data in both files and the database.

Limit the impact on a live site. A sitewide plugin shutdown can interrupt features that still work. On an active store or membership site, make sure you can reverse each step before trying anything broad.

Use the WordPress Recovery Mode email if you have it

WordPress Recovery Mode gets you back into administration when a fatal error traces to a plugin or theme. WordPress 5.2 introduced it, and it emails a special recovery link to the site’s admin address.

Find the genuine WordPress recovery email in the admin mailbox, including spam and filtered folders.
Open the protected link and log in with an administrator account.
Check which plugin or theme Recovery Mode flags and use the controls it offers to fix it.

The WordPress Recovery Mode documentation explains that WordPress can pause the flagged plugin during your recovery session.

Why the recovery email can fail to arrive

An April 8, 2026 r/Wordpress post shows the problem: “I am a site admin but have not received an email to say what the critical error was. This happened last week as well.”

Recovery Mode needs two conditions. The fatal error must occur where WordPress’s handler can process it, and WordPress must tie it to a plugin or theme. Email adds more failure points: outgoing mail handling before an email plugin loads, host delivery, spam filtering and notification rate limits.

Don’t try to build a recovery link by guessing URL parameters. The real link carries protected recovery information. For WordPress, PHP errors, and recovery, use the procedure to troubleshoot WordPress errors by symptom.

No recovery email? Find the PHP fatal error in the logs

The most useful evidence is the PHP fatal error tied to the failed action. Start with the PHP or web-server error log in your hosting account. If it tells you too little and you have file access, WordPress debugging gives you a second source.

Read the error that matches the failure

Find the entry whose timestamp matches your failing action, then read its error class, message, file, line and stack trace.

A WordPress.org support report about NGG Smart Image Search shows what this looks like:

PHP Fatal error: Uncaught Error: Call to undefined function shell_exec()

PHP reports an uncaught Error from a call to the unavailable shell_exec() function, and the plugin file named line 2974. That points to the plugin and your host’s PHP environment. The WordPress core file visible elsewhere in the stack trace isn’t the suspect.

Configure temporary WordPress logging if necessary

If host logs are missing or too thin, the WordPress debugging documentation describes a log-first setup. Find wp-config.php in the WordPress installation and edit any existing definitions of these constants. Don’t add duplicates. For WordPress, wp-config.php, and database settings, use the procedure to edit wp-config.php without breaking the site.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Place the settings before WordPress’s standard configuration marker:

/* That's all, stop editing! Happy blogging. */

WordPress writes the log to wp-content/debug.log. Setting WP_DEBUG_DISPLAY to false keeps errors off your public pages. Repeat the failing action once, then check wp-content/debug.log through your file manager or SFTP for the new entry. If the action can alter live data, rely on your host’s logs or reproduce the failure in staging.

Keep diagnostic output private. WordPress recommends debugging in development or staging. If you have to log on a live site, keep it controlled and temporary. A file like debug.log can contain filesystem paths or sensitive information, and turning off on-page display doesn’t protect a log that anyone can open.

If debug.log is missing or empty, WordPress logging didn’t reach the failed operation or your host recorded the error elsewhere. Go back to the PHP or web-server logs.

Fix the implicated plugin, theme, or recent code change first

When the log or a recent change points to one plugin, theme or file, reverse that one change first. Deactivate the plugin, revert the theme or custom edit, or restore the previous version if an update caused the problem. A plugin installed just before an editor failure is your first suspect, especially if the fatal entry names its code. For work involving WordPress plugins, theme conflicts, and PHP errors, follow the steps to isolate WordPress plugin and theme conflicts.

Deactivate a specific plugin

If Recovery Mode gives you dashboard access, open the flagged plugin and use its deactivation or correction controls.

No admin access? Open your host’s file manager or SFTP and rename the plugin’s folder. WordPress documents this approach, for example:

/wp-content/plugins/hello-dolly/
/wp-content/plugins/hello-dolly-1/

The second path is the same folder under a temporary name. Use the folder of the plugin you’re investigating, write down its original name and keep the files so you can reverse the change.

With SSH and a working WP-CLI setup, you can deactivate a named plugin with:

wp plugin deactivate example-plugin

Replace example-plugin with the plugin’s slug.

Deactivate all plugins only if the targeted checks found nothing.

Identify the culprit after broad plugin isolation

WP-CLI can deactivate all regular plugins with wp plugin deactivate --all. You need the same CLI access, and the command can interrupt services on a live site.

If the failure disappears, restore the normal plugin directory arrangement where you renamed folders, then reactivate plugins one at a time. Repeat the failing operation after each activation. If the error returns after one activation, that plugin is your suspect, or it conflicts with a plugin that’s already active.

Run the reactivation tests during a maintenance window. Don’t knowingly reactivate a plugin you’ve confirmed crashes a critical production operation.

On multisite installations, check network-activated plugins too. WP-CLI’s global --skip-plugins option doesn’t skip must-use plugins, which can still matter when ordinary plugin isolation fails.

A temporary deactivation can restore access and remove a feature your site needs, so a lasting fix means a compatible release, repaired custom code or a controlled rollback.

When the log points to PHP or the hosting environment instead

A PHP fatal error can come from an unavailable function, an execution-time limit, exhausted memory or faulty code. Each needs a different fix.

Error category	Typical diagnostic wording	What to check
Unavailable function	`Call to undefined function ...`	Whether the plugin works with your host’s PHP setup
Execution-time limit	`Maximum execution time ... exceeded`	What the operation does and which time limit applies
Memory exhaustion	`Allowed memory size ... exhausted`	How much memory the failing task needs
Type or syntax failure	`TypeError` or a PHP parse error	Code or dependencies that changed recently

The error class tells you where to start. Raise a PHP limit only when the error names a resource constraint.

Disabled functions and plugin compatibility

In an August 2026 WordPress.org support discussion, NGG Smart Image Search v4.0.0 hit the disabled-function failure from the log example above. It happened in editor-related functionality, and the developer then supplied a fix. One participant reported that v3.4.3 had worked on the same hosting setup, which made the version change a useful lead.

Enabling a server-disabled function just to suit one plugin is a poor default. Check how the plugin handles the restriction, then use a supported fix or ask the developer or host about compatibility.

Execution time and code changes

Another WordPress.org support case described a plugin update to version 1.64 followed by this fatal message:

PHP Fatal error: Maximum execution time of 30 seconds exceeded

The failure appeared while changing conditions in a complex operation. The reporter said restoring plugin version 1.63 recovered that operation.

That environment included WordPress 7.0.2 and PHP 8.2.14, and the discussion also mentioned WooCommerce order editing.

If the first fix fails, stop guessing and escalate with evidence

If a targeted change makes no difference, undo that test and reassess. Another plugin, a must-use plugin, custom code, the theme or the PHP environment can be involved. Contact your host or developer when you lack the logs or permissions you need, the cause is still unclear, or further experiments would disrupt an essential production workflow.

If disabling ordinary plugins changes nothing, look at other loaded code and the server environment. Don’t delete WordPress or replace core files.

What to send your host or developer

Symptom: The exact message, the affected URL and the action that triggers it.
Timing: When it failed and any changes made just before.
Error: The PHP fatal message, error class and a shortened stack trace with private details removed.
Versions: WordPress, PHP and plugin versions.
Tests: What you changed, what happened and what you reversed.
Restore point: Whether you have a backup covering both files and database.

When a backup restore is justified

A complete known-good backup is your option when no targeted fix is available and the incident requires restoration. The restore point must cover a consistent set of WordPress files and database information.

On a site that takes orders, membership updates or new content, a restore can overwrite changes made after the backup. What you lose follows from what was written since then and how you restore. Treat a full restore as its own procedure with a final test. Don’t improvise a database overwrite in the middle of a plugin investigation.

Verify the repair and remove the temporary debugging setup

You’re done when the action that failed works again and your debug settings are off. Loading the homepage proves little when the failure involved the editor or an admin action.

Repeat the original action: Open the same editor, dashboard screen or public-page operation and confirm it completes.
Check the site: Load a few public pages and the admin screens you use, plus any feature the affected plugin provides.
Leave Recovery Mode: Confirm normal behavior outside the temporary recovery session.
Clean up: Turn debug off, then secure or delete debug.log.

Test in a normal visitor or administrator session, since caching or an existing session can hide the result.

How to Fix the WordPress White Screen of Death

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

When your WordPress site or dashboard goes blank, find out which requests fail and read the recovery message or error logs, then make the smallest repair those clues support and make sure you can undo it. If you have no safe fix and no reliable recovery point, stop experimenting and call your hosting provider or administrator. Confirm that public pages, the dashboard and essential functions work before closing the incident.

A blank white page tells you almost nothing about what broke. WordPress calls it the White Screen of Death (WSOD). The cause can be a plugin, a theme, PHP, the database or the host.

Start by noting where the failure stops. A working homepage with a blank admin screen points to a different problem than a site that fails on every URL.

Find out which part of WordPress is blank

A white screen describes what the visitor sees. It doesn’t point to one cause or one HTTP status. The browser can show an empty page even when the server returns 200, and then you need to look at what the application returned. Other incidents return an error such as 500, and a 502 points to the web server and its upstream service. A completely blank response calls for checking the actual HTTP status and PHP error log even when WordPress displays no message.

Open the affected URL and compare it with the homepage, another public page and /wp-admin. Note which ones work. Then open the browser’s Developer Tools, the Network tab, reload the failing page and check the main document request: its status and response body.

What is blank?	What to check	What to do next
Public pages, but not the dashboard	Which URLs fail, their status, recent front-end changes	Read existing error logs, then test the theme or plugin you suspect
`/wp-admin`, but the public site works	Whether login, dashboard or both fail	Use Recovery Mode or a method that doesn’t need the dashboard
One post or page	The exact URL and whether neighboring pages load	Look at changes to that page and matching log errors
Nearly every site URL	Public and admin response statuses	Check recovery messages and hosting or PHP logs
One browser or user session	How logged-in, private and other sessions differ	Compare logged-in and private sessions, then check the cache
Requests return `500`, `502`, or `503`	The exact status and the failing URL	Diagnose the web server or PHP service

An owner in a January 7, 2026 r/Wordpress discussion wrote, “For the past two days, my website hasn’t allowed me to log in directly from wp-admin, but the site itself functions normally.”

Also load the failing page in a private or logged-out window, and on another device or account. Write down any difference.

Use Recovery Mode if WordPress offers it

WordPress added Recovery Mode in version 5.2 for qualifying fatal errors. A fully blank site can produce no recovery message or email. If you do get a genuine recovery email, open its private link. That starts an administrator recovery session where WordPress temporarily pauses the failing plugin or theme, so you can find and fix it. The WordPress Recovery Mode documentation explains the process. No valid link? Go to the error logs or your hosting access instead of waiting for an email that can fail to arrive.

Check what changed and collect the first error messages

Before you change anything, look at what changed around the failure: plugin or theme updates, PHP settings, deployments, WordPress updates and host maintenance. If the failure started soon after one of those changes, suspect that change first.

Note these four things before testing anything:

Failure timeline: The approximate time of the first failure and your last visit when the page worked.
Recent changes: The update, setting or deployment closest to that time.
Recovery state: Which files and database data your backup contains, and how you would restore it.
Existing errors: Hosting or PHP error entries from around the failed request. Copy the relevant message and keep it private.

A log entry that names a plugin file, a theme file, exhausted memory or a parse error tells you where to look next. The stack trace shows where the error appeared.

You can get an error viewer in the control panel, while a server administrator reads separate PHP or web-server logs. If none of those entries explain the blank page, turn on temporary WordPress debugging.

Log the error without showing it to visitors

WordPress can write temporary diagnostic information to a log and keep debug output off the page. If you can reproduce the failure on staging, debug there. In a live incident you can need temporary protected logging on production.

Each of the three settings does one job:

Setting	What it controls
`WP_DEBUG`	Turns WordPress debugging on
`WP_DEBUG_LOG`	Sends debug information to a log when debugging is on
`WP_DEBUG_DISPLAY`	Decides whether debug output appears on the page

Keep a copy of the original wp-config.php. Find any existing definitions of these settings and edit them in place, above the stop-editing line. Don’t add duplicates.

WordPress documents this temporary configuration:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The last line asks PHP to stop displaying errors for the running process. Your server-level PHP configuration must also block public error display, especially for failures that happen before WordPress loads.

With the standard log destination, WordPress writes to wp-content/debug.log. On many installations that path sits in a web-served directory, so block public access to the file before generating sensitive diagnostic information. If your environment supports it, use a secured destination or a protected host logging facility instead.

Apply the settings, reload the failing request and read the private log. The WordPress debugging documentation describes these constants and how to use them.

If debug.log doesn’t appear, check the PHP or hosting error log. Early PHP startup or configuration failures stop WordPress logging from running, and some installations use a different log location. When WordPress, fatal errors, and plugin recovery need a separate check, see how to recover from a WordPress critical error.

Test the plugin or theme most likely to have changed

If a recent change or an error points to a particular plugin, start with that one. Test one suspect at a time. If a test changes nothing, undo it before trying the next.

When the dashboard still works

Deactivate the suspect plugin on the Plugins screen, then reload the page that went blank. If the page loads again, that plugin is the cause.

To test a theme, temporarily switch to an installed default theme. Note any changes to the site’s appearance or functions when you read the result.

Deactivating many plugins or changing the active theme can break checkout, forms, membership access and other live functions. Run a wider test only when you can accept that and can’t narrow the suspect down.

Restoring service and fixing the underlying incompatibility are separate jobs. Before putting the plugin or theme back, review its recent changes and compatibility requirements with whoever maintains it.

Recover when wp-admin won’t load

If the dashboard is blank, you can’t use the usual plugin and theme controls. Your next step follows from whether you have a hosting file manager, SFTP or SSH with WP-CLI. Change only servers you are authorized to change.

Access you have	Recovery method
Hosting file manager	Temporarily rename the suspect plugin or theme folder. Note its original path and name.
SFTP	Run the same folder-rename test. Make sure you’re in the correct WordPress installation.
SSH with WP-CLI	Deactivate a plugin with the WP-CLI command. Run it from the right site directory.
No file or command access	Ask the host or the person who maintains the site to recover it.

Temporarily isolate a plugin through files

When the clues point to one ordinary plugin, find its folder under wp-content/plugins and rename it to something easy to recognize. Write down the original name and path. WordPress can no longer load the plugin from its original folder, so you can see whether the affected screen changes.

If you don’t know which plugin is responsible, WordPress documents a broader test: temporarily rename the whole plugins directory. For example:

wp-content/plugins
wp-content/plugins.hold

The second line is the temporary name for the first. After the test, restore the original directory name. WordPress can mark ordinary plugins as deactivated while the directory is missing, so restoring the name doesn’t reactivate every plugin that was active before. Re-enable only the plugins you want.

Use WP-CLI when SSH access exists

With WP-CLI working, deactivate the suspect plugin:

wp plugin deactivate PLUGIN_SLUG

Replace PLUGIN_SLUG with the real identifier. If plugin loading stops the command from starting, WP-CLI documents a form that skips plugin loading:

wp plugin deactivate PLUGIN_SLUG --skip-plugins

--skip-plugins skips ordinary plugin loading for that one command. It leaves must-use plugins loaded and doesn’t change activation state. The separate wp plugin deactivate --all command deactivates all ordinary plugins.

When the active theme is suspected

If the failure followed a theme change and you’ve lost dashboard access, first confirm that an installed fallback theme exists. WordPress documents a file-based test: temporarily rename the active theme’s folder, so a suitable installed default theme can take over. If the test settles nothing, or WordPress can’t pick a valid alternative, rename the folder back.

After each no-dashboard test, check the page that failed and the relevant admin screen.

If plugins and themes aren’t the cause, follow the next clue

If the plugin and theme tests leave the screen unchanged, look at another layer. A failed test still narrows the search, as long as it really stopped the component from loading. When WordPress plugins, themes, and updates need a separate check, see how to manage WordPress plugins and themes.

An owner in an April 26, 2026 r/Wordpress thread wrote, “My website is showing a white screen. I tried to deactivate the plugins and themes folder, but no luck.”

What you find	Where to look next
PHP reports exhausted memory	PHP resource usage and host memory limits
PHP startup or early runtime error	Hosting PHP configuration or service
HTTP `500`, `502`, or `503`	The web server or upstream PHP service
Database error	The database connection and server availability
Blank output only from a cached view	Cache delivery versus origin response
Possible WordPress core modification	WordPress core integrity
Plugin tests don’t isolate the code that is running	Must-use plugins or other application components. Note which loading paths your test actually excluded.

Whatever you find, save the exact error message, the request time and the failing URL. Keep database credentials out of any notes you share.

When the error points to PHP memory

Look at memory limits only when logs or measurements show memory exhaustion. Find out which operation needs the memory and what your host allows before changing the limit.

When cache changes what a visitor sees

If you can get an uncached or origin response, compare it with the cached view. A cached blank page can persist after the underlying problem is fixed. If the origin itself fails, diagnose the origin.

When WordPress core files are suspect

If damaged or altered core files are a real possibility, WP-CLI can check them:

wp core verify-checksums

It compares your core files against the published WordPress checksums. The command checks core files only. If you get an unexpected mismatch, confirm that the comparison uses the installed WordPress version and locale.

Know when to stop changing files and recover the site another way

Stop experimenting when you have no plausible next test, can’t undo a change, or can’t get into the failing service. Also stop when a production site handles important transactions and an unplanned restore can overwrite newer data.

A managed host can inspect service logs and run a controlled recovery outside the WordPress dashboard. On a self-managed server, that job falls to an administrator who knows its PHP, database and web-server setup.

Before choosing a restore point, check which files and database contents it includes and what happened on the site afterward. A backup taken before new orders, form submissions, posts or account changes restores an earlier database state. If you need that newer information, save or reconcile it first.

Verify the repair and close the debug session

A working homepage is only part of a recovery. Check the page that originally failed and the functions your visitors and administrators rely on.

Original symptom: Open the exact page, dashboard view or login URL that went blank.
Public pages: Load the homepage and one other public URL.
Administration: Confirm you can log in, reach /wp-admin and open the affected management screen.
Different user contexts: Repeat any logged-in, logged-out, browser or device condition that gave a different result at the start.
Essential functionality: Check the contact form, publishing, membership login or a test-mode checkout, whichever applies.
Error recurrence: Read the private logs for new failures from the recovered request.

Record which plugin, theme or setting stays changed. Return the debug constants to your intended production settings, confirm that PHP errors aren’t shown publicly, and either store the temporary logs securely or delete them, depending on what you need for the incident.

How to Diagnose WordPress 500, 502, and 503 Errors

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

When WordPress returns a 500, 502, or 503 error, find the failing request and the server layer that answered it, then use the matching log entry or maintenance evidence to pick one targeted, reversible fix. If you can’t get that evidence or don’t control the server, send your host the error, URL, time, and any diagnostic clues. Retest the original failing operation before calling the site recovered.

Your homepage can load fine while the dashboard, an AJAX request, or a WooCommerce operation fails. Start with the one request that broke and the server message logged for it.

What 500, 502, and 503 mean

Each code describes a different kind of failure. Separate 500, 502, and 503 at the first responding layer: the application, the proxy-to-upstream connection, or service availability can each require different log evidence.

Response	HTTP meaning	First useful clue
500 Internal Server Error	The server hit an unexpected condition and couldn’t complete the request.	An application fatal error, a web-server configuration failure, or another server-side error entry.
502 Bad Gateway	A gateway or proxy got an invalid response from its upstream.	The upstream destination and the gateway’s matching error message.
503 Service Unavailable	The service can’t handle the request right now, for example during maintenance or overload.	A maintenance indicator or evidence that the service has no capacity.

Note the scope along with the status. Does the error hit every public page, only /wp-admin/, or one endpoint such as /wp-admin/admin-ajax.php?

Capture the failure before changing settings

Write down one failed request in enough detail that you can find it in a log.

If the page shows no HTTP status, open Chrome DevTools and select Network. With recording on, repeat the failing page load or action, then click the request to read its URL and Status. A browser label such as (failed) or a CORS error is not an HTTP 500, 502, or 503 response.

Request: The exact URL or endpoint, what you were doing, and whether you were signed in.
Response: The HTTP status, the error text on screen, and any non-sensitive CDN or hosting identifiers in the response.
Time: The date, clock time, and time zone, so a host can match it to server logs.
Scope and recurrence: Which requests worked, which failed, and whether the failure was constant or intermittent.
Recent change: A plugin, theme, PHP, .htaccess, migration, server, or CDN change made before the symptom appeared.
Environment: Hosting provider, managed-hosting panel or VPS access, and CDN if you use one.

An error that follows a configuration edit makes that edit worth checking first.

Find the failing layer: CDN, server, or WordPress

A request can pass through a CDN, an origin proxy, a web server, PHP-FPM, and WordPress before a response comes back. For a 503, Cloudflare’s 503 guidance treats cloudflare or cloudflare-nginx in the error HTML as the sign that Cloudflare generated the response. In that case, go to Cloudflare support. If the error HTML lacks that text, the origin generated the response, so check your host’s server logs. Custom error pages, extra proxies, and other CDNs need provider-specific evidence.

Find the useful logs even if wp-admin is down

Start with whatever access you have left and find the error entry logged at the time of the failed request.

A GoDaddy/cPanel user wrote on r/Wordpress, “I edited my .htaccess file and now my site shows a 500 error, i failed to access my site using /wp-admin and now i am completely locked-out.” The host’s file manager or support channel still works when WordPress doesn’t.

Access available	Specific route	Evidence to obtain
Managed-hosting panel	Open the site’s application or server error-log view, if provided.	The entry for the failing URL at the incident time.
File manager or SFTP	Inspect hosting-exposed logs or the site’s configured WordPress debug-log file.	A matching PHP or application error, or confirmation that the host exposes no log.
Authorized VPS access	Use the server’s configured web-server and PHP-FPM error-log locations.	A gateway, service, or runtime message that matches the request.
No technical access	Ask the hosting operator to retrieve the web or PHP error entry.	The failing service and its logged message, without guessing a filesystem path.

On managed hosting, the panel can show an application log but not the PHP-FPM service underneath. On a VPS, the web server and the PHP runtime each record part of the same failure. The timestamp and request tell you which entry belongs to your failure and which is an unrelated warning.

When a WordPress debug log helps

WordPress documents WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY in its debugging handbook. The log and display settings take effect when WP_DEBUG is enabled. With WP_DEBUG_LOG on, errors go to wp-content/debug.log by default, though you can configure another path. This helps with off-screen AJAX and cron errors.

While you diagnose, WP_DEBUG_DISPLAY=false keeps WordPress debugging messages off the public page. If the request fails before WordPress runs, the debug log has no matching entry. Use the server or PHP-FPM logs for that layer.

Can a WordPress.org login restore access to a self-hosted site’s admin?

Your WordPress.org account and the administrator account on a self-hosted WordPress site are separate. Recover access with the site’s own credentials or through your host’s account recovery.

For a 500 error, match the log to the change

An Apache directive error, a PHP fatal, and a filesystem-access error can all break a WordPress request, and each needs a different fix. Start with the message logged for the failed operation.

Say an Apache-based site returns 500 after an .htaccess edit and the Apache error log names the directive you changed. Save a copy of the current file, then restore the known-good directive or your previous configuration. WordPress’s Apache configuration documentation describes the file’s role and the basic WordPress rules.

A standalone Nginx server ignores Apache .htaccess directives. Its routing rules live in the Nginx configuration. A setup with both Apache and Nginx can involve both configurations.

If the log shows a PHP fatal pointing to a component, find the reported file or function and the code change made just before it, then follow the WordPress critical-error recovery for that component.
If the message is about server configuration, find the directive it names and the server that reads it. Leave unrelated configuration alone.
For a permission or ownership error, identify the failing path and the account running the operation before you change any access rights. Blanket permission changes create security risks.
If the error is database-related, follow the separate WordPress database troubleshooting procedure once the log points there.
If the log reports resource exhaustion, check which resource it names before changing PHP, process, or storage limits.

For a 502 error, inspect the upstream connection

When Nginx is the gateway to PHP-FPM, its error log shows whether the configured upstream accepted the connection and whether it returned a valid response. The fastcgi_pass setting can point to a TCP address or a Unix socket, depending on the server configuration. For Nginx logs, PHP errors, and HTTP responses, see how to read logs after a website failure.

Observed gateway message	What it means and what to check
Connection refused to upstream	The connection attempt failed. Compare the `fastcgi_pass` destination with the PHP-FPM listener and service state.
`upstream prematurely closed connection`	The upstream closed the connection before the response finished. Match the request time with the PHP-FPM and application error records.
Invalid or empty upstream response/header	The gateway got no valid response. Check the FastCGI response and runtime logs for the affected request.

A gateway that waits and never gets the upstream response is a timeout, which is a 504. A 502 means the upstream sent an invalid response.

In r/woocommerce, a beginner using Nginx and Plesk wrote, “I keep getting an nginx 502 errors whenever different php endpoints are called, namely for example load-scripts.php or /wp-admin/admin-ajax.php.” The same thread included this recorded message:

2026-08-19 18:34:40 [error] upstream prematurely closed connection while reading response header from upstream

The failing request was POST /wp-admin/admin-ajax.php HTTP/2.0.

The log shows the connection broke. A PHP memory limit, a plugin fault, or a killed process can each cause that, and the PHP-FPM log from the same time shows which.

For a 503 error, separate maintenance from lost capacity

First work out whether WordPress itself is in maintenance mode or the responding service is out of capacity.

During WordPress core maintenance, the default message is “Briefly unavailable for scheduled maintenance. Check back in a minute.” The core handler can send HTTP 503 with Retry-After: 600.

The header sets 600 seconds in that handler. WordPress can also use a custom wp-content/maintenance.php drop-in, and hosting systems can show different maintenance responses.

Observed evidence	What it suggests	Next investigation
WordPress maintenance text during an update	Core maintenance is on.	Find out whether the update is still running or was interrupted.
503 with host or runtime resource warnings	The service lacks capacity.	Inspect the host’s resource observations and the PHP-FPM pool measurements.
503 on `/wp-admin/` while public pages work	The problem sits on an administrative path.	Compare the admin request with its runtime and application records.

Don’t delete a maintenance marker just because it exists. Confirm the update’s state first, then use the maintenance-specific recovery.

Reading PHP-FPM capacity evidence

If the PHP-FPM status interface is enabled and secured, PHP’s FPM status documentation describes listen queue, active processes, idle processes, slow requests, and max children reached. A nonzero listen queue means requests were waiting for a free process at the time you looked.

A max children reached value of 0 means the pool hasn’t hit that maximum in the recorded period. Any value of 1 or more means it has hit it at least once since the last restart. That is history. It doesn’t show the pool is saturated now, and it doesn’t give you a safe new value for pm.max_children.

Make one reversible fix, not five guesses

Pick the smallest change the logs support. Prepare a rollback before touching a production site, especially if other functions must stay up. For systemd, systemctl, and journalctl, see how to inspect systemd services and logs.

On r/Wordpress, a managed WooCommerce operator facing persistent 503 errors wrote, “Honestly, I can’t risk breaking this more.” Bulk plugin deactivation can break checkout, payment, or login on an active store.

Match the fix to the log: Name the exact setting, code component, maintenance operation, or service fault the diagnosis points to.
Keep the old version: Keep the previous configuration or component version and a way to restore it. If the change affects the database, you also need a usable database backup, not just the site files.
One change: Apply one change and check its effect before making a second. If you combine a PHP upgrade, a plugin change, and a server restart, you can’t tell which one affected the response.
Your host or admin: Ask your server administrator or managed-hosting provider to make service, socket, resource, and runtime changes that go beyond your account’s access.

For a severe outage, a host-managed restore of a known-good state is an option, provided you understand its effects and the rollback.

Verify recovery and know when to call the host

Repeat the failing URL or workflow in a safe test. Use the exact operation that failed, not a different page. If the next step involves WordPress, PHP errors, and recovery, see how to troubleshoot WordPress errors by symptom.

Confirm the admin action, AJAX operation, or business process completes as expected. Don’t run test purchases that affect live customers.
Compare the new attempt with the same server or application log to see whether the failure continues.
For an intermittent failure, keep watching under the conditions where it recurred.

A useful hosting-support handoff

If the failing system is beyond your access, send your host the domain, failing URL or endpoint, status and visible message, incident time and time zone, affected operations, hosting and CDN setup, a sanitized log extract if you have one, and any change you already tried. Say which public or logged-in functions still work. Remove cookies, authentication headers, credentials, and customer information from anything you share.

For a Cloudflare-generated 503, Cloudflare’s support procedure can also ask for the site’s /cdn-cgi/trace output. Send that privately.

How to Fix “Error Establishing a Database Connection” in WordPress

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

To fix “Error establishing a database connection” in WordPress, confirm which database the site is configured to use, then test access to it before repairing tables or restoring a backup, because the error that test returns tells you which fix to apply. If a site that used to work fails now and then, check database availability, disk space, and connection limits before changing credentials. After the fix, test database-backed functions and watch for the error to return.

What “Error Establishing a Database Connection” means

WordPress loads much of its site data, including posts and settings, from its database. This error means it can’t establish or use the configured connection. The message doesn’t tell you whether any content is lost. A different message, “One or more database tables are unavailable,” points to a table problem instead. “I really hope that i can get back all the edits that were made on the website last night. It took hours. :(” That’s what a poster in r/Wordpress wrote after a recently customized site stopped loading.

Before you change anything, find out when and where it failed

Answer three questions first. Did the installation ever work? Does every request fail? What access do you have to the hosting environment?

What you observe	Where to start	What to check
New installation or recent migration	The database, account, and destination host you intended	Compare them with the active WordPress configuration
Previously working site, consistently unavailable	Recent changes and the database service status	Test the configured connection
Error comes and goes	Failure times and resource conditions	Check server health
Managed or shared hosting	Your provider’s database details and diagnostics	Use the hosting panel or contact provider support
Self-managed Linux VPS	Whether the database service is running	Read the logs and test database access on the server
Docker Compose deployment	Database readiness and the settings the containers run with	Work through the Docker Compose section

“The issue turned out to be I was using 100% of available storage space on my digital ocean droplet,” an r/Wordpress poster wrote after investigating a website outage.

Check the database settings WordPress is actually using

Start with the values WordPress actually uses, especially after a migration or deployment change.

The WordPress configuration reference defines four central settings:

Setting	Purpose	What must match
`DB_NAME`	Names the selected database	The intended database on the selected server
`DB_USER`	Identifies the database account	The account this installation is allowed to use
`DB_PASSWORD`	Authenticates that account	The account’s current password
`DB_HOST`	Defines the connection endpoint	The correct hostname, plus the port or socket if one applies

The database name and account name are different things. A valid account can still lack access to the database WordPress asks for.

On a conventional installation, read these values in wp-config.php. Some deployments generate their configuration from runtime environment variables. In those, an edited example file doesn’t control the running application’s settings.

Look closely at DB_HOST. WordPress accepts hostnames with port or Unix socket information when you need it. localhost and 127.0.0.1 can select different connection mechanisms.

Compare the active values with the database details from your host or deployment configuration. Fix any mismatch, and keep the previous configuration so you can roll back.

Protect database credentials: Never put passwords in publicly accessible PHP diagnostic files, screenshots, support messages, or exposed command output.

Test the connection and capture the actual database error

Test the connection with the same details WordPress uses. The test shows whether your database account can reach and use the selected database.

Managed hosting: Use your provider’s database interface or diagnostic tool. Note which database and account you test.
Linux VPS: Use a restricted database client from the server environment and keep its error message.
WP-CLI: If WP-CLI and the database client tools are installed, run a read-only query using the site’s configuration.

For WP-CLI, the WP-CLI database query command includes an example that returns the selected default database:

wp db query 'SELECT DATABASE();'

Run it from the intended WordPress installation. If the result names your database, the connection works and can run the query against its selected database. An authentication, transport, or database-selection error tells you where to look next. The MySQL DATABASE() function returns NULL if the connection has no selected default database.

wp db check is a separate command. It runs mysqlcheck --check with your WordPress configuration and checks tables, so use it for table integrity problems, not for this connection test.

Database login and database selection need a successful connection with the right account and target database. A MySQL client connected to another database instance can succeed while WordPress still can’t connect to its configured target. For work involving MySQL, database users, and permissions, follow the steps to check MySQL user credentials and grants.

Match a persistent connection error to its fix

Login, access to a named database, and the connection itself are three separate stages, and the error code tells you which one failed.

The MySQL 8.4 server error reference lists errors the server reports. Its Client Error Message Reference covers connection errors that client libraries report:

Error	Meaning	Next action
`1045` (Access denied)	The server rejected the account’s login, or the host you connect from isn’t permitted for that account	Compare the configured account, password, and allowed connecting host
`1044` (Database access denied)	The account lacks access to the requested database	Check the account’s permissions on the named database
`1049` (Unknown database)	The requested database name is not recognized on that server	Check the database name, the target instance, and whether the database exists
`2002` or `2003` (Cannot connect)	`2002` concerns a local socket connection, `2003` concerns a specified host and port	For `2002`, check the socket and the local service. For `2003`, check the host, port, service, and network path
`1040` (Too many connections)	The database server has reached a connection-capacity limit	Check server load and connection limits

Find the row for your error before changing any setting.

If the account is rejected

With 1045, either the password is wrong or the account isn’t allowed to log in from that source host. Check the configured account and the hosts it can connect from before changing anything.

A client that logs in successfully can still hit a database-level privilege rejection, such as 1044. Keep the two errors apart when you check account grants. For work involving WordPress, PHP errors, and recovery, follow the steps to troubleshoot WordPress errors by symptom.

If WordPress requests an unknown database

With 1049, confirm which database instance received the request and whether your database exists on it. After a migration, the active configuration can still point to a name from the previous host, or to a destination setup that isn’t finished.

If the connection cannot reach the server

A 2002 or 2003 puts the problem at the service or the connection path. The failing endpoint can be a local socket, a TCP hostname and port, or an address the application’s environment can’t reach.

After you fix the mismatch, repeat the test. If the error changes, a different stage is failing now.

If the site was working or the error comes and goes, check server health

For errors that come and go, look at the server while the failure happens. MySQL or MariaDB can become temporarily unavailable, run short of a resource, or reject connections once capacity runs out.

One poster in r/Wordpress running WordPress and MariaDB in Docker described the symptom: “However, after refreshing the page a few times sometimes the website will load again (live site, not cached).”

On a self-managed VPS, check the database service status and the error logs around the failed requests.

What to look for

Service availability: Was the database process accepting connections when WordPress failed?
Database logs: Look for errors tied to the failed requests or to unexpected restarts.
Disk space: Check free space on the filesystem the database and its operations use.
Connection pressure: Compare rejected connections with the server’s limits during the incident.

MySQL documents 1040, “Too many connections,” for a server that has used up its client connection capacity.

If a restart brings the database back for a while, look at the errors and resource use before the restart to find what keeps causing the failure. For MySQL, SQL dumps, and database recovery, use the procedure to back up and restore a MySQL database.

On shared hosting, you can’t read privileged database logs or restart the service yourself. Ask your provider to check them.

Docker Compose: check database readiness, service names, and persistent data

A running Docker container can still be waiting for its database to become ready. WordPress also needs the right service address and the credentials of the database that’s already been initialized.

In r/selfhosted, a poster starting WordPress with Docker Compose put it this way: “I have waited as long as 24 hours trying to get it to launch but it never moves from that page.”

Docker Compose can wait for a dependency marked service_healthy, which means its configured health check passed. Read the database logs and look at what the check actually tests to judge readiness. A healthy result reflects that condition, so you still need to run the connection test for WordPress’s account and selected database.

Match the service address to the Compose network

When WordPress and its database run in separate containers, the database host must name the database’s endpoint on their network. Inside the WordPress container, localhost refers to that container’s own environment.

Compare the application’s database target with the database service defined in Compose. Check the database name and account the running installation uses.

Keep the initialized database data intact

Initialization environment variables don’t reconfigure a MySQL database that already sits in a populated data directory. A password you changed in an environment file therefore won’t match the credentials that remain in the existing database.

Find the persistent data volume attached to the active database service before modifying its configuration or storage.

Preserve the database volume: Deleting or recreating a populated database volume can destroy WordPress content.

When to repair, restore, or contact the host

Repair modifies database tables. Restoration recovers data from an existing backup. Before doing either, check the connection result and see what stored data you can still read.

What you see	What to do	Rule
Credentials, endpoint, or service connection fails	Fix access or bring the service back	Don’t repair tables for a connection failure
Database connects, but required tables are unavailable or damaged	Check table integrity, then repair only the affected tables	Save recoverable data first
Required data is missing or unusable, and a suitable backup exists	Consider restoring the backup	Check what the backup covers and what changed after it
Necessary server-side information is inaccessible	Escalate to hosting support or the server administrator	Send the exact error and the timeline

When WordPress database repair makes sense

Before running repair, make sure you have a recoverable backup or preserved copy of the current database and site files. If database access blocks a safe backup, ask your host or server administrator about recovery options before altering tables.

WordPress has a repair facility controlled by WP_ALLOW_REPAIR, with its interface at /wp-admin/maint/repair.php. The WordPress repair documentation explains that the interface requires no logged-in user while repair mode is enabled.

Use this feature only to repair tables you’ve confirmed are damaged, and remove or disable WP_ALLOW_REPAIR as soon as you finish. Know which database and tables are affected before starting.

Before restoring a backup

A complete WordPress backup includes the site’s files and database.

Check the backup’s contents and recovery point before overwriting production data. Restoring an older database replaces any posts, settings, or other changes made after the backup was created.

When to hand it to your hosting provider

If you can’t reach service health, privileged logs, or database account settings, give your provider a short incident report:

Time and behavior: When the failure began, when the site last worked, and whether it comes and goes.
Deployment: Whether it’s a new installation, a recent migration, or a site that worked before.
Test result: The exact database error and how you ran the test.
Changes made: The configuration edits or recovery attempts you’ve already tried.

Verify the site is back and that the error stays gone

A cached public page can look normal while database-backed requests still fail, so check more than the front page.

Run these checks after your fix:

Open a public page and the WordPress admin area. The page should behave as expected, and the admin area should retrieve site information.
Repeat the action that showed the error, and run one non-cached action that needs database access. If you ran a connection test, confirm it no longer fails.
For intermittent failures, compare later errors and service behavior with the original failure pattern.

WordPress Not Sending Emails? Diagnose the Failure First

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

To fix WordPress emails that don’t arrive, follow the original notification through its trigger, WordPress, the sending service, and the intended mailbox, fix the first stage that fails, then send that same notification again. If the receiving mail server already accepted the message, look at mailbox filtering or the recipient’s mail administrator before changing your WordPress mailer. Begin by working out whether the problem hits every message, one notification type, or one recipient.

Start with the pattern: which WordPress emails fail?

A missing password-reset email and a missing contact-form notification look the same to the person waiting for them. They follow different paths. Before you touch your mail settings, pin down what stopped working. Trace one test message from the WordPress action through its mail transport, authentication and DNS records, then check the receiving mailbox.

Write down four things: the type of email, its recipient, when it last worked, and what changed around that time. A hosting move, a plugin update, or a new mail service narrows the search. Timing alone leaves the cause open.

What you observe	What it points to	Where to investigate
Every WordPress email seems to fail	The shared sending path	WordPress mail attempt
A form submits, but no notice arrives	Form processing and email sending are separate steps	Form configuration
SMTP tests work, but form notifications fail	The test and the form use different application paths	Form notification settings
The mailer reports a connection or authentication error	Transport or provider submission failed	Exact mailer error
Sender authentication fails	Domain identity or authentication needs attention	From, SPF, DKIM, DMARC
Provider reports Delivered, but the inbox is empty	The receiving side handled the message	Recipient mailbox
Only one recipient misses messages	A problem specific to that destination	Recipient filtering
Email failed after a hosting migration	Website and mail responsibilities changed	Hosting and routing
Only order or password-reset messages fail	The notification trigger	Application notification

If WooCommerce order notifications arrive while your contact-form messages disappear, the problem sits in the form-specific path. If every type of WordPress message fails, look at the shared mail path.

Find out whether WordPress tried to send the message

A thank-you screen can appear even when the form created no email.

WordPress sends mail through wp_mail(), which uses PHPMailer underneath. The WordPress wp_mail() documentation states that a successful return from the function doesn’t prove the recipient received the message.

WordPress also gives you two hooks:

wp_mail_failed: Reports failures in the PHPMailer mail path.
wp_mail_succeeded: Reports success in that same path.

Track one original notification

Trigger one identifiable instance of the notification that originally failed. Submit the affected contact form with test details, or start a password reset.

Look for that event in your WordPress mail log, plugin diagnostics, or application error output.

You’ll end up with one of three outcomes:

WordPress tried to send: WordPress or its mailer recorded an attempt to process the message.
WordPress logged an error: An error identifies a failure during mail processing.
The logs don’t say: Your diagnostic tools hold too little information about that event.

The third outcome needs care. A missing entry in a logging plugin means WordPress skipped the send only if you know what the plugin captures and how it’s configured. If you have no record you can trust, turn on mail logging, trigger the notification again, and check the new entry.

When SMTP tests work but contact forms still fail

An SMTP test can succeed while the real contact form stays broken. The test uses one mail path and one destination. The form has its own notification settings and its own trigger.

An Elementor administrator on r/elementor wrote: “I tried Wp-smtp using office settings, the plugin sent a successful email but the forms continue to not send.”

Next, check the form’s notification settings:

Notification enabled: Is the form set up to produce the email?
Recipient: Does the notification go to the right mailbox?
Sender and reply addresses: Are From and Reply-To set for their separate purposes?
Suppression: Does the form plugin have a setting that blocks actual mail transmission?

Contact Form 7 has two checks worth making in Additional Settings. With demo_mode: on, the form returns a successful response but skips the email. With skip_mail: on, sending is suppressed, but other form activity, including submission storage through Flamingo, can continue. Both are documented in the Contact Form 7 additional settings guide.

A form plugin can keep submitted entries even when its email notification fails.

Fix any mismatch you find in the form’s settings. Note the old value first so you can undo the change if the diagnosis turns out wrong. When WordPress, PHP errors, and recovery need a separate check, see how to troubleshoot WordPress errors by symptom.

Read the SMTP or mail-provider error before changing settings

When WordPress tried to send, the transport or provider can tell you what stopped it. A connection problem, rejected credentials, and an unauthorized sender each need a different fix.

Find the matching entry in your mailer’s error log or your sending provider’s activity records, and read the exact message.

Error or status	What it means	Fix
`SMTP Error: connect() failed`	The SMTP connection failed	Check the configured endpoint and your host’s restrictions
`SMTP Error: Could not authenticate`	The server was reached, but authentication failed	Review the service’s credentials or authentication setup
`SMTP Error: Data not accepted`	The SMTP server rejected the submitted message data	Read the provider’s rejection details and check sender or message restrictions
Sender rejected or unauthorized	The sending identity wasn’t authorized	Check the sender’s verification or authorization requirements
Accepted for processing	The provider accepted the message at the reported stage	Continue with the provider’s delivery events
Outcome unknown	The records don’t show whether submission succeeded	Use the selected service’s diagnostic documentation

The first three error strings are examples from Gravity Forms troubleshooting. Their categories hold for other plugins too, but the wording differs by SMTP integration and provider.

Hosting-specific example: WP Engine documents restrictions on outbound SMTP port 25.

Keep SMTP credentials, API keys, and sensitive logs out of public support posts.

Check the From address, SPF, DKIM and DMARC

A message can reach the sending service and still run into sender-identity problems. Read the From address, the authenticated sending domain, and the recipient’s authentication checks together.

From shows the sender to the recipient. Reply-To tells the email client where replies go.

Say a visitor enters visitor@otherdomain.example in your contact form. If your site sends the notification with that address in From, your mail service is trying to send for a domain it isn’t authorized to use. Put a site-domain address in From and the visitor’s address in Reply-To. Replies still reach the visitor, and you aren’t impersonating them.

What SPF, DKIM and DMARC do

SPF: Lets a domain list its authorized sending systems in DNS.
DKIM: Authenticates a message with a cryptographic signature from the signing domain.
DMARC: Checks whether the domain in the visible From address aligns with a domain authenticated through SPF or DKIM, according to the domain’s DMARC rules.

An SPF pass for one domain doesn’t mean the message passes DMARC alignment.

Google’s Email Sender Guidelines set different requirements by sender category. Every sender to Gmail needs SPF or DKIM. Senders that meet Google’s published bulk-sender threshold need SPF, DKIM, and DMARC.

Compare your sending identity

Compare the From domain you’ve configured with the domain your sending service authorizes and authenticates. Check the provider’s published DNS instructions against your SPF, DKIM, and DMARC records.

If a message arrives anywhere in a Gmail mailbox, Gmail’s Show original feature shows its authentication results in the headers.

Change DNS records only when your configuration and the provider’s requirements show a mismatch. Replacing unrelated entries adds new failure points and doesn’t explain the original problem.

If the provider says “Delivered,” check the receiving side

A sending provider’s Delivered status can mean the recipient’s mail server accepted the message. Final placement in the Inbox is a separate outcome. Postmark’s delivery-status documentation describes this distinction.

A poster on r/Wordpress posted an update about a nonprofit site’s missing notifications: “It seems that emails were coming through after all, but they had suddenly started going into spam.”

Check how the receiving side handled the message to that address:

Spam or junk: Filtering can move a message out of Inbox.
Quarantine: Some organizations hold messages outside the recipient’s normal folders.
Mailbox rules or forwarding: Automated rules can move or redirect incoming mail.
Recipient-domain mail trace: A mailbox administrator can tell whether the organization’s mail system received, rejected, or handled the message.

Compare what you find on the receiving side with the sending provider’s event for the same message.

If email broke after moving hosts, separate web hosting from email routing

In an unresolved r/webhosting case involving GoDaddy domain and email services, a poster wrote: “After changing the website host from Cloudway(s) to SiteGround, our email is no longer working.”

The website, DNS zone, email mailboxes, and WordPress transactional sending service can each be managed by a different provider. Map out which service moved and which stayed. Then work out whether inbound mailbox delivery, outbound WordPress notifications, or both failed. Do that before changing MX records or local mail-routing settings.

Check the original notification: password resets and WooCommerce emails

Some WordPress emails rely on a specific application event. A working mailbox or mailer says nothing about whether a given account or commerce notification was generated.

Password-reset requests and administrative email changes run through WordPress-specific workflows. When one of those messages is missing, ask whether the event actually happened and produced the expected notification.

WooCommerce works differently. Its email notifications follow the configured email type and the order event or status. An order in the dashboard can exist without every possible order email having been generated.

Check the event and the notification

For the missing account or WooCommerce message, check whether the notification is enabled and which event or order status triggers it.

WooCommerce introduced built-in transactional email logging in version 10.9. If your installation has the feature and it’s set to record the relevant events, open WooCommerce → Status → Logs and select the transactional-emails source. The records show one of four outcomes:

Sent: WooCommerce reports handing the email to its sending path. This isn’t an inbox-delivery confirmation.
Failed: The email attempt hit a recorded error.
Disabled: The notification was disabled.
Skipped: WooCommerce skipped sending that notification.

Your logging configuration sets log visibility and detail. These are WooCommerce transactional-email records, not a full history of WordPress password-reset or other core messages.

For an account-related message, focus on the operation you requested and the WordPress notification it should produce. Ordinary messages arriving through Google Workspace or another mailbox provider prove only that those messages arrived.

Verify the fix with the same end-to-end notification

A repaired setting needs a test that reproduces the original problem. Use the same application event and the same intended recipient.

A developer on r/Wordpress wrote: “Everything works for me. I get the emails. She doesn’t. What’s the deal?”

What each successful result proves

Evidence	What it proves	What it doesn’t cover
Form reaches thank-you page	The form reached that UI state	Mail generation and delivery
`wp_mail()` reports success	The WordPress/PHPMailer path reported success	Downstream acceptance and mailbox arrival
SMTP test reaches a test inbox	That specific test succeeded for its destination	The original notification and other recipients
Provider accepts or processes the message	Provider-side submission succeeded at the reported stage	Recipient-server and mailbox outcomes
Provider reports Delivered	Recipient-server acceptance, as the provider defines it	Inbox placement and reading
Intended recipient sees the original notification	That event reached the mailbox in this test	Future delivery to every address

After the fix, record the message type, test time, intended address, any event or log identifier, the provider’s delivery record for that notification, and the setting you changed. If you can’t check the final mailbox, report the highest stage you confirmed, such as provider acceptance or receiving-server acceptance.

How to Fix Mixed Content in WordPress (Find the HTTP URL First)

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

To fix mixed content in WordPress, open the affected page in your browser’s developer tools to find the HTTP resource your HTTPS page requests, before installing another plugin or editing the database. Then correct whatever produces it: a WordPress setting, a stored URL, a generated asset, a plugin or theme reference, or the proxy configuration. Reload the page to confirm the resource loads and the page works, and if DevTools shows no mixed-content request, investigate the failure it does report.

An HTTPS page can look normal until a font vanishes, a video fails, or the browser reports an insecure request. The clue you need is the URL the page tried to load and how the browser responded.

What a WordPress mixed-content warning means

Mixed content happens when an HTTPS page requests a resource over HTTP. Say a post at https://example.test/page/ references http://example.test/wp-content/uploads/photo.jpg. The page arrives securely, but the image URL uses an insecure scheme.

Browsers handle these requests differently by resource type and host.

HTTP resource on an HTTPS page	Browser treatment	Likely observation
Ordinary domain-hosted	Auto-upgraded to HTTPS	Image loads if its HTTPS URL works, or fails if it does not
JavaScript file	Blockable	Page interaction can fail
Stylesheet or web font	Blockable	Styling or typography can disappear
or `fetch`/XHR request	Blockable	Embedded content or fetched data can fail
Responsive image in or	Blockable	A responsive image can disappear
Otherwise-upgradable resource addressed by IP	Blocked	Browser refuses the insecure IP-hosted request

MDN’s mixed-content reference documents these distinctions. An upgraded image can still carry an outdated http:// reference in the page source.

A missing image alone does not mean mixed content. Certificate errors, 403 or 404 responses, CORS restrictions and redirect loops each need their own investigation. For WordPress, PHP errors, and recovery, see how to troubleshoot WordPress errors by symptom.

Find the insecure request in Chrome before changing WordPress

Inspect the affected WordPress page in Chrome DevTools. It shows the HTTP address, the resource type and what initiated the request.

Open the affected HTTPS page. Open Chrome DevTools and select Console and Network.
Reload the page. Look for mixed-content warnings and requests to http:// resources.
Inspect the request. Record the full URL, hostname, path, resource type, response status and initiator if shown.
Check what the browser did. It blocked the request, upgraded it automatically, or the request failed with an ordinary HTTP error.
Pick the repair. The URL tells you where to look. The initiator and surrounding page content show who generated it.

Chrome also offers a focused option under Privacy and security → Security → Non-secure origins → View requests in Network panel, as described in the Chrome DevTools Security panel documentation.

Insecure request or context	Possible origin	Repair section
Own-domain CSS or JavaScript generated with HTTP	WordPress URL settings or HTTPS detection	WordPress addresses. Proxy configuration
Old media address inside a post or widget	Stored WordPress content	Database URL replacement
Generated font CSS under Elementor uploads	Page-builder data or generated assets	Elementor repair
Asset under a plugin directory	Plugin settings or URL generation	Plugin and theme references
Script or image from another hostname	External provider or CDN	Third-party resources
HTTP URLs appear after TLS termination upstream	Proxy scheme detection	Reverse proxy/CDN
Missing image with no mixed-content request	File access, incorrect path, or another resource error	Remaining-failure diagnosis

Suppose Network shows:

http://example.test/wp-content/uploads/2024/header.jpg

That looks like a media URL, but the path does not prove it came from a post’s database content. A page builder, template or plugin can have produced it.

Another request looks like this:

http://cdn.example.test/app.js

The external hostname means someone else controls the resource, and the .js extension marks a script, which the browser can block.

WordPress has two address settings with different jobs. On a standard single-site installation, open Settings → General and compare both against your HTTPS setup.

WordPress Address (URL) is where the WordPress core files live. Site Address (URL) is the public address of the website. On an HTTPS site, both use https. Their paths can differ.

For example, a site served from https://example.test/ can keep its core files at https://example.test/wordpress/. WordPress documents this distinction in its migration guidance.

Some installations set these values through configuration or hosting tools, so you cannot edit them in the dashboard.

In a WordPress.org support thread about an insecure cookie-popup asset, the site owner wrote, “WP and Site addresses are both HTTPS”, so the next step is the resource that still uses HTTP.

If one address uses HTTP by mistake, correct that value and confirm the public page and admin navigation still work. If both fields are already correct, leave them alone and look at the component that emitted the insecure URL.

Replace old HTTP URLs stored in WordPress safely

Your address settings can be correct while old absolute HTTP links remain in posts, widgets, options or other stored content.

When the offending request comes from stored data, the replacement method matters. WordPress settings can contain PHP serialized values, and a raw string replacement can damage them.

Back up first

Before you change stored URLs, back up the WordPress database and site files. Then note the old address, the HTTPS address that replaces it, and the installation or tables the change covers. If the next step involves HTTPS, redirect rules, and TLS, see how to set HTTP-to-HTTPS redirects without loops.

The WP-CLI search-replace command reference documents serialized-data handling and dry-run support. The command takes the old value first, then the new one. If the next step involves WP-CLI, serialized data, and URL replacement, see how to run a safe WP-CLI URL search-replace.

For a single-site installation at example.test, run this first:

wp search-replace 'http://example.test' 'https://example.test' \
  --skip-columns=guid --dry-run

--dry-run reports the changes without saving them. Check that the matches belong to the right hostname, paths and tables.

--skip-columns=guid protects the guid field. WordPress’s migration documentation cautions against changing wp_posts.guid during a site move because those values serve as feed identifiers.

Apply the replacement

Once the dry run looks right and the affected resources work at their HTTPS URLs, run the same command without the dry-run flag:

wp search-replace 'http://example.test' 'https://example.test' \
  --skip-columns=guid

If the site also uses http://www.example.test, handle that variant separately.

WordPress Multisite needs extra care. The command covers the selected site and its registered tables. Options such as --url and --network control which installation it targets.

Without SSH: a database replacement plugin

If you only have dashboard access, use a database search-and-replace plugin such as Better Search Replace on WordPress.org. It lets you select database tables, handles serialized data and previews changes with a dry run.

Limit the replacement to your site and the addresses you are changing. In versions with a Replace GUIDs option, leave it unchecked on an established site.

Fix Elementor, plugin, theme and third-party HTTP URLs

When the main address settings are correct, the insecure URL can come from a page builder, plugin, theme, widget, custom stylesheet or external service.

Elementor-generated assets

Elementor keeps settings and generated assets that can retain or reproduce old addresses.

Its documented workflow is WordPress Dashboard → Elementor → Editor → Tools → Replace URL, which changes stored addresses. The same Tools area has Clear Files & Data, which regenerates Elementor’s generated files.

These menu labels follow Elementor’s documented interface from May 2026.

A WordPress.org forum user troubleshooting Elementor’s generated Google Fonts CSS asked, “Any ideas why this is happening or how to force Elementor to generate secure font URLs?”

The reported asset directory was:

/wp-content/uploads/elementor/google-fonts/css/

If the browser’s request points to that directory, start there. Replace URL handles stored content and Clear Files & Data handles generated files, so fixing one can leave the other broken. If the warning survives a file regeneration, a stored or hardcoded reference is still producing it.

Hardcoded plugin and theme resources

An HTTP address can also sit in a plugin setting, custom CSS, a template or a widget. Find the setting or code that produces it and correct that reference.

A cookie-banner asset is a clear example. An HTTPS WordPress page can reference a file under:

/wp-content/plugins/cookie-law-info/lite/frontend/images/close.svg

The plugin can output HTTP even when both address fields are correct.

With an external stylesheet, script or embed, the remote provider controls whether HTTPS is available. Your options are a secure URL from that provider, a replacement asset, or removing the obsolete integration.

Check HTTPS detection behind a reverse proxy or CDN

When a reverse proxy or CDN terminates HTTPS before the request reaches WordPress, the backend sees plain HTTP unless the original scheme is passed along. WordPress then generates insecure URLs. One WordPress operator using HAProxy, WireGuard and Nginx wrote on r/Wordpress, “I can get the page to load with Mixed content errors.”

If you run a similar chain, check where TLS terminates. Then check whether a trusted proxy sends X-Forwarded-Proto. With that header, WordPress detects HTTPS and avoids an admin redirect loop. Never trust forwarding headers supplied by the client, because they can be spoofed.

Choose a source repair, rewriting plugin or CSP

Correct a bad URL where it originates whenever you can. A source fix stays fixed without any rewrite on later responses. If the database is the source, use a serialized-aware replacement. Reach for output rewriting or a browser policy only when you cannot edit the origin yet.

Method	Suitable situation	What changes	Limitation
Edit source URL or setting	Known incorrect reference	Stored value or component configuration	Requires access to the source
WP-CLI replacement	Confirmed legacy database addresses with command-line access	Targeted stored data	Covers only the selected site and registered tables unless you target more
Dashboard database replacement plugin	Confirmed stored HTTP values without SSH access	Targeted stored data	Depends on correct table scope
Elementor URL and file tools	Builder-owned addresses or generated assets	Elementor data or generated files	Other components can still emit HTTP
Mixed-content rewriting plugin	Source cannot readily be corrected	Generated output or requests during runtime	Adds an ongoing dependency
CSP `upgrade-insecure-requests`	Browser-level upgrading fits the deployment	Browser request behavior	Does not edit WordPress data
Cloudflare HTTPS rewriting	Supported CDN-managed deployment	Edge URL handling	Depends on edge configuration and available HTTPS resources

SSL Insecure Content Fixer offers targeted settings and broader Capture modes. WPBeginner warns that extensive capture can slow the site.

The Content-Security-Policy: upgrade-insecure-requests directive changes how the browser makes insecure resource requests. It leaves your WordPress records unchanged.

Before changing an asset reference from http:// to https://, open the exact HTTPS URL and confirm it serves the file you need. If it fails, use a secure replacement or remove the obsolete reference. CSP, rewriting plugins and CDN rewrites do not create an HTTPS endpoint at the destination.

Verify the repair and investigate what remains broken

A source repair removes the insecure reference. A browser or CDN rewrite loads the resource securely but leaves the stored HTTP URL as it is. Cached output can keep older references, so test a fresh response after the change.

After the fix, check the page like this:

Clear caches. Clear every layer your site uses, such as WordPress page caching, generated builder assets, hosting or CDN caching, and browser cache.
Reload the affected page with DevTools. Compare the original insecure request with the new Network and Console entries.
Inspect the result. Confirm the resource loads securely and no mixed-content violation remains.
Test the original feature. Check the image, typography, stylesheet, embedded content or script behavior that first exposed the fault.
Sample related pages. Check other templates and routes, and test logged in if the original issue depended on it.

When the warning is gone but something still fails

Remaining observation	What to investigate
Image URL now uses HTTPS but returns 404	File existence and requested path
Resource returns 403	Permissions, server rules or access restrictions
External script remains unavailable	Provider’s HTTPS resource and URL
Plugin asset still uses HTTP	Plugin-specific settings or URL generation
Old URL reappears after a stored-data edit	Generated assets, templates or cached output
Admin login enters a redirect loop	HTTPS forwarding and redirect configuration

In one r/Wordpress report after a security-plugin change, a WordPress Multisite maintainer wrote, “Deactivating it again doesn’t bring them back.”

The same discussion involved upload-directory .htaccess rules. A request that fails because of access controls needs a different repair from a browser refusing an HTTP subresource.

If a change causes new damage, restore from the backup or the configuration you recorded before the change. Do not make a second broad change while the first failure is unexplained.

Why Is WordPress Slow? Find the Bottleneck Before You Fix It

NoScript Team — Thu, 29 Oct 2026 16:21:43 +0000

Find the delayed request before choosing a fix. Once your tests point to an expensive component, change that one component in a way you can undo, then test the same task again. If the cause stays unclear, give your host or developer the measured request and the conditions it ran under.

A homepage can appear instantly while the WordPress editor takes several seconds to open. Another site can send its HTML promptly, then spend the next few seconds loading scripts and images. The two call for different investigations.

Start with the exact thing that’s slow

Pick the page, screen or action that’s delayed and name it by URL or operation.

What feels slow	Request to isolate	Where to look
Public page loads slowly	Open the affected public URL	Initial response and browser loading
Dashboard or editor lags	Open or save a specific `/wp-admin/` screen	Logged-in WordPress processing
Product search or checkout stalls	The affected search, cart or order action	Dynamic request processing
Slowdowns come and go	A named action during a slow period	Incident timing and host activity

A public product page and an admin product lookup are different operations, even for the same product.

Write down the URL or action, your login state, device and browser, the approximate time and time zone, and any visible error. If the problem is intermittent, note when it happened even if the delay vanishes before it can be reproduced. Keep guesses about plugins out of it.

Get a baseline measurement

A performance score can go up while one user action stays painfully slow. Google PageSpeed Insights gives you a lab assessment and, when enough observations exist, real-user data from the Chrome User Experience Report (CrUX).

CrUX data in PageSpeed Insights covers the previous 28 days, and Google’s field classification uses the 75th percentile of recorded experiences. A fresh lab run and the aggregated field data can disagree. The Google PageSpeed Insights documentation explains both.

Metric	What it describes	Good	Poor
TTFB	Time to First Byte: initial response timing	≤ 800 ms	> 1,800 ms
LCP	Largest Contentful Paint: largest relevant visible content	≤ 2.5 s	> 4.0 s
INP	Interaction to Next Paint: response to user interaction	≤ 200 ms	> 500 ms
CLS	Cumulative Layout Shift: visual stability	≤ 0.1	> 0.25

CLS has no time unit, since it measures layout movement. Use the thresholds to pick which metric to investigate.

A Hostinger user discussing WP Rocket, Perfmatters, and other optimizations wrote on r/Wordpress on July 11, 2026: “However, my website still takes time to load. and it frustrates me.”

Take a baseline for the operation you chose in the first section. Run the test more than once, with the same page, login state, device and cache state each time, and save every result. If PageSpeed Insights has no CrUX data for your URL, keep the lab measurement and label it as lab data.

Pick diagnostic tools that match your access

Start with what you can reach. A browser shows request and rendering behavior, WordPress diagnostics add application detail, and server access exposes the processes behind a slow response. For CPU, memory, and disk usage, see how to measure Linux server resource usage.

Access	What you get	Use it to
Browser only	Network waterfall, request timing, browser performance, PageSpeed Insights	Locate the slow request or rendering phase
WordPress administrator	Tools → Site Health; Query Monitor	Check environment details, queries and WordPress operations
Host, developer or server administrator	Application performance monitoring (APM), server logs, PHP and database/resource telemetry	Trace the costly parts of a slow transaction and see server conditions during the incident

In WordPress, Tools → Site Health has Status and Info views that list configuration details and potential problems. An administrator can also use the Query Monitor plugin to inspect queries, HTTP API activity and component timings.

The browser can show that a response arrived late. It can’t show how much of the delay came from PHP, a database query or an external service the server called. Your provider and account permissions set APM and log access, so on managed hosting your host can be the one to pull those details for you.

Find out whether the delay happens before or after the HTML arrives

Your browser shows whether the HTML itself starts late, or arrives promptly and the page is slow afterward.

In Chrome, open DevTools → Network, reload the slow public page, select its main document request and open the Timing tab. The Chrome DevTools Network reference describes phases such as DNS lookup, connection, Waiting (TTFB) and Content Download.

The Timing tab’s Waiting (TTFB) phase covers the wait inside that one request. TTFB for the whole page navigation can also include earlier redirects and connection time.

If the document response begins late

Check the connection and wait phases. A long wait on the HTML request points to network conditions, cache behavior or backend execution. A server or application trace can then separate PHP work, database operations and remote calls the server makes.

If the HTML arrives promptly but the page remains slow

Read the waterfall below the document request and find the LCP element or the delayed interaction. Large images, blocking scripts, styles, fonts and third-party resources loaded by the browser are the first things to check. A slow LCP and a slow INP are different problems, so go by the action that felt slow.

Why a fast homepage can hide a slow dashboard

The public homepage and a logged-in dashboard take different paths. A full-page cache can return HTML it generated earlier for an eligible public request, which skips most of the work WordPress would otherwise repeat.

Request or cache layer	What gets reused	What it tells you
Anonymous HTML cache hit	Generated page output	A fast hit says nothing about uncached PHP and database speed
Authenticated admin or personalized action	Depends on the route and your cache configuration	Can run fresh PHP, queries and plugin code
Persistent object cache	Reusable application data	Cuts repeated data work without serving a whole cached page

The WordPress caching documentation separates page caching from object caching. Personalized routes can be excluded from full-page caching on purpose.

On December 28, 2025, a nonprofit administrator using DreamHost shared hosting and Cloudflare posted this on r/Wordpress: “However, the backend, the WP admin dashboard, runs super slow–not always, but most of the time.”

Load the public page as an anonymous visitor, then compare it with the slow logged-in or dynamic action. Check whether your cache or host reports a status on the response. A hit means the page came from cache. A miss means it didn’t. If nothing is reported, you can’t tell.

Trace slow WordPress admin screens and recent changes

Profile a lagging editor or dashboard as its own logged-in operation. Admin requests run plugin and theme hooks, load metadata, query MySQL or MariaDB and call remote services that a cached public page never needs.

In an August 24, 2026 r/Wordpress thread about structured content built with Advanced Custom Fields (ACF), a poster wrote: “My WordPress admin, however, is absurdly slow.” The same thread mentioned a recent HTTPS change.

Open the slow admin screen or repeat the same save while a trace is running, either in WordPress or from your host. Query Monitor groups database queries by the responsible component, flags slow operations and shows WordPress HTTP API request timing. A provider’s APM shows costly PHP transaction segments. The Query Monitor plugin page describes its views.

Look for a query, callback or HTTP call that takes a large share of the time during the slow action, and note which plugin or theme it belongs to. Repeat the action. If the same one is slow again, it’s your lead. Many short queries can cost less than one long wait, so plugin count and query count don’t point to a culprit.

If the slowdown began after a plugin, theme, PHP or configuration change, add that change to your record.

Trace slow AJAX requests, database work, and outside services

A stalled product lookup or order action can be waiting on one dynamic request while the rest of the page responds. WordPress interactions can go through admin-ajax.php, a REST API route or an application-specific endpoint. When page cache, Redis, and PHP OPcache need a separate check, see how to choose the right WordPress cache layer.

A poster on r/Wordpress asked this on September 4, 2026, in a discussion about a B2B WooCommerce workflow: “Any ideas that I can look into to improve loading speed and improve ajax lookup speed”

Trigger the slow action with the browser’s Network panel open and find the matching request by its timing and action. If you have access, line that same request up with WordPress query, PHP, database and HTTP-call diagnostics. Sort the delay into one of these:

WordPress/PHP processing: A handler, hook or callback takes measurable time to run.
Database work: A query or database wait takes time during the slow action. Look at its measured duration and whether something blocks it.
Remote call from the server: PHP waits on another service through WordPress HTTP handling or a related application request.
Browser-side resources: JavaScript execution or a third-party resource delays the displayed result after the server responds.
Unresolved: Your tools show a slow request but can’t split up its internal cost.

A wait on an API call made from PHP shows up in the application trace. A third-party script loaded by the browser shows up in the browser waterfall. Judge a database query by its behavior and measured time. Never change or delete rows based on table size.

WordPress Site Health warns when autoloaded options exceed a configurable default of 800,000 bytes. Background activity from WP-Cron or Action Scheduler is another candidate if its timing matches the slow operation.

Investigate intermittent slowdowns and hosting limits

When slowness comes and goes, line up the times it happens with resource graphs, PHP worker activity, scheduled jobs, database events and error logs.

A publisher with about 3,000 articles wrote on r/Wordpress on October 23, 2026: “When we move our website to another host then it is fixed for about 2-3 years.”

A move changes the PHP environment, caching, database setup and resource limits all at once, so the improvement doesn’t tell you which one mattered. Match the slow periods against your host’s telemetry and configuration history. If you can’t see those records, ask your host for them.

Test one suspected cause safely

Once your trace points to an expensive component, test by changing one condition you can restore afterward. If you change a caching setting, a plugin configuration and the PHP environment at once, you can’t tell which one made the difference.

Use staging or a planned maintenance window. Back up the site and keep the original configuration so you can reverse the change.

Protect the live site. Isolating plugins, changing the database or editing PHP settings can interrupt production workflows. Debugging and profiling add overhead and can expose sensitive information. Limit temporary access and logging, protect what you collect, and turn off diagnostic tools when the test ends.

Write the test down in three lines:

Suspect: The query, component or external call the trace pointed to.
Change: One setting you can revert, or one component you isolate.
Must still work: The action that has to keep working, and the failure that triggers a rollback.

For a slow editor save, the save has to keep working while you isolate the expensive operation from its trace.

Verify the fix or give your host an actionable report

A change worked if the original slow operation got faster and still does its job. Repeat your baseline test on the same URL or action.

Check function as well as speed. A faster editor that can’t save, or a checkout that won’t complete, is a broken workflow. One fast run doesn’t prove an intermittent problem is gone.

Improved and functional: Timings improve and the action still works. Keep the change.
Unchanged or broken: The action got no faster or stopped working. Roll back to the saved state.
Unresolved: You still can’t identify the expensive component. Escalate the specific incident.

When you escalate, send your host or developer the record you started in the first section, plus the cache state, measured delay, browser timings, the changes you made and any PHP, database or application trace you have.