WordPress 7.0 shipped on May 20 with the biggest set of core changes since 2018, and the maintainers have spent the month since then compiling the bug list that will become 7.0.1. On June 18, Aaron Jorbin published the release schedule for 7.0.1 on the Make WordPress Core blog, with a first bug scrub that afternoon, four more scrubs through June 30, RC1 on July 1, and a general release on Thursday, July 9. That is nineteen days away. If you upgraded to 7.0 the day it came out, you have been living with whatever shipped broken for a month already, and the clock to do something about it just started ticking.
The hotfix you can install today
The most useful thing in the 7.0.1 release post is a single line most small business owners will skim past: at least one regression from the 7.0 cycle already has a hotfix shipped as a standalone plugin, and the maintainers are recommending that sites hit by that specific bug install it now instead of waiting for 7.0.1. That is the correct posture for a small team. You do not have to triage every ticket in the 7.0.1 milestone. You have to know which one ticket is bad enough that the core team pushed a stopgap, and apply that one stopgap. The full milestone list lives on the core Trac minor release workflow report and the 7.0.x editor tasks board on GitHub, but neither of those is something a non-developer should feel obligated to read end to end. Read the hotfix post, install the hotfix plugin if it applies to your situation, and move on with your week.
Why the major releases are bigger this time
WordPress 7.0 was not just a feature drop. It added a built-in AI API layer, a redesigned admin dashboard, real-time collaborative editing inside the block editor, and a stack of under-the-hood changes to the REST API and the block themes system. The June developer roundup posted by the official WordPress account confirms the 7.0 cycle is now closed and that attention has shifted to client-side media processing tests for 7.1 plus more collaborative editing outreach. The reason any of that matters to your business is that the surface area of what can break just got larger. A styling regression in 7.0 hit hard enough that a thread on r/Wordpress titled "WordPress 7.0 ruined my website's styling" collected hundreds of replies within 48 hours of release. Most of those were solved by clearing caches, switching to a block theme, or restoring a backup, which is the same playbook you will use when 7.0.1 ships, just with fewer surprises because the maintainers will already have fixed the obvious ones.
What the next three weeks actually look like
The 7.0.1 schedule is short and predictable on purpose. Four bug scrubs between June 18 and June 30, RC1 on July 1, one more scrub, then GA on July 9. For a small business owner, that translates into three concrete windows. Between now and June 30, your only job is to figure out whether the 7.0 hotfix plugin applies to your site and install it if it does. Between July 1 and July 9, your job is to spin up a staging copy, apply 7.0.1 RC1, and click through your most important pages — homepage, top three landing pages, checkout if you run WooCommerce, contact form, and whatever you would be most embarrassed to see broken. On July 9, when the general release goes live, you update production during low-traffic hours and watch the error log for the next 24. That is the entire game plan. It is not glamorous, but it is the difference between a quiet update and a Monday morning full of "the website looks weird" emails.
A small business owner's actual to-do list
If you manage your own site, block one hour this Friday and do three things. First, check whether you are on 7.0 already or still on 6.x. If you held off, do not rush to upgrade before 7.0.1 — waiting three weeks for the maintenance release is a perfectly defensible choice, especially if your site is making money right now. Second, if you are on 7.0 and you have noticed a specific reproducible bug since May 20, search the 7.0.x milestone board for it and see whether the hotfix plugin covers your case. Third, regardless of which version you are on, take a full backup today. Not a backup that ran last Tuesday. A backup you can confirm is on disk and restorable, because 7.0.1 will arrive on a Thursday and you do not want to be debugging a failed restore at 11pm. The whole point of a maintenance release is to make your site slightly less broken than it was last week. The way you find out whether it succeeded is by being able to put things back the way they were if it did not.