The arrival of WordPress 7.1 RC1 creates an option to evaluate the next version. It does not create a reason to update a live business website.
In its official notice of 5 August 2026, WordPress says RC1 remains under development. It also says not to install, run or test the release on production or mission-critical websites, and directs testing to a test server and site.
For an owner or operational lead, that guidance resolves the immediate decision. Keep RC1 away from the live service. Any evaluation should be separately authorised, isolated and tied to a useful question about the site.
Availability is not approval
Release candidates are made available so that the next version can be examined before its stable release. That purpose can easily be misunderstood inside a business. Someone sees a new version, assumes it is almost finished and treats it as the next routine update.
The important distinction is not how close the version may appear to release. It is whether the version has a place in the environment under consideration. RC1 can have a legitimate place in a controlled test environment. It has no place on the production website that receives enquiries, supports bookings, provides customer access or underpins a daily workflow.
This gives decision-makers two separate approval questions:
- Is there a good reason to evaluate RC1 on an isolated copy?
- At some later point, is a stable release ready for this specific live site?
Answering yes to the first question says nothing about the second.
Testing is optional, even when staging exists
Having a staging site does not mean every preview release needs to be installed on it. Early testing takes time, creates results that need interpretation and may require the environment to be refreshed afterwards.
A business may have a sound reason to test when its website contains bespoke functionality or operational dependencies that deserve advance attention. Custom blocks, unusual publishing workflows, important forms and connections to external systems are examples. The purpose might be to identify areas that will need another look when the stable version becomes available.
A straightforward company site may gain little from that exercise. Waiting is a valid operational choice. The official notice makes testing possible in the right place; it does not make testing compulsory.
Isolation means protecting real operations
A useful test environment needs more than a different URL. It must prevent the test from reaching customers or changing live business data.
Forms and email delivery need to be contained. Connections to a live CRM, booking platform or other external service need suitable test settings or controls. Scheduled tasks should not trigger production actions. Search engines should not be offered a public duplicate of the website.
The test environment also needs enough fidelity to answer the intended question. The relevant theme, plugins, PHP version, configuration and integrations should reflect the live setup. Otherwise, a successful test may prove only that RC1 runs on a generic WordPress installation, not that the organisation’s own operating paths behave as expected.
Isolation and realism pull in different directions, so both need deliberate ownership. The environment should resemble production where that improves the test, while remaining unable to affect production.
Test the path, not just the page
Before RC1 is installed, write down the small number of outcomes that matter. For a service business, these might include receiving a complete enquiry, confirming an appointment, signing into a protected area or publishing an urgent content change.
Then run each path from beginning to end. Submitting a form is not enough if nobody checks whether the message arrives. Opening the editor is not enough if the normal review and publishing steps are omitted. A connected system has not been tested merely because the page containing its form still loads.
Record what was done and what was observed. A useful note identifies the function, the action, the expected result and any difference seen during the check. There is no need to turn an optional evaluation into an exhaustive audit of every page.
The result is advance information, not production clearance. It may identify something to revisit, or it may show no relevant difference within the chosen scope. Neither outcome establishes how a later stable release will behave on the final production configuration.
Give the live decision its own gate
Production approval belongs to a later process. It starts only once a stable version exists, and it depends on checks against the website the business actually operates.
That gate should have a named owner. The person carrying out the technical work can report what was tested, but someone with responsibility for the website’s business role must be able to see the boundary: preview evaluation was authorised; live deployment was not.
A concise release policy helps make that visible:
- Development builds, betas and release candidates stay off production.
- Preview testing requires a defined reason for the particular website.
- The test environment must be isolated from real customers, data and workflows.
- A stable release receives a fresh, site-specific production decision.
For WordPress 7.1 RC1, there is no need to speculate about defects, performance or a future release date. The official environment restriction is enough. Evaluate it only where testing belongs, and reserve production approval for a stable release and the real website that will depend on it.