WordPress 7.1 Could Reduce the Need for Page Builders. Here's What's Changing

WordPress 7.1 "Mary Lou" shipped on 19 August 2026, and for the first time in the platform's history you can give a heading one size on desktop and another on mobile, or make a button change colour on hover, without writing CSS, installing a plugin, or paying for a page builder. We wrote this in July from Beta 1. Now the release is out, we've been back through it against the shipped code and the developer notes. Two things we told you in July turned out to be wrong, and they're corrected below rather than quietly deleted. Two we called correctly, and those are marked too.

That sentence would be unremarkable for almost any other design tool. Elementor has offered per-device styling for a decade. But WordPress core never has, and that one gap has quietly driven millions of licence purchases. When the free editor can't do the basics of responsive design, a £75-a-year plugin that can starts to look like a bargain.

The short version: WordPress 7.1 removes two of the biggest everyday reasons to reach for a page builder on a new site. It does not convert your existing Elementor pages to blocks, it doesn't replace forms, popups or WooCommerce template building, and the licence saving from dropping a builder almost never pays for the rebuild. We'll take you through what actually shipped on 19 August, what quietly didn't, and the numbers we'd want in front of us before touching a healthy site. We hosted WordPress 7.0's launch day across hundreds of production sites in May, so this is the follow-up question we've been asked ever since: what does 7.1 mean for my builder site?

