Gutenberg

Blocks are saved inside post_content as HTML comments that carry attributes, for example <!-- wp:image {"id":88,"sizeSlug":"large"} -->. WordPress parses them with parse_blocks() and renders each through its save markup or a PHP render callback. The Gutenberg plugin ships ahead of core, so its version number differs from the WordPress release you run.

To audit use, search the database: SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%<!-- wp:%' AND post_status = 'publish'. A count near zero on an old site means most content is still classic.

A travel blog with 640 posts upgrades its theme and notices that 590 of them have no block comments. They are single Classic blocks. The remaining 50 posts, written last year, each contain between 6 and 30 blocks, including 11 Gallery blocks that now render with a different gap after a core update.

The editor converts the 10 most visited posts to blocks one at a time, checks each on mobile, and leaves the archive alone.

Gutenberg is the current editor, while the classic editor is the earlier single-field editor. Gutenberg also has a plugin version that previews features before they reach core. Neither one decides your site's design; that belongs to the theme, and in a block theme the same blocks also build templates.

Installing the Gutenberg plugin on production to test features. Treating the plugin version as the WordPress version. Pasting raw HTML into a Paragraph block instead of using a Custom HTML block. Relying on a block from a plugin that you later remove, leaving a block that says it has unexpected content. Not adding show_in_rest to a custom post type and wondering why it opens in the old editor.

Try new blocks on a staging copy rather than the plugin on production. Keep a short list of the third-party blocks your posts depend on, because deactivating the plugin breaks them. Use reusable patterns for repeating layouts instead of copy-pasting groups.