WordPress 7.1 is out. Is your site being maintained?

Two major versions in three months

WordPress did not stand still in 2026.

On 20 May 2026, WordPress 7.0 "Armstrong" was released, named after Louis Armstrong. It introduced, among other changes, a modernized administration experience and a clearer foundation for AI integrations through an AI Client in WordPress Core, the Abilities API, and client-side capabilities.

On 19 August 2026, WordPress 7.1 "Mary Lou" followed, named after pioneering jazz pianist, arranger, and composer Mary Lou Williams.

Version 7.1 develops several parts of the everyday workflow:

• the admin bar follows users throughout the administration experience
• blocks gain more direct control over responsive styles
• media editing moves into a clearer workflow for cropping, rotating, flipping, and managing metadata
• Notes can be placed more flexibly within content, with rich text and mentions
• new Playlist and Tabs blocks expand what can be built without additional plugins
• developers gain an API for registering custom icons for the Icon block

Those are concrete improvements for developers and editors. For a business owner, the main message is simpler:

The platform your website runs on continues to evolve. Your website therefore needs continuous management too.

This is about maintenance, not feature chasing

Most businesses do not need to adopt every new feature on release day.

They need a website that:

• remains secure
• works with the current server environment
• uses compatible themes and plugins
• behaves correctly on mobile and desktop
• can be updated without panic
• has a working backup if something goes wrong

WordPress still fits many marketing sites, publishing systems, membership platforms, and online stores. That depends on maintenance being treated as normal operations, not a task deferred until something breaks.

I work on WordPress websites regularly and often see the same difference after major releases.

Teams with a maintenance routine can test and introduce changes under controlled conditions. Teams that postpone updates for long periods are more likely to face a separate catch-up project in which WordPress Core, PHP, the theme, plugins, and hosting all need attention at once.

What could have remained routine becomes recovery work.

Staying current does not always mean installing on day one

It is important to distinguish between different types of updates.

Security updates should normally be assessed and installed quickly. Known vulnerabilities are often scanned for automatically, and a small website is not invisible simply because it receives little traffic.

Maintenance releases typically contain bug fixes and should form part of a regular update routine.

Major versions, such as 7.0 and 7.1, can include broader changes to the editor, APIs, and administration environment. They should be tested against the site’s theme, plugins, server environment, and critical functionality before the production update.

The objective is not to be first. It is to remain close enough to current releases that upgrading stays manageable.

A site that deliberately remains one tested version behind for a few weeks is not necessarily poorly maintained. A site that has fallen several years behind without anyone knowing why is a different situation.

"We will update later" has a cost

When I review older WordPress installations, I often find the same combination of warning signs:

• WordPress Core is several versions behind
• the PHP version is old or approaching the end of support
• the site has many plugins, but nobody knows which ones are still required
• some extensions have been abandoned or removed from distribution
• the theme has not been reviewed since launch
• a backup exists, but nobody has tested whether it can be restored
• there is no staging environment, or staging differs significantly from production
• hosting that was sufficient years ago has never been reassessed
• forms and analytics have not been tested recently

The public website may still look normal. Pages open, the form appears to work, and nothing feels urgent.

Then a required PHP upgrade, an unsupported plugin, a security issue, or a bug in a critical user journey forces action. Several years of technical debt suddenly need to be resolved under pressure.

For the business, that can mean:

• downtime
• lost inquiries or orders
• broken tracking
• expensive cleanup
• delayed marketing work
• dependence on the one person who understands the old setup
• a rebuild earlier than planned

A structured WordPress health check can identify many of these issues while there is still time to prioritize them sensibly.

Security updates protect business continuity

WordPress security is not only about WordPress Core.

A typical website also includes:

• a theme
• plugins
• hosting and server software
• PHP and a database
• administrator accounts
• third-party integrations
• forms and email delivery
• backups and recovery

