Quick answer: Gutenberg is the block-based editor destined for WordPress core. Today it ships as a feature plugin you can install and test. WordPress 5.0 is not released yet and no final date is locked, but waiting until the last minute is risky. Install Gutenberg on staging, check your theme and plugins, train editors on blocks, and keep Classic Editor as a fallback plan.
WordPress 4.9 is the current stable release (with 4.9.x maintenance updates landing through early 2018). The editing experience most teams know is the classic TinyMCE box. Gutenberg replaces that with blocks: paragraphs, images, headings, galleries, quotes and more, each as its own unit.
This checklist helps you prepare without breaking the live site.
What Gutenberg is right now
Gutenberg is a feature plugin. You install it from the plugin directory like any other plugin. Versions in the 2.x range are what many testers are using in early 2018. It is under active development. Things change between releases, which is why production sites should test on a copy first.
WordPress 5.0 will eventually merge a block editor into core. That release is not out, and the project has been clear that compatibility work matters more than a fixed calendar date. Treat Gutenberg as “coming,” not as “already the default on your live site.”
The Classic Editor plugin already exists (released in late 2017). It is the escape hatch if you need the old editor after 5.0 ships.
Why you should test now
Themes and plugins that inject meta boxes, shortcodes or custom TinyMCE buttons may behave oddly in the block editor. Discovering that on launch day is expensive. Discovering it on staging this month is cheap.
Editors also need time. Blocks feel different from a single blank canvas. A short internal training session prevents a week of frustrated support tickets later.
Preparation checklist
1. Create a real staging copy
Clone the site (files and database) to a staging URL. Match the PHP version, WordPress version and active plugins with production where you can. WordPress officially still lists a low PHP minimum, but PHP 7.x is what you want for speed and security; PHP 7.2 is the current line. See our notes on PHP versions and WordPress if you are overdue for an upgrade.
2. Install Gutenberg only on staging first
Install and activate the Gutenberg plugin on staging. Open a few representative posts and pages: a long article, a landing page with shortcodes, a page built with a page builder, and a custom post type if you use them.
3. Audit the theme
Check:
- Does the theme style Gutenberg blocks sanely (wide images, quotes, columns)?
- Are custom editor styles fighting the block UI?
- Do template parts that assumed classic content still render?
Theme shops are releasing Gutenberg-ready updates gradually. If your theme is abandoned, budget for a custom theme refresh or a well maintained alternative before you rely on blocks in production.
4. Audit plugins
Common friction points:
- Page builders (they often keep their own editor and may conflict)
- Shortcode-heavy plugins (blocks can still embed shortcodes, but the workflow changes)
- Custom meta boxes that appear below the editor
- SEO plugins and their snippet previews
- Advanced Custom Fields and similar field UIs
Deactivate plugins in groups on staging if you need to isolate a conflict. Update everything you can before blaming Gutenberg.
5. Inventory shortcodes and custom HTML
List the shortcodes your content team uses. Confirm each still works inside a Shortcode block or a Classic block. Convert critical layouts to native blocks where a stable block exists, but do not rewrite the entire archive in one weekend.
6. Train editors on a small set of blocks
Start with Paragraph, Heading, Image, List, Quote, Button and Embed. Show how to rearrange blocks, how to undo, and how to switch a block to HTML when needed. Save a reusable block for common calls to action once the feature is stable enough for your team.
7. Decide your fallback
Document the plan:
- If 5.0 ships and a critical plugin breaks, install Classic Editor and keep publishing
- If only one custom post type breaks, keep that type on Classic while posts use blocks
- Who approves moving staging tests to production
8. Back up before any production trial
Full file and database backups, plus a way to restore quickly. Pair this with your normal WordPress maintenance routine so backups are not a one-off scramble.
9. Give feedback upstream
Gutenberg is still being shaped. If you find a bug or a workflow that does not suit real editors, report it on the Gutenberg GitHub repository or the WordPress support forums. Clear reports with steps to reproduce help the core team fix problems before 5.0 ships.
What not to do yet
Do not activate Gutenberg on a busy production site without staging proof. Beta software plus real customers is a poor mix.
Do not rebuild the whole site around experimental blocks. Stick to stable blocks for content you care about.
Do not ignore accessibility and keyboard use. Have an editor who relies on the keyboard try the staging editor and report issues upstream or to your developer.
Do not assume page builders are obsolete overnight. Many sites will run builders and Gutenberg side by side for a long time. Test the combination you actually use.
Content and markup habits that help
Whether or not you switch editors this quarter, cleaner content migrates more easily:
- Prefer semantic headings over bold paragraphs pretending to be titles
- Avoid paste-from-Word mess when you can
- Keep embeds through registered providers rather than huge pasted scripts when possible
- Store structured data in custom fields or a proper SEO plugin rather than buried in HTML comments
Those habits help classic content and block content alike.
How this fits a broader WordPress plan
Preparing for Gutenberg is one slice of keeping WordPress healthy: updates, PHP, security, speed and editorial workflow. If you are already planning a theme or hosting change, align the Gutenberg test with that project so you are not migrating twice. One combined project with one round of testing is cheaper and less disruptive than two separate ones a few months apart.
FAQ
Is Gutenberg required today?
No. It is optional via the plugin. Classic editing remains the default until WordPress 5.0 ships with the block editor.
Will my old posts break?
Most classic posts open in a single Classic block or convert cleanly into paragraph and heading blocks. Odd markup is where you spend cleanup time.
Should agencies force every client onto Gutenberg on day one?
No. Test per site. Some clients will want Classic Editor for months. That is a valid choice.
Does Gutenberg replace page builders?
Not automatically. Builders still power many complex layouts. Watch how each builder vendor integrates with blocks.
Test on staging, then decide
Gutenberg is close enough that every serious WordPress site should have a staging test and a written fallback. You do not need to switch production this week. You do need to know whether your theme, plugins and editors can cope. If you want help running that checklist and hardening the stack so you can turn visitors into customers without editor drama, we are happy to help.