What WordPress 7.1 Actually Shipped (and What Quietly Didn't)

The commodity coverage of this release copied the June roadmap post and called it a feature list. That's how several large hosting blogs ended up promising features that never arrived. In July we sorted the roadmap claims against Beta 1. Now we've re-checked the lot against the release announcement, the 7.1 field guide and the individual developer notes behind it. The release is named Mary Lou, after the jazz pianist and arranger Mary Lou Williams.

Shipped on 19 August:

• Responsive styling. Block styles can differ between desktop, tablet and mobile, in Global Styles and on individual blocks. It covers every block type and block style variation built on core supports: typography, colour, background, border, dimensions, spacing and layout. Themes set the breakpoint widths themselves through a new top-level settings.viewport key in theme.json.
• Interactive states. Hover, focus, focus-visible and active styling with a visual control, no CSS required. Four states, not the three we listed in July.
• Notes on selected text. Feedback threads attach to specific words, with rich text, @mentions, multiple threads per block and email notification when you're mentioned.
• Suggestion mode and emoji reactions. In July we reported both as having missed the cut. They landed. Suggestion mode is the Google Docs-style view where a colleague proposes wording and you accept or reject it in a click.
• A dedicated media editor. A proper editing modal with freeform and aspect-ratio cropping, flip, fine rotation and metadata editing, replacing the old inline crop. Client-side processing adds AVIF, HEIC and HDR gain map support, so iPhone photos stop being a support ticket.
• Two new blocks. Tabs and Playlist, plus an always-visible toolbar, grouped command palette results and an "On This Day" dashboard widget.

Two of those bullets are corrections to what we published in July. The bigger one is suggestion mode and emoji reactions: when we published, the Notes tracking issue still had both outstanding and we reported them as having missed the cut. Both were finished during the beta cycle and are in the release. The smaller one is the count of interactive states, which we gave as three and is four. If you read this piece in July and took our word for either, those are the lines to unlearn.

What genuinely didn't make it: the inherited-styles indicator, the "why is this button still blue?" feature that would show you where a style is actually coming from. It isn't in 7.1, and the Global Styles inheritance UI has since been moved behind a Gutenberg plugin experiment flag rather than merged, so it isn't imminent either. Google Docs-style live co-editing also remains an experiment, not a feature. Anne McCarthy, the 7.1 release lead, was careful about all of this in the roadmap post itself: "What's shared here is being actively pursued, but doesn't necessarily mean each will make it into the final release." Several publications quoted the list and skipped the caveat. The AI Client work we covered in our WordPress AI agents piece also continues in this release, with response streaming and embeddings.

That's the pattern worth taking away, and it cuts both ways: the roadmap over-promised on styling and under-delivered on collaboration, and we got caught on both. The roadmap is a statement of intent, not a changelog, and the gap between the two is where the bad hosting advice lives. The clearest example is the release's performance work: the automatic speculative loading upgrade never shipped either, and a manual host-level setting landed in its place.

Responsive Styling Without Custom CSS: The Headline Feature

Here's the job responsive styling replaces. A client wants their homepage headline at 64px on desktop, but on a phone that fills the screen with four words. Until now the honest fixes were custom CSS with media queries, a third-party block pack, or a page builder. In WordPress 7.1 you switch the editor to the tablet or mobile view, change the font size, and that value is saved for that viewport. It works in Global Styles for every instance of a block across the site, and on individual blocks for one-offs. The editor previews it live.

Anne McCarthy put the intent plainly in the Roadmap to 7.1:

"The aim is to make responsive design a built-in, first-class part of the editing experience."

"First-class" is the phrase that got me, because I've spent 20-odd years watching what its absence cost. I've lost count of the tickets where somebody's heading looked wrong on a phone and the answer involved pasting CSS into a box they didn't know existed. Every one of those tickets was a small argument for buying a page builder. Core finally treating viewport styling as a basic editing action, rather than a developer task, changes who needs help and when. Fewer "it looks broken on my phone" conversations is good for site owners and, frankly, good for our support queue.

Now the fine print, because this is where the "Elementor killer" headlines fall over. The shipped developer note is upfront about the boundaries:

• It's desktop-first, and literally so. There is no @desktop style key at all. The default style you set is the base, it applies at every width, and the tablet and mobile styles override it inside their own breakpoint ranges.
• You get two breakpoints out of the box. Themes can change the widths through settings.viewport, but a theme that never touches it leaves you with the defaults.
• Only controls built on core block supports pick up responsive values. That's typography, colour, background, border, dimensions, spacing and layout, which covers most of what you'd want, and not the toolbar settings.
• Third-party blocks inherit the system automatically only where they use those same core supports. Blocks with custom style controls need developer work before their settings go responsive.

That last point matters if your site leans on big block libraries or a builder. Ryan Welcher of Automattic spent the beta cycle telling plugin developers to test exactly this: blocks shipping custom style controls, and themes leaning on theme.json presets. The release is out now, so the question has stopped being hypothetical. If your favourite block pack still hasn't said anything about 7.1 compatibility, that silence is worth noticing.

And here's the detail that hasn't made a single roundup we've read, which matters because it's the one that can make this whole feature vanish from your editor. Both new control sets can be switched off. responsiveEditingEnabled hides the responsive styling controls, and blockStatesEditingEnabled hides the state dropdown in the block inspector and the pseudo-state options in Global Styles. Both default to true, so a stock install has them. But they're editor settings, which means a theme, a plugin or an agency can turn them off for a site, and the styles already saved keep applying while the controls to change them disappear. If you update to 7.1 and can't find the responsive toggles the articles promised, that's the first thing to check, before you conclude the update failed.

Hover States Without a Stylesheet

The second headline feature is smaller but might be the one ordinary users notice first. Making a button change colour when someone hovers over it has been a solved problem in CSS since before WordPress existed:

.wp-block-button__link:hover {
    background-color: #0D4F4F;
    color: #ffffff;
}

Three lines. And yet for a non-technical site owner those three lines meant finding the Additional CSS box, learning what a selector is, and discovering the hard way that their theme already styles hover with higher specificity. In 7.1 there's a State dropdown: pick Hover, Focus, Focus-visible or Active, restyle the button, done. Set it in Global Styles and every button on the site follows; set it on one block and only that button changes.

Jonathan Bossenger, a developer advocate at Automattic, summed it up when the Global Styles version of this landed in the Gutenberg plugin back in April:

"No more needing theme.json or custom CSS to style button states."

I'll admit that line landed differently for me than it will for most readers. We build sites in plain PHP and CSS as well as WordPress, so writing a hover state costs me nothing. But I've watched customers give up on that exact task. One of our longest-running support patterns is someone who bought a page builder licence for a five-page brochure site, and when you ask why, the answer boils down to two or three visual jobs core couldn't do. Hover styling was almost always on the list. As of 19 August it comes off the list.

One honest limitation, and it moved between our July draft and the release. State styling is limited to two blocks: Button and Navigation Link. In July, working from the Beta 1 testing guide, we said Button only, and we said hover effects on navigation items weren't coming. Navigation Link made it. Cards and images still didn't, so the shape of the caveat holds even though one of its examples is now wrong. Everything else exposes no state controls, and Global Styles covers the site-wide behaviour of those two blocks.

There's a second layer underneath, and it tells you where this is heading. Alongside the four pseudo states, 7.1 quietly added custom states, which generate CSS targeting a class name rather than a pseudo-class. It's theme.json only right now, with no interface at all, and it works on the Navigation Link block, where it can style the current menu item. That's the plumbing for a future where you style a "current" or "selected" state visually. It is not a thing you can use in the editor today. First release of the machinery, not the finished factory.

Notes, the Media Editor, and What Didn't Ship

Two more changes deserve a mention before the page builder question, because both replace paid plugins or external tools for a lot of small teams.

Notes grew up, and grew up further than we expected in July. WordPress 7.0 introduced block-level comments; 7.1 lets you attach a note to selected text, even across blocks, with formatting, links, emoji, @mentions and an email when someone mentions you. If you've ever emailed a colleague "second paragraph, third sentence, change 'cheap' to 'affordable'", this is that workflow moving inside the editor. Suggestion mode goes one better: your colleague proposes the actual wording, you accept or reject it in a click, and nobody retypes anything. Emoji reactions landed too, which sounds trivial until you've watched a four-person approval thread that could have been four thumbs-up.

What still hasn't arrived is simultaneous typing. Two people cannot edit the same post at the same time; that experiment continues in the Gutenberg plugin and was pulled from 7.0 over server load and data integrity concerns. So 7.1 gets you the review half of Google Docs and not the writing half, and anyone selling you the second half is describing a plugin experiment.

The media editor is the quieter win. Until now, editing an image in WordPress meant a cramped inline crop tool that hadn't meaningfully changed in years, so people round-tripped through Canva or Photoshop to straighten a photo. 7.1 opens a dedicated modal with freeform and ratio-locked cropping, flip, fine-grained rotation and metadata editing. Add client-side processing (your browser, not the server, converts the file) with HEIC support, and the "my iPhone photo won't upload" problem largely disappears.

And the one everyone will miss: the roadmap floated an indicator showing where a block's styles come from, so you could finally answer "why is this still blue, I changed it three times". In July we said it was an open proof of concept, that several roundups were wrong to list it as confirmed, and that nobody should expect it on 19 August. It didn't ship. The Global Styles inheritance work has since been put behind a Gutenberg experiment flag rather than merged into core, which means it isn't in the next release either unless something changes. Style debugging in a mixed theme-plus-overrides setup remains the confusing mess it's always been, and that's the single biggest gap between core and a mature builder interface.

Do You Still Need a Page Builder? The 43% Question

Some context on how big the Elementor vs block editor question really is. HTTP Archive's 2025 Web Almanac detected Elementor on 43% of the WordPress pages it sampled on mobile, against 18% for the block editor, 13% for WPBakery and 10% for Divi. The trend line is the interesting bit: a year earlier Elementor's figure was around 56%. The builder is still the most-used design tool in the WordPress world by a distance, and it's losing share at the same time as core gets better at design. Those two facts aren't a coincidence.

Elementor isn't standing still either. Elementor 4 launched on 15 April 2026 with a rebuilt Atomic architecture: CSS classes, variables, reusable components, per-device styling for effectively every property, and much leaner markup than the div-soup the builder was famous for. Our sister design studio spent time in the beta and wrote up what Elementor 4's design system feels like to use; the short version is that the gap between "builder" and "design tool" closed a lot. So 7.1 versus Elementor 4 isn't core catching a stationary target. It's two moving targets, and for full design-system work Elementor is still ahead.

Where a builder still earns its licence outright: visual form building with submissions, popups, WooCommerce template design, dynamic content wired to custom fields, motion effects, and a widget library the size of a small country. WordPress 7.1 replaces none of that. Core is also getting stronger for structured content (the Block Bindings work our WordPress specialists at Press Forge covered in their block bindings guide is quietly excellent), but "core can do responsive text now" and "core replaces Elementor Pro" are very different claims.

Our own position might carry some weight here because we've sat on every side of this. We hold page builder licences ourselves, we built years of client sites on Avada, and we still host that portfolio today. A few years ago we stopped choosing Avada for new builds. We did not rebuild the existing sites, and when Avada's million-site SQL injection landed in May, we patched the portfolio rather than panic-migrating it. "I wouldn't choose it today" and "it should be replaced" are different judgements, and mixing them up is how site owners get talked into £4,000 rebuilds they didn't need.

The Maths of Dropping Elementor: £75 a Year vs a £1,800+ Rebuild

Here's the calculation we'd actually run, with real UK numbers, because "you'll save the licence fee" is the most misleading sentence in this whole debate.

The saving: Elementor Pro's one-site Advanced Solo plan lists at $84 a year, which lands around £75 including VAT at current exchange rates. The mid-tier Essential plan is a little less, the 25-site Expert plan about £180.

The cost of leaving: there is no migration path. Deactivate Elementor and your pages don't fall back to tidy blocks; layouts built with builder widgets need rebuilding by hand, template by template, then checking against the old site. IT Jobs Watch puts the median advertised day rate for a UK WordPress contractor at £465 (a small sample, but consistent with what we see agencies charge). UK studios publish small-business redesign pricing from about £1,800 to £4,500, with SEO migration work pushing it higher.

So the break-even, using the licence saving alone:

• One contractor day (£465) equals roughly 6 years of licence fees.
• A £1,800 rebuild equals roughly 24 years.
• A £4,500 rebuild equals roughly 60 years.

Nobody rationally spends £4,500 to save £75 a year. A migration only stacks up when the builder is costing you more than its licence: recurring developer hours fixing builder conflicts, paid add-on subscriptions on top of the licence, Core Web Vitals that stay red after the usual image and caching work, accessibility fixes fighting generated markup, or a builder version holding you back from PHP and WordPress upgrades. Add those up over three years, compare them with the one-off rebuild cost, and sometimes the rebuild wins. On a healthy site, it usually doesn't.

The decision we give customers in one line: switch editors when you were going to redesign anyway; never redesign just to switch editors. A redesign you'd already budgeted is the one moment a move to native blocks costs almost nothing extra, because you're rebuilding templates regardless.

Why a 20-Year Client With Thousands of Pages Is Refreshing in Elementor 4, Not Rebuilding in Core

A real decision from our own customer base, published with permission. Richard Antrobus runs The Employment Law Solicitors, and he's hosted with 365i for close to 20 years, through multiple full rebuilds of his site. The current site is a previous-generation Elementor build carrying thousands of pages and posts, with the sort of organic search traffic where mistakes are expensive. His site runs on our multi-site WordPress hosting with the £10-a-month Website Turbo upgrade on the main domain, added when the traffic outgrew the standard tier.

With Elementor 4 now stable, Richard is planning a fresh refresh on Elementor 4, not a migration to native blocks. And when he asked what we thought, we agreed. Walk through the maths above with a content-heavy legal site: thousands of URLs whose rankings pay the bills, dozens of templates, staff who know the current workflow. A platform swap would put all of that in motion to remove a licence fee that rounds to nothing against the site's value. A refresh on the builder's new architecture gets him the performance gains of leaner markup without betting the traffic.

The honest counterweight: if Richard were starting today with five pages and a contact form, we'd tell him core WordPress with a good block theme covers it, and 7.1 makes that truer than it's ever been. The right answer depends on which site you have, not which year it is.

What WordPress 7.1 Can't Fix: A 35-Minute Lesson From Our Helpdesk

One more real case, anonymised. In January a UK business owner forwarded us the automated fatal-error email WordPress had sent him. His Elementor admin screen had died after a core update. The stack the error email disclosed: WordPress 6.9, Elementor 3.29.2, and PHP 7.4.33, a PHP version that reached end of life in November 2022. Plenty of outdated plugins besides. No backup taken before the failure; he started one after, which is a photograph of a broken site. We logged in, updated the stale pieces, fixed the Elementor error, and had him running in about 35 minutes. Charged him nothing; he'd offered to pay.

I bring him up because every "WordPress 7.1 changes everything" article skips his situation entirely, and his situation is the most common one we see. His problem was never that Elementor lacked responsive controls or that core lacked hover states. His problem was a four-year-old PHP version and no restore point. WordPress 7.1's shiny styling panel does precisely nothing for a site in that condition, and the sites most likely to have a rough 19 August aren't the well-maintained builder sites at all. They're the neglected ones, whatever editor they run. If your backup story is "I think the host does something", read our piece on why a backup isn't a backup until you've restored it before you worry about anything in this article. Every 365i WordPress plan includes Timeline Backups with 30 days of separate restore points precisely because of customers like him.

How to Update to WordPress 7.1 Safely

The release is out, so this section has changed from a countdown into a routine. It's the same one we ran for 7.0, when we tested the release candidates on our own staging and live test sites first (Elementor 4 included, which ran smooth and fast on 7.0) and then let hundreds of customer sites auto-update on launch day. That produced zero upgrade tickets, zero rollbacks and zero white screens. Read that as a 7.0 result and a platform track record, not as a 7.1 measurement, because it's the former.

First, know what you're actually running. If you have WP-CLI access, two commands give you the whole picture:

wp core version
wp plugin list --format=csv

No WP-CLI? The Site Health screen under Tools lists the same essentials. What you're looking for: your PHP version (8.1 at minimum, current 8.x ideally), any plugin that hasn't been updated in over a year, and your theme's last release date. Old PHP plus stale plugins is the exact recipe from the 35-minute rescue above.

Second, confirm you have a restore point you've actually tested, not a backup you believe in. Third, if the site matters commercially, put a copy on staging and run the update there first, checking the templates your revenue flows through: forms, checkout, enquiry pages. That order matters more now than it did in July, because the update is sitting in front of you rather than six weeks away. 7.1 is the current release, and the longer a site sits behind, the bigger the jump when it finally moves. And if you want a look at the responsive controls without touching your own site at all, WordPress Playground gives you a throwaway WordPress in a browser tab. We flagged the same discipline in our WordPress 7.0 hosting readiness checklist, and every word of it applies to 7.1.

If your current host makes any of that hard (no staging, one overwritten nightly backup, PHP versions stuck in the past), that's worth fixing before a major release, not after. Moving to 365i is free and doesn't have to wait for a quiet week: our free Migration Centre moves your website, databases and mailboxes, it's designed for zero downtime, and you preview everything before switching DNS. If a migration still feels scarier than a major WordPress release, we wrote about what actually happens when you switch hosts, minute by minute.

Frequently Asked Questions