An up-to-date WordPress installation does not help enough if an abandoned plugin contains a known vulnerability. Similarly, installing a security plugin does not solve every problem if administrator passwords are shared, old accounts remain active, or nobody tests the backups.

A compromise is rarely "just an IT problem." It can cause:

• the website to go offline
• visitors to be redirected to fraudulent pages
• form information to be exposed
• damage to domain or email reputation
• paid ads to send traffic to a broken website
• urgent cleanup and recovery costs

Maintenance does not remove every risk. It reduces avoidable risk and improves your ability to respond when something happens.

Plugins: WordPress capability and maintenance risk

Plugins are one reason WordPress suits so many different projects. They add forms, SEO tools, multilingual content, e-commerce, caching, memberships, and integrations without requiring everything to be developed from scratch.

Every plugin also adds:

• code that must run
• another update stream
• possible conflicts with the theme or other plugins
• an external provider you depend on
• more settings somebody needs to understand
• potential security and privacy implications

During reviews, I have found several extensions solving overlapping problems. Each one looked reasonable in isolation. Together, they produced a system nobody wanted to change.

Before chasing new WordPress 7.1 features, map what the website actually needs:

1. Remove inactive plugins that will not be used again.
2. Identify active plugins that no longer serve a clear purpose.
3. Look for overlapping solutions.
4. Check when each extension was last updated.
5. Assess whether the provider actively supports current WordPress and PHP versions.
6. Test before replacing or removing anything in production.
7. Document which plugins are business-critical.

Fewer dependencies are not automatically better if important functionality then needs to be developed and maintained internally. The goal is not the lowest possible count. It is a controlled set of necessary, actively maintained dependencies.

The upgrade alone will not fix performance

WordPress 7.0 and 7.1 improve parts of the platform and editing workflow. That does not mean a Core update will automatically make a slow site fast.

WordPress Core cannot fix, by itself:

• oversized hero images
• video loaded before it is needed
• more analytics and advertising scripts than the business uses
• heavy page-builder configurations
• uncontrolled font and stylesheet loading
• weak hosting
• API requests that block the page
• several years of layered temporary fixes

I have seen meaningful performance gains on marketing sites after work on images, scripts, caching, and resource loading. The value came from finding the actual bottlenecks, not from installing a new major version and hoping for an automatic improvement.

If performance has never been assessed properly, begin with a website performance review covering the most important templates and user journeys.

Visitors do not say the site has an LCP or INP problem. They experience it as slow, unstable, or awkward to use.

How I would plan the upgrade to 7.1

A major WordPress upgrade should be treated as a small technical release, not a casual click between unrelated tasks.

1. Document the starting point

Record:

• the current WordPress version
• PHP and database versions
• the active theme and any child theme
• active and inactive plugins
• custom code
• the hosting environment
• critical integrations
• the latest working backup

If the site is far behind, the WordPress version may not be the largest challenge. PHP, the theme, and plugins can present greater risks.

2. Create a complete backup

The backup should include both files and database. Confirm where it is stored, how long it is retained, and how it is restored.

A backup that has never been tested is a hope, not a documented recovery plan.

3. Create a representative staging environment

Staging should resemble production in terms of:

• PHP version
• active plugins
• theme and custom code
• important configuration
• enough realistic content to test the templates

At the same time, ensure staging does not send real customer messages, become indexed by search engines, or accidentally trigger production integrations.

4. Check compatibility

Look for:

• documented support for WordPress 7.1
• newer versions of themes and plugins
• abandoned extensions
• known issues reported by providers
• outdated custom code
• dependencies that require a different PHP version

A "Compatible up to" label is useful but not a guarantee. The real test is your site with your data and workflows.

5. Update and test on staging

Test more than the homepage.

Review:

• contact forms and email delivery
• login and administration
• search
• menus and mobile navigation
• important page templates
• multilingual content
• payments and checkout
• memberships or user accounts
• cookies and consent
• analytics and events
• caching
• scheduled jobs and integrations

