Updated June 10, 2026: WordPress 7.0 “Armstrong” is now the current major WordPress branch, and it is a bigger upgrade than a routine dashboard click. WordPress.org says 7.0 was released on May 20, 2026, while the Core team says WordPress 7.0.1 is tentatively targeted for later in June 2026. That timing matters: if you run a business, publication, store, membership site, or client website, this is the moment to prepare deliberately instead of waiting for the first maintenance release to surprise you.
This WordPress 7.0 upgrade checklist is written for site owners who want the practical answer: what should I check before updating, what can break, what changed, and when is it safe to press “Update Now”? For background on the broader release timeline, keep WPArena’s WordPress version history open in another tab. For the actual upgrade process, use this checklist.
Quick Answer: Should You Update to WordPress 7.0?
Yes, but update with a plan. The official WordPress update documentation says WordPress should be kept on the latest version and recommends backing up your site before starting. WordPress 7.0 is a major release, not a minor background update, so production sites should check hosting, PHP, plugins, themes, backups, caching, editorial workflows, and custom code before switching.
The safest rule is simple: update a staging copy first, then production. If your site is small and uses a standard theme with well-maintained plugins, the upgrade may be uneventful. If your site uses page builders, custom blocks, membership plugins, WooCommerce, LMS plugins, custom admin screens, or custom Gutenberg extensions, treat WordPress 7.0 like a compatibility project.
What Changed in WordPress 7.0?
The headline is not one single feature. WordPress 7.0 is a platform release. The release announcement highlights AI integration, a modernized dashboard, new design controls, new blocks, and developer tooling. The WordPress 7.0 Field Guide is even more specific: the release includes more than 419 Core Trac tickets, more than 300 bug fixes, 40+ editor tickets, 90+ wp-admin tickets, 411 editor/dashboard/AI enhancements, and more than 486 editor/dashboard/AI bug fixes.
For site owners, the practical changes to know are:
- AI foundations: WordPress 7.0 introduces AI infrastructure through the WP AI Client, Client-Side Abilities API, AI Connectors screen, and Connectors API, according to the official Field Guide.
- Dashboard changes: The release adds a refreshed admin experience, a command palette shortcut, view transitions, visual revisions, and a dedicated font management page, according to WordPress.org and the Field Guide.
- Block and design controls: WordPress 7.0 adds device-based block visibility, new block supports, a Breadcrumbs block, a Heading block, an Icons block, gallery improvements, mobile navigation overlay controls, and block-level custom CSS, according to the Field Guide.
- Developer changes: WordPress 7.0 adds PHP-only block registration, Interactivity API updates, DataViews/DataForms changes, Block Bindings iterations, plugin list filters, and Site Editor routing work, according to the Field Guide.
- Real-time collaboration did not ship: Make WordPress Core says real-time collaboration was removed from WordPress 7.0 because the approach was not considered robust enough for Core at that time.
If you only remember one thing, remember this: WordPress 7.0 changes the editor, admin, AI integration layer, and developer surface area. That is exactly why a checklist is necessary.
WordPress 7.0 Requirements: Check Hosting First
Before updating any plugin or theme, check your server. WordPress.org recommends PHP 8.3 or greater, MariaDB 10.6 or greater or MySQL 8.0 or greater, and HTTPS support. The same official requirements page says WordPress can still run on PHP 7.4+ and MySQL 5.5.5+, but those older versions have reached official end of life and may expose your site to security vulnerabilities.
There is also a WordPress 7.0-specific PHP change. Make WordPress Core says the minimum supported PHP version is 7.4 since WordPress 7.0, while the minimum recommended PHP version remains 8.3. That means PHP 7.2 and PHP 7.3 should not be part of your WordPress 7.0 production plan.
Use this server checklist before updating:
- Confirm your site runs on PHP 8.3+ if possible.
- Confirm your database is MariaDB 10.6+ or MySQL 8.0+ if possible.
- Confirm HTTPS works across the whole site.
- Confirm object caching, page caching, CDN, and image optimization are documented before you change anything.
- If your host still exposes PHP 7.2 or 7.3 as the active runtime, fix hosting before you fix WordPress.
If hosting is already a weak point, review WPArena’s WordPress hosting guide and WordPress optimization guide before treating the update as a one-click task.
Back Up the Site Before You Touch the Update Button
WordPress.org explicitly recommends backing up your website before updating. That backup should include the database, uploads, themes, plugins, must-use plugins, custom code, and configuration files. The official update documentation also warns that the upgrade process affects files and folders included in the main WordPress installation, so any direct modifications to Core files can be lost.
A serious WordPress 7.0 backup plan should include:
- A database backup created before the update.
- A full file backup, including
wp-content/uploads, themes, plugins, and mu-plugins. - A note of the current WordPress version, PHP version, active theme, and active plugins.
- A restore test on staging, not just a downloaded zip file.
- A rollback decision: who restores the site, how quickly, and from which backup.
If you need a plugin-focused path, WPArena has a maintained WordPress backup plugins guide. The best backup is not the one with the prettiest dashboard; it is the one you have already restored successfully.
Build a Staging Upgrade Path
A staging site is where you find problems before readers, customers, editors, or clients find them. WordPress.org’s update documentation explains both one-click and manual update paths, but a major release deserves a rehearsal. Copy production to staging, update staging, then test real workflows.
Your staging test should include:
- Homepage, top landing pages, category pages, search pages, and 404 pages.
- Post editor, page editor, reusable patterns, custom blocks, and block patterns.
- Login, password reset, comment forms, contact forms, newsletter forms, and checkout if relevant.
- Admin screens created by plugins, page builders, security plugins, SEO plugins, caching plugins, and analytics plugins.
- Visual checks on desktop, tablet, and mobile.
If your staging site exposes content to search engines, fix that before testing. WPArena’s WordPress SEO checklist can help you keep technical SEO from becoming collateral damage during an upgrade.
Update Plugins and Themes Before Core
WordPress 7.0 touches the editor, dashboard, blocks, fonts, AI connectors, and developer APIs. The Field Guide is written for extending developers precisely because plugin and theme authors need to account for those changes.
Before updating Core, update your active theme and active plugins on staging. Then check whether your critical extensions mention WordPress 7.0 compatibility in their changelogs. This matters most for:
- Block libraries and custom block plugins.
- Classic Editor customizations and post publishing panel extensions.
- Page builders and theme builders.
- SEO plugins, schema plugins, redirect plugins, and sitemap tools.
- Membership, LMS, booking, directory, form, and ecommerce plugins.
- Admin UI plugins that add custom screens, metaboxes, columns, or dashboards.
One specific compatibility note is already visible in Core discussions: a Make WordPress Core post says a permanent fix for a Classic Editor publishing panel issue is targeted for WordPress 7.0.1. If your site relies heavily on Classic Editor extensions, test the publishing screen carefully before updating production.
Check Custom Code, Blocks, and Admin Extensions
Custom code is where “it works on my site” can become expensive. WordPress 7.0 adds or changes APIs across the editor and admin. According to the Field Guide, developers should review PHP-only block registration, Interactivity API changes, DataViews and DataForms, Block Bindings iterations, and Site Editor routing work.
Ask your developer to check these areas:
- Custom blocks using older Block API assumptions.
- JavaScript that depends on editor internals.
- Admin CSS that assumes older wp-admin markup or colors.
- Custom metaboxes and post publishing panel buttons.
- Block bindings, patterns, synced patterns, and content-only editing behavior.
- Theme JSON settings, dimensions presets, button pseudo-element styles, and block-level CSS behavior.
If your site has direct edits inside WordPress core files, move those changes into a child theme, plugin, or mu-plugin before updating. WordPress.org warns that core-file modifications can be lost during the upgrade process.
Understand the New AI Layer Before Enabling AI Features
WordPress 7.0 adds AI foundations, but that does not mean every site should immediately enable every AI workflow. WordPress.org says 7.0 includes a new AI Client in Core and a Connectors screen for managing external connections. The WordPress Developer Blog explains that plugins should not talk to a single AI provider directly; instead, the AI Client lets site owners configure providers through Settings > Connectors.
For site owners, the responsible checklist is:
- Decide who is allowed to configure AI connectors.
- Review whether any plugin starts using the AI Client after the update.
- Document which provider keys are used and who owns them.
- Check privacy, editorial review, licensing, and output-quality rules before AI-generated content or media becomes part of your workflow.
- Do not assume AI features are available just because WordPress 7.0 is installed; the Developer Blog says site owners still need to configure a provider for AI features that require one.
This is especially important for editorial teams. AI can assist with content, metadata, media, and workflow, but it should not quietly change publishing standards.
Test the Editor Like an Editor, Not Like a Developer
The biggest practical risk in WordPress 7.0 is not always a white screen. Sometimes it is a tiny editorial change that slows the team down every day. The release announcement highlights visual revisions, the command palette, font management, responsive controls, new blocks, and block-level design tools. Those are useful, but they still need workflow testing.
Create a real test post on staging and check:
- Can editors create and save posts without JavaScript errors?
- Do existing blocks open and save cleanly?
- Do reusable patterns, synced patterns, and template parts still behave correctly?
- Do custom blocks still render in the editor and on the front end?
- Do font settings, spacing, buttons, galleries, breadcrumbs, and responsive visibility controls behave as expected?
- Does the preview match the published page?
If the site uses an old theme or heavy page builder stack, compare before-and-after screenshots. If something shifts, do not publish the production update until you know whether the issue comes from Core, theme CSS, plugin CSS, caching, or stale assets.
Test Front-End SEO and URLs After the Upgrade
An upgrade is not complete until URLs, titles, canonical tags, schema, sitemaps, internal links, and redirects still work. WordPress 7.0 adds a Breadcrumbs block and routing-related Site Editor work according to the Field Guide, so sites with custom templates should confirm that navigation and template output still matches expectations.
After the staging update, check:
- Homepage title, meta description, canonical URL, and schema.
- Single-post title, author, modified date, schema, and breadcrumbs.
- Category, tag, author, and search archive behavior.
- XML sitemap output.
- Redirects from old URLs.
- Permalink settings and custom post type URLs.
If you are changing permalink structures during the same maintenance window, separate that work from the WordPress 7.0 upgrade. Read WPArena’s WordPress permalink structure guide before touching URLs.
Production Upgrade Checklist
When staging passes, schedule the production update. Do not do it during your highest traffic hour. Do not do it when the only person who can restore the site is offline. Do not combine it with a redesign, migration, hosting move, and plugin cleanup unless you are intentionally running a larger maintenance project.
Use this production order:
- Announce a maintenance window if the site is business-critical.
- Take a fresh database and file backup.
- Confirm the restore location and rollback owner.
- Update plugins and themes that were already tested on staging.
- Update WordPress Core to 7.0.
- Run any database update prompt shown by WordPress.
- Clear page cache, object cache, CDN cache, and browser cache where relevant.
- Test login, editing, publishing, forms, search, checkout, and top landing pages.
- Check error logs, PHP logs, browser console errors, and server health.
- Document what changed and who approved it.
WordPress.org says one-click updates work for most people, but it also documents manual updates and failed-update recovery. If the update hangs, do not keep clicking. Check maintenance mode, server logs, file permissions, and backups first.
What to Watch After Updating
The first 24 to 72 hours matter. WordPress 7.0.1 is already being organized, with Make WordPress Core saying the maintenance release is tentatively targeted for later in June 2026. That does not mean you must wait, but it does mean you should monitor your site after updating.
Watch for:
- Editor save failures.
- Classic Editor publishing-panel issues.
- Unexpected layout shifts in templates or block patterns.
- Broken admin pages from plugins.
- SEO plugin sitemap or schema changes.
- Cache conflicts and stale CSS or JavaScript.
- PHP warnings after plugin or theme updates.
If something breaks, start with the boring checks: clear cache, disable the most recently updated plugin on staging, switch to a default theme on staging, check PHP logs, and compare against your pre-update snapshot. WPArena’s WordPress troubleshooting guide is useful when the symptom is visible but the cause is not obvious.
Who Should Wait for WordPress 7.0.1?
Some sites can update now. Some should wait for 7.0.1 after testing. If your site is a brochure site with reliable hosting, updated plugins, a modern theme, and clean staging results, updating to WordPress 7.0 is reasonable. If your site depends on custom admin extensions, Classic Editor publishing-panel customizations, mission-critical ecommerce, or complex editorial tools, consider staging now and scheduling production after 7.0.1 is released.
That is not fear. It is release discipline. The Core team has already said a permanent fix for at least one Classic Editor publishing-panel issue is targeted for 7.0.1, and the same June 8 Make WordPress Core post says 7.0.1 is tentatively targeted for later in June.
Final Recommendation
WordPress 7.0 is worth taking seriously. It brings the official start of AI infrastructure in Core, a refreshed dashboard, more visual design control, new block capabilities, and a deeper developer surface. It also arrives with a near-term maintenance release already being planned.
The winning upgrade strategy is not “wait forever” and it is not “click blindly.” The right move is to back up, test staging, check hosting, verify plugins and themes, test editor workflows, confirm SEO output, update production during a planned window, and monitor closely afterward.
If you are planning a bigger project around this update, pair this checklist with WPArena’s guides to migrating a WordPress site, WordPress security, building a WordPress website, and WordPress optimization. WordPress 7.0 should make your site easier to manage, not harder to recover.
FAQ
What is the latest WordPress 7.0 release date?
WordPress.org says WordPress 7.0 “Armstrong” was released on May 20, 2026.
Is WordPress 7.0.1 available?
As of this June 10, 2026 update, Make WordPress Core says WordPress 7.0.1 is tentatively targeted for later in June 2026.
What PHP version should I use for WordPress 7.0?
Make WordPress Core says WordPress 7.0 supports PHP 7.4 as the minimum, while WordPress.org recommends PHP 8.3 or greater.
Did real-time collaboration ship in WordPress 7.0?
No. Make WordPress Core says real-time collaboration was removed from WordPress 7.0 because the feature needed more work before being included in Core.
Do I need a backup before updating to WordPress 7.0?
Yes. The official WordPress updating guide recommends backing up your website before starting an update.
Should I update WordPress 7.0 on staging first?
For business-critical sites, yes. WordPress.org documents the official update process, and this WPArena checklist recommends staging first because WordPress 7.0 changes the editor, dashboard, design controls, AI infrastructure, and developer APIs.
Official Sources Used
- WordPress 7.0 “Armstrong” release announcement
- WordPress 7.0 Field Guide
- Call for WordPress 7.0.x Release Managers
- PHP support clarification, spring 2026 edition
- WordPress.org requirements
- Official WordPress updating guide
- Real-time collaboration will not ship in WordPress 7.0
- WordPress Developer Blog: AI Client example


Responses (0 )