Applies to WordPress 7.0 and 7.1. Last verified: 2026-09-11, against WordPress 7.1.
Short answer: switch from a plugin to the core WordPress feature only when three things are true. Core covers every task you actually use the plugin for, the content the plugin created can move without breaking pages, and nothing you rely on every week is left behind. If core covers 80% of the job, the deciding question is whether the missing 20% is something you use or something you have never touched. Test the switch on a copy, and deactivate the plugin before you ever delete it.
This page is a decision method, not a list. It names no plugin and recommends none, because the right answer depends on how you use the plugin, not on the plugin. The same five questions work for fonts, tabs, bulk editing, revisions, notes, or whatever core absorbs next.
Back up before you act on any of this. Removing a plugin is the one step in this process that can take content with it. Keep a backup you have restored at least once, not just one you have made.
Why the core feature vs plugin question keeps coming up in WordPress
Recent releases keep moving jobs from plugins into core:
| When | Core features that overlap with common plugin jobs |
|---|---|
| Before 7.0 | Notes, block-level editorial feedback in the editor (6.9); the Accordion block, documented by WordPress.org since December 2025 |
| WordPress 7.0 | The Font Library on every theme type, Visual Revisions, the Icons and Breadcrumbs blocks |
| WordPress 7.1 | The Tabs and Playlist blocks, inline notes and @mentions, a new media editor with cropping, flip and rotation, responsive styling without custom CSS |
The table comes from the WordPress 7.1 release page and the WordPress 7.0 release page, both read on September 11, 2026, plus WordPress.org's documentation for Notes and the Accordion block.
This is by design. The Make WordPress Core handbook's Features as Plugins page, last updated February 7, 2018 and read on September 11, 2026, describes how a feature can be "built, tested, refined, and polished" as a plugin before it is considered for core. It also names the other outcome: "Features that don't get included in core can continue to live on as awesome plugins." Core is not trying to replace every plugin. It absorbs the parts most sites need, and a well-made plugin often carries on with the extras.
The five-question test
Answer these in order, in writing. It takes ten minutes and avoids the common mistake, which is comparing the plugin's feature list with core's feature list. What matters is your use, not either list.
| Question | Keep the plugin if | Switch to core if |
|---|---|---|
| 1. Which tasks do you actually use it for? | You use features core has no equivalent for | Everything you use has a core equivalent |
| 2. Does core do each task on the version you run? | Core is missing a task you use weekly | The official documentation for the core feature covers each task |
| 3. Where does the plugin keep your content? | Shortcodes or its own storage across dozens of pages | Little or no content depends on it, or it converts cleanly |
| 4. Who maintains each side? | The plugin is actively maintained and the core feature is brand new | The plugin looks abandoned |
| 5. What does the gap cost you? | The missing piece affects readers or your workflow | The missing piece is something you have never used |
1. List the tasks, not the features
Open the plugin's settings and write down what you have actually configured and what appears on your pages. A plugin with forty options that you use for two is, for this decision, a two-option plugin.
2. Check core on your version, from the official source
Use the release announcement and the WordPress.org documentation page for the feature, not a roundup of what's new. Roadmaps are plans. The Roadmap to 7.1 on Make WordPress Core, read on September 11, 2026, listed a Table of Contents block alongside Tabs and Playlist, and said plainly that what it describes "doesn't necessarily mean each will make it into the final release." The 7.1 release page lists Tabs and Playlist and no Table of Contents block, and WordPress.org had no documentation page for one when we checked on September 11, 2026. Anyone who deleted a table-of-contents plugin on the strength of the roadmap would have been left without one. Reading WordPress release notes shows how to tell what actually shipped.
3. Find out where your content lives
This question decides most cases. If the plugin works through shortcodes, every page using them shows raw bracketed text the moment the plugin stops running. If it stores content in its own database tables, that content may not survive the plugin's removal. If its output is ordinary blocks, the move is easy. Search your posts for the plugin's shortcode name before deciding: the number of results tells you how much conversion work the switch really costs.
4. Look at who maintains each side
A plugin whose last update was years ago is a reason to move, and what to do when a plugin is no longer updated covers that case in full. Before reading too much into a plugin page, check what Tested up to on a plugin page really means. On the core side, the Features as Plugins page says that once a feature is merged, "the feature team remains responsible for the feature, with added support from the Core team." A core feature in its first release is maintained, but it is also new, and waiting for one point release before rebuilding a critical page is reasonable.
5. Price the gap honestly
"Core does 80% of it" is a common and useful finding. The decision turns on the other 20%. If it is something readers see, or something you rely on every week, keep the plugin for now and check again at the next major release. If it is an option you have never switched on, it is not a reason to keep the plugin.
A worked example: bulk editing
Say you installed a bulk-edit plugin to change categories on many posts at once. Question 1: the only thing you use it for is changing categories and status on many posts. Question 2: the redesigned Posts screen can filter and bulk-edit, as described in bulk-editing posts in DataViews. Question 3: a bulk-edit tool changes your posts rather than storing content of its own, so nothing on your pages depends on it. Questions 4 and 5 barely matter. This is the easy case: deactivate the plugin, work with core for a few weeks, and delete the plugin once you have not missed it.
If the same plugin also edits a custom field in bulk that you update every week, question 5 changes the answer. Check whether the Posts screen covers that field before you decide, and keep the plugin if it does not.
How to switch without losing anything
- Make a backup and confirm it restores.
- Work on a copy of the site first. The same approach as testing a WordPress update on a copy applies here.
- Rebuild one real page with the core feature and compare it with the original, including on a phone.
- Convert the remaining pages one at a time, removing the old shortcodes or plugin blocks as you go.
- Deactivate the plugin on the live site from the Plugins screen. Deactivating is reversible and leaves the plugin's data where it is.
- Wait. A week of normal use shows you anything you missed.
- Delete only then. WordPress.org's Manage Plugins documentation, last updated January 10, 2026 and read on September 11, 2026, describes the order: deactivate the plugin first, then use its Delete link. Some plugins also remove their stored data when they are deleted, so read the plugin's own documentation before this step.
When keeping the plugin is the right call
Plugins win this comparison more often than articles about new core features admit.
- It holds content core cannot read. Converting hundreds of pages is real work, and the plugin works.
- The core version is missing something readers use. Wait for a later release rather than downgrading the page.
- You manage sites for other people. Retraining a client on a different interface has a cost that no feature list shows.
What to avoid is running both for the same job. Two tools that each think they control the same element make problems hard to trace. Pick one tool per job, and write down which one you picked.
FAQ
Is a core feature always better than a plugin?
No. A core feature is maintained along with WordPress itself, which is a real advantage, but it may do less than a mature plugin. Use the five questions: switch when core covers every task you use and your content can move cleanly.
Can I use the plugin and the core feature at the same time?
During a transition on a copy of the site, yes. Long term, avoid having two tools control the same job on the same pages, because conflicts between them are hard to diagnose.
How do I know a feature is really in core and not just announced?
Check the release announcement for your version and look for the feature's own page in WordPress.org's documentation. Roadmap posts describe plans, and features listed on them can slip to a later release.
Should I delete the plugin as soon as I switch?
No. Deactivate it, use the site normally for a while, and delete it only when nothing depends on it. Deactivating is reversible; deleting may not be.
Version context. Written against WordPress 7.1, released August 19, 2026, and confirmed as the current release on the WordPress.org release archive on September 11, 2026. Feature lists come from the WordPress 7.0 and 7.1 release pages on WordPress.org and its documentation for Notes, the Accordion block and the Tabs block. The quotations about how features reach core come from the Features as Plugins page of the Make WordPress Core handbook, the roadmap caveat from the Roadmap to 7.1, and the uninstall order from WordPress.org's Manage Plugins documentation, all read on September 11, 2026. No plugin is named, ranked or recommended on this page. Review trigger: every major WordPress release, since what core covers changes each time.
