How to Test a PHP Update on a WordPress Staging Site

Key takeaways

• A staging site is a private copy of your website. You change PHP there first, so a mistake never reaches your visitors.
• Most owners can get one in minutes. Many hosts have a button for it, a plugin can make a copy, or a developer can copy the files and database by hand.
• Test the pages that make money. Home page, forms, login, checkout, the admin area, and then the error log.
• Staging cannot prove everything. Live data, real payments and real email behave differently on a copy, so a short check on the live site is still needed.
• Going live carries a risk of its own. Pushing a staging database over a live one can wipe orders and comments made in the meantime.
• The reason to hurry. Two critical PHP flaws were fixed on 21 October 2026, and our main PHP vulnerability guide explains why moving to a fixed release matters.

What a staging site is, in plain words

Think of staging as a dress rehearsal. It is a separate copy of your WordPress site, with its own files and its own database, that sits away from the public one. You can update plugins, switch PHP and break things there, and your real customers see nothing.

Kinsta's documentation describes staging as a separate copy of a WordPress install used to test new WordPress versions, plugins and code without touching the live site (checked 22 October 2026). Many hosts offer something similar, so search yours for "staging".

WordPress.org's own PHP guide, checked on 22 October 2026, tells owners to make a full backup before updating and to check that themes and plugins work on the new version. It does not talk about staging. Staging is our advice on top of that.

Three ways to get a staging site

If your host has a staging button

This is the easiest route. As one example, Kinsta says you pick the site, use the environment selector, create a new environment and clone the live one, which takes a few minutes (checked 22 October 2026). Your host's steps will differ.

Plugin or manual copy

A well known staging or migration plugin can copy a site to a test address. Pick one that is actively maintained and read its reviews on WordPress.org. A manual copy means copying files, copying the database and giving the copy its own web address. If that sounds like a lot, ask a developer, because a wrong address can mix up test and live visitors.

Before you touch PHP on staging

1. Make a full backup of the live site. WordPress.org says a backup lets you revert if something breaks, and that reverting also needs your host to switch PHP back to the old version.
2. Check that the copy hides itself from Google. Kinsta says indexing is off on its staging by default. If your tool does not do that, ask your host or developer to set it up.
3. Update WordPress, theme and plugins on the copy first. Our PHP update guide lists what to update.
4. Write down the current PHP version. Our guide to checking your PHP version shows where to look.

Switching the copy to PHP 8.3

WordPress.org currently recommends PHP 8.3 or higher (checked 22 October 2026). The PHP project's advisory of 21 October 2026 lists fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and says PHP 8.1 and older get no official fix. If your host lets you set PHP per environment, change it on staging and leave live alone. Whether your host keeps the PHP setting separate for each copy is something to ask them. Our list of host questions helps with that, and the WordPress PHP requirements post explains what WordPress itself needs.

Turn on the error log

WordPress developer documentation, checked 22 October 2026, explains three settings in the wp-config.php file:

• WP_DEBUG switches on debug mode, which shows PHP errors, warnings, notices and deprecation notices. It is off by default.
• WP_DEBUG_LOG writes those messages to a file. Set to true, it creates debug.log in the wp-content folder. It only works when WP_DEBUG is on.
• WP_DEBUG_DISPLAY decides whether errors show on the page. Setting it to false hides them from visitors, so you can log quietly.

The same page says it is not recommended to use these debug tools on live sites. They are meant for local testing and staging. That is one more good reason to do this work on a copy.

What to click through after the switch

Use this as a checklist. Tick each line, and write down anything odd, even small things.

How to read the error log

Open the file and look at the newest lines. Each usually names a plugin or theme folder. A fatal error means something stopped, so fix it before going live. A warning needs a look at the plugin it names. A deprecated notice means the code still runs but will fail in a later PHP release, so note it and ask the plugin author.

If you run a shop, read our post on WooCommerce and the PHP flaw before you test checkout.

What staging cannot prove

A copy is a very good test, but not a perfect one. Be honest with yourself about four gaps.

1. Live data. Your real database holds orders, members and comments that the copy may not have. A bug that only shows with a certain order or user can slip past you.
2. Payments. Test mode proves your checkout runs. It does not prove your real payment provider is happy with the live site. Kinsta's page does not cover payment gateways at all, so ask your own provider how its test mode works.
3. Email. Kinsta warns that staging sends transactional email by default, so a test order can email real customers. Use a plugin to turn that off, or test with an address you own. And because staging often uses different mail settings, a working test email does not prove live email is fine.
4. Server load and caching. Kinsta says standard staging has less power than live and caching is off by default, so speed tests on staging will look different.

So plan one short check on the live site right after the real switch. It takes ten minutes and covers these gaps.

How to move the change to live

Here the choices are simple, but the order matters.

1. Take a fresh backup of the live site. Do this right before the change.
2. Pick a quiet time. Late evening or early morning for your visitors.
3. Change the PHP version on live. PHP is a server setting, so this is done in your host's panel or by the host, not inside WordPress. If you made plugin or theme updates on staging, repeat those updates on live, or push only the files.
4. Be careful with the database. Kinsta's page says pushing a staging database overwrites live data created since the copy was made, such as comments, orders and sign-ups. If your site takes orders or form entries, do not push the database. Repeat the plugin updates on live instead.
5. Run the checklist again on live. Use the table above, shorter.
6. Check Site Health. Tools, then Site Health, then Info, then Server, shows the PHP version you are really running.
7. Watch for a day. Keep the old PHP version noted in case of a roll back.

What is still unclear, and when this advice does not apply

• Staging features vary by host. We read Kinsta's page as an example. Your host may name things differently, limit the number of copies or charge for premium staging. Check your own plan.
• We could not read every host's documentation. Where we describe a host feature, treat it as an example, not a rule.
• The PHP setting may not travel with a push. Whether a host carries the PHP version when you push staging to live differs by host. Ask before you rely on it.
• Sites that cannot wait. If your PHP is below the fixed releases and a test copy will take days, weigh a fast, careful live update with a backup against waiting. Our main guide covers the trade off.

How we help at Amariq

A staging copy is the safest place to find a problem, and setting one up properly is a good use of an expert's hour. Within a day of the advisory our team had already put some WordPress sites through exactly this kind of test and then switched the live PHP version. The WordPress PHP update gig on Fiverr has an extra for staging tests, so you can ask for it when you order. For wider help with the site, see our WordPress development service. Public reviews on Fiverr and Upwork, plus the videos on our YouTube channel, let you check us out yourself.

Frequently asked questions

What is a staging site in WordPress?

It is a private copy of your website with its own files and database. You try changes there, such as a new PHP version, and only copy them to the live site once everything works.

Do I really need staging to update PHP?

No, but it lowers the risk. WordPress.org asks for a full backup and compatibility checks. A staging copy lets you find broken plugins before visitors do. On a very small site, a backup and a careful live check can be enough.

Is staging free?

It depends on your host. Kinsta's page describes standard staging as free and a premium type as a paid subscription. Other hosts include it only in higher plans.

Will my staging site show up in Google?

It should not. Kinsta says indexing is off on its staging by default, using a WordPress setting and a header. If you use a plugin or copy by hand, check that the copy is hidden from search engines.

Can I push the whole staging site to live?

You can, but you may lose live data. Kinsta warns that pushing the database overwrites orders, comments and sign-ups made since the copy. A files-only push leaves the live database alone, though settings saved in the dashboard live in the database.

What if staging works but live breaks?

Restore the backup you took before the change. WordPress.org says to ask your host to put the old PHP version back first, then restore the backup. Then compare the live setup with staging, for example caching, plugins and server settings.