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

WordPress 7.1 arrives on 19 August 2026, and for the first time in the platform's history you'll be able to 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. Beta 1 shipped on 15 July, so these aren't roadmap promises any more. They're testable features with official testing guides.

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 in Beta 1, 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 Ships (and What Quietly Didn't)

The commodity coverage of this release copies the June roadmap post and calls it a feature list. That's how several large hosting blogs ended up promising features that aren't in Beta 1 at all. We went through the official Beta 1 announcement, the testing guide and the underlying Gutenberg trackers, and sorted the claims into shipped and not shipped.

Confirmed in Beta 1:

• Responsive styling. Block styles can differ between desktop, tablet and mobile, in Global Styles and on individual blocks. Theme authors can define custom breakpoints in theme.json.
• Interactive states. Hover, focus and active styling with a visual control, no CSS required.
• Notes on selected text. Feedback threads can now attach to specific words, with rich text, @mentions, multiple threads per block and notifications.
• 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 HEIC and AVIF 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.

Listed on the roadmap but absent from Beta 1: the inherited-styles indicator (the "why is this button still blue?" feature) remains an open proof of concept on GitHub, suggestion mode and emoji reactions for Notes didn't make the cut, and Google Docs-style live co-editing is still a separate experiment in the Gutenberg plugin, not a 7.1 feature. Anne McCarthy, the 7.1 release lead, was careful about 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.

The WordPress 7.1 release date is 19 August 2026, and the schedule from here runs Beta 2 on 22 July, Beta 3 on 29 July, then release candidates through early August. Any of the WordPress 7.1 features above can still be pulled between now and then. That's not hedging; it's how 7.0 lost real-time collaboration three weeks before launch.

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 official call for testing is upfront about the boundaries:

• It follows a desktop-first cascade: smaller viewports inherit desktop values until you override them.
• Only controls built on standard block supports pick up responsive values. Toolbar settings like alignment stay global for now.
• Third-party blocks inherit the system automatically only where they use standard 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 told plugin developers to test exactly this: blocks that ship custom style controls, and themes leaning on theme.json presets, should run the call for testing and report what breaks. If your favourite block pack hasn't said anything about 7.1 compatibility yet, that silence is worth noticing.

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 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. From 19 August it comes off the list.

One honest limitation, straight from the official 7.1 testing guide: per-block interactive states currently work on the Button block only. Other blocks don't expose the controls yet. Global Styles covers site-wide button behaviour today, and the underlying system is built to extend, but if you were picturing hover effects on cards, images and navigation items in 7.1, that's not what's shipping. This is a 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. 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 reply notifications. If you've ever emailed a colleague "second paragraph, third sentence, change 'cheap' to 'affordable'", this is that workflow moving inside the editor. It's asynchronous feedback, not live co-editing. Two people still can't type in the same post at once; that experiment continues in the Gutenberg plugin and was pulled from 7.0 over server load and data integrity concerns. Anyone promising you Google Docs in WordPress 7.1 hasn't read the Beta announcement.

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". That feature is still an open proof of concept awaiting review on GitHub. It isn't in Beta 1 and shouldn't be expected on 19 August. Several roundups have reported it as confirmed. It isn't, and style debugging in a mixed theme-plus-overrides setup remains the confusing mess it's always been.

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 Get Your WordPress Site Ready Before 19 August

What we'd do on any WordPress site between now and release day, builder or not. It's the same routine we ran before 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. The result was zero upgrade tickets, zero rollbacks and zero white screens, and that record wasn't luck. It was this list. We'll be running the same release-candidate testing on our own sites again before 19 August.

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. And if you fancy an early look at the responsive controls, the official Help Test WordPress 7.1 guide walks you through running Beta 1 safely in WordPress Playground, which is a throwaway sandbox in your browser. Don't put a beta anywhere near production; that's not what it's for. 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