Those submissions went to the old server. It was still answering for a slice of the internet twenty hours after the DNS change, and by then I had already stopped syncing it.

That is the failure that separates a bulk WordPress migration from moving a single site. When you move one site you watch it. When you move twenty in a weekend, you are running a pipeline, and the things that go wrong are the ones nobody is watching: writes landing on a server you have mentally decommissioned, cron firing on two boxes at once, a certificate that never issued because a DNS record was still pointing at the old IP when the challenge ran.

This is the process I use for fleet moves onto a single VPS: the manifest that makes the weekend repeatable, the two-pass sync, the database step people rush, the certificate limits that bite specifically at fleet scale, and a cutover order that keeps rollback cheap. It assumes SSH on both boxes and some comfort on the command line.

The failure that actually costs you: writes landing on the old server

Every migration guide tells you to lower your TTL. Almost none of them tell you what happens in the gap afterwards, and the gap is where the money goes.

Here is the mechanism. You change the A record. Most resolvers pick up the new IP inside the TTL window. Some do not: corporate resolvers that clamp minimum TTLs, ISP resolvers that ignore short values, browsers holding a connection open, a mail server that resolved the host an hour ago. For those clients, the old server is still the site. It still has a working database. It still accepts comments, form entries, orders, user registrations and password resets.

Nothing errors. Nothing logs. The write succeeds on a database you are about to throw away.

There are only two honest answers to this, and picking one per site is the first real decision of the weekend.

• Accept the loss. Fine for brochure sites, documentation, most blogs. A missed comment is not a business problem.
• Make the old server read-only the moment DNS changes. Mandatory for anything with a checkout, a booking flow, a members area or a lead form that feeds a sales process.

Read-only in practice means maintenance mode on the old copy, a static holding page on the old vhost, or pointing the old install’s wp-config.php at a database user with SELECT only. Any of those turns silent data loss into a visible error the visitor can react to. Someone who sees “temporarily unavailable” comes back. Someone whose order vanished does not.

Do not skip this because the old server “will be off soon”. The window between DNS change and old server shutdown is the longest, least supervised part of the whole weekend.

Build the fleet manifest before you touch a server

Twenty sites is the point where memory stops working. You will not remember which one runs an old PHP branch, which one has a hardcoded absolute path in a theme, which one has MX records pointing somewhere else entirely.

So the first artifact is a table. One row per site, filled in before anything moves.

• Document root and database name
• Current siteurl and home values, exactly as stored
• PHP version the site currently runs under
• Disk size of the document root and dump size of the database
• Where DNS is authoritative, and who holds the login
• Whether mail for that domain is on this server or elsewhere
• Does it take writes from the public: comments, forms, checkout, registration
• Cache and object cache in use
• Cutover batch number and rollback owner

Most of that you can pull off the old server rather than typing it. This walks a DirectAdmin-style layout and prints a tab-separated line per WordPress install:

for d in /home/*/domains/*/public_html; do
  [ -f "$d/wp-config.php" ] || continue
  printf '%st%st%sn' 
    "$d" 
    "$(wp --path="$d" option get siteurl --skip-plugins --skip-themes 2>/dev/null)" 
    "$(du -sh "$d" | cut -f1)"
done

The --skip-plugins --skip-themes flags matter here. Without them WP-CLI boots the full site, and one broken plugin on one install will stop your inventory halfway through with a fatal error.

The DNS column is the one people fill in last and regret. Check where each zone actually lives before the weekend, not during it. A domain whose nameservers point at Cloudflare while you are editing records in the old host’s DNS panel will not move no matter how many times you refresh.

Rebuild the stack, don’t clone the disk

There is a tempting shortcut where you image the old server and restore it onto the new one. It usually works and it is usually the wrong call, because you have just carried across every accumulated fix, every orphaned config, and every reason the old box got slow enough to need replacing.

Build the destination clean. Whatever the provider is, whether that is Contabo, InterServer, Hetzner or a machine you already have, the sequence is the same: base OS, web server, PHP with the version and extensions the manifest says you need, database server, control panel if you use one, firewall, then a hardening pass.

Two things to get right before any files land.

PHP versions. If three sites need an older branch and seventeen are happy on current, install both and make the per-site assignment explicit in the manifest. Discovering the mismatch after cutover means a white screen on a live domain instead of a note in a spreadsheet. Check the extension list too, not just the version number, because imagick, soap and intl are the usual absentees.

Access during the weekend. If you lock SSH and the control panel behind an IP allowlist, decide beforehand what your source address will be. A rotating home IP is how people lock themselves out of their own migration at two in the morning. A dedicated-IP option from a VPN provider such as NordVPN or Surfshark gives you one stable address to allowlist; a second admin path on a non-standard port works too. Deciding at the moment you are locked out does not.

Two-pass rsync beats one big copy

The mistake at fleet scale is treating the file copy as a cutover-day task. Copy everything on cutover day and your maintenance window is however long twenty document roots take, which for a media-heavy fleet is hours you do not have.

Split it. Do a warm sync days in advance while both sites are live, then a delta sync at cutover that moves only what changed.

Warm sync, run from the old server, no deletes:

rsync -aHAX --numeric-ids --info=progress2 
  -e "ssh -p 22" 
  /home/user/domains/example.com/public_html/ 
  root@NEW_SERVER_IP:/home/user/domains/example.com/public_html/

What those flags buy you: -a preserves permissions, times, symlinks and ownership; -H keeps hard links, which some backup plugins and dedup schemes rely on; -A and -X carry ACLs and extended attributes; --numeric-ids stops rsync remapping ownership through name lookups when the UIDs differ between boxes, which is exactly what happens when the new server creates users in a different order.

Delta sync at cutover, same command with one addition:

rsync -aHAX --numeric-ids --delete --info=progress2 
  -e "ssh -p 22" 
  /home/user/domains/example.com/public_html/ 
  root@NEW_SERVER_IP:/home/user/domains/example.com/public_html/

--delete removes files on the destination that no longer exist on the source. It is what makes the second pass an accurate mirror rather than a merge of two states. It is also the flag that will destroy your afternoon if you get the paths wrong, so check the trailing slashes: a source path ending in a slash copies the contents of the directory, one without it copies the directory itself, one level deeper than you meant.

Run the delta pass once with --dry-run before running it for real. And on SELinux systems, relabel the tree afterwards: files arriving over rsync carry contexts the web server may not accept, and that produces a 403 which has nothing to do with permission bits.

Databases last, and never with sed

Files can be stale for a few days. Databases cannot. Dump each database as late as you reasonably can, immediately before that site’s cutover, not on Friday for a Sunday move.

# on the old server, per site
wp --path=/home/user/domains/example.com/public_html db export 
  /root/migration/example.com.sql --skip-plugins --skip-themes

Import on the new box, then handle URLs. If the domain is not changing, you may have nothing to replace. If the site is moving from HTTP to HTTPS, or from a staging hostname, or from a temporary preview domain you used for testing, you do.

The rule that matters: do not run a find-and-replace over the SQL file with sed. WordPress stores widget settings, theme options, page builder layouts and plugin config as PHP serialized arrays, and every serialized string carries a byte-length prefix. Change the string without recalculating the prefix and the array fails to unserialize. The site does not error loudly. It loses its widgets, or its theme options revert to defaults, or the page builder renders an empty page.

WP-CLI unserializes, replaces and reserializes, which is why it is the only tool I use for this.

wp search-replace 'http://example.com' 'https://example.com' 
  --all-tables-with-prefix 
  --precise 
  --skip-columns=guid 
  --report-changed-only 
  --dry-run

Read the dry-run output before you commit. Each flag earns its place: --all-tables-with-prefix catches plugin tables that share your prefix and would otherwise be skipped, --precise forces a full unserialize pass on every column instead of the faster string-level path, and --skip-columns=guid leaves the GUID column alone because feed readers use it as an identifier, not as a URL to fetch. Drop --dry-run to apply.

Flush the object cache afterwards if the site uses one. A stale Redis or Memcached entry will happily serve you the old values and convince you the replacement failed.

TLS at fleet scale: where Let’s Encrypt rate limits actually bite

Twenty certificates in one weekend is where a limit you have never noticed becomes the thing that blocks you.

Let’s Encrypt publishes its limits and they are worth reading properly before a fleet move. Two of them are the ones that catch migrations.

• New certificates per registered domain. Up to 50 certificates per registered domain every 7 days, counted globally across all accounts. If your twenty sites are twenty separate registered domains, you are nowhere near it. If they are subdomains of one or two parent domains, which is common for an agency fleet, you can burn through it.
• Authorization failures per identifier per account. Up to 5 failures per hostname per account per hour, refilling at one every 12 minutes. This is the one that actually bites, because it is triggered by the exact thing you are doing: requesting a certificate for a hostname whose DNS still points at the old server, so the HTTP-01 challenge is served by the wrong machine and fails.

Order matters as a result. If you issue before DNS moves, HTTP-01 fails. If you issue after DNS moves, visitors hit a certificate error in the gap. Three ways out, in the order I reach for them:

1. DNS-01 validation. Proves control through a TXT record instead of an HTTP request, so it does not care where the A record points. You can issue every certificate before touching DNS. This is the clean answer if your DNS provider has an API your ACME client supports.
2. Cut DNS first, issue immediately after. Simple, and the exposure is short if you are watching. Batch it so you are never waiting on twenty challenges at once.
3. Copy the existing certificates and keys across. Buys you a bridge until the new server can renew on its own. Only viable if you control the old server’s filesystem and the certificates have real time left.

Whichever you choose, test the plumbing against the staging environment first. Most ACME clients expose this as a dry-run mode, and it exists precisely so you can fail as many times as you like without spending production budget.

One more thing that catches people: if any site has HSTS enabled with a long max-age, browsers that have seen it will refuse to fall back to HTTP. There is no grace period and no way to talk them out of it. Those sites need a valid certificate on the new server from the first request, which pushes them firmly toward DNS-01 or a copied certificate.

Planning the cutover order for a bulk WordPress migration

Do not move twenty sites at once. Batch them, and batch by risk rather than alphabetically or by size.

1. Batch one: the throwaways. Two or three low-traffic sites you own or that nobody would notice. This batch exists to prove the stack, not to make progress.
2. Batch two: the ordinary majority. Standard brochure and content sites, no checkout, no logins that matter.
3. Batch three: the ones with writes. Stores, membership sites, anything with a form feeding a sales process.
4. Batch four: the awkward ones. Custom stacks, odd PHP requirements, third-party integrations that whitelist your server IP.

Stop between batches. Look at the error logs on the new server, not just the homepages. Twenty sites failing the same way is one problem; catching it after three is a fifteen-minute fix, catching it after twenty is a rollback.

The per-site sequence inside a batch:

1. Drop the TTL on that domain’s records to a low value, at least a day ahead.
2. Run the delta rsync.
3. Dump, transfer and import the database.
4. Run search-replace if the URL is changing at all.
5. Test through a hosts-file entry or a resolved request, before DNS moves.
6. Change the A and AAAA records.
7. Put the old copy read-only.
8. Verify from outside, then move to the next site.

Step five is the one people skip and should not. You can send a request to the new server as if DNS had already changed, without changing anything:

curl -sSI --resolve example.com:443:NEW_SERVER_IP https://example.com/
curl -sS --resolve example.com:443:NEW_SERVER_IP https://example.com/wp-login.php | head -n 20

That gives you real status codes, real redirects and a real TLS handshake against the new box while the live site is untouched. If that returns a 301 loop or a 500, you have found it before any visitor did.

Cron, email, and the things that run twice

During the overlap window you have two live copies of every site. Both have a database. Both have a scheduler.

WordPress schedules through wp-cron.php, fired by visitor traffic. The old server still gets traffic, so it still fires cron, so it still sends the newsletter, still processes the subscription renewal, still runs the backup plugin. Subscribers get things twice. Worse, the site’s system crontab came across in your file sync and is now also running on the new box.

Handle it explicitly. On the old copy, disable the loopback scheduler when you make it read-only:

define( 'DISABLE_WP_CRON', true );

And on the new server, set up a real system cron per site rather than leaving it to traffic, because a site with no traffic yet has no scheduler at all:

wp --path=/home/user/domains/example.com/public_html cron event run --due-now

Wrap that in a cron entry or a systemd timer at whatever interval the site needs, and check wp cron event list before assuming nothing important is queued.

Email is the parallel problem and it fails quietly in the other direction. Your sites now send from a new IP. If SPF still authorizes only the old server’s address, and DKIM keys did not come across, and DMARC is set to anything stricter than none, your transactional mail starts landing in spam. Nothing bounces visibly. Password resets just stop arriving and you hear about it in support tickets a week later.

Three records to check per domain. MX is the one not to touch casually: if mail lives elsewhere and you replace a zone wholesale, the mailboxes go with it.

• MX: unchanged unless mail is genuinely moving with you.
• SPF: add the new server’s IP before cutover, remove the old one after the overlap window closes, not during.
• DKIM: keys are per-server. Either copy them or regenerate and publish the new public key.

The more resilient answer is to stop sending through the server at all. Routing WordPress mail through an authenticated SMTP relay means outbound deliverability stops depending on which machine the site happens to live on, which makes the next migration a non-event.

Troubleshooting the weekend

Redirect loop on the new server. Usually siteurl and home disagreeing with what the vhost or reverse proxy is doing about HTTPS. Check both values with wp option get siteurl and wp option get home. If the site sits behind a proxy or CDN that terminates TLS, WordPress may see HTTP on the back end and redirect forever.

Site loads, media does not. Either uploads did not finish syncing, ownership is wrong, or database paths still reference the old host. Compare a file listing on both sides before assuming it is a database problem.

Widgets or theme options empty after import. This is the serialization damage described earlier. It is not recoverable by re-running the replacement. Restore the database from the dump and redo the URL change with WP-CLI.

Certificate issuance failing repeatedly. Confirm what the challenge is actually hitting before retrying, because each failure spends part of your hourly authorization budget.

dig +noall +answer example.com A
dig +noall +answer @1.1.1.1 example.com A
openssl s_client -connect NEW_SERVER_IP:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

The first query uses your local resolver, the second asks a public one directly, and the difference between them tells you whether you are looking at a real propagation state or your own DNS cache.

Site fine, admin slow. Often a plugin trying to reach an external service that whitelisted the old IP. Look for API integrations, license checks and payment gateways in the manifest’s awkward-ones column.

Common mistakes

• Lowering TTL on cutover day. The old value is still cached; the change has no effect for as long as the old TTL says.
• Cancelling the old server as soon as the sites load. Keep it running, read-only, for the whole overlap plus a margin. It is your rollback.
• Replacing an entire DNS zone instead of editing the A record, and taking MX, SPF and verification TXT records with it.
• Running search-replace before importing, or on the SQL file instead of the live database.
• Testing only the homepage. Homepages are static and cached. Test a login, a form submission, an admin page and an uploaded image.
• Leaving both schedulers live and finding out through duplicate customer emails.
• Assuming the new server’s PHP extension set matches the old one because the version number does.
• Treating rollback as a fleet-level decision. Per-site rollback is what keeps one bad site from stalling nineteen good ones.

Best practices for a fleet move

• Write the manifest first and update it as you go. It is the migration record and the handover document.
• Take a restorable backup of each site to somewhere off both servers before you start, and test restoring one. A backup you have not restored is a hypothesis.
• Warm sync early, delta sync at cutover, dump databases last. Batch by risk, and prove the stack on sites nobody will miss.
• Verify every site from outside with a resolved request before its DNS moves.
• Point uptime monitoring at the new IP before cutover, not after. UptimeRobot or Better Stack will tell you about a broken site faster than the client will.
• Make the old copy read-only at the moment of DNS change, not at the end of the weekend.
• Keep a rollback note per site: which records changed, what they were before, who can revert them.
• Re-check cache configuration after the move rather than assuming it carried over, whether that is WP Rocket, WP Fastest Cache or a server-level layer.
• Retire the old server on a scheduled date with a final archived backup, not by forgetting to renew it.

Frequently asked questions

Is a bulk WordPress migration of 20 sites realistic in one weekend?

Yes, if the preparation happens in the week before. The weekend itself should be delta syncs, database moves and DNS changes. If you are still installing PHP extensions on Saturday morning, the weekend is not long enough.

How low should I set the TTL, and how far ahead?

A low value like 300 seconds, set at least 24 to 48 hours before cutover so the previous TTL has fully expired everywhere. Going much lower than 300 buys little and increases query load. Raise it back after the migration settles.

Will moving hosts hurt my search rankings?

Changing the server behind an unchanged domain is not itself a ranking event. What hurts is what goes wrong during it: 5xx responses while crawlers visit, failed certificates, redirect loops, a staging copy left indexable. Keep URLs identical, keep the site responding, and check Search Console afterwards.

Can I use a migration plugin instead of the command line for this?

For one site, plugins are a reasonable choice and handle serialized data correctly. At twenty the arithmetic changes: twenty manual export and import cycles through a browser, with no dry run and no delta sync. The command line is repeatable and scriptable, which is the point at fleet scale.

How long should I keep the old VPS running?

At least a week after the last site cuts over, in read-only mode. Some problems only appear over a full traffic cycle: weekly scheduled jobs, integrations that call in periodically, mail arriving at the old MX. Keep an archived backup after you destroy it.

What if one site breaks after cutover?

Revert that site’s A record and lift the read-only restriction on the old copy. That is why the old server stays up and why rollback is per site. If you sync the database back afterwards, be careful not to overwrite writes that landed on the new server in the meantime.

Do I need to move email at the same time?

No, and separating them is usually wiser. Move web first, confirm it is stable, then plan mailbox migration as its own change with its own window. Combining them means a single mistake in one DNS zone takes down both.

The one thing worth remembering

A bulk WordPress migration is not twenty small migrations. It is one process run twenty times, and the difference is that at scale the visible failures get caught while the invisible ones do not.

The copy is the easy part. rsync and WP-CLI are reliable, well documented and boring. What costs you is the overlap window: two servers both answering, both writing, both scheduling, for hours after you have mentally finished. Decide before the weekend what happens to writes on the old server, make that decision per site, and act on it at the moment DNS changes rather than at the end.

Do that, batch by risk, and keep a rollback that works at the level of a single site, and twenty sites in a weekend is an ordinary piece of work rather than a gamble.

Need help moving a fleet of sites?

Migrations are a good thing to have a second pair of hands on, because the expensive mistakes are the quiet ones. This is work I do regularly:

• Auditing an existing fleet and producing the migration manifest, batch order and rollback plan before anything moves
• Provisioning and hardening the destination VPS, including multiple PHP versions, control panel setup and firewall rules
• Running the sync and database cutover with WP-CLI, including URL replacement on serialized data
• Planning TLS issuance around ACME rate limits, including DNS-01 validation and automated renewal
• Sorting out post-migration email: SPF, DKIM, DMARC and moving transactional mail onto an authenticated relay
• Sitting in as the on-call engineer for the cutover window itself, or reviewing a plan you have already written

If you are planning a move and something in it worries you, send me the concrete thing: the site list, the current vhost config, the rsync output, the certbot error. I would rather look at the actual output than talk in general terms.

The post Bulk WordPress Migration: Moving 20 Sites to a New VPS in One Weekend appeared first on John Nessime.

That is the thing about DirectAdmin PHP-FPM pools that catches people out. You think you are tuning a site. You are not. You are tuning a user, and every domain that user owns is sharing the same worker budget, the same queue, and the same memory ceiling.

This post covers where DirectAdmin actually keeps the pool config, how to size pm.max_children from numbers your server gives you rather than from a blog post’s magic value, which per-site PHP limits are worth setting and which are theatre, why OPcache does not behave the way you expect on a multi-tenant box, and how to make all of it survive the next CustomBuild run.

The design fact that explains most of your 502s

DirectAdmin generates one FPM pool per user account, per PHP version. The pool is named after the Linux user. It listens on a Unix socket named after the user. It runs as that user. Apache or Nginx hands PHP requests to that socket for every domain and subdomain in the account.

So if a reseller client has twelve domains under one username, those twelve sites share a single value of pm.max_children. There is no per-domain pool. This is a long-standing feature request rather than an oversight, and it has a real consequence: the noisiest site in an account sets the availability of every other site in that account.

Once you have internalised that, the fix for a lot of “mystery 502” tickets stops being a config tweak and starts being an account layout decision. If a site matters commercially, give it its own DirectAdmin user. That is the cleanest isolation the panel offers without going off-piste, and it costs you nothing but a bit of admin tidiness.

The alternative, if you have User jails enabled, is DirectAdmin’s isolated FPM mode. That runs a separate php-fpm master process per jailed user instead of a shared master with many pools:

da config-set isolated_fpm 1
systemctl restart directadmin
da taskq --run 'action=rewrite&value=httpd'

It only applies to users who already have Jailed enabled. The trade-off is memory: one master process per user, plus a separate OPcache region for each, adds up quickly. DirectAdmin mitigates that by letting idle per-user FPM instances exit after a period of inactivity, but on a box with sixty accounts you will feel it. I would reach for this on a server hosting a handful of paying clients, not on a general shared box.

Where the pool config actually lives

This trips up almost everyone the first time, because there are two files with nearly the same name and only one of them matters for user sites.

• /usr/local/php83/etc/php-fpm.conf is the master config for that PHP version. Editing it by hand is how you learn that CustomBuild overwrites it.
• /usr/local/directadmin/data/users/USERNAME/php/php-fpm83.conf is the generated per-user pool. This is the file that governs a customer’s sites.
• /usr/local/directadmin/data/templates/php-fpm.conf is the template those per-user files are rendered from.

Substitute your PHP version for 83 throughout. To see what every account is currently running:

ls /usr/local/directadmin/data/users/*/php/php-fpm*.conf

grep -H 'pm.max_children' /usr/local/directadmin/data/users/*/php/php-fpm*.conf

The second command is the one I run first on any server I have just inherited. It gives you the entire worker budget of the box on one screen, and it is usually the moment you discover that forty accounts are all sitting on the stock default.

The DirectAdmin template ships with pm = ondemand and a low default child count, driven by a MAX_CHILDREN token. Ondemand means no workers exist until a request arrives, and idle workers are reaped after a timeout. On a shared box with many mostly-idle accounts, that is the right default and I would leave it alone. On a server dedicated to one busy WordPress site, the spawn latency on the first request after an idle period is real and switching to dynamic is defensible. Most people who switch to dynamic on a shared server are trading memory they do not have for a latency win they will not notice.

Sizing pm.max_children without guessing

Every tuning guide gives you a formula. The formula is fine. The input everyone gets wrong is worker memory, because they use a number from someone else’s server instead of measuring their own. A lean WordPress install and the same install with a page builder, a security plugin and WooCommerce are not remotely the same workload.

Measure it. This averages the resident memory of the workers currently running in one pool:

ps -eo rss,args | grep '[p]hp-fpm: pool wpuser' 
  | awk '{sum+=$1; n++} END {if (n) printf "%d workers, avg %.0f MBn", n, sum/n/1024}'

The bracket trick in the grep pattern stops grep matching its own process. rss is resident set size in kilobytes, which is why the awk divides twice. Run it during a busy period, not at three in the morning, and run it a few times.

Two honest caveats about RSS. It overstates real consumption, because workers forked from the same master share a lot of pages, including the OPcache region. And it understates your worst case, because a worker that has not yet hit a memory-hungry request looks cheap. Treat the average as a planning figure, not a guarantee, and leave headroom.

Then the arithmetic:

1. Take total RAM and subtract what MySQL or MariaDB, the web server, mail, and the panel itself need. On a WordPress box the database is usually the second-largest consumer and it is not optional.
2. Reserve a further slice for page cache and burst. I aim to leave a comfortable margin free rather than allocating to the last megabyte.
3. Divide what is left by your measured per-worker figure. That is your ceiling for all pools combined.
4. Split that ceiling across accounts by actual traffic, not evenly.

Step three is where people go wrong on cheap VPS plans. If you are running a dozen WordPress sites on one of the low-RAM tiers from a provider like Contabo or InterServer, the honest answer is often that you cannot give every account a generous pool and you need to either cut the site count or move up a tier. Setting pm.max_children to a number your RAM cannot back does not buy capacity. It buys the OOM killer, and the OOM killer usually takes the database with it, which turns a slow site into a broken one.

To raise the server-wide default:

da config-set php_fpm_max_children_default 30
systemctl restart directadmin
da build rewrite_confs
systemctl restart php-fpm83

For a single account, go to Admin Level → Custom HTTPD Configurations → domain.com and open the php-fpm entry for that PHP version. In the |CUSTOM1| textarea, set the token:

|?MAX_CHILDREN=40|

That syntax is a template token override, not a config line. It tells the template renderer to use 40 instead of the default when it writes pm.max_children for that user. Writing pm.max_children = 40 in that box instead is the single most common mistake here, and it does something worse than nothing: the template still emits its own pm.max_children, you now have the directive twice in one pool, and FPM refuses to start. On a server where one broken pool file stops the whole master, that takes down every site on the box.

Rewrite and restart after any change, then confirm the value actually landed in the generated file rather than trusting the panel.

Per-site PHP limits, and the difference that matters

The |CUSTOM2| textarea on the same page is where PHP settings go. The syntax is FPM pool syntax, not php.ini syntax:

php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 120
php_value[upload_max_filesize] = 64M
php_value[post_max_size] = 64M
php_value[max_input_vars] = 5000

The admin in php_admin_value is not decoration. Settings written with php_value can be raised at runtime by the application through ini_set(). Settings written with php_admin_value cannot. That distinction is the whole game on a multi-tenant server.

WordPress and a good number of plugins will happily try to raise memory_limit at runtime, and some optimisation plugins push it to values that would let one bad request consume a large slice of the machine. If you want a genuine ceiling, use php_admin_value. If you want a sensible starting point that a developer can raise for a legitimate import job, use php_value. I use admin for memory and execution time, plain for upload sizes, because upload sizes are a support-ticket generator and not a stability risk.

max_input_vars deserves its own note. It is the one that silently truncates a large WooCommerce product save or a menu with hundreds of items, with no error anywhere. The user reports “my changes did not save” and every log is clean. If you support content-heavy sites, raise it before someone asks.

Letting site owners set their own

Under FPM there is no .htaccess route for PHP settings, because FPM is a separate process and never sees the file. DirectAdmin enables the per-directory alternative by default: a .user.ini file in public_html, controlled by the user_ini.filename setting. It handles the PHP_INI_PERDIR and PHP_INI_USER class of settings only, so it will never override anything you set with php_admin_value. That is the point of it.

The WP-CLI gap

None of this applies to WP-CLI. Cron jobs and shell commands run through the CLI SAPI and read the CLI php.ini, not your pool. So a plugin update that works fine in the browser can die on memory in a cron-driven wp cron event run, and you will hunt through the pool config finding nothing wrong. Check the CLI limits separately when a scheduled task fails but the same action succeeds in wp-admin.

OPcache is shared, and that is the invisible one

OPcache allocates its shared memory region when the FPM master starts, before any pool exists. Every pool under that master inherits the same region. You cannot meaningfully give one account its own OPcache budget through a pool directive, because by the time the pool is read the memory has already been carved out.

Two consequences, and the second is the one nobody plans for.

First, capacity. The default OPcache size is comfortable for one application and thin for thirty WordPress installs, each with its own core, theme and plugin tree. When it fills, OPcache starts evicting and eventually restarts, and every site on the version gets slower at once with nothing in any error log to explain it. Watch the wasted-memory and restart counters rather than guessing.

Second, the sizing you actually need scales with the total number of PHP files across all accounts on that PHP version, not the biggest site. Consolidating everyone onto one PHP version looks tidy and quietly makes this worse. Spreading accounts across two or three PHP versions gives each master its own region, which is an underrated side effect of not forcing everyone to upgrade on the same day.

OPcache is configured through CustomBuild rather than the pool. Edit the customised copy under CustomBuild’s custom directory so your changes survive updates, then rebuild and restart the FPM master.

Making changes survive the next rebuild

Anything you type directly into a generated file is temporary. The next rewrite_confs, PHP update or panel update will flatten it, usually weeks later, and the regression will look like it came from nowhere.

There are three durable places to put changes, in increasing order of blast radius:

• Per user, all PHP versions. /usr/local/directadmin/data/users/USERNAME/php/php-fpm.conf.custom1 and .custom2. These feed the same CUSTOM tokens as the panel textareas, so the settings follow the account when the user switches PHP version in Domain Setup. This is the one I reach for first.
• Server-wide, all users, all versions. /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom1 and .custom2. If either exists, its contents are injected into every pool file DirectAdmin writes. Good for a baseline you want everywhere.
• A full custom template. Copy /usr/local/directadmin/data/templates/php-fpm.conf to the custom subdirectory and edit it. This is the only route for pool directives that have no token, but you now own that file forever and stop receiving upstream template improvements. Use it when nothing else works, and leave a comment at the top saying why.

Global first, then per-user on top. Both land in the same token, so a per-user value does not replace a global one, it appends. For a directive that can only appear once in a pool, that is a duplicate and a failed restart.

Troubleshooting

“server reached max_children setting”

The pool name in that warning tells you which account, not which site. Find the log first rather than guessing at a path:

grep -i 'error_log' /usr/local/php83/etc/php-fpm.conf

Before raising the limit, check whether the requests are legitimate. Cross-reference the timestamps against each domain’s access log in that account. Nine times out of ten it is one of three things: an uncached admin-ajax.php loop from a plugin, a bot crawling faceted search or filtered archive URLs that bypass page cache, or wp-cron.php firing on every request on a site with a heavy scheduled task. Raising pm.max_children to absorb bot traffic is paying for garbage with RAM.

502 or 504 with no PHP error

The request is dying at the FPM boundary rather than inside PHP. Usual causes are a worker killed by request_terminate_timeout, a full listen queue, or the master failing to start after a config change. Check the FPM service status before you check anything in WordPress. If FPM did not start at all, the panel will still show your settings saved and every site on that PHP version will be down.

Changes in the panel that do nothing

Read the generated per-user file after every change. If the value is not in there, the rewrite did not run or the token was wrong. If it is in there and PHP still reports something else, the master was not restarted, or something later in the pool is overriding it. A temporary phpinfo() file served by the site in question settles the argument in seconds. Delete it immediately afterwards.

Session or temp files that are not where you left them

If PHP writes to /tmp and you cannot see the files over SSH, that is systemd’s PrivateTmp giving the FPM service its own private namespace. Nothing is broken. The files exist, in a mount only that process can see.

disable_functions that will not budge

disable_functions is special. From a pool you can add to the list but not remove from it, because the php.ini value has already been applied. To allow a function for one account you have to stop setting it in php.ini at all and drive the whole thing from templates instead. DirectAdmin documents that pattern, and it is worth reading before you start rather than after you have half-done it, because the intermediate state removes protection server-wide.

Common mistakes

• Editing /usr/local/phpXX/etc/php-fpm.conf directly and being surprised when it reverts.
• Writing pm.max_children = 40 into a CUSTOM box instead of the |?MAX_CHILDREN=40| token, producing a duplicate directive and a dead master.
• Sizing workers from a memory figure found online rather than measured on the box.
• Using php_value for memory_limit on shared hosting, then wondering how a plugin raised it to 2G.
• Assuming pool settings apply to WP-CLI and cron.
• Raising limits to absorb bot traffic instead of blocking or caching it upstream.
• Putting a client’s revenue site in the same account as their abandoned projects.

Best practices for tuning DirectAdmin PHP-FPM pools

• One DirectAdmin user per site that matters. Isolation you get for free beats isolation you have to engineer.
• Keep ondemand on shared servers. Only move to dynamic when a single busy site owns the box.
• Set a global baseline in the custom template, then override per user. Do not hand-tune forty files.
• Use php_admin_value for anything that protects the server and php_value for anything that is only a convenience.
• Cut PHP requests before you add workers. Full-page caching, a CDN in front, and Cloudflare or similar handling bots removes far more load than any pool setting.
• Disable WordPress’s request-triggered cron and drive it from a real system cron, so scheduled work stops competing with visitors for workers.
• Alert on saturation, not just uptime. Worker utilisation per pool and PHP-FPM error log entries are the signals worth having in Netdata, Prometheus, or whatever you already run. A site that is queueing looks perfectly healthy to an HTTP check.
• Re-measure after major plugin changes. A page builder or a new security plugin moves per-worker memory enough to invalidate your arithmetic.

Frequently asked questions

Can I create a separate PHP-FPM pool for each domain in DirectAdmin?

Not through the panel. Pools are generated per user, per PHP version, and every domain in the account shares one. The supported ways to get separation are to move the domain to its own DirectAdmin user, or to enable isolated FPM mode for jailed users, which gives each user their own master process. Anything else means custom systemd units you maintain yourself, outside the panel’s knowledge.

What is a good pm.max_children value for WordPress?

There is no portable number, because the input is your measured per-worker memory and your available RAM after the database. Measure the average resident size of your workers under real traffic, subtract everything else the server needs from total RAM, and divide. A lean brochure site and a WooCommerce store with thirty plugins can differ by a factor of three or more.

Where does DirectAdmin store PHP-FPM pool configuration?

Generated per-user pools live at /usr/local/directadmin/data/users/USERNAME/php/php-fpmXX.conf, rendered from the template at /usr/local/directadmin/data/templates/php-fpm.conf. Do not edit either directly. Put durable changes in the custom files under the user’s php directory or in the templates/custom directory.

Why do my PHP settings disappear after a CustomBuild update?

Because they were written into a generated file. CustomBuild and DirectAdmin regenerate those files on update and on any config rewrite. Only the custom template files and the CUSTOM token areas persist.

Does .htaccess work for PHP settings under PHP-FPM?

No. FPM is a separate process from the web server and never reads .htaccess. Use a .user.ini file in the web root for the settings PHP allows at that level, or set the rest in the pool.

Should I switch from ondemand to dynamic or static?

On a shared server, no. Ondemand exists precisely so that dozens of idle pools cost you nothing. On a server dedicated to one high-traffic site, dynamic removes cold-start latency and static gives the most predictable memory profile. The question to ask is whether your idle pools outnumber your busy ones.

Can I give one WordPress site its own OPcache?

Not from the pool config. OPcache’s shared memory is allocated by the FPM master at startup and shared by every pool under it. The practical routes are isolated FPM mode, which gives jailed users their own master, or moving the site to a different PHP version so it sits under a different master.

The one thing to take away

DirectAdmin PHP-FPM pools are a per-user boundary, not a per-site one. Every tuning decision that follows, how many workers to allow, whether a memory limit should be a suggestion or a wall, whether a client’s twelve domains belong in one account, comes out of that single fact.

Measure your workers before you size them, use the CUSTOM token files so your work survives the next rebuild, and watch pool saturation rather than waiting for the 502 ticket. The site that goes down is rarely the site that caused it.

Need a hand with a DirectAdmin server?

Most of the work I do on DirectAdmin boxes is this kind of thing: sites that are fine in isolation and fall over together. If that sounds familiar, I can help with:

• Auditing every pool on a server and producing a worker budget that matches the RAM you actually have
• Tracking down which domain in a shared account is saturating the pool, and why
• Building a global custom template so per-user tuning stops being forty hand-edited files
• Splitting a multi-site DirectAdmin account into isolated users without breaking mail, DNS or SSL
• OPcache and per-version sizing on servers hosting many WordPress installs
• Wiring up pool-level monitoring and alerts so saturation shows up before the ticket does

Send me a pool file, the output of that RSS command, or the last hour of your PHP-FPM error log, and I will tell you what I see.

The post DirectAdmin PHP-FPM Pools: Why One WordPress Site Takes Down the Others appeared first on John Nessime.

So you close the ticket. Then it happens again next week, to a different customer, on a different mailbox provider.

This is the shape of almost every WordPress email deliverability problem I’ve had to unpick. The site is not broken and the mail is genuinely leaving. It is being evaluated somewhere downstream and quietly filed into spam by a receiver that has decided it cannot prove who sent it. Nothing in WordPress will ever tell you this happened.

This post covers the four places that failure actually lives: how the message leaves your server, whether SPF survives evaluation, whether DKIM signs and aligns, and what DMARC does with the result. It is organised by failure family rather than by protocol tour, because the protocols are individually well documented and the failures are not.

The failure mode that costs you money: silent success

Start with the thing that makes this hard to debug. wp_mail() returns a boolean. That boolean tells you whether PHPMailer handed the message off without throwing. It tells you nothing about whether the message was delivered, and nothing at all about whether it reached an inbox rather than a spam folder.

So “WordPress says it sent” and “the customer got it” are separated by four or five systems you have no visibility into. That gap is where the money leaks: WooCommerce order confirmations, membership welcome mails, password resets, form notifications. All of them fail the same silent way.

So stop guessing about the boolean. WordPress fires an action when the handoff itself fails, and almost nobody hooks it:

// Log the real reason PHPMailer refused, instead of a bare false.
add_action( 'wp_mail_failed', function ( $error ) {
    error_log( 'wp_mail failed: ' . $error->get_error_message() );
} );

Then force a send from the command line so you are testing the mail path and not a contact form plugin:

wp eval 'var_dump( wp_mail( "you@example.com", "deliverability test", "body" ) );'

If that prints bool(true) and the mail still never arrives, you have ruled out WordPress entirely. Everything from here is transport and DNS.

Failure family one: how the message leaves the box

By default wp_mail() falls through to PHP’s mail(), which shells out to the local mail transfer agent. On a shared host or a default VPS build, that means your marketing site is now an email server with none of the reputation, warm-up, or bounce handling that implies.

Receivers are not being unreasonable about this. A message arriving from a web server IP, with no authentication, from a domain the IP has no relationship with, looks exactly like a compromised WordPress install pumping out spam. Because most of the time, it is.

The three transport options, honestly

Local mail(). Genuine case for it: zero dependencies, no credentials to leak, and it works fine when the box already runs a properly configured MTA with correct reverse DNS and a warmed IP. Where it fails: almost everywhere else. Most hosts either block outbound port 25 or run an MTA nobody has configured for authentication. Skip it unless you own the mail infrastructure and know its reputation.

Authenticated SMTP submission. WordPress connects to a real mail provider over port 587 with STARTTLS, or 465 with implicit TLS, and authenticates. This is the portable option, it works with any provider, and it is what I reach for first on a site I did not build. The cost is that SMTP is a chatty, connection-oriented protocol running inside a page request, so a slow or throttled provider makes checkout feel slow.

Provider HTTP API. The plugin posts the message to an API endpoint over 443 instead of speaking SMTP. Faster, immune to hosts that block SMTP ports outbound, and usually gives you richer delivery events back. The cost is real lock-in: your sending config is now provider-specific and moving means reconfiguring, not just changing a hostname.

On the plugin side, WP Mail SMTP and Post SMTP both cover the common providers and both have usable free tiers. For providers, transactional-focused services like Postmark, Amazon SES, Mailgun, Brevo and SendGrid all do this job well; the differences that matter are bounce webhook quality, log retention, and how quickly a human answers when your account gets throttled. If your host bundles a transactional relay, check whether it authenticates as your domain or the host’s shared domain before you rely on it. Providers like InterServer, Cloudways and Kinsta differ meaningfully here.

Prove the transport before you touch DNS

Before blaming records, confirm the server can actually reach the relay. This opens a TLS session against the submission port and shows you the SMTP banner and advertised capabilities:

openssl s_client -starttls smtp -crlf -connect smtp.example.net:587

-starttls smtp issues the STARTTLS upgrade for you, and -crlf sends proper line endings so the session does not hang. If this times out, your host is filtering outbound SMTP and you want the HTTP API transport instead of a longer argument with support.

To send a full test message end to end, swaks is the tool worth having on every box:

swaks --to you@example.com --from wp@example.com 
      --server smtp.example.net:587 --auth --tls

It prints the entire conversation, so an authentication failure or a policy rejection shows up as an actual SMTP response code rather than a shrug from a plugin.

Failure family two: SPF passes until it silently doesn’t

SPF is a DNS TXT record listing who may send using your domain in the envelope sender. It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Two things about that record cause more WordPress email deliverability incidents than anything else in SPF.

The ten lookup budget

RFC 7208 caps SPF evaluation at ten mechanisms that require DNS lookups. include, a, mx, ptr, exists and redirect all count, and crucially so does everything nested inside someone else’s include. ip4 and ip6 cost nothing.

Cross the limit and the receiver returns permerror. That is not a soft fail. The receiver could not evaluate your record at all, treats SPF as failed, and every message from the domain is affected at once.

Here is why it bites so hard on WordPress sites specifically. Nobody adds ten includes in one sitting. Someone adds Google Workspace. Six months later the marketing team adds a newsletter platform. Then a CRM. Then a help desk. Then you add a transactional provider for the WooCommerce mail, and the record tips over. Nothing in DNS warns you, no plugin surfaces it, and the only visible signal is in DMARC aggregate reports you probably aren’t reading yet.

Check the record and count what it actually resolves to:

dig +short TXT example.com

Counting nested includes by hand is tedious and error-prone, so use a checker that expands them. When you are over budget, the durable fixes are removing senders you no longer use and moving distinct sending systems onto their own subdomains, each with their own SPF record. Flattening includes into raw IPs works, but you have just taken ownership of someone else’s IP ranges and they will change without telling you.

One record, and mind the envelope

Publish exactly one SPF record per domain. Two records is not additive, it is invalid, and receivers may fail the check outright.

Also remember SPF checks the envelope sender, not the address your visitor sees. On WordPress those can easily differ, especially when a plugin sets a friendly From address while the MTA uses the system user as the envelope. If you need to control it explicitly:

add_action( 'phpmailer_init', function ( $phpmailer ) {
    $phpmailer->Sender = 'bounces@example.com';
} );

Setting Sender sets the envelope from, which is what SPF evaluates and where bounces are returned. It is not the same field as From, and conflating the two is a classic source of “but SPF passes when I test it” confusion.

Failure family three: DKIM signs, but alignment is what counts

This is the invisible one, and if you take one thing from this post, take this.

DKIM adds a cryptographic signature to the message. The receiver fetches your public key from DNS at the selector your provider gave you and verifies the signature held. Check yours like this:

dig +short TXT selector1._domainkey.example.com

Straightforward enough. Here is the part that catches people: SPF and DKIM can both pass and DMARC can still fail.

DMARC does not care that a domain authenticated. It cares that the domain the recipient sees in the From header matches the domain that authenticated. That match is called alignment, and it is the whole point of DMARC. SPF aligns when the envelope sender domain matches the From domain. DKIM aligns when the signing domain in the d= tag matches the From domain. You need at least one of them aligned. Not both, but at least one.

Now picture the default setup on a WordPress site with a transactional provider. The From header says orders@example.com. The envelope sender is a bounce address on the provider’s own domain, so SPF authenticates the provider and does not align with you. And if you skipped the DNS records the provider asked you to add, the message is signed with the provider’s shared key, so d= is the provider’s domain and DKIM does not align either.

Both checks pass. Alignment fails. DMARC fails. Every deliverability tester you paste the record into says your DNS is fine.

The fix is nearly always the same: complete your provider’s domain authentication step so mail is signed as your own domain rather than their shared one. That usually means publishing a CNAME or TXT record at a selector under _domainkey, and often a CNAME for a custom return path so SPF aligns too.

Read the headers, don’t trust the dashboard

Send yourself a real message from the site and open the raw source. The Authentication-Results header the receiver added is the ground truth. You are looking for the SPF result, the DKIM result, the d= domain on the DKIM signature, and the DMARC verdict. If d= is not your domain and the SPF domain is not your domain, you have found your problem regardless of what any dashboard claims.

One practical note on the key itself: a 2048-bit DKIM public key does not fit in a single 255 character DNS string and has to be published as multiple concatenated strings. Most DNS providers handle this transparently. Some do not, and the symptom is a key that looks present but fails verification.

Failure family four: DMARC policy, and what just changed

DMARC ties the previous two together. It tells receivers what to do when neither SPF nor DKIM aligns, and it asks them to send you reports about it.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Start at p=none. It changes nothing about how mail is handled and turns on the aggregate reports, which are the only view you will ever get of who is sending as your domain. Read them for a few weeks, find the legitimate senders you forgot about, fix their alignment, then move to p=quarantine and eventually p=reject.

Do not skip straight to p=reject on a domain you have not observed. You will reject your own invoicing system.

The specification itself was updated. RFC 7489, the original DMARC document from 2015, has been obsoleted by RFC 9989 together with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting, and DMARC has moved onto the IETF standards track. Records still begin with v=DMARC1 and nothing you have published stops working, so this is not an emergency. Two changes are worth knowing:

• The pct tag is gone, along with rf and ri. Percentage-based staged rollout was implemented inconsistently by receivers and has been replaced by a simple t testing flag. If your record still carries a partial pct value from a rollout that never finished, that is worth cleaning up.
• Organisational domain discovery no longer depends on the Public Suffix List; receivers now walk the DNS tree. Single-domain owners will not notice. If you run a lot of subdomains, publishing explicit records rather than relying on inheritance removes the ambiguity.

There are also new optional tags. The one worth considering is np, which sets a policy for non-existent subdomains so attackers cannot spoof from a subdomain you never created, without changing your main policy.

Aggregate reports arrive as compressed XML and are unpleasant to read by hand. Feeding them to a processor is worth it; dmarcian, Postmark’s free DMARC digest and MXToolbox all do this, and Cloudflare can host the DNS side.

Are the bulk sender rules your problem?

Probably not, and it is worth saying so plainly because a lot of writing on this topic implies otherwise. Google’s stricter bulk sender requirements apply to domains sending roughly 5,000 or more messages a day to personal Gmail accounts. A typical WordPress business site sends a few dozen.

What changed for everyone is the direction of travel. Authentication that used to be a nice-to-have is now the baseline for being evaluated on your merits rather than treated as suspicious by default. If you do cross into bulk territory, the additional obligations are one-click unsubscribe on marketing mail via the List-Unsubscribe and List-Unsubscribe-Post headers, and keeping spam complaints low. Google’s published guidance is to stay under 0.1% and never reach 0.3%.

Domain strategy: keep resets away from newsletters

One structural decision saves more grief than any single record. Separate your transactional mail from your marketing mail at the domain level.

Send password resets and order confirmations from something like mail.example.com, and send campaigns from news.example.com. Each subdomain gets its own SPF record, which keeps you comfortably inside the lookup budget. More importantly, reputation is largely tracked per sending domain. When a campaign goes badly and complaints spike, the damage stays contained. Your password resets keep landing.

The trade-off is real: more DNS records to maintain, more DMARC reports to read, and a From address that is slightly less clean. On a site where a lost order confirmation costs actual revenue, that is a trade worth making.

Troubleshooting: a working order

1. Does the message leave? Hook wp_mail_failed and send via WP-CLI. A logged error here means credentials, ports or a plugin, not DNS.
2. Can the box reach the relay? openssl s_client -starttls smtp against the submission port. A timeout means outbound filtering.
3. What does the receiver say? Send to a mailbox you control, open the raw source, read Authentication-Results. This single header settles most arguments.
4. Is the DKIM d= your domain? If not, you have not completed provider domain authentication. Fix that before anything else.
5. Does SPF actually evaluate? Expand nested includes and count. A permerror looks like a pass in most naive testers.
6. What do the aggregate reports show? If mail is failing for a subset of recipients only, the reports will name the sending source you forgot about.

If Gmail is deferring rather than rejecting, the enhanced status code in the bounce tells you which check failed. Codes in the 4.7.x range point at authentication or alignment specifically rather than content, which narrows the search considerably.

Common mistakes

• Publishing two SPF records and assuming they merge. They do not.
• Treating a green tick from an online record checker as proof of delivery. Those tools validate syntax, not alignment on your actual mail.
• Jumping to p=reject before reading a single aggregate report.
• Setting a From address on a domain you do not control, such as a customer’s own address on a contact form. Use your domain in From and put theirs in Reply-To.
• Adding a new SaaS include without re-counting the lookup budget.
• Leaving a stale include for a service you stopped using two years ago, which is both a wasted lookup and a live authorisation.
• Configuring an SMTP plugin and never testing what happens when the provider is down. Mail queued nowhere is mail lost.

Best practices

• Route WordPress mail through a real provider, and prefer the HTTP API transport when the host filters SMTP ports.
• Complete provider domain authentication properly so DKIM signs as your domain. This is the single highest-value action on the list.
• Publish DMARC at p=none with rua on day one, even before you intend to enforce. The reports are the visibility you are missing.
• Keep SPF under the ten lookup budget with headroom for the next service someone adds.
• Split transactional and marketing sending onto separate subdomains.
• Enable email logging in your SMTP plugin so you have a record of what was attempted and when.
• Monitor DKIM key expiry and provider selector changes the same way you monitor TLS certificates. Both fail silently and both fail completely.

Frequently asked questions

Do I need an SMTP plugin if my host already sends mail?

Check what the host’s relay authenticates as. If it signs with the host’s shared domain rather than yours, DKIM will not align with your From address and DMARC will fail even though mail is technically going out. If it authenticates as your domain, you are fine without a plugin.

Is SPF enough on its own?

No. SPF breaks on forwarding, because the forwarding server is not in your record, and it authenticates the envelope sender rather than the visible From address. DKIM survives forwarding and gives you a second, independent path to alignment. Publish both.

Why do my emails reach Gmail but not Outlook, or the reverse?

Receivers weight signals differently and each maintains its own reputation view of your sending IP and domain. Divergent behaviour usually means your authentication is borderline rather than solid, so one receiver’s threshold catches it and another’s does not. Fix alignment rather than chasing individual receivers.

How long until DNS changes take effect?

As long as the TTL on the record, plus whatever the resolver in front of you decides to cache. Lower the TTL before you plan changes, not after. Verify with dig against an authoritative nameserver rather than trusting a browser-based checker.

Does DMARC stop people spoofing my domain?

At p=reject it stops exact-domain spoofing at receivers that honour the policy, which is most large ones. It does nothing about lookalike domains, display-name spoofing, or a compromised mailbox sending genuinely authenticated mail. It is one control, not a complete answer to phishing.

Should I update my DMARC record for the new RFCs?

Nothing breaks if you do not. At your next DNS edit, remove pct, rf and ri if present, and consider adding np if you want to close the non-existent subdomain gap. Leave the new tags unset otherwise, because the defaults are sensible.

Why did deliverability get worse after I moved hosts?

Usually because the old host had a relay configured that the new one does not, so PHP mail() is now sending direct from an unwarmed IP with no authentication. It is also common for a migration to move the site but not the DNS records the old provider had added. Re-verify SPF, DKIM selectors and the return path after any move.

Wrapping up

If you remember one thing about WordPress email deliverability, remember that authentication and alignment are different questions. SPF passing and DKIM verifying does not mean DMARC passes. The receiver is asking whether the domain your recipient can see is the domain that proved itself, and on a default WordPress plus transactional provider setup, the honest answer is often no.

Get the transport off PHP mail(), complete your provider’s domain authentication so d= is your own domain, keep SPF inside its lookup budget, and publish DMARC at p=none so you can finally see what is happening. Then read the reports for a month before you enforce anything.

The alternative is closing the same ticket every week and never learning why.

Need someone to fix this properly?

Mail problems are unusually well suited to outside help, because the failure is almost always in a place the site owner cannot see. This is work I take on regularly:

• Auditing an existing setup end to end and telling you exactly which of the four failure families you are in
• Rebuilding SPF records that have drifted past the ten lookup limit, without breaking a live sender
• Completing DKIM and return-path domain authentication with your provider so alignment actually holds
• Taking a domain from p=none to enforcement safely, using the aggregate reports rather than guesswork
• Splitting transactional and marketing sending onto separate subdomains with their own records and reputation
• Migrating WordPress mail off PHP mail() onto a provider, with logging and failure alerting wired up

If you want a second opinion, send me a raw message source with the full headers, or your current SPF and DMARC records, and I will tell you what I see.

The post Why Your WordPress Emails Vanish: SMTP, SPF, DKIM and DMARC appeared first on John Nessime.

The host had removed it. It was on their disallowed list, a routine scan found it, and the platform did exactly what its documentation said it would do. Everyone had agreed to that when they signed up. Nobody had read it.

That incident is the whole managed WordPress hosting vs VPS argument in miniature, and it has almost nothing to do with page speed. Both models can serve a fast WordPress site. They differ on which failures land on you, which land on someone else, and which ones stay invisible until the worst possible moment.

This post compares the two the way I’d compare them for a client: an honest profile of each, the costs that never appear on the invoice, a procedure for modelling the real number, and the decision rules I actually use. No benchmark charts, because your theme and your plugin count will dominate anything the host does.

The real question: who owns the failure at 2am

Most comparisons frame this as control versus convenience. True, but useless, because it doesn’t tell you what to buy. The framing that predicts regret is: when something breaks, whose problem is it, and how fast can they fix it?

Split the failure surface into layers and the answer gets concrete:

• Hardware and hypervisor. Theirs in both models. Your recovery time is still yours.
• OS, web server, PHP, database. Theirs on managed hosting, yours on an unmanaged VPS. This is the big split.
• Backups and restores. Theirs on managed, and tested, because their business depends on it. Yours on a VPS, and almost nobody tests them.
• Core, themes, plugins. Mostly yours either way. Some hosts auto-update, but the compatibility fallout is still yours.
• Your code and your content. Always yours. No host takes this on.

The bottom two rows never move. A managed platform will not make your bloated page builder fast, and it will not stop a vulnerable plugin from being exploited. It moves the middle three rows off your plate and charges you in money and in flexibility.

Managed WordPress hosting, assessed honestly

Where it genuinely wins

The strongest argument isn’t performance. It’s that the boring, high-consequence work gets done by people whose job it is, on a schedule, whether or not you remember.

• Restores that work. One-click recovery from a backup the platform verifies. That’s the difference between a bad hour and a bad week.
• Server-level page caching, already tuned. WP Engine, Kinsta, Pressable and Flywheel run full-page caching in front of PHP. It’s why they ban plugins that try to do the same thing badly.
• Staging that isn’t a science project. Clone, test, push back. On a VPS that’s yours to build, and a half-built staging setup is worse than none.
• Support that knows WordPress. A generic VPS provider’s ticket ends at “the server is up”. A WordPress host will look at your slow query log.
• Edge protection before PHP loads. WAF and bot filtering at the infrastructure layer, the only layer where they meaningfully help. A plugin firewall runs after the request has already cost you a PHP worker.

If nobody on your team wants to own a Linux box, that list is decisive. The rest of this section is about what you’re trading away.

Visit metering is a billing model, not a traffic report

This is the cost that bites hardest, because it doesn’t look like a technical constraint until the invoice arrives.

Most managed plans meter “visits” rather than bandwidth or CPU, and the definition is narrower than it sounds. WP Engine defines a billable visit as one unique IP address logged per day, with static assets like images, CSS and JavaScript excluded, and known and suspected bot user agents filtered out. Kinsta counts the sum of unique IPs seen within each 24-hour period across the plan, and also sells bandwidth-metered plans as an alternative. Flywheel filters IPs belonging to known bots, spammers and attackers before counting.

Three consequences follow, and they’re the ones people miss:

• Your host’s number will not match Google Analytics. Analytics counts sessions from browsers that ran its JavaScript. Your host counts IPs that hit the server. Arguing about the gap is wasted effort.
• Bot filtering is best-effort. Hosts filter what they can identify. A scraper with a browser-shaped user agent and rotating IPs looks, to the meter, like a crowd of new visitors.
• Overages are charged per block of excess visits. Rates change, so check the current figure rather than trusting any article, including this one. What matters is the shape: a viral post or a bad crawl month produces a bill you didn’t budget for.

A VPS has the opposite failure mode. Bad traffic costs you CPU and RAM, not money, right up until it exhausts them and the site falls over. One model converts load into a bill, the other converts it into an outage. Pick the one you’d rather explain to whoever owns the site.

The plugin policy is a real constraint

Managed hosts publish disallowed plugin lists and they enforce them. WP Engine documents that disallowed plugins are found by periodic scans of the site’s filesystem, the owner is notified, and the plugin is removed. That’s not a threat, it’s the operating model, and it’s why the incident I opened with was nobody’s fault.

The banned categories are consistent across vendors, and the reasoning holds up in each case:

• Caching plugins. They fight the platform’s own page cache and produce stale output that support then has to debug.
• Backup plugins. They write large archives onto the same disk the site runs on, which is a useless backup if the disk is what fails.
• Database optimisation plugins. Long-running write-heavy queries on shared infrastructure affect neighbours.
• Some security plugins, or specific features within them. Filesystem-based rule storage and high-volume traffic logging are the usual triggers. Policies vary a lot here.
• Plugins that send mail directly. Platforms push you to a transactional provider instead, for deliverability reasons that are genuinely in your interest.

None of that is unreasonable. The problem is when a plugin your business depends on lands in one of those buckets, or when a host adds something to the list later. Before migrating, read the current disallowed list for that specific host and diff it against your live active plugins. Ten minutes, and it’s the highest-value thing you can do in a hosting evaluation.

You get one shape of application

A managed WordPress platform runs WordPress. If your project also needs a Node service, a Python worker, a queue, or a self-hosted analytics instance, that’s a second bill somewhere else. On a VPS those things are free in cash terms because you already own the machine. They cost you memory and attention instead. Whether that’s a good trade depends on whether you were going to need them anyway.

Running WordPress on your own VPS, assessed honestly

Where it genuinely wins

• Resources per unit of money. Hetzner, InterServer, DigitalOcean and Vultr will sell you more CPU and RAM than an entry managed plan. Whether you can use it is a separate question.
• Many sites, one bill. This is where the economics genuinely flip. Ten small sites on one adequate VPS is one server to patch. Ten managed plans is ten invoices.
• No metering surprises. Traffic spikes hit your load average, not your credit card.
• You choose the stack. Nginx or Apache, PHP-FPM pool sizing, Redis for the object cache, your own MariaDB tuning and firewall rules. If the platform’s opinions were what limited you, this is the fix.
• No lock-in. A tarball and a database dump move anywhere. Platform-specific caching behaviour, redirect rules and deployment workflows do not.

The failure that stays invisible: the backup you never restored

Here’s the one that actually ends projects. Backups on a self-managed VPS fail silently. The cron entry runs, the exit code goes nowhere, the destination bucket quietly rejects writes after a credential rotation, and nothing tells you. You find out the day you need it, which is also the day you have no other option.

The fix isn’t a better tool. Restic and BorgBackup are both excellent and neither will save you. The fix is a restore drill on a schedule, into a scratch directory, where you verify the data is actually there.

# Restore the newest snapshot into a scratch path, never over the live site
restic -r /srv/backups/wp restore latest --target /tmp/restore-drill

# Confirm the dump is real and not a zero-byte file or a truncated
# write from a run that died halfway through
ls -lh /tmp/restore-drill/db/
head -n 20 /tmp/restore-drill/db/site.sql

# Load into a throwaway database and count what came back.
# If wp_posts is empty, your backups have been failing for weeks.
mysql -u drill -p drill_db < /tmp/restore-drill/db/site.sql
mysql -u drill -p -e "SELECT COUNT(*) FROM drill_db.wp_posts;"

Adjust the repository path and database names to your own. The shape is the point: restore somewhere harmless, then check a row count that would be non-zero on a healthy site. A backup you haven’t restored is a hypothesis, not a backup. Uptime checks from something like UptimeRobot tell you the site is down; they tell you nothing about whether you can get it back.

Patching debt compounds quietly

The second invisible cost is the gap between “updates are available” and “updates are applied and the affected services have actually restarted”. Upgrading a package without restarting the process leaves the old, vulnerable code resident in memory. That’s why security scanners and package managers disagree so often.

# RHEL family (AlmaLinux, Rocky, CentOS Stream)
# What security updates are outstanding?
sudo dnf updateinfo list security

# After applying them: does anything still need a restart?
# Exit 0 means no reboot required, exit 1 means reboot required.
sudo dnf needs-restarting -r

# Debian and Ubuntu: what would unattended-upgrades actually do?
sudo unattended-upgrade --dry-run --debug

Run those on any VPS you inherited from someone else. The output is usually educational. Then there’s the WordPress layer, which stays yours regardless of hosting model:

# Do the core files match the official checksums for this version?
# A mismatch means a modified core file or an active compromise.
wp core verify-checksums

# How many plugins are behind?
wp plugin list --update=available --format=count

# Which tables are eating the disk? Usually wp_options, wp_postmeta,
# or a logging plugin nobody remembers installing.
wp db size --tables --format=table

Model the cost before you argue about it

Sticker price comparisons are how people talk themselves into the wrong answer in both directions. This procedure produces a number you can defend.

1. Count your sites. One tilts toward managed. Five or more tilts toward a VPS, because admin time is close to fixed and plan fees are per-site.
2. Estimate your metered visit count from your own logs. If you’re already on a server you control, you can approximate what a metered host would bill you before signing anything.
3. Price the VPS honestly. Instance plus block storage plus offsite backup destination plus any control panel licence. The advertised instance price is rarely the whole line.
4. Put a rate on your own hours. Whatever you’d bill a client, or pay someone else. Zero is not an honest number.
5. Add the one-off build. Standing up a hardened WordPress VPS with TLS, firewall, object cache, tested backups and log rotation is a solid chunk of focused work the first time. Amortise it over twelve months.
6. Add your recovery cost. Hours to rebuild from scratch, times your rate, times how often you honestly think it’ll happen. This term is what makes managed hosting look cheap for a single revenue-generating site.

Step two is worth doing properly, because it’s the number nobody has. On Nginx with the standard combined log format, this gets you close:

# Unique client IPs in the log. A rough upper bound on metered "visits".
awk '{print $1}' /var/log/nginx/access.log | sort -u | wc -l

# Closer to how hosts count: ignore static assets, since most platforms
# exclude images, CSS and JS from billable visits.
awk '$7 !~ /.(css|js|png|jpg|jpeg|gif|svg|webp|woff2?|ico)$/ {print $1}' 
  /var/log/nginx/access.log | sort -u | wc -l

# What is actually hitting you? User agents by request count.
# If the top entries are crawlers, that is your overage risk.
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Field positions assume the combined log format; adjust the column numbers if you’ve customised log_format. The third command is the interesting one. If crawlers dominate your traffic, visit-metered hosting will charge you for whatever the host’s filtering misses, and that’s a risk you can quantify before signing up rather than after.

The middle ground worth looking at first

This gets presented as two options. There are four, and the middle two get skipped far too often.

• Managed VPS. InterServer, Liquid Web and others sell VPS plans where the provider handles OS patching, firewall and backups while you keep root. Read the scope: “managed” often stops at the operating system and leaves the WordPress stack to you.
• Control panel on your own VPS. DirectAdmin, cPanel or CyberPanel gives you WordPress-aware tooling, staging and one-click TLS on infrastructure you still own. You pay a licence and give up some configuration purity.
• Server management platforms. Cloudways, RunCloud, GridPane and SpinupWP provision and manage a stack on a VPS you rent from a provider of your choice. Managed-style workflows without the per-visit meter.
• A CDN in front of anything. Putting Cloudflare or a similar edge ahead of a modest VPS absorbs a large share of the traffic that would otherwise push you onto a bigger plan. Cheapest performance win available to either model, and frequently the actual answer to “we need better hosting”.

If you’re leaning toward a VPS mainly because managed pricing looks steep, look at options two and three before committing to a bare Linux box.

How I’d decide between managed WordPress hosting vs VPS

These are the rules I apply, in order. The first match usually settles it.

• Nobody on the team can or wants to run Linux. Managed, and it isn’t close. An unpatched VPS is worse than the most restrictive managed plan.
• One site, and it generates revenue. Managed. The recovery term dominates everything else in the cost model.
• Five or more sites and someone competent to run them. VPS, or a management platform on top of one.
• You need services WordPress isn’t. VPS. Don’t pay for two platforms to avoid learning one.
• A plugin you can’t remove is on the host’s disallowed list. VPS, or a different managed host. Do not migrate hoping for an exception.
• Traffic is spiky and crawler-heavy. Lean VPS, or pick a bandwidth-metered plan over a visit-metered one. Metering punishes exactly this traffic shape.
• You’re mostly annoyed at the current bill. Neither, yet. Put a CDN in front, cut the plugin count, fix the object cache. Hosting is often not the bottleneck.

Arguments that don’t survive contact

• “A VPS is faster because you get dedicated resources.” Only if it’s configured well. A default LEMP install with no object cache and an untuned PHP-FPM pool loses to a managed platform’s edge cache every time.
• “Managed hosting handles security, so I’m covered.” It handles infrastructure security. The most common route into a WordPress site is a vulnerable plugin, and that’s yours in both models.
• “I’ll just move if I outgrow it.” Migration cost is real and grows with the site. Redirect rules, caching behaviour, deployment workflow and email configuration all need rebuilding.
• “The VPS is only a few dollars a month.” The instance is. Offsite backup storage, monitoring and your own hours are not, and they’re most of the number.
• “Managed hosts back everything up, so I don’t need my own backups.” Retention windows are finite and account access can be lost. Keep an independent copy the host doesn’t control. This applies to both models.

Frequently asked questions

Is a VPS actually cheaper than managed WordPress hosting?

For one site, usually not once you price your own time honestly. For several sites, usually yes, and the gap widens with each site you add. The crossover sits somewhere around three to five sites for most people, depending on what your hours are worth and how much the sites change.

Why does my managed host report more visitors than Google Analytics?

They measure different things. Analytics counts browser sessions that executed its JavaScript, so it misses anything blocking scripts and misses non-browser clients entirely. Your host counts requests reaching the server, deduplicated by IP per day. Bot filtering closes some of the gap but never all of it. The two numbers are not supposed to match.

Can I run other applications alongside WordPress on managed hosting?

Generally no. Managed WordPress platforms run WordPress and nothing else. A background worker, a separate API, a queue or a self-hosted analytics instance needs a VPS or a second platform. Factor that second bill into the comparison.

What happens if I install a disallowed plugin?

It depends on the host, but the documented pattern at WP Engine is that periodic filesystem scans detect it, you get notified, and the plugin is removed. Check the specific host’s current policy and enforcement mechanism before migrating, and check it against your live plugin list rather than what you assume is installed.

Do I still need a caching plugin on a VPS?

You need caching. Whether it’s a plugin is a design choice. The strongest setup is full-page caching at the web server or CDN layer plus a persistent object cache in Redis or Memcached, which handles the repeated database queries page caching can’t touch. A page cache alone leaves logged-in traffic and admin requests hitting the database on every load.

Is managed VPS hosting a real middle ground or just marketing?

It’s real, but the scope varies enormously and the word isn’t standardised. Ask specifically: who applies OS security patches, who restarts services afterwards, who owns backups and where they live, whether restores are tested, and whether the WordPress stack is in scope or the coverage stops at the operating system. Get the answers in writing before comparing prices.

How hard is migrating from managed hosting to a VPS?

Moving files and the database is the easy part. The work is everything the platform did invisibly: redirect rules living in the host’s dashboard, cache purging behaviour, transactional email, TLS renewal, and any deployment workflow tied to the platform. Plan a parallel run with low DNS TTLs rather than a cutover, and keep the old plan alive until the new one has survived a full traffic cycle.

The one thing worth remembering

Managed WordPress hosting vs VPS isn’t a performance question, and it isn’t really a price question either. It’s a question about which failures you’re equipped to own.

Managed hosting converts operational risk into a predictable bill and a set of constraints you have to live inside. A VPS converts that bill into flexibility plus a standing obligation to do the boring work: patch, restart, and prove your restores actually restore. Both are defensible. What isn’t defensible is buying a VPS because it looked cheap and then skipping the work, which is the most common failure in this whole category and the one that ends with a rebuild from a backup nobody ever tested.

Run the restore drill. Whatever you choose.

Need a second opinion on your hosting decision?

Most of the hosting work I get asked for is one of these. If it looks like your situation, I can help:

• Cost modelling before you commit. Working out from your own access logs what a visit-metered plan would actually bill you, against a realistically priced VPS including backup storage and hours.
• Migration in either direction. Managed to VPS or VPS to managed, planned as a parallel run with DNS TTL staging so there’s no blind cutover.
• Building the VPS properly the first time. Nginx or Apache with PHP-FPM sized to the actual RAM, Redis object cache, TLS with automated renewal, firewall and Fail2ban, log rotation that doesn’t fill the disk.
• Backups you’ve actually restored. Offsite destination, retention policy, and a scheduled restore drill that fails loudly instead of silently.
• Plugin policy audits. Checking your live plugin list against a specific host’s disallowed list before migration, and finding replacements for anything that fails.
• Monitoring that answers the right question. Grafana and Prometheus dashboards covering PHP-FPM saturation, database load and cache hit ratio, not just whether the site returns 200.

Send me something concrete and I’ll tell you what I see: an access log sample, your current plan and traffic numbers, your active plugin list, or the output of the commands above. That’s usually enough for a straight answer before either of us talks about scope.

The post Managed WordPress Hosting vs VPS: Who Owns the Failure? appeared first on John Nessime.

The thing that needed the memory was Redis, installed three weeks earlier to speed up the admin, running with the configuration it shipped with. Redis defaults to no memory limit and a policy of never evicting anything. Left alone it will happily grow until the machine runs out, and then the kernel picks a victim, and it will not necessarily pick Redis.

That is the framing for everything below. Redis object caching for WordPress is genuinely one of the highest-value changes you can make to a busy site, and Redis out of the box is configured as a durable datastore, not a cache. You are storing data you can regenerate at any time. The defaults assume the opposite.

Setup takes ten minutes. The gotchas are the post.

What it does, and what it doesn’t

WordPress has an object cache built in, and by default it lasts exactly one request. Every page load fetches the same options, terms, post meta and user meta from MySQL, uses them, and throws them away. A persistent object cache keeps that data between requests, so the second visitor does not repeat the first visitor’s queries.

Two expectations worth setting before you install anything.

It is not a page cache. Page caching serves a finished HTML file and never runs PHP. Object caching runs the whole application and makes the database part faster. They live in different drop-ins, do different jobs, and coexist happily.

Its biggest effect is where page caching does not reach. Logged-in requests, wp-admin, WooCommerce carts and checkouts, REST API calls. If your front end is already cached and fast while the dashboard crawls, an object cache is aimed exactly at your problem.

Setup

1. Install Redis from your distribution’s packages, and bind it to localhost unless something remote genuinely needs it.
2. Install a PHP Redis client. PhpRedis (the PECL extension) is faster than the pure-PHP Predis and is what you want on a real server. Relay is a newer option worth knowing about if you are pushing volume.
3. Install the Redis Object Cache plugin, then add the constants below to wp-config.php before enabling the drop-in.
4. Enable it, which copies object-cache.php into wp-content/. That file, not the plugin, is what WordPress actually loads.
5. Verify it end to end, which is step five for a reason.

// wp-config.php, above the "That's all, stop editing" line.

define( 'WP_REDIS_HOST',     '127.0.0.1' );
define( 'WP_REDIS_PORT',     6379 );

// Two different protections, and you want both. The database
// number scopes flushes; the prefix prevents key collisions.
define( 'WP_REDIS_DATABASE', 1 );
define( 'WP_REDIS_PREFIX',   'acme-prod:' );

// Ceiling for keys written with no expiry, so nothing lives forever.
define( 'WP_REDIS_MAXTTL',   86400 );

One note if you are following an older tutorial: the prefix constant used to be WP_CACHE_KEY_SALT and was renamed to WP_REDIS_PREFIX in version 2.0 of the plugin, to stop it being confused with a core constant of the same name. The old name is still read for compatibility, but if a guide is still using it, that guide predates a major version and its other advice may too.

Then prove it works rather than trusting a green indicator on a settings page:

# The plugin's own view.
wp redis status

# Write through WordPress, read it back through WordPress.
wp eval 'wp_cache_set("probe","ok","test",60); echo wp_cache_get("probe","test");'

# Then confirm the key landed in the database and prefix you expect.
redis-cli -n 1 --scan --pattern 'acme-prod:*' | head

Site Health under Tools will also tell you whether WordPress considers a persistent object cache to be in use. That is the check to trust, because it reflects what core sees rather than what the plugin believes.

Gotcha 1: the defaults are a datastore’s defaults

The one from the opening paragraph, and the only one on this list that can take a server down.

# /etc/redis/redis.conf

# Without a limit, Redis grows until the machine runs out and the
# kernel kills something. It will not necessarily kill Redis.
maxmemory 512mb

# The default policy is to refuse writes rather than evict. Correct
# for a datastore, wrong for a cache: you want the least recently
# used keys dropped, silently, forever.
maxmemory-policy allkeys-lru

# Cache contents are regenerable by definition. Persisting them buys
# nothing and costs you fork latency on save and slower restarts.
save ""
appendonly no

Size maxmemory against what the machine can spare after MySQL and PHP-FPM have what they need, not against what is currently free. Free memory on a healthy Linux box is mostly page cache, and it is doing useful work.

The honest trade-off with allkeys-lru: under memory pressure Redis will evict things you would rather it kept, and cache misses go up. That is the correct failure mode. The alternative is write errors surfacing inside WordPress, or an outage.

If you are on managed hosting, do not change any of this. Ask them what they have set, because they may have tuned it and may not appreciate you undoing it.

Gotcha 2: one Redis, several sites

Redis is a single key-value store. Two WordPress installs pointed at it with default settings both write post_123 to the same key and read each other’s data. On a server hosting several sites that is a correctness bug. Where it gets genuinely nasty is staging.

Staging is usually a clone of production, which means it inherits production’s wp-config.php, which means it inherits production’s Redis settings. Now both environments share a namespace, and a developer clearing the cache on staging clears production’s, or worse, staging serves production’s cached objects.

The two constants guard against different things and you want both:

• WP_REDIS_DATABASE selects a logical database, of which Redis provides sixteen by default. This scopes flushes, so one site clearing its cache does not clear another’s.
• WP_REDIS_PREFIX namespaces every key. This prevents collisions if two installs ever land in the same database, which is what happens the day somebody copies a config file.

Make the prefix readable and environment-specific: acme-prod: and acme-staging:, not a random string. It is a namespace, not a secret, and you will want to read it in redis-cli at some point.

If you use Relay as the client, a dedicated database and a unique prefix per install is a requirement rather than a suggestion.

Gotcha 3: some things are never cached, and one thing is enormous

Not every cache group is persistent. WordPress marks some as non-persistent, and plugins can mark their own, so those groups keep behaving exactly as they did before you installed anything. If you expected a specific thing to get faster and it did not, this is a likely reason and it is not a misconfiguration.

The more interesting one is alloptions. WordPress stores all autoloaded options as a single cache entry. On a site with a bloated options table, that is one very large key, fetched on every request, and invalidated whenever any autoloaded option is written. Under concurrency that produces a lot of simultaneous re-priming of the same large value.

Which means an object cache does not excuse a bloated options table; it changes where the cost lands. Check what your keys actually look like:

# Reports the largest key per type. If one key dwarfs everything
# else, it is probably alloptions and your options table needs work.
redis-cli -n 1 --bigkeys

Gotcha 4: flushing is not free

Clearing the object cache on a busy site means every subsequent request rebuilds what it needs from MySQL simultaneously. On a quiet site nobody notices. On a busy one you get a load spike at exactly the moment you were trying to fix something.

Know what your flush actually does. Some implementations issue a Redis-wide flush; others delete only keys matching your prefix. Those are very different operations when the instance is shared, and finding out during an incident is a bad time.

Also worth deciding deliberately: whether deploys flush the cache. Stale cached objects after a plugin update cause genuinely confusing bugs, so a flush in the deploy script is often right. Just do it knowing it costs a load spike, and put it at the start of a quiet window rather than at five o’clock on a Friday.

Troubleshooting

“Drop-in: invalid” or “not connected”. Usually the PHP extension is missing, or PHP cannot reach Redis on the host and port you gave it. Check with php -m | grep redis and redis-cli ping from the same machine PHP runs on, which is not always the machine you are logged into.

Everything looks connected but nothing is cached. Something replaced object-cache.php. Optimisation plugins install their own drop-in, and only one can win. Check the file’s contents, not just that it exists.

The site got slower. Latency to Redis. A remote instance across a network adds a round trip to every cache operation, and there are a lot of them per request. Localhost or a Unix socket beats a fast network every time.

Stale data after an update. Flush once, then work out which plugin is caching something it should be invalidating. Do not put a flush on every request to make the symptom go away.

Memory keeps climbing. Either no maxmemory, or keys written with no expiry and no WP_REDIS_MAXTTL ceiling. Check INFO memory and the eviction counters.

Staging and production interfering. They are sharing a database number, a prefix, or both. Fix the config on staging as part of your restore script so it cannot recur.

Common mistakes

• Running Redis with default memory settings on a shared box.
• Leaving persistence enabled for a pure cache workload.
• No prefix and no database number, so sites read each other’s objects.
• Cloning production to staging without changing the Redis settings.
• Trusting the plugin’s status page instead of Site Health and an actual read-back.
• Expecting it to speed up an already page-cached front end.
• Installing it and ignoring an options table full of autoloaded junk.
• Predis on a production site when PhpRedis is available.
• Putting Redis on a different host and adding a network hop to every cache call.
• Flushing the cache during peak traffic to fix a display bug.
• Two plugins competing for the object-cache.php drop-in.

Best practices

• Set maxmemory and allkeys-lru before you point any site at it.
• Disable persistence unless Redis is also doing a job that needs it.
• Unique database number and readable prefix per install and per environment.
• Bind to localhost, or require a password and TLS if it must be remote.
• PhpRedis over Predis, and Redis on the same host as PHP where you can.
• A WP_REDIS_MAXTTL ceiling so nothing lives forever by accident.
• Verify with Site Health plus a write-and-read test, not a status indicator.
• Clean up autoloaded options rather than caching the mess.
• Monitor memory used, evicted keys and hit rate; a collapsing hit rate is an early warning.
• Make staging’s Redis config part of the restore script, not something to remember.

FAQ

Do I need Redis if I already have a caching plugin?

Probably, because they solve different problems. Page caching handles anonymous visitors; object caching handles everything that cannot be page cached, which is the admin, logged-in users and anything transactional. Run both.

Redis or Memcached?

For WordPress, Redis, mostly because the tooling and plugin ecosystem around it is better and you get richer diagnostics. Memcached is perfectly capable and slightly simpler. This is not a decision worth agonising over.

How much memory should I give it?

Start modestly, watch memory used and evicted keys for a week, and raise it if evictions are constant while free memory remains. Sizing from an article is guessing; sizing from your own eviction counter is not.

Is it safe to lose everything in Redis?

Yes, for an object cache. Everything in it is regenerable from MySQL, which is exactly why persistence is unnecessary. Losing it costs a burst of database load, not data.

Why did my dashboard not get faster?

Check the cache is genuinely active first, then look at what else is slow: outbound HTTP calls during admin requests, a large autoloaded options blob, or the heartbeat. An object cache removes repeated database work and nothing else.

Should staging share the production Redis?

It can, with a different database number and a different prefix. It is cleaner not to. Either way, set it as part of the restore process so a clone never inherits production’s cache namespace.

The one thing to remember

Redis ships configured to protect data it assumes you cannot afford to lose. You are storing data you could regenerate in a second. Every default that follows from that assumption, unlimited memory, no eviction, persistence to disk, is wrong for your use case and one of them can take the server down.

So set maxmemory and an eviction policy before you enable the drop-in, give every install its own database and prefix, and verify with Site Health rather than a green dot. Then it is genuinely one of the best changes you can make to a WordPress site.

Want it set up properly?

Object caching is quick to install and easy to get subtly wrong in ways that show up weeks later. Work I take on:

• Installing and tuning Redis object caching on a VPS or dedicated server, including memory limits, eviction and persistence settings.
• Auditing an existing setup for shared namespaces, competing drop-ins and caches that are not actually active.
• Multi-site and multi-environment configuration so staging can never touch production’s cache.
• Cleaning up autoloaded options so the object cache is caching something sensible.
• Monitoring for Redis memory, evictions and hit rate, wired into Prometheus and Grafana.
• Diagnosing sites where caching was installed and nothing got faster.

Send me your Site Health info and redis-cli INFO memory, and I will tell you what is worth changing.

The post The OOM Killer Took MySQL: Redis Object Caching for WordPress appeared first on John Nessime.

Six weeks later the Core Web Vitals report in Search Console still says the same URLs are failing. Nothing moved.

Here is why, and it is the single most important thing to understand before touching anything: the score and the assessment are two different measurements of two different things. The score is Lighthouse running a simulated page load on throttled hardware, once, from wherever you are. The assessment is Chrome telemetry from real visitors on real devices, aggregated over 28 days, graded at the 75th percentile.

Worse: Lighthouse cannot measure one of the three metrics at all. Interaction to Next Paint requires an actual human interacting with the page, so no lab tool produces it. You can score 100 and fail INP for every mobile visitor you have.

This walks through fixing Core Web Vitals on WordPress the way that actually shifts the report: get field data first, then work each metric in the order that pays.

Field data first, or you are guessing

Three facts that determine everything else.

You are graded at the 75th percentile. Three quarters of page views need a good result. Not the median, not your laptop. The fourth-slowest visitor out of four, typically a mid-range Android phone on patchy mobile data, decides whether you pass.

The window is 28 days and it rolls. Deploy a fix today and the report will not reflect it for weeks, and even then it moves gradually as old data ages out. Anyone promising you a same-week improvement in Search Console does not understand the mechanism.

Thin URLs fall back to origin-level data. If a page has too few visits for its own dataset, Google uses a group or your whole origin instead. So one badly performing template can drag URLs that are individually fine.

Practically: start in the Core Web Vitals report in Search Console to see which templates fail and how many URLs are affected. Then run PageSpeed Insights on a representative URL and read only the field data section at the top to decide what is broken. Use the Lighthouse section below it to work out why, which is what lab data is genuinely good for.

If you want faster feedback than 28 days, add real user monitoring. Google’s web-vitals JavaScript library reports all three metrics from your own visitors and you can send them wherever you like. On a site where performance matters commercially, this is worth the afternoon it takes.

LCP: the biggest thing on screen

Largest Contentful Paint is when the largest visible element finishes rendering. Good is under 2.5 seconds. On WordPress it is almost always the hero image or the first image in post content, and the causes are boringly consistent.

The lazy-loaded hero

Still the most common LCP problem on WordPress sites, years after core started handling it. Core skips lazy loading on the first image in content and adds fetchpriority="high" to the likely LCP candidate, but the heuristic only works on images core knows about. A hero rendered by a page builder, a theme header, or a slider often sits outside that, and some optimisation plugins re-add loading="lazy" to everything regardless.

# Look at what the server actually sends. If your hero image has
# loading="lazy" on it, you have found your LCP problem.
curl -s https://example.com/ | grep -o '<img[^>]*>' | head -5

For a theme-rendered hero, be explicit rather than hoping a heuristic catches it:

<!-- No loading="lazy". width and height reserve space, which
     also protects CLS. fetchpriority tells the browser this
     is the one image worth fetching before everything else. -->
<img src="/hero.webp"
     width="1600" height="900"
     fetchpriority="high"
     decoding="async"
     alt="">

Slow server response

LCP cannot be faster than time to first byte. On shared hosting with no page cache, an uncached WordPress response can eat most of your budget before a single byte of image is requested. Full-page caching is the single highest-yield change on most WordPress sites, and a CDN in front of it removes the geographic distance as well.

If TTFB is still poor with caching on, the cache is being bypassed. Cookies from analytics, a cart, or a logged-in session will do it. Check the cache-status header on a real request rather than trusting the plugin’s dashboard.

Render-blocking CSS

The browser will not paint until it has the stylesheets. A theme loading four separate CSS files plus a font stylesheet plus an icon library delays every LCP candidate on the page. Self-host fonts with font-display: swap, drop icon libraries you use six glyphs from, and be sceptical of “combine CSS” plugin features, which on HTTP/2 often make things worse rather than better.

Speculative loading, which is free

Worth knowing because most WordPress performance guides predate it. Since WordPress 6.8, core ships speculative loading using the Speculation Rules API: the browser starts fetching a link’s destination when the visitor interacts with it, so the next page is partly or entirely loaded before they arrive. It is on by default for logged-out visitors, using prefetch with “conservative” eagerness, and it is a progressive enhancement with no downside for browsers that do not support it.

You can push it further, at a cost:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    // Prerender actually renders the next page, including running
    // its JavaScript. Much faster, and analytics or anything with
    // side effects may fire for a visit that never happens.
    return array(
        'mode'      => 'prerender',
        'eagerness' => 'moderate',
    );
} );

Test that carefully on anything transactional. Core also honours no-prefetch and no-prerender CSS classes on individual links, which is the simplest way to keep carts, checkouts and logout links out of it.

INP: the hard one, and it is your JavaScript

Interaction to Next Paint measures the time from a user interacting to the browser painting the response, across every interaction on the page, and reports roughly the worst one. Good is under 200 milliseconds; above 500 is poor.

It replaced First Input Delay in March 2024, and the change matters more than a metric swap sounds. FID measured only the delay before processing the first interaction. INP measures the whole round trip, every time. Plenty of sites that comfortably passed FID fail INP, because the thing that was always sluggish is now the thing being graded.

Since no lab tool reports it, use Total Blocking Time in Lighthouse as a proxy, and Chrome DevTools’ Performance panel to find which handler is blocking. On WordPress the usual suspects:

• Plugin JavaScript loading site-wide. A form builder, a slider and a popup tool each shipping their bundle on every page, including pages that use none of them.
• Third-party tags. Tag managers, chat widgets, heatmaps, ad scripts. These run on the main thread and are usually the largest single contributor.
• Long tasks in event handlers. Anything doing real work synchronously in response to a click.
• jQuery-era code attaching handlers to hundreds of elements on a listing page.

The fixes, in order of yield. First, stop shipping JavaScript to pages that do not use it. Conditionally dequeue plugin assets rather than accepting that a contact form script belongs on every article. This alone often solves INP.

Second, audit the third-party tags. Every one is somebody’s request from two years ago, and at least one of them is for a tool nobody uses any more. Removing a tag is the cheapest performance work available.

Third, break up long tasks so the browser can paint between chunks:

// Yielding lets the browser respond to the click that started this,
// instead of finishing all the work first. INP measures exactly
// that gap, so yielding moves the metric even though total work
// stays the same.
async function processAll(items) {
  for (const item of items) {
    doWork(item);
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

Newer Chrome versions offer scheduler.yield(), which does the same thing without losing your place in the task queue. Feature-detect it and fall back to the above.

One honest warning: “delay JavaScript until user interaction” features in optimisation plugins look like an INP fix and frequently are not. Delaying scripts until the first interaction means the first interaction now waits for all of them to load and execute, which is the worst possible moment. It improves lab scores and can make INP worse.

CLS: usually an afternoon

Cumulative Layout Shift measures unexpected movement of visible content. Good is under 0.1, and it is the metric most likely to be fixable in one sitting.

• Images without dimensions. Set width and height so the browser reserves space before the file arrives. WordPress does this for media library images; hand-written theme markup often does not.
• Ads and embeds. Reserve a fixed-height container. An ad slot that collapses to nothing and then expands is a large shift on every page view.
• Fonts. A web font swapping in at a different metric reflows everything. font-display: swap plus size-adjust on the fallback, or a system font stack, both work.
• Cookie banners and notices injected by JavaScript that push the page down rather than overlaying it.
• Lazy-loaded content above the fold that appears after paint.

Chrome DevTools’ Performance panel highlights layout shifts with the element that moved, which turns this from detective work into a checklist.

The order I’d work in

1. Anything in the “poor” band, whichever metric it is. Poor hurts more than two mediocre metrics.
2. Caching and TTFB, because it is one change and it moves LCP for every page at once.
3. The LCP image on your highest-traffic template.
4. JavaScript you can delete. Unused plugin assets and dead third-party tags, for INP.
5. CLS, which is quick and visible to users even where the number already passes.
6. Everything else, measured one change at a time.

What I would skip: chasing a green Lighthouse score once field data passes, stacking a second optimisation plugin on top of the first, and micro-optimising a metric that is already comfortably good. There is no bonus for 1.1 seconds when 2.5 is the bar.

When the numbers don’t move

It has been two weeks. That is normal. The window is 28 days and rolling, so give it a full month before concluding anything.

Lab improved, field did not. You optimised something the lab measures and users do not experience, or the problem is INP, which the lab never measured. Go back to the field data section.

Desktop passes, mobile fails. Expected, and mobile is what is graded for most sites. Test with CPU throttling on, because the gap is usually processing rather than network.

One URL is fine but the group fails. Origin-level fallback, or a different template in the same group is dragging it. Check what else Search Console has bundled together.

It regressed after a plugin update. Very common, and the reason to record your field numbers before and after any significant change rather than relying on memory.

Common mistakes

• Treating the PageSpeed Insights score as the thing being measured.
• Optimising INP with a lab tool that cannot measure INP.
• Testing from a fast laptop on fibre and concluding the site is fine.
• Lazy-loading the hero image, or letting a plugin re-add it.
• Running two optimisation plugins that both minify and both defer.
• Enabling “delay JavaScript until interaction” and expecting INP to improve.
• Judging a fix after a week.
• Loading every plugin’s JavaScript on every page.
• Adding a CDN while the origin has no page cache.
• Fixing the homepage when the failing template is the blog archive.

Best practices

• Decide what is broken from field data; work out why from lab data.
• Fix by template, not by URL, since one template covers thousands of pages.
• Full-page caching first, then a CDN, then image work.
• Explicit width and height on every image in theme markup.
• fetchpriority="high" on the LCP image and lazy loading on nothing above the fold.
• Dequeue plugin assets on pages that do not use them.
• Review third-party tags on a schedule and delete the ones nobody owns.
• Self-host fonts with font-display: swap.
• Real user monitoring so you are not waiting a month for feedback.
• Record field numbers before and after every significant change.

FAQ

Why is my PageSpeed score 95 but Search Console says I’m failing?

They measure different things. The score is a simulated load on your connection; the assessment is real Chrome users at the 75th percentile over 28 days. Read the field data section at the top of PageSpeed Insights, not the score.

How long before a fix shows up?

The data window is 28 days and rolls daily, so improvement appears gradually and takes about a month to fully reflect. Real user monitoring gives you same-day feedback if you cannot wait.

Will a caching plugin fix Core Web Vitals?

It will help LCP substantially, because TTFB is a floor under it. It does very little for INP, which is about JavaScript execution, and nothing for CLS. Caching is a strong first move and not a complete answer.

What happened to FID?

INP replaced it in March 2024 and FID is retired. Any guide still listing it predates the change, which is a useful signal about the rest of its advice.

Do I need to switch themes?

Sometimes, and it is a bigger project than it looks. A heavy multipurpose theme loading a page builder, a slider library and an icon set on every request is fighting you. Measure first, because a theme swap on a site with hundreds of pages is rarely the cheapest route to passing.

Does passing actually help rankings?

Core Web Vitals are a ranking signal among many, and content relevance dominates. The reliable win is on the user side: faster pages convert better and get abandoned less. Treat ranking as a bonus rather than the business case.

The one thing to remember

You cannot fix what you are not measuring, and the tool most people measure with cannot see the metric most people are failing. Lighthouse is a debugger. The Chrome User Experience Report is the exam.

So open Search Console before you open PageSpeed Insights, find out which of the three is actually red, and fix that one. Then wait a month before deciding whether it worked, because the measurement takes longer than the work.

Site failing and not sure why?

Most of the WordPress sites I get sent have already had a fortnight thrown at the wrong metric. Work I take on:

• Diagnosing which Core Web Vital is actually failing, for which templates, from field data rather than a score.
• LCP work: caching and TTFB, image priority and formats, render-blocking CSS, CDN configuration.
• INP work, which is mostly JavaScript archaeology: dequeuing plugin assets by page, auditing third-party tags, breaking up long tasks.
• CLS fixes across templates, including ads, embeds, fonts and consent banners.
• Setting up real user monitoring so you get feedback in a day instead of a month.
• Untangling sites running two or three overlapping optimisation plugins.

Send me your Search Console Core Web Vitals report and a URL from a failing template, and I will tell you what is actually wrong.

The post A 100 Score and a Failing Report: Fixing Core Web Vitals on a Real WordPress Site appeared first on John Nessime.

Here is the thing that explains almost every case of this, and it is worth getting straight before you touch a single setting: wp-admin is the only part of your site that never gets cached. Every page cache plugin, every CDN, every reverse proxy in front of WordPress explicitly excludes logged-in requests. It has to, otherwise you would serve one editor’s draft screen to another. So the front end you keep measuring is a static HTML file being handed over by Cloudflare or Nginx, and the dashboard is your actual application running end to end, every single time.

A slow WordPress admin is not a separate problem from a slow site. It is the same problem, visible. The cache was hiding it, not fixing it.

This post walks through where that time actually goes, in the order I check things: how to tell server time from browser time, the wp_options table, outbound HTTP requests that block your page load, admin-ajax and the heartbeat, wp-cron, database bloat, and the server underneath it. Plus the troubleshooting steps for the cases that do not fit the pattern.

First, split the problem in two

Do not start changing things. Find out whether you are waiting on the server or on the browser, because the fixes have nothing in common.

Open the browser dev tools, go to the Network tab, hard reload an admin page, and look at the document request. If TTFB on that first request is three seconds, the server is thinking and nothing you do to JavaScript will help. If TTFB is 200ms and the page still feels slow, you have a rendering problem: too many scripts, a bloated admin notice area, a media grid loading hundreds of full-size images.

For server-side time, install Query Monitor. It is the single most useful diagnostic tool in the WordPress ecosystem and it costs nothing. It gives you, per admin page load: total queries and their time, which queries came from which plugin, every HTTP request WordPress made server-side and how long each took, hook timings, and PHP errors. Nine times out of ten the answer is sitting in the HTTP API panel or the Queries panel, and you will have it in under a minute.

One caution: Query Monitor itself adds overhead, so use it to find the culprit, then deactivate it before you measure the improvement.

The invisible one: your autoloaded options

This is the failure that hides for years and then bites everybody at once, and it is where I look first on any slow WordPress admin.

WordPress loads every option marked as autoload in one query at the start of every single request, then unserializes the lot into memory. That design is fine when the total is a few dozen kilobytes. It stops being fine when a page builder decides to autoload its full asset manifest, a slider plugin stores every slide’s settings in one row, an analytics plugin caches an API response there, and three plugins you uninstalled two years ago left their rows behind.

Now every admin click pulls several megabytes out of MySQL and runs it through PHP’s unserializer before WordPress has drawn anything. No error, no warning, no slow query in the log worth noticing. Just a tax on every request.

Measuring it

There is a trap in the usual SQL query you will find online. WordPress 6.6 changed the autoload column from a simple yes/no to a set of values: on, off, auto, auto-on, auto-off. Older rows keep yes and no, and there is no upgrade routine, so a real site has a mix. Querying only for autoload = 'yes' undercounts, sometimes badly.

-- Total bytes loaded on every request.
-- Adjust wp_ if your table prefix is different.
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

-- The worst offenders, largest first.
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY size_bytes DESC
LIMIT 25;

If you have WP-CLI, this is quicker and you do not need database credentials:

# Total size of everything autoloaded, in bytes.
wp option list --autoload=on --format=total_bytes

# Biggest autoloaded options. Note the sort happens in the shell:
# wp option list only sorts by option_id, option_name or option_value.
wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail -25

Site Health flags this too, under Tools then Site Health, once the total crosses core’s threshold. Treat that warning as an audit trigger rather than a number to chase.

Fixing it without breaking anything

Read the list before you delete anything. You are looking for three categories:

• Orphans. Options with the prefix of a plugin that is no longer installed. Safe to delete after a backup.
• Wrongly autoloaded. Settings for a plugin that only ever runs on one admin screen. These should not be autoloaded, but they should not be deleted either.
• Cache data in the wrong place. A plugin storing an API response or an asset map as a permanent option. Usually safe to delete, because the plugin will rebuild it, but check that assumption on staging first.

For the middle category, flip autoload off instead of deleting. Use the WordPress API rather than raw SQL, because a direct UPDATE leaves the object cache holding the old value and you will spend twenty minutes convinced nothing changed:

# Stop autoloading a specific option. Run once, then remove.
wp eval "wp_set_option_autoload( 'some_plugin_bulky_setting', false );"

While you are in there, clear out expired transients. They live in the same table and orphaned ones accumulate quietly, especially on sites that have been through a few plugin migrations:

wp transient delete --expired

Outbound HTTP requests that block your page load

This one is regional and it catches people out badly. WordPress makes server-side HTTP calls during admin requests: core update checks, plugin and theme update checks, the Events and News dashboard widget, and whatever your commercial plugins do to phone home for licence validation.

Those calls are synchronous. If the endpoint is slow to reach from your server, or a firewall is silently dropping the packets rather than refusing them, PHP sits there until the timeout expires. Two plugins doing that with a five-second timeout each is ten seconds of dashboard, and absolutely nothing in the interface tells you why.

Query Monitor’s HTTP API panel shows every one of these with its duration, which is usually enough. To confirm from the server directly:

# How long does the server take to reach the WordPress.org API?
# -w prints the timing, -o discards the body, -s hides the progress meter.
curl -w "%{time_total}n" -o /dev/null -s https://api.wordpress.org/core/version-check/1.7/

If that takes seconds, or hangs, you have found it. For a pure diagnostic, you can temporarily block all outbound HTTP from WordPress and see whether the dashboard snaps back:

// wp-config.php, ABOVE the "stop editing" line.
// DIAGNOSTIC ONLY. This breaks updates, licence checks and
// anything else that calls out. Remove it once you have your answer.
define( 'WP_HTTP_BLOCK_EXTERNAL', true );

// Optionally allow specific hosts back through while testing.
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.wordpress.org' );

Do not leave that in place as a fix. If outbound connectivity is genuinely the problem, the real solution is at the network layer: fix the firewall rule, fix DNS resolution on the box, or move to a host that does not throttle outbound connections. If you are on shared hosting and cannot influence any of that, a small VPS from somewhere like InterServer will usually behave better than a crowded shared box, purely because you control the network stack.

The dashboard news widget is the one piece here you can just remove, and most teams never look at it:

// In a site-specific plugin, not in a parent theme.
add_action( 'wp_dashboard_setup', function () {
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );
} );

admin-ajax.php and the heartbeat

Open the Network tab in dev tools, filter on admin-ajax.php, and leave a dashboard tab sitting idle for two minutes. You will see requests firing on a timer. That is the Heartbeat API, and it powers autosave, post locking, and session expiry warnings. Those are real features and you should not rip them out.

The cost is that each tick boots WordPress, loads every active plugin, runs any handlers hooked into it, and occupies a PHP worker for the duration. The post editor ticks fastest because autosave needs to feel responsive; other admin screens tick more slowly. Multiply by every open tab and every logged-in editor, and on a small server you can spend a meaningful share of your PHP workers on polling.

The proportionate fix is to slow it down rather than kill it:

// Slow the heartbeat down across admin screens.
// Core clamps this to its allowed range, so an out-of-range
// value is quietly ignored rather than applied.
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

Worth being honest about the trade-off: at a longer interval, autosave and post-lock detection get less immediate. On a single-author blog that is invisible. On a newsroom where three people edit the same article, post locking becoming less prompt is a genuine cost and you should leave the editor alone and throttle elsewhere.

Heartbeat is not the only thing hitting that endpoint. Cart fragments, live search, popup builders, notification pollers and bots all target admin-ajax.php. Look at the action parameter in the request payload to see which plugin is responsible, then deal with that plugin rather than blaming the endpoint.

wp-cron riding along on your admin requests

WordPress has no scheduler of its own. It checks for due tasks on page loads and fires them off, which means somebody’s page view pays for your backup job, your feed import and your email queue. On a low-traffic site the person unlucky enough to be that page view is usually you, logged in, clicking around the admin.

# What is scheduled, and is anything badly overdue?
wp cron event list

# Run everything due right now, so you can time it in isolation.
wp cron event run --due-now

A long list of overdue events means cron is not firing reliably, which is its own problem. The fix is to take the scheduler off page loads and give it to the operating system:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# crontab -e, as the user that owns the WordPress files.
# Every five minutes is enough for most sites.
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

The order matters. Set the constant and the system cron in the same change, because if you disable wp-cron and forget the cron job, scheduled posts stop publishing and nobody notices for a week.

Database bloat, and the list tables that trip over it

Admin list screens do work the front end never does. Counting posts by status for those “All | Published | Draft” links, joining postmeta for sortable columns, building filter dropdowns from distinct values. All of it scales with table size, and none of it is cached.

# Which tables are actually large?
wp db size --tables --human-readable

What usually turns up:

• wp_postmeta far larger than wp_posts. Normal to a point. Suspicious when the ratio is extreme, which usually means a plugin writing meta per page view.
• Revisions. Every save keeps a full copy of the post. Cap them with define( 'WP_POST_REVISIONS', 10 ); in wp-config, which limits new ones without touching existing content.
• Action Scheduler tables on WooCommerce sites. Completed actions accumulate. There is a cleanup screen under WooCommerce tools, and it is worth checking before you assume the store itself is slow.
• Spam and trashed comments still counted by every dashboard widget that shows a comment count.

Two quick wins that need no database work at all. Use Screen Options at the top right of any list table to drop the per-page count from twenty to ten on a slow screen. And switch the Media Library from grid view to list view, because the grid loads far more per scroll.

The server underneath

If the application is clean and the admin is still slow, look down a layer. Site Health covers most of it, under Tools then Site Health then Info.

• No persistent object cache. Without one, every options lookup and every transient read goes to MySQL on every request. Adding Redis or Memcached with the matching drop-in is often the single biggest improvement available to an admin-heavy site, because the admin is exactly the workload that benefits.
• OPcache disabled. PHP recompiling every WordPress file on every request. Free to enable, immediately noticeable.
• An old PHP version. Upgrading a WordPress site’s PHP is usually the cheapest performance work available, and it is a security matter regardless.
• PHP-FPM worker exhaustion. If requests are queuing for a worker, every page waits, and the admin waits longest because it holds a worker for the whole request. Check the pool status and the error log before adding more workers, because a worker shortage is often a symptom of slow requests rather than the cause.
• A low memory limit. The admin needs more than the front end, especially plugin and update screens.

If you run your own server, track admin response time the same way you track front-end response time. Scraping PHP-FPM and MySQL metrics into Prometheus and graphing them in Grafana costs an afternoon and turns “the dashboard feels slower lately” into something you can actually see.

Troubleshooting

Only one admin screen is slow

That points at a specific plugin, not the platform. Query Monitor on that exact screen will name the caller. Common culprits are the plugins list (update checks for every installed plugin) and any settings page that fetches remote data to populate a dropdown.

Slow only for some users

Check user meta. Some plugins store per-user data such as dismissed notices, column preferences or activity logs, and one user’s row can grow enormous. Also check whether the slow users are administrators, since admins load update checks and notices that editors do not.

Fast for a while after clearing cache, then slow again

Something is rebuilding a large transient or option on a schedule and it is expensive. Watch wp_options row sizes over a day, or check the cron list for a job that lines up with the slowdown.

Slow in one browser or on one machine only

Not a server problem. Test in a private window with extensions disabled. Ad blockers and password managers interact badly with some admin screens, and a stale service worker from a caching plugin can serve half-broken admin assets.

Everything looks fine but it is still slow

Bisect on staging, never production. Deactivate all plugins, confirm the admin is fast, then reactivate in halves rather than one at a time. Switch to a default theme too, because functions.php in a commercial theme can do as much work as a plugin.

Common mistakes

Things I would push back on if you suggested them:

• Judging admin performance by front-end speed test scores. Those measure a cached HTML file.
• Installing a second caching plugin because the first one “did not fix the dashboard”. No page cache will ever cache wp-admin.
• Running an UPDATE against the autoload column directly, then wondering why nothing changed. The object cache still holds the old values.
• Only counting autoload = 'yes' and concluding the table is fine.
• Disabling the heartbeat completely, then losing work when two people edit the same post.
• Setting DISABLE_WP_CRON without adding a real cron job.
• Deleting rows from wp_options without a backup, or without checking on staging first.
• Leaving WP_HTTP_BLOCK_EXTERNAL in place because it made the dashboard fast. It also stopped your security updates.
• Adding PHP-FPM workers to hide slow requests instead of finding out why they are slow.
• Deactivating plugins one at a time on a live site during business hours.

Best practices

• Measure with Query Monitor before changing anything, and measure again with it deactivated.
• Check autoloaded option size whenever you install, remove or update a major plugin.
• Remove uninstalled plugins’ leftover rows as part of routine maintenance, not as an emergency.
• Run a persistent object cache on any site where people spend real time in the admin.
• Move wp-cron to a system cron job on every site you manage.
• Cap post revisions rather than deleting them in bulk later.
• Keep a staging copy so bisecting plugins never happens on production.
• Treat Site Health warnings as a starting point for investigation, not a checklist to silence.
• Uninstall plugins properly instead of deactivating them and leaving them installed, since update checks still run for installed plugins.
• Watch admin response time over time, so you catch a slow regression before somebody files a ticket.

FAQ

Why is my WordPress dashboard slow when the site itself is fast?

Because the front end is being served from a cache and the dashboard cannot be. Page caches and CDNs bypass logged-in requests by design, so wp-admin runs the full PHP and MySQL stack on every click. The dashboard is showing you your site’s real uncached performance.

Will a caching plugin speed up wp-admin?

Not the page caching part, no. What can help is the object caching side, if your caching plugin ships one, because that caches option and transient lookups rather than whole pages. Redis or Memcached with the matching drop-in does the same job more reliably.

How much autoloaded data is too much?

Core’s Site Health check will tell you when you have crossed its threshold, and that is the number to work against rather than one from an article. More usefully: if a single option is measured in hundreds of kilobytes, look at it regardless of the total, because one bad row is easier to fix than a general diet.

Is it safe to delete rows from wp_options?

With a backup and a staging test, yes for orphaned rows from plugins you have removed. For anything belonging to an active plugin, turn autoload off instead of deleting, and use wp_set_option_autoload() rather than raw SQL so the object cache stays consistent.

Should I disable the Heartbeat API?

Throttle it, do not disable it. Turning it off entirely breaks autosave and post locking, which is a bad trade for a site with more than one editor. Raising the interval keeps both working and removes most of the load.

Does the number of plugins matter?

Less than people assume. Twenty well-written plugins can cost less than one that runs a remote API call on admin_init. Count what each plugin does per request, not how many are in the list. Query Monitor attributes queries and HTTP calls to specific plugins, which turns this from a guess into a measurement.

Will better hosting fix a slow WordPress admin?

It helps when the constraint is genuinely the server: no OPcache, no object cache, throttled CPU, a shared MySQL instance under load. It does nothing for four megabytes of autoloaded options or a plugin blocking on a remote API. Diagnose first, because moving a slow site to a faster server usually gives you a slightly less slow site and a new bill.

The one thing to remember

Your dashboard is not a separate, badly built part of WordPress. It is the only place you ever see your site running without a cache in front of it, which makes it the most honest performance signal you have. A slow WordPress admin is telling you something true about the application, and the front end has been politely covering for it.

So measure before you change anything, and go in this order: autoloaded options, outbound HTTP requests, admin-ajax traffic, cron, database size, then the server. That sequence puts the highest-yield, lowest-risk checks first, and most of the time you will not get past the second one.

Need someone to find where the time is going?

Diagnosing a slow admin is mostly measurement discipline, and it goes faster with someone who has looked at a lot of these. Work I take on regularly:

• Profiling a slow WordPress admin and reporting back with the actual cause, named, rather than a list of generic tips.
• Cleaning up wp_options and autoloaded data safely, tested on staging before it touches production.
• Setting up Redis or Memcached object caching, OPcache and PHP-FPM tuning on a VPS or dedicated server.
• Moving wp-cron to system cron and fixing scheduled jobs that have quietly stopped running.
• Database maintenance: revisions, orphaned meta, Action Scheduler cleanup on WooCommerce sites, and indexing where it genuinely helps.
• Adding proper monitoring so admin performance regressions show up on a graph instead of in a complaint.

Send me a Site Health info report and a Query Monitor screenshot from your slowest admin screen, and I will tell you what I would look at first.

The post Your Site Is Fast and Your Dashboard Is Not: Fixing a Slow WordPress Admin appeared first on John Nessime.

Then it clicks. Somebody logged into wp-admin last month, saw an update notice, clicked it. The plugin got updated on the server and never in git. Last night’s deploy synced the repo over the top and put the old version back, along with the vulnerability the update was patching. No error, no warning. The deploy did exactly what it was told.

That is the failure mode that kills most attempts at Git-based WordPress deployment, and it has nothing to do with your pipeline. WordPress is designed to modify itself. It installs plugins, updates core, writes files, all from the browser. The moment you put it under version control you have two systems that both believe they own the file tree, and they will quietly overwrite each other until somebody notices.

This post covers the whole chain: what belongs in the repo, how to shut the second write path, how configuration differs per environment, which way the database is allowed to travel, and how to make staging safe enough that you can restore production data into it without emailing your customers by accident.

The two things that make WordPress awkward under Git

Everything in this workflow follows from two facts.

State is split across files and a database. Your theme is code. Your posts are data. But so are your plugin settings, your menus, your widget layouts, and your permalink structure, and those live in the database next to the content. Git only manages half your site, and it is not obvious which half a given change landed in.

The two halves travel in opposite directions. Code moves forward, local to staging to production. Content moves backward, production to staging to local. Once a site is live, production is the only authoritative source of orders, comments and posts, and pushing a database upward destroys everything written since your last pull.

Write that rule somewhere the whole team can see it. Almost every catastrophic WordPress deployment story is somebody pushing a database in the wrong direction.

Decide what actually goes in the repo

Three approaches, in increasing order of discipline and payoff. Pick one deliberately rather than drifting into the first.

1. Theme only. The repo contains one custom theme, sometimes a custom plugin. Everything else is installed through wp-admin. Easy to start, and it means you have no reproducible build: rebuilding the site from the repo is impossible.
2. All of wp-content, minus uploads. Themes, plugins and mu-plugins in git; core and media excluded. This is the pragmatic middle and where most teams land. You get reproducible plugin versions and a real diff when a plugin changes.
3. Composer-managed, Bedrock-style. Core, plugins and themes are all declared as dependencies. The repo holds a composer.json and your own code, nothing else. The lockfile is the source of truth and composer install rebuilds the site anywhere.

Option three is the one I reach for on anything with more than one developer, because “which plugin version is production running” becomes a question with an answer. The honest cost: premium plugins that are not on a Composer repository need either a private repository or a manual step, and that friction is real. If most of your plugin stack is commercial, option two is a reasonable place to stop.

One thing to check if you are following an older tutorial. The Composer repository landscape for WordPress plugins shifted recently: WPackagist was acquired by WP Engine, and the Roots team launched WP Packages as an independent alternative with different package naming. Both work. Any guide written before that change will use the older wpackagist-plugin/ prefix, so make sure the repository URL and the prefixes in your composer.json match each other.

The gitignore that matters

# Secrets and machine-specific config. Never committed.
wp-config.php
.env

# Content, not code. This gets pulled down from production,
# it never gets deployed up.
wp-content/uploads/

# Generated at runtime or by the build.
wp-content/cache/
wp-content/upgrade/
wp-content/debug.log
node_modules/
vendor/

Ignoring vendor/ assumes your deploy runs composer install. If your pipeline just rsyncs the repo with no build step, commit it instead, or you will ship a site with no dependencies. Decide which, then be consistent, because half-and-half is how you end up with a missing autoloader at two in the morning.

Close the second write path

This is the step people skip, and it is the one that makes everything else work. If production can still install and update plugins from the browser, your repo is not the source of truth. It is a suggestion.

// wp-config.php on production and staging.

// Removes the ability to install, update or delete plugins and
// themes from the admin. Also disables the built-in file editor,
// so DISALLOW_FILE_EDIT is implied by this one.
define( 'DISALLOW_FILE_MODS', true );

// Stops core from updating itself behind your back, including
// the automatic minor updates that would otherwise change files
// your deploy is about to overwrite.
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Be clear-eyed about the trade-off, because it is a real one. You have just taken away automatic security updates. That is only an improvement if you replace them with something: a scheduled dependency update job, a weekly review of the update list, a bot that opens a pull request when a plugin version changes. If you disable updates and then do nothing, you have made the site less safe, not more controlled.

The update flow now runs through the repo. On your local machine:

# Composer-managed: bump the lockfile, commit it, deploy.
composer update wp-plugin/some-plugin

# wp-content-in-git: let WP-CLI do the download locally,
# then commit the resulting file changes as a normal diff.
wp plugin update some-plugin

The second form is worth appreciating. A plugin update becomes a reviewable diff. When something breaks two days later, git log tells you exactly which files changed and git revert puts them back.

Configuration per environment

Database credentials, salts and API keys differ per environment and none of them belong in git. Keep wp-config.php out of the repo and place it on each server, or use an environment file with a committed .env.example showing the required keys with no values.

Core has a first-class way to tell environments apart, and it is underused:

// Per environment, in wp-config.php.
// Recognised values: 'local', 'development', 'staging', 'production'.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

<?php
// mu-plugin, committed to the repo, safe on every environment
// because it checks where it is running.

if ( wp_get_environment_type() !== 'production' ) {

    // Keep non-production sites out of search results.
    add_filter( 'pre_option_blog_public', '__return_zero' );

    // Short-circuit wp_mail() entirely. Returning a non-null
    // value stops WordPress before it hands anything to PHPMailer.
    add_filter( 'pre_wp_mail', '__return_false' );
}

That mail filter is the single most valuable line in this post. Restore a production database onto staging, forget this, and the first cron run mails real order confirmations, password resets and abandoned-cart nudges to real customers from a URL that does not work. It is silent until it is very loud.

Moving the database in the allowed direction

Set up WP-CLI aliases once and the rest becomes short commands instead of a runbook nobody follows.

# wp-cli.yml in the project root, committed to the repo.
@staging:
  ssh: deploy@staging.example.com/var/www/staging.example.com
@production:
  ssh: deploy@example.com/var/www/example.com

Now pulling production down to your machine is one pipe. The trailing hyphen means “write the dump to standard output”, and the leading hyphen on the import means “read it from standard input”, so nothing touches disk:

# Back up your local database first, then overwrite it.
wp db export local-backup.sql
wp @production db export - | wp db import -

The URLs inside that dump still point at production, and they are buried in serialized PHP arrays where a plain SQL find-and-replace corrupts the string length prefixes. This is exactly what wp search-replace exists for: it unserializes, replaces, and reserializes properly.

# Always dry-run first and actually read the table list it prints.
wp search-replace 'https://example.com' 'https://example.test' 
  --all-tables-with-prefix --skip-columns=guid --dry-run

# Then for real.
wp search-replace 'https://example.com' 'https://example.test' 
  --all-tables-with-prefix --skip-columns=guid

wp cache flush

Two flags worth understanding rather than copying:

• --skip-columns=guid because the guid column is a permanent identifier that feed readers and external systems use to decide whether they have already seen a post. Rewriting it makes subscribers re-receive your entire archive, and you find out from an angry email weeks later.
• --all-tables-with-prefix because plugins create their own tables using your prefix, and those tables are not registered with WordPress. Without this, the replacement misses them and you get half-migrated URLs in places nobody checks.

Uploads are the other half of the content problem. Do not put them in git; a media library will outgrow a repository quickly and every clone pays for it. Sync them separately with rsync when you need them, or skip them entirely locally and let a plugin proxy missing images from production. Offloading media to object storage sidesteps the question completely and is worth considering on any site with a large library.

The deploy itself

Three broad options. git pull on the server is the simplest and the one I would move away from first: it puts a .git directory next to your document root, it has no build step, and a failed pull leaves the site half-updated. Rsync from CI is the pragmatic default. Atomic releases with a symlink swap, the way Deployer or Capistrano work, are the most correct because the site switches versions instantly and rollback is a symlink change.

A workable rsync deploy from GitHub Actions, with staging on merge and production on tag:

name: Deploy
on:
  push:
    branches: [main]     # goes to staging
    tags: ['v*']         # goes to production

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4    # pin to a full SHA in production

      - name: Build
        run: |
          composer install --no-dev --optimize-autoloader
          npm ci
          npm run build

      - name: Sync files
        run: |
          echo "$DEPLOY_KEY" > deploy_key
          chmod 600 deploy_key
          rsync -az --delete 
            -e "ssh -i deploy_key -o StrictHostKeyChecking=accept-new" 
            --exclude-from=.deployignore 
            ./ "$TARGET"
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
          TARGET: ${{ secrets.DEPLOY_TARGET }}

--delete is what makes the target match the source exactly, which is the entire point of a deploy. It is also the flag that will erase your uploads directory if .deployignore is wrong. Test the exclude list against staging before you ever point this at production, and use --dry-run the first time.

Files landing on the server is not the same as a working deploy. Run a post-deploy step over SSH:

#!/usr/bin/env bash
set -euo pipefail

cd /var/www/example.com

# Applies schema changes that a core or plugin version bump needs.
# Safe to run when there is nothing to do.
wp core update-db

# Rewrite rules live in the database, so a plugin that registers
# new routes needs this or you get 404s on the new URLs.
wp rewrite flush

# Options and transients are cached; stale ones survive a file deploy.
wp cache flush

# Prove the site answers before you call the deploy finished.
# --fail makes curl exit non-zero on a 5xx instead of shrugging.
curl --fail --silent --show-error https://example.com/ > /dev/null

If you run PHP-FPM with OPcache, add a reset to that script. Otherwise PHP happily serves the previous version of your code from its compiled cache and you spend twenty minutes convinced the deploy did not run.

Making staging safe to hold real data

Staging is only useful if it mirrors production, and the moment it does it becomes dangerous. Every one of these has bitten somebody:

• Outbound email. Covered above. Kill it at the wp_mail() level rather than trusting a plugin setting somebody can toggle.
• Cron. A restored production database brings production’s scheduled jobs with it. Set DISABLE_WP_CRON on staging and do not add a system cron job unless you specifically need to test scheduling.
• Payment gateways. The database carries live API keys. Overwrite them with test-mode credentials as part of your restore script, not by hand afterwards.
• Search indexing. Filter blog_public as shown, and put HTTP basic auth in front of the whole environment. Duplicate content ranking above your real site is an avoidable embarrassment.
• Personal data. A production restore is real customer data on a server that probably has weaker access controls. Either anonymise user records during the restore or treat staging with the same seriousness as production.

Write the restore as a single script that does all of this in order, so nobody has to remember step four. If it is a checklist in a wiki, it will be skipped.

Troubleshooting

The deploy ran but the site is unchanged

In order: OPcache serving compiled bytecode, a page cache or CDN holding the old response, or rsync excluding the directory you edited. Check them in that order. Confirm the file on disk actually changed before blaming anything upstream of it.

White screen immediately after deploying

Usually a missing autoloader, meaning vendor/ was neither committed nor built. Check the PHP error log rather than guessing. A memory limit lower on the server than locally is the other common cause, and it produces the same blank page.

Site works, admin redirects in a loop

siteurl and home in the options table disagree with the URL you are actually using. Almost always a search-replace that missed. Check with wp option get siteurl and wp option get home, and set them explicitly with wp option update rather than running the replacement again.

Serialized data broken after a migration

Somebody ran sed or a SQL REPLACE on the dump. The length prefix inside each serialized string no longer matches the string, so PHP silently fails to unserialize and widgets, theme options and ACF fields come back empty. Restore from the dump and redo it with wp search-replace. There is no partial recovery worth attempting.

Permalinks return 404 after deploy

Rewrite rules are stored in the database and did not get regenerated. Run wp rewrite flush. If it recurs on every deploy, add it to the post-deploy script permanently.

Plugin reverts to an older version after every deploy

Somebody is still updating in wp-admin. That is not a pipeline bug, it is the second write path being open. Set DISALLOW_FILE_MODS and give the team a documented way to request an update.

Common mistakes

• Committing wp-config.php, and with it your database password and salts.
• Putting wp-content/uploads in the repo, then wondering why clones take ten minutes.
• Pushing a staging database over production because “the content is the same”. It never is.
• Using sed or SQL to swap URLs instead of wp search-replace.
• Replacing the guid column, and re-sending your archive to every RSS subscriber.
• Running rsync --delete against production without testing the exclude list.
• Leaving updates enabled in wp-admin, so the repo and the server drift apart silently.
• Disabling automatic updates without putting a review process in its place.
• Restoring production data onto staging with mail still enabled.
• Forgetting DISABLE_WP_CRON on staging, so scheduled jobs fire twice across two environments.
• Treating “the files copied” as proof the deploy worked, with no smoke test.

Best practices

• Make the repo the only way code reaches a server, and enforce it with DISALLOW_FILE_MODS.
• Keep code moving forward and content moving backward, and state that rule where the team can see it.
• Deploy staging from a branch and production from a tag, so production releases are deliberate.
• Dry-run every search-replace and every rsync the first time.
• Back up the target database immediately before any deploy that touches it.
• Script the staging restore end to end, including mail, cron, keys and anonymisation.
• Finish every deploy with a real HTTP request through the public URL, not a file listing.
• Use environment-aware code with wp_get_environment_type() instead of commented-out blocks.
• Keep uploads out of git and sync or offload them separately.
• Replace automatic updates with a scheduled dependency review, and put it in a calendar.

FAQ

Should WordPress core be in the repository?

Only if you are not managing it another way. Committing core works and makes the repo self-contained, at the cost of noisy diffs on every update. Declaring core as a Composer dependency is cleaner and gives you a pinned version without the noise. What you should not do is leave core unmanaged, so nobody can say which version production runs.

How do I handle the database in a Git workflow?

You do not put it in Git. Git handles code; the database is handled by scripted pulls in one direction. Production to staging to local, with a search-replace on import. The only time a database legitimately goes upward is the initial launch, before there is real content to lose.

What about plugin settings changed in staging?

This is the genuinely hard part and there is no clean answer. Settings live in the database, so they do not deploy. Options are: reapply them by hand in production with a documented checklist, script them as WP-CLI commands in a deploy step, or use a plugin that exports configuration to files. Whichever you pick, write it down, because “I’ll remember” is how a setting gets applied to staging and never production.

Is Bedrock necessary?

No. It is a well-made set of defaults for Composer-managed WordPress with environment-based configuration, and it saves assembling those pieces yourself. Plenty of teams run a perfectly disciplined Git deployment with a standard directory layout. Adopt it if you want the conventions; do not adopt it as a prerequisite.

Do I need three environments?

You need local and production. Staging earns its cost when you have multiple people, a client who signs off on changes, or a site where breakage costs money. On a personal blog it is overhead. On a store, skipping it means production is your test environment.

Can I do this on shared hosting?

Partly. You need SSH and ideally WP-CLI, and plenty of shared plans have neither. Some managed WordPress hosts offer a git push deployment target, which handles the file half for you. If you want the full workflow with your own build steps and post-deploy hooks, a small VPS from a provider like InterServer gives you the SSH access and cron control the workflow assumes.

How do I roll back a bad deploy?

Files are easy: redeploy the previous tag, or swap the symlink back if you use atomic releases. The database is the hard part, which is why you take a dump immediately before any deploy that runs a migration. Rolling files back without rolling the database back can leave you worse off than the broken version, so know which of the two actually changed before you act.

The one thing to remember

Git-based WordPress deployment is not really a pipeline problem. The pipeline is the easy part, and you can build a working one in an afternoon. The hard part is making the repo the only way code reaches a server, and then keeping the database flowing in exactly one direction.

Get those two right and everything else is detail. Get them wrong and you will keep having the same confusing morning, staring at a plugin version that nobody remembers changing.

Want this set up properly on your site?

Retrofitting version control onto a live WordPress site is fiddly work, mostly because you have to do it without downtime and without losing whatever has been changed directly on the server. Things I take on:

• Moving an existing production site into Git without downtime, including reconciling whatever has drifted on the server.
• Converting a site to Composer-managed plugins and core, with a working lockfile and a sane update process.
• Building local, staging and production environments that actually match, with per-environment configuration.
• Deploy pipelines in GitHub Actions or GitLab CI: build, rsync or atomic releases, post-deploy WP-CLI steps, smoke test, rollback path.
• Scripted database refreshes from production to staging with mail, cron, API keys and personal data handled automatically.
• Server setup for the workflow: SSH deploy users, correct file ownership, OPcache resets, cron.

Tell me how your site is hosted and how plugins currently get updated, and I will tell you what the first step should be.

The post Two Sources of Truth: Git-Based WordPress Deployment From Local to Production appeared first on John Nessime.

A successful WordPress migration is not just a matter of copying files from one server to another. It is a controlled infrastructure change involving the website files, database, domain records, SSL certificate, email configuration, caching layers, scheduled tasks, security settings, and third-party integrations.

When the process is planned correctly, visitors may never notice that the website has moved. When it is rushed, the result can include broken pages, missing images, database errors, lost form submissions, email disruption, redirect loops, certificate warnings, or several hours of downtime.

This guide explains how to migrate a WordPress website safely, how to reduce downtime, what can go wrong, and what should be verified before the old hosting environment is finally switched off.

What Is a WordPress Migration?

A WordPress migration is the process of moving a WordPress website from one environment to another. The destination might be a new hosting provider, a cloud server, a virtual private server, a staging environment, a new domain, or a different server configuration.

The website may look like a single application from the visitor’s perspective, but several separate components normally need to be transferred:

• WordPress core files
• Theme files
• Plugin files
• Uploaded media
• The MySQL or MariaDB database
• Configuration files
• Custom code and server rules
• DNS records
• SSL certificates
• Email-related DNS records
• Cron jobs and scheduled tasks
• CDN and caching configuration
• Analytics and tracking scripts
• External API integrations

A complete migration must preserve both the visible website and the underlying functionality. Copying the homepage successfully is not enough if contact forms stop sending, checkout sessions fail, redirects break, or administrators can no longer log in.

Common Reasons for Migrating a WordPress Website

Website owners migrate WordPress installations for many different reasons. In most cases, the decision is connected to performance, reliability, cost, control, or security.

Slow Hosting Performance

A website may outgrow its original shared hosting plan. Pages become slow, the WordPress dashboard takes longer to load, and traffic spikes begin causing resource-limit errors. Moving to a better-managed host, VPS, or cloud server can provide more CPU, memory, storage performance, and configuration flexibility.

Frequent Downtime

Unreliable infrastructure can damage customer trust and search visibility. If the current host experiences repeated outages or provides weak technical support, migration may be the most practical long-term solution.

Security Concerns

Outdated server software, poor account isolation, weak backup systems, or limited firewall controls can expose a WordPress website to unnecessary risk. A migration can be used as an opportunity to rebuild the site on a cleaner and more secure environment.

Hosting Cost Optimization

Some hosting plans become expensive as traffic grows, especially when backups, staging, CDN access, email, malware scanning, or additional storage are charged separately. Migrating to a more suitable platform can reduce costs without sacrificing performance.

Business Growth

A small brochure website may eventually become a membership platform, online store, booking portal, or content-heavy publication. The original environment may no longer support the website’s operational requirements.

Domain or Branding Changes

Some migrations involve changing the domain name as well as the server. This requires additional planning because internal URLs, redirects, analytics properties, search-engine records, cookies, and third-party callbacks may all depend on the original domain.

The Difference Between a Simple Migration and a Production Migration

A small personal blog with few updates can often be moved using a migration plugin. A production website requires more care.

Production websites may receive new orders, registrations, comments, bookings, support requests, or form submissions while the migration is taking place. If the database is copied too early and DNS is updated hours later, any data created during that gap may remain only on the old server.

That is why a production migration should be treated as a controlled cutover rather than a one-click file transfer. The objective is to minimize the period during which the old and new environments contain different information.

What Can Go Wrong During a WordPress Migration?

Most migration problems fall into a predictable set of categories. Knowing them in advance makes the process easier to plan and troubleshoot.

Database Connection Errors

The WordPress configuration file may contain the wrong database name, username, password, or database host. The user may also lack the necessary permissions on the destination database.

Broken Internal URLs

WordPress stores URLs in the database. If the domain, protocol, folder path, or staging address changes, old references can remain inside posts, menus, widgets, page-builder content, serialized options, and plugin settings.

Missing Images or Media Files

The uploads directory may be incomplete, excluded from the transfer, or copied with incorrect ownership and permissions. A site may appear functional while older images silently return 404 errors.

PHP Compatibility Problems

The destination server may use a newer PHP version than the original host. An outdated theme or plugin can then generate warnings, fatal errors, blank pages, or broken administrative screens.

Redirect Loops

Conflicting HTTPS, proxy, CDN, and WordPress redirect rules can cause the browser to repeatedly redirect between two versions of the same URL.

Email Delivery Failure

A migration may affect outgoing form emails, SMTP authentication, domain verification, or mailbox routing. DNS changes can also unintentionally overwrite MX, SPF, DKIM, or DMARC records.

SSL Certificate Warnings

The destination server may not yet have a valid certificate, or the certificate may not cover every hostname used by the website. Mixed-content warnings can also appear when pages load images, scripts, or stylesheets through HTTP.

Lost Transactions or Form Submissions

This is one of the most serious risks. If visitors continue using the old website after the final database backup, their activity may not exist on the new server.

Phase One: Audit the Existing Website

Before copying anything, document the current environment. A migration is much safer when the source system is fully understood.

The audit should include:

• Current WordPress version
• PHP version and PHP extensions
• Database engine and version
• Active theme and child theme
• Active and inactive plugins
• Disk usage
• Database size
• Upload directory size
• Web server type
• Caching configuration
• Scheduled cron tasks
• CDN or reverse proxy usage
• External SMTP provider
• Payment and booking integrations
• DNS provider
• SSL configuration
• Backup availability

This audit often reveals problems that already existed before the migration. For example, a plugin may be abandoned, the database may contain excessive transient records, or the site may still rely on an unsupported PHP version.

A migration should not automatically copy every old problem into the new environment. It is often the right time to clean up unused plugins, remove abandoned themes, review administrator accounts, and confirm that all essential components remain supported.

Phase Two: Prepare the Destination Server

The destination environment should be ready before the website is transferred. This reduces last-minute troubleshooting during the cutover.

The server preparation usually includes:

• Creating the hosting account or virtual host
• Installing the correct PHP version
• Enabling required PHP extensions
• Creating the database and database user
• Configuring file permissions
• Setting PHP memory and upload limits
• Configuring the web server
• Preparing SSL issuance
• Configuring backups
• Installing monitoring or logging tools
• Preparing caching and performance settings

The destination should ideally match the source environment closely during the first transfer. Major software upgrades can be performed later, after the website is stable. Combining a hosting migration, PHP upgrade, plugin cleanup, theme redesign, and domain change into one maintenance window increases the number of possible failure points.

Phase Three: Create Verified Backups

A migration should never begin without a complete backup. More importantly, the backup should be verified rather than merely assumed to be usable.

At minimum, create separate copies of:

• The entire WordPress file system
• The website database
• The WordPress configuration file
• Web server rules
• DNS records
• SSL-related information
• Custom cron jobs
• Email routing records

A backup is only valuable if it can be restored. Confirm that the archive opens correctly, the database export is not empty or truncated, and the files include the full uploads directory.

For business-critical websites, keeping more than one backup copy is sensible. One copy may remain on the source server, while another is stored externally.

Phase Four: Copy the WordPress Files

The files can be transferred using several methods, including a migration plugin, hosting control panel, SFTP, SCP, rsync, or a compressed archive.

For small websites, a plugin may be sufficient. Larger websites often benefit from server-level transfer tools because they handle large file sets more efficiently and provide better visibility into transfer errors.

During the transfer, confirm that hidden files are included. Files such as .htaccess may contain essential rewrite, security, redirect, or caching rules.

After copying, verify ownership and permissions. Incorrect permissions can prevent uploads, plugin updates, cache creation, or WordPress core operations.

Phase Five: Export and Import the Database

The database contains the website’s posts, pages, users, settings, menus, plugin data, WooCommerce orders, form entries, and most application-level configuration.

It can be exported using tools such as phpMyAdmin, WP-CLI, a migration plugin, or the database command line. Large databases are generally more reliable to move through command-line tools because browser-based imports may fail due to upload or execution limits.

Once imported, update the destination wp-config.php file with the correct database details:

define('DB_NAME', 'destination_database');
define('DB_USER', 'destination_user');
define('DB_PASSWORD', 'strong_password');
define('DB_HOST', 'localhost');

The exact database host depends on the hosting environment. Some providers use a remote database hostname instead of localhost.

Phase Six: Handle URL Changes Correctly

If the website keeps the same domain, fewer URL changes may be required. However, staging URLs, temporary hostnames, HTTP-to-HTTPS changes, subdirectory changes, or domain changes require a controlled search-and-replace operation.

A plain text replacement inside a database export can damage serialized WordPress data. WordPress plugins and page builders often store structured values where string lengths matter.

Use a WordPress-aware tool such as WP-CLI:

wp search-replace 'https://old-domain.example' 'https://new-domain.example' --all-tables --precise --dry-run

The dry run displays the expected replacements without modifying the database. Once reviewed, the operation can be repeated without the --dry-run flag.

After the replacement, check:

• Page and post links
• Navigation menus
• Image URLs
• Page-builder templates
• Widgets
• Logo and favicon paths
• Canonical tags
• Open Graph images
• Plugin callback URLs
• Webhook endpoints

Phase Seven: Test the Website Before Changing DNS

The destination website should be tested before public traffic is sent to it. This is one of the most important steps in a low-downtime migration.

A local hosts-file override can map the production domain to the new server only on your own computer. This allows the website to be tested under its real domain while the rest of the internet continues reaching the old server.

Testing should cover more than the homepage.

Front-End Testing

• Homepage
• Posts and pages
• Category and archive pages
• Search functionality
• Navigation menus
• Images and downloads
• Responsive layout
• 404 page
• Redirects

Administrative Testing

• WordPress login
• Post editing
• Media uploads
• Plugin settings
• Theme customization
• User management
• Scheduled tasks

Business Function Testing

• Contact forms
• Newsletter subscriptions
• Account registration
• Password reset emails
• Checkout and payment flow
• Booking forms
• Customer dashboards
• API integrations
• Webhook delivery

Check the browser console, server logs, WordPress debug logs, and network requests. A page can appear normal while scripts, API calls, or background processes are failing silently.

How to Reduce WordPress Migration Downtime

Zero downtime is difficult to guarantee for every website, but downtime can often be reduced to a very small window.

Lower the DNS TTL in Advance

DNS Time to Live determines how long resolvers may cache a record. Lowering the TTL before migration can help changes propagate more quickly.

This should be done before the migration window, not at the exact moment of cutover. Existing cached records will continue using the previous TTL until they expire.

Perform an Initial Copy Before Cutover

Copy the website files and database to the destination in advance. This gives enough time to test the environment and resolve compatibility problems before the final switch.

Freeze Content Changes Briefly

For dynamic websites, a short maintenance or content-freeze window may be necessary. During this period, editors should stop publishing and customers may need to be temporarily prevented from submitting transactions.

Perform a Final Database Synchronization

After the initial copy and testing, export the latest database immediately before the DNS or proxy cutover. This minimizes the chance of losing recent activity.

Keep the Old Server Available

Do not cancel the original hosting account as soon as DNS is changed. Some visitors may still reach the old server due to DNS caching. The source environment should remain available until propagation is complete and the new website has been monitored.

DNS Migration: More Than Changing One Record

DNS errors are responsible for many migration failures. A domain may have records for the website, email, verification services, subdomains, APIs, and third-party platforms.

Before making changes, export or document the complete DNS zone. Important records may include:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF records
• DKIM records
• DMARC records
• Domain verification records
• Service-specific subdomains

If only the web server is changing, there may be no reason to modify email records. Accidentally replacing the entire DNS zone with a simplified version can interrupt business email even when the website itself works correctly.

SSL and HTTPS After Migration

The destination server must have a valid SSL certificate for the production domain. The certificate should cover all required hostnames, such as the root domain and the www version.

After enabling HTTPS, verify that:

• The certificate is valid and not expired
• The certificate matches the domain
• HTTP redirects to HTTPS correctly
• The root and www versions behave consistently
• No redirect loop exists
• Images and scripts load through HTTPS
• CDN resources use secure URLs

Mixed-content errors should be corrected rather than hidden. They usually indicate that some database values, theme settings, CSS files, or external resources still reference HTTP URLs.

Email and Contact Form Verification

A website migration is not complete until email functionality is tested.

WordPress may rely on the local server mail function, SMTP authentication, a transactional email provider, or an external mailbox service. Each method has different requirements.

Test at least the following:

• Contact form delivery
• Administrator notifications
• Password reset emails
• WooCommerce order emails
• Registration emails
• Newsletter confirmation messages
• SMTP authentication

Also confirm that SPF, DKIM, and DMARC records remain valid. Successful message submission does not always mean successful inbox delivery.

Migrating a WooCommerce Website

WooCommerce migrations require additional care because the database may change continuously. Orders, inventory, customer records, carts, subscriptions, refunds, and payment events can be created during the migration window.

A WooCommerce migration plan should include:

• A clearly defined cutover time
• A short checkout freeze if required
• A final database synchronization
• Payment gateway testing
• Webhook testing
• Order email verification
• Inventory validation
• Subscription and scheduled-payment checks
• Customer login testing
• Transaction log review

For high-traffic stores, a simple export-and-import workflow may not be sufficient. More advanced database synchronization or application-level migration techniques may be needed.

Migrating WordPress to a New Domain

Changing the domain adds an SEO and application layer to the migration.

In addition to moving the website, the process should include:

• Updating WordPress URLs
• Replacing old domain references
• Creating page-to-page 301 redirects
• Updating canonical URLs
• Updating XML sitemaps
• Updating analytics properties
• Updating Search Console records
• Updating social profiles
• Updating payment callbacks
• Updating API allowlists
• Updating email addresses where required

A blanket redirect from every old URL to the new homepage is not a good migration strategy. Each important old URL should redirect to its closest equivalent on the new domain.

Protecting SEO During WordPress Migration

A hosting migration that keeps the same domain should normally have limited SEO impact when implemented correctly. A domain change or large structural change requires more planning.

Important SEO checks include:

• Preserving existing URL structures
• Maintaining page titles and metadata
• Keeping canonical tags correct
• Preserving structured data
• Checking robots.txt
• Checking XML sitemaps
• Verifying redirects
• Removing accidental noindex directives
• Checking HTTP status codes
• Monitoring crawl errors
• Monitoring organic traffic after launch

Staging environments are often configured with noindex rules to prevent search engines from indexing them. That setting must not be carried into production accidentally.

It is also important to remove temporary password protection, development redirects, and staging-specific canonical URLs before launch.

Performance Optimization After Migration

A migration provides a good opportunity to improve performance, but optimization should be performed methodically.

Start by confirming that the website is stable. Then review:

• Page caching
• Object caching
• PHP OPcache
• Database performance
• Image compression
• WebP or AVIF delivery
• CDN integration
• Browser caching
• Gzip or Brotli compression
• Slow plugins
• Unused scripts and styles
• External API delays

Do not enable several caching systems at the same time without understanding how they interact. Duplicate caching layers can create stale pages, login problems, checkout issues, and difficult-to-diagnose behavior.

Security Checks After Migration

The new environment should be reviewed before the migration is considered complete.

Post-migration security checks should include:

• Removing temporary migration files
• Removing exported database archives
• Deleting unused administrator accounts
• Changing temporary credentials
• Confirming file ownership and permissions
• Disabling directory listing
• Reviewing firewall rules
• Enabling brute-force protection
• Updating WordPress, themes, and plugins
• Reviewing backup access
• Protecting configuration files
• Confirming malware scanning

Database exports and full-site archives often contain sensitive information. They should not remain publicly accessible inside the website directory after migration.

WordPress Migration Plugins vs Manual Migration

Both methods are valid. The right choice depends on the website.

Migration Plugins

Migration plugins are convenient for small and medium-sized websites. They can package files and databases, update URLs, and simplify restoration.

However, they may encounter:

• File size limits
• PHP execution time limits
• Memory limits
• Hosting restrictions
• Archive extraction failures
• Large database timeouts
• Limited visibility into errors

Manual or Server-Level Migration

Manual migration provides more control and is often more reliable for large, customized, or business-critical websites.

It also allows the migration specialist to inspect logs, control database operations, preserve permissions, perform incremental transfers, and troubleshoot individual layers separately.

The tradeoff is that server-level migration requires stronger knowledge of Linux, databases, DNS, web servers, PHP, SSL, and WordPress internals.

A Practical WordPress Migration Checklist

Before Migration

• Audit the current website
• Record PHP and database versions
• List active integrations
• Export DNS records
• Lower DNS TTL if needed
• Create and verify backups
• Prepare the destination server
• Install required PHP extensions
• Create the destination database
• Plan the maintenance window

During Migration

• Copy WordPress files
• Export and import the database
• Update wp-config.php
• Perform safe URL replacement
• Verify permissions
• Test using a hosts-file override
• Check logs and browser errors
• Test forms, logins, and transactions
• Perform the final database sync
• Update DNS

After Migration

• Verify SSL
• Test email delivery
• Check redirects
• Check sitemap and robots.txt
• Clear all cache layers
• Review application logs
• Monitor uptime
• Monitor search and analytics data
• Keep the old server available temporarily
• Remove migration archives
• Confirm backup schedules

When Should You Hire a WordPress Migration Specialist?

A simple personal website may be moved successfully with a migration plugin. Professional assistance becomes more valuable when the website has operational or commercial importance.

Consider hiring a specialist when:

• The website generates sales or leads
• Downtime has a direct business cost
• The database changes frequently
• The site uses WooCommerce or memberships
• The migration includes a domain change
• Email services share the same DNS zone
• The site contains custom plugins or code
• The destination server requires manual configuration
• The site has a large media library or database
• You need SSL, DNS, redirects, and testing handled together

A professional migration should provide more than a copied website. It should include preparation, backups, testing, DNS coordination, SSL validation, post-migration verification, and a rollback plan.

Final Thoughts

WordPress migration is a technical process, but the real objective is business continuity. Visitors should continue reaching the website, customers should continue completing transactions, administrators should retain access, and search engines should continue finding the same content.

The safest migrations are rarely the fastest-looking ones. They are the migrations where the destination is prepared in advance, backups are verified, the website is tested before cutover, DNS is handled carefully, and the old environment remains available until the transition is confirmed.

Whether the website is moving to a new hosting company, a VPS, a cloud server, or a new domain, a structured migration plan dramatically reduces the risk of downtime, missing data, and unexpected failures.

The post WordPress Migration Without Downtime: A Practical Guide to Moving Your Website Safely appeared first on John Nessime.