If your client sites live on WordPress.com, the WordPress 7.0 update is already running on them. The platform auto-updated every site when 7.0, code-named Armstrong, shipped on May 20, and self-hosted sites picked it up through the usual background updates over the following days.
The WordPress.com changelog that announced this mixes two different things: the core release, which every WordPress site eventually gets, and a set of writing and repurposing tools that exist only on WordPress.com. Coverage tends to blur them. I maintain sites in both places, so here is the split, plus what I would check this week.
What shipped in the WordPress 7.0 update
The release post on WordPress.org credits more than 875 contributors and 420-plus enhancements and fixes, so this is a normal major release in scale. The pieces editors notice first are visual markers on post revisions, a dedicated editing canvas for the mobile navigation overlay, new Breadcrumbs and Icon blocks, and a font library shared across every theme on a site. I sorted the June release into work and noise when it landed, and the follow-up hotfix arrived as plugin updates. The change with the longest tail for builders is responsive block visibility.
Letting clients use responsive block visibility
Any block can now be shown or hidden per device (phone, tablet, or desktop) without writing CSS, and the rule travels with the block markup. The dev note on Make Core says the three viewport keys map to fixed breakpoints in 7.0, with configurable breakpoints and theme.json integration planned for 7.1. So don’t promise a client that the thresholds match their design system, because right now they can’t be changed.
My caution is about content. Google indexes the mobile rendering first, so a block hidden on phones is a block mobile crawlers don’t see, even though desktop visitors do. Hiding a decorative hero image on phones is fine. Hiding a spec table or FAQ answers on a product page is a quiet way to lose rankings, and the client will never connect the drop to a setting they clicked months ago.
Plugins that did this with CSS classes are now redundant, but check old content before deactivating one. Depending on how the plugin stored its rules, deactivation can either expose everything a client had hidden or drop the rules entirely. I’m also not sure how the new visibility rules behave through an export and import into a fresh install, so I wouldn’t rely on that path for a migration yet. After the auto-update lands, I run a short WP-CLI pass on each site I keep an eye on:
wp core version
wp plugin list --update=available
wp theme list --update=availableIf you’ve got a mix of WordPress.com and self-hosted client sites and want the post-7.0 checks run, the old visibility plugins retired without breaking pages, and your themes verified against the new blocks, that’s the kind of cleanup work I do. Send me the site list.
The podcast and video tools on WordPress.com
Posts to Podcast sits under Media > Create AI Podcast on every WordPress.com site. It turns a published post into a two-host audio episode, saves it to the Media Library, and queues a draft post with the audio and a transcript. Feature Clips, on Premium plans and up, generates a short vertical video from the editor sidebar. You get ten generations per site per day and can download the result as an MP4 for TikTok or YouTube Shorts. Write, a distraction-free editor in beta on every plan including Free, saves real posts you can open in the full block editor later.
None of this ships in core, so self-hosted clients get none of it, and the closest equivalent is Jetpack’s podcast support. On WordPress.com, I have one strong opinion: put the transcript text on the original post instead of leaving it in the separate draft. A transcript sitting in a draft adds nothing crawlable, while the same text on a page that already ranks does. For a store, an audio version of a long buying guide is a cheap experiment. A generated clip is only a teaser. One detail from the changelog comments: an Automattic developer confirmed the generated audio is WAV, chosen for quality, so a batch of episodes eats storage quickly. Convert it before re-uploading anywhere with a size budget.
The permalink setting on every paid plan
The changelog also moved the permalink structure setting down to every paid plan, Personal through Commerce. On a new site that’s harmless. On a site with indexed URLs, changing the structure strands every one of them, because WordPress core doesn’t add redirects when permalinks change. Redirect plugins handle it, but plugin uploads only open at the Business plan on WordPress.com, which means a Personal or Premium site can now rewrite its URL structure with no way to redirect the old ones. On plans below Business, I’d treat that setting as locked even though it’s open.
This week I’d run the version and available-updates check on everything I look after, compare any theme that ships its own breadcrumbs against the new core block before someone uses both, and leave permalinks alone on WordPress.com unless the client has a real reason. The rest of the changelog can wait until someone asks for it.