Also check the browser console, PHP logs, and server logs for errors.

6. Compare performance and presentation

Measure a few representative pages before and after the upgrade. Check mobile and desktop.

Look for:

• changes in load time
• new JavaScript errors
• layout shifts
• missing styles
• editor problems
• changed caching behavior
• differences between logged-in and logged-out users

The objective is not for every metric to improve after a Core upgrade. It is to find regressions before users do.

7. Plan the production update

Choose a time with:

• lower traffic
• somebody available to check the site afterward
• a clear rollback plan
• no major campaign or content launch happening simultaneously
• enough time to respond if something fails

Friday afternoon without anyone available for follow-up is rarely a good choice.

8. Monitor after deployment

Check the website immediately after updating and again after background jobs, caches, and real traffic have had time to act.

Pay particular attention to:

• forms and email
• payments or bookings
• error logs
• traffic and conversion events
• server load
• scheduled processes
• editorial workflows

A successful deployment does not only mean the homepage opens. It means the critical functions still do their jobs.

What if the site is several years behind?

There is no single correct upgrade method for every old WordPress installation.

WordPress Core can often be upgraded directly across several versions. That does not mean the site’s entire ecosystem can tolerate a large jump without preparation. The risk frequently lies in old PHP, outdated plugins, an abandoned theme, or custom code, not only WordPress Core.

I would not automatically install every intermediate Core version one by one in production. I would first:

1. clone the website to staging
2. document the current environment
3. update or replace critical dependencies
4. test the target version
5. investigate errors and compatibility
6. decide whether upgrading or rebuilding is the more responsible option

Some old sites can be brought current through controlled cleanup. Others have accumulated enough technical debt that another round of temporary repairs will cost more than a planned rebuild.

That decision should follow a technical assessment, not the version number alone.

What 7.0 and 7.1 mean in practice

WordPress 7.0 established a clearer foundation for AI integrations in Core. That does not mean every website should immediately connect to a model or automate content production.

Before using such functionality, a business should clarify:

• which provider will receive data
• which data may be included in requests
• who reviews and approves the output
• what costs the integration creates
• how incorrect or unsuitable content will be handled
• whether the function solves a real problem

WordPress 7.1 provides more immediate improvements to administration, responsive styles, media work, and collaboration. Some teams will benefit directly. Others will notice very little on the public website.

That is fine.

The business value of an upgrade is not that every new feature gets used. It is that the platform remains supported, manageable, and ready for future development.

Build a maintenance cadence, not an annual rescue project

A realistic maintenance routine can include:

• regular checks for available updates
• prompt assessment of security releases
• scheduled testing of major WordPress versions
• automated backups with periodic restoration tests
• regular review of users and administrator permissions
• testing of forms, email, and payments
• monthly or quarterly performance checks
• cleanup of plugins, content, and old integrations
• documentation of significant changes

The right frequency depends on the risk.

A simple brochure website and an online store processing daily transactions do not need identical procedures. A site responsible for a substantial share of revenue should not be maintained like an ownerless digital leaflet.

The line I would remember

Your website is infrastructure. Infrastructure that is updated, backed up, and tested deliberately is safer and usually cheaper to own than infrastructure rescued after a crisis.

WordPress 7.1 is the current major release as of August 2026. It is not a finish line, but another reminder to assess where your website stands.

You do not need to activate every feature or upgrade without testing. You need a known version, controlled dependencies, working backups, and a plan for the next update.

Not sure whether your site is ready for the next upgrade?

I have seen businesses spend more repairing problems that could have been identified early than planned maintenance would have cost.

A focused review can surface outdated plugins, compatibility problems, performance bottlenecks, security risks, and weaknesses in backup or upgrade procedures before the situation becomes urgent.

Request a website audit and get a clear view of your site’s security, performance, and readiness for WordPress 7.1 and future releases.