WordPress Domain Rename 500 error Blues — and What Actually Fixed It

Recently, I decided to rename the primary domain of my WordPress multisite setup hosted on a server managed with Hestia Control Panel. The original domain was something like dev.example.com, and I wanted to upgrade it to example.com — the production version. Simple idea, right? Rename the domain, issue a new SSL cert, and we’re golden. What could go wrong?

Spoiler: a whole lot. But the fix turned out to be something wonderfully specific.

The Starting Point

I used Hestia’s CLI tool to rename the primary web domain from dev.example.com to example.com:

[bash] sudo /usr/local/hestia/bin/v-change-web-domain-name [username] dev.example.com example.com

This changed the directory structure and Hestia’s internal config. It even automatically made the old domain an alias, which seemed convenient. I regenerated the SSL certificate and figured I was done.

But when I visited the site? 500 Internal Server Error. Not just for WordPress — even simple test.php files died, while test.html worked fine.

The Investigative Spiral

Here’s what I ruled out:

• WordPress siteurl and home entries were correct in the database
• The multisite DOMAIN_CURRENT_SITE constant in wp-config.php was correct
• .htaccess was restored and working
• Tried switching PHP versions (8.3 ↔ 8.1) — still 500
• Other sites on the same server were running fine with PHP
• Creating a basic phpinfo() page still threw a 500

Something was clearly wrong with PHP execution for that specific domain.

Missing PHP-FPM Config

Eventually, I checked:

/etc/php/8.3/fpm/pool.d/

…and found there was no pool config file for example.com. That explained why PHP was crashing — there was no instruction for how to handle the domain. I ran:

sudo /usr/local/hestia/bin/v-rebuild-web-domain [username] example.com

Which created a config file… but it was completely blank.

That led to another trail of debugging: missing templates, restart failures, bad Hestia metadata, even wondering if I should just delete the domain and start over.

The Real Culprit: .user.ini

Right as I was about to start from scratch, I checked a seemingly unrelated file in the site’s root:

auto_prepend_file = '/home/[username]/web/dev.example.com/public_html/wordfence-waf.php'

It was from Wordfence, a security plugin. That path was hardcoded to the old domain folder, which no longer existed. PHP was trying to load that file for every request before anything else — and since the path didn’t resolve, it threw a fatal error instantly.

The Fix

I updated .user.ini to point to the new correct path:

auto_prepend_file = '/home/[username]/web/example.com/public_html/wordfence-waf.php'

Then restarted PHP-FPM:

sudo systemctl restart php8.3-fpm

Like magic — the site came back. No 500 error. No broken PHP. No need to nuke the setup after all.

Lessons Learned

• Plugins like Wordfence often write to .user.ini, and those paths do not update automatically during a domain rename.
• PHP’s auto_prepend_file fires before WordPress even loads — and a broken path will kill PHP silently.
• A 500 on test.php but not on .html almost always means a low-level PHP execution problem — not a WordPress issue.
• If you rename a domain in Hestia and PHP stops working, check:
  • PHP-FPM pool config (/etc/php/X.X/fpm/pool.d/)
  • .user.ini for hardcoded paths
  • Plugin configs and security hooks

If this post saves even one future developer from tearing their hair out like I did — totally worth it. Shout out to my AI debugging partner for walking this one through with me.