I asked Claude to spend time inside both the WordPress Site Editor and the block editor, click everything, break things, and report back. This is that report.
What follows is Claude's analysis of where WordPress is today, what works well, where friction remains, and how the editing experience might evolve in the future.
To find out, I spun up a fresh WordPress installation in WordPress Playground (a browser-based WordPress sandbox) and handed Claude the wheel. It explored both the Site Editor (the tool for designing your entire website) and the** block editor** (the tool for writing individual posts and pages), interacting with every panel, toolbar, menu, and setting it could find.
What follows is Claude's full, unfiltered analysis — the good, the bad, and the "who thought this was a good idea."
We're starting with the Site Editor. Then we'll move to Page Editing. Buckle up.
PART ONE: The WordPress Site Editor (Full Site Editing)
Rating: 5.6 / 10
The Site Editor — officially called the Full Site Editing interface, or FSE — is WordPress's answer to Squarespace, Webflow, and Wix. It lets you control the entire visual structure of your site: the header, footer, page templates, global colours and fonts, navigation menus, and reusable layout components called patterns. No code required. At least, that's the pitch.
How You Get There (And Why That's Already a Problem)
To open the Site Editor, you go to your WordPress dashboard → Appearance → Editor. That's it. You're in.
The problem is what greets you when you arrive. The interface opens to a dark left sidebar listing five sections — Styles, Navigation, Pages, Templates, Patterns — next to a full live preview of your website rendered in the main canvas area. It's clean. It looks professional. And if you're a new user, you have absolutely no idea what to do next.
There's no welcome message, no "here's how this works", no guided tour. The WordPress welcome panel on the dashboard does have a link that says "Open site editor", but all the explanation it gives you is: "Design everything on your site." That's not an explanation. That's a tagline.
The Problem That Defines Everything: Two Modes, One Interface
Here's the single most important thing to understand about the Site Editor, and it's also the biggest design failure: the interface has two completely different modes, and it never tells you.
Browse mode is the default. The sidebar is active, and the canvas is a non-interactive preview of your site. You can click around the sidebar to look at templates and patterns, but you can't actually edit anything in the canvas.
Edit mode is what happens when you click directly on the canvas — the toolbar at the top transforms into a full Gutenberg-style editing interface, block controls appear, and everything becomes interactive. The entire character of the UI changes.
There is no label that says "you are now in edit mode." There is no "Click to edit" prompt on the canvas. The only clue that something has changed is that the URL gains &canvas=edit at the end — information that precisely zero non-developer users will notice.
The practical result: new users spend several minutes clicking nav items in the sidebar, wondering why they can't change anything, and then accidentally click the canvas and find themselves inside an editor they didn't realise existed. Or they never click the canvas at all and conclude the Site Editor "doesn't work."
This single issue — the absence of a clear browse/edit mode indicator — is responsible for more user confusion than any other aspect of the Site Editor. It needs to be fixed.
Styles: The Global Design System (Hidden Brilliance)
The Styles section is where you control the visual identity of your entire site. It's the most feature-rich section in the Site Editor, and in many ways it's genuinely excellent. It contains:
Style Variations — The "Browse styles" option shows a grid of pre-built colour and font combination thumbnails from your theme. One click switches the entire site to a different aesthetic. This is a powerful feature executed cleanly — it's the closest the Site Editor gets to the "delight" experience that Squarespace offers.
Typography — You can pick from preset font pairings ("Typesets"), manage individual fonts, and then drill into per-element settings for Text, Links, Headings, Captions, and Buttons. You can also manage Font Sizes as presets.
Colors — A full colour palette editor, plus per-element colour assignment (Text, Background, Links, Buttons, Headings). Each element shows its current colour as a small swatch.
Background, Shadows, Layout — Controls for global background treatments, box shadow styles, and site-wide layout constraints like content width.
Blocks — Override styles for every block type globally. Change how every button on the entire site looks. Change the default paragraph font size for every post. This is theme.json editing via UI, and it's genuinely powerful.
The Style Book — Accessed via a small eye icon (👁) in the Styles section header, the Style Book opens a comprehensive design reference in the canvas: every colour in your palette shown as labelled swatches, followed by a full typographic specimen (complete alphabet, all symbols, all numbers, in your site's fonts). This is a professional-grade feature that designers and developers will love.
The catch? Virtually nobody will find it. The eye icon has no label, no tooltip on default settings, and no mention anywhere in the interface. It is hidden behind the least descriptive icon in the UI. In user testing, this kind of discoverability failure consistently results in important features going completely unused.
The deeper problem with the Styles section is its navigation. To reach per-element heading typography settings, you must click: Styles → Typography → Elements → Headings → font setting. That's four levels of nested sub-panels, each replacing the last, with no way to see multiple sections simultaneously and no overview of where you are. The breadcrumb inside the Styles panel (a small back arrow + section name) helps, but only slightly.
Navigation: A Genuine Mess
The Navigation section manages your site's menus. In our test environment, it displayed: "No Navigation Menus found."
There was no "Create one" button. No explanation. Just a void.
Even setting aside the empty state problem, Navigation is the most confusing section in the Site Editor for a structural reason: there are three different ways to edit navigation menus, none of which are clearly signposted as canonical.
You can: (1) click Navigation in the sidebar, (2) enter the Header template part and click the Navigation block inside it to get a toolbar with an "Edit navigation" button, or (3) go to Patterns → Template Parts → Header and edit from there. All three routes exist. None of them tell you the others exist. Users inevitably find one path, use it, get confused when it doesn't work quite right, and then stumble onto a different path and wonder if they're now editing something different.
The Navigation experience needs a ground-up rethink to provide a single, clear, visual editing interface — similar to how Squarespace or Wix handle menus: you see the menu, you click items, you add or remove them, done.
Pages: A Promising Addition
Pages is a relatively recent addition to the Site Editor and is a good idea in principle: it brings page management into the same environment as template and style editing, so you can work on your site holistically.
The panel provides filter tabs (All, Published, Scheduled, Drafts, Pending, Private, Trash), search and sort controls, grid/list view toggle, and an "Add Page" button. It functions well. The issue is that it creates a confusing duplication with the classic WordPress admin "Pages" section — both work, both exist, and nothing in either place tells you which to prefer or whether they're identical.
Templates: The Strongest Section
Templates is where the Site Editor is at its most impressive — and also where its most significant UX challenge lives.
The template browser is genuinely well designed. Templates appear as a grid of miniature rendered thumbnails — actual tiny screenshots of what each template looks like, complete with your current content and styles. Each thumbnail is accompanied by:
-
The template name
-
A plain-English description of what it does and when it applies
-
Author/theme attribution
The descriptions deserve special praise. "Index: Used as a fallback template for all pages when a more specific template is not defined" is a clear, helpful, jargon-light explanation. "Blog Home: Displays the latest posts as either the site homepage or as the 'Posts page' as defined under reading settings" tells you exactly what it does and how to control it. This level of contextual explanation is something the rest of the Site Editor desperately needs more of.
The Multi-Level Rabbit Hole
Editing a template is where the Site Editor's deepest usability problem emerges. Here is the actual flow a user goes through when trying to edit their site header:
-
Go to Templates and click "Index"
-
You're now in the template canvas. The header area is visible but clicking it shows a block toolbar with "Edit original" — you can't edit it directly here.
-
Click "Edit original" in the toolbar or sidebar
-
You're now in a separate editor context for the Header Template Part. The URL changes, the top bar says "Header · Template Part", and there's a "Back" button.
-
Click the Site Title text
-
The breadcrumb at the bottom of the screen reads: Template Part > Header > Group > Row > Site Title
That's four levels deep. And to get back to where you started — the main Site Editor — you must click "Back" in the toolbar, which takes you to the template, then click the WordPress logo or navigate via the browser to return to the main view. There is no single "home" button, no overview breadcrumb in the top bar, and no map of where you are in the hierarchy.
For a developer, this is manageable. For a small business owner trying to change their logo, it is bewildering.
The fix is relatively straightforward: add a clickable breadcrumb trail in the top toolbar itself — e.g. "Site Editor > Templates > Blog Home > Header" — so users can jump to any level at any time.
The Template Parts Naming Problem
A minor but persistent annoyance: in the Template sidebar's "Content" section, template parts are listed as "Template Part" and "Template Part" — identical labels, identical icons, no names. Without clicking each one, there is no way to know which is the Header and which is the Footer.
Patterns: A World-Class Library, Buried
The Patterns section might be the most pleasant surprise in the entire Site Editor. It contains 70 pre-built patterns (page sections and layout components) spread across clearly labelled categories: About, Banners, Call to Action, Contact, Featured, and more.
The pattern thumbnails are high-quality rendered previews — not abstract wireframes, but actual representative designs showing how each pattern looks. An "Upcoming events" pattern shows actual-looking event rows. A "Cover with big heading" pattern shows bold editorial typography. An "Our online store" pattern shows a product grid. Browsing the Patterns library feels like flipping through a design catalogue.
The left sidebar organises patterns helpfully: first by type (Template Parts, Header, Footer, General) and then by category. An "Add Pattern" button lets you create and save your own. A "Sync status" filter lets you separate synced patterns (changes propagate everywhere they're used) from unsynced patterns (local copies).
The problem? "Not synced" appears as a badge on most patterns, and nowhere in the UI is there an explanation of what this means or why it matters. Users who don't understand the synced/unsynced distinction — which is the majority of users — will simply ignore the badge and potentially be confused later when changing one pattern doesn't change others they expected it to.
Save, Undo, and the Absence of a Safety Net
A single "Save" button in the Site Editor publishes your changes immediately to the live site. There is no "save draft", no "preview first", no "this will be visible to all visitors — are you sure?" confirmation. For changes to a post, this is fine. For changes to the global header that appears on every page of your site, this is a significant risk.
The undo/redo buttons work within an editing session, but there is no revision history visible in the Site Editor UI. If you make a mistake, save, and close the browser, your only recovery option is to manually undo from the export zip — something that is completely impossible for a non-technical user.
The Export feature (found in the ⋮ menu when in edit mode) does let you download your entire theme with all customisations as a zip file — a unique and powerful feature that no major competitor offers. But it's tucked away, and most users will never discover it.
Site Editor Scorecard
Visual design & cleanliness 7/10
Conceptual clarity for new users 3/10
Browse mode experience 7/10
Template editing capability 7/10
Global Styles depth & power 8/10
Patterns library quality 8/10
Navigation management 3/10
Onboarding & contextual help 2/10
Save/undo/revision safety 4/10
Advanced/developer capability 7/10
Overall 5.6 / 10
Top 5 Things WordPress Should Fix in the Site Editor
Fix the mode blindness. Add an explicit "Edit" button on the canvas in browse mode and a clear mode indicator in the toolbar during edit mode. This single fix would eliminate the biggest source of new user confusion.
Add a top-bar breadcrumb for template navigation. Replace or supplement the "Back" button with a full clickable breadcrumb trail so users always know where they are in the template/template-part hierarchy and can jump to any level instantly.
Give empty states a next step. Every "No results found" and "No Navigation Menus found" panel should include a clear, prominent call-to-action button. Empty states without guidance are dead ends.
Label the Style Book. Add a text label or tooltip to the eye icon. Better yet, move it to a dedicated entry in the sidebar so it doesn't hide one of the most useful features in the entire editor.
Add a save confirmation for global changes. A lightweight "You're about to save changes to the Header — this will affect every page on your site" prompt would prevent a huge proportion of accidental site-breaking mistakes.
PART TWO: The Gutenberg Block Editor
Rating: 6.5 / 10
If the Site Editor is the tool for designing your site, Gutenberg is the tool for filling it with content. Every time you write a post or edit a page in WordPress, you're in Gutenberg. It was introduced in WordPress 5.0 in 2018 — controversially — and has been significantly improved in every release since.
The core concept is simple: everything is a block. A paragraph is a block. A heading is a block. An image, a video, a pull quote, a table, a button group — all blocks. You build content by stacking and nesting blocks, each of which can be individually styled.
The Interface at a Glance
The Gutenberg editor has four main zones:
The top toolbar — Block inserter (+), undo/redo, document overview toggle, the post title/type indicator that doubles as a command palette launcher, save/draft controls, preview options, sidebar toggle, and the all-important three-dot options menu (⋮). The design is clean and spacious, but almost entirely icon-only — there are very few text labels visible by default.
The canvas — The editing area, where blocks live. It's pleasingly minimal. Content renders approximately as it will appear on the live site (depending on your theme). The canvas width is fixed, which sometimes means the preview doesn't match the actual layout for full-width designs.
The left panel — Opens on demand to show the block inserter (which can also reveal block patterns and media), or the document overview (list view and outline). It closes when not in use, keeping the canvas clear.
The right sidebar — The most dynamic zone. When a block is selected, it shows "Block" settings for that specific block type. When no block is selected, it shows "Post" settings (featured image, excerpt, status, author, categories, tags, and more). Toggling between Post and Block tabs is how you access all metadata and formatting controls.
Inserting Blocks: Three Good Ways
One of Gutenberg's genuine strengths is the flexibility of block insertion. There are three methods, all of which work well once you know about them:
The + button in the top toolbar (or the inline + that appears when hovering between blocks) opens the block inserter panel — a full sidebar with blocks categorised into Text, Media, Design, Widgets, and more, plus a search field. This is the most discoverable method.
The slash command /) is the power-user route. Type a / at the start of a new line to get an instant popup with searchable block suggestions. Type /head and you get options for Heading 1 through Heading 6. Type /image and you get an image block. This is fast, keyboard-driven, and genuinely satisfying to use once you know it exists.
The inline + button appears as a faint + icon on the right side when hovering near any block. Click it to insert a block in that specific position. This is the most spatial method — you're placing a block exactly where you want it.
The problem: these three methods are not equally discoverable. New users will find the + button. Some will discover the slash command through the "Type / to choose a block" placeholder text that appears in empty paragraphs. Virtually no new user will find the inline hover + without being told about it.
Block Toolbars and the Fragmented Settings Problem
When you select a block, a floating toolbar appears above it. For a paragraph block, this toolbar contains: block type switcher (¶), drag handle (⠿), up/down position controls, alignment options, Bold, Italic, Link, a dropdown "more text options" (chevron ↓), and a three-dot options menu (⋮). That's a lot.
The three-dot menu on a block is a revelation and a problem simultaneously. It reveals: Copy, Cut, Duplicate, Add before, Add after, Add note, Copy styles, Paste styles, Group, Lock, Rename, Hide, Create pattern, Edit as HTML, Delete. This is a comprehensive and genuinely useful set of operations. The problem is that most of them will never be discovered by anyone who doesn't specifically look.
"Copy styles" and "Paste styles" let you apply the visual formatting from one block to another — a powerful feature with no equivalent in most content editors. "Lock" prevents a block from being moved or deleted. "Rename" lets you give a block a custom name that appears in the document outline. "Create pattern" saves the block as a reusable component. "Edit as HTML" gives direct access to the block's markup.
All of these are hidden three clicks deep: select the block, find the ⋮ icon (which is in the toolbar but easy to miss), click it, then find the option. The discoverability is very low.
The fragmentation is the bigger issue. Block settings are split across three places: the floating toolbar (basic options), the right sidebar Block tab (typography, colour, spacing, styles), and the ⋮ context menu (operations like duplicate, group, lock). There is no logical rule governing which settings appear where — it requires learning by exploration or by accident.
The Right Sidebar: Contextual but Confusing
The right sidebar switches between two tabs: "Post" and "Block."
The Post tab contains all the metadata for the document you're writing — status, publish date, author, permalink (slug), post format, template, discussion settings, categories, tags, and featured image. It also shows a word count and last-edited timestamp. This is comprehensive and well-organised.
The Block tab contains formatting settings specific to the currently selected block. For a paragraph, this means Styles (Default, Display, Subtitle, Annotation), Color (Text, Background), Typography (font size as S/M/L/XL/XXL buttons), Dimensions, and Border. For a heading, it adds a heading level switcher (H1–H6).
The sidebar is smart enough to switch automatically when you select a block, which is a good interaction design choice. The problem is that new users frequently don't notice this switching and become confused about where settings have "gone." And when no block is selected, the Block tab shows a generic message ("Select a block to see its settings") — which is accurate but not especially helpful.
The Document Overview: A Hidden Gem
The Document Overview panel — opened by the list icon in the top toolbar — deserves particular praise. It has two tabs:
List View shows every block in the document as a hierarchical tree, with nesting shown through indentation. Selecting a block in the list selects it on the canvas. This makes navigating complex documents with many nested blocks much more manageable.
Outline shows the document's heading structure, word count, character count, and reading time estimate. It also displays a visual diagram of the heading hierarchy and flags structural problems like incorrect heading levels (e.g. an H4 that jumps from an H2 without an H3 in between) — a genuinely useful accessibility and SEO feature.
Both of these features are excellent. Both are almost invisible, hidden behind an icon in the top toolbar that looks like a stacked list. Many users will write in Gutenberg for years without knowing they exist.
The Command Palette: A Power Feature Done Right
Pressing ⌘K opens the Command Palette — a searchable modal with actions across the entire editor. Type "distraction" and get "Enter Distraction free." Type "duplicate" and get the duplicate block command. This is the same paradigm used by Figma, VS Code, Linear, and Notion — and its inclusion in Gutenberg is genuinely excellent.
For experienced users, the Command Palette is faster than hunting through menus. It's accessible, keyboard-first, and elegant. The only issue is that it defaults to showing contextual block operations (Duplicate, Add before, Group, Delete) rather than editor-wide commands — which means the global commands are not immediately prominent.
View Modes: More Options Than You Think
The three-dot ⋮ Options menu reveals a set of view modes that most users never explore:
Distraction Free mode hides the toolbar and sidebar, leaving just the canvas. Ideal for long-form writing.
Spotlight mode fades all blocks except the currently active one. Good for focusing on one section at a time.
Top toolbar consolidates all block controls into a fixed bar at the top of the screen, rather than floating above each block. This is more stable visually and useful on smaller screens.
Code editor switches the canvas to raw block HTML, letting you see and edit the underlying markup directly.
The preview button offers Desktop, Tablet, and Mobile views — rendered directly in the canvas — plus "Preview in new tab" for a true live preview.
All of these are useful. All are hidden in a three-dot menu that could equally be mistaken for "more post options."
The Preferences Panel: Powerful But Buried
Under Options → Preferences, you'll find:
General — Toggle: Always open List View, Show block breadcrumbs (the hierarchy trail at the bottom of the editor), Allow right-click contextual menus, Show starter patterns.
Appearance — Toggle: Top toolbar, Distraction Free, Spotlight mode, Use theme styles (makes the editor match the live site's visual design).
Accessibility — Toggle: Contain text cursor inside block (keeps arrow-key navigation within a block, important for keyboard users), Show button text labels (replaces icons with text labels across the entire interface).
Blocks — A searchable list of every available block with checkboxes to show or hide each one from the inserter.
The "Show button text labels" option in Accessibility deserves special mention. If enabled, it transforms the icon-heavy toolbar into a labelled interface — dramatically improving the experience for new users. It's turned off by default, which is the wrong default. It should be on for the first few sessions, then offer to switch to icon-only mode once the user has enough familiarity to not need labels.
What Gutenberg Gets Right
The slash command experience is genuinely delightful once you know it. The block inserter search is fast and well-organised. The right-click context menu is a good discovery pathway for users who know their way around a desktop application. The keyboard shortcut library (⌃⌥H) is comprehensive. The autosave indicator is reassuring. The breadcrumb at the bottom of the editor ("Post > Heading 2") is useful without being intrusive. The reading time and word count in the Outline tab are the kind of quality-of-life details that writers genuinely appreciate.
And the sheer depth of what you can do with blocks — spanning from a simple paragraph all the way to nested Groups, Columns, Query Loops, Cover blocks, and custom HTML — is remarkable for a tool that is supposed to be approachable by non-technical users.
What Gutenberg Still Gets Wrong
The icon-only interface remains the single biggest barrier to entry. With "Show button text labels" turned off (the default), new users face a toolbar full of symbols and must learn by trial and error what each does. The ¶ icon for the block type switcher, the ⠿ icon for drag-to-reorder, and the ↓ chevron for "more formatting options" are not intuitive to anyone who hasn't already used the editor.
The settings fragmentation — toolbar for some things, sidebar for others, context menu for yet others — creates a scavenger hunt for users trying to find a specific option. "Why can't I change the background colour?" because it's in the sidebar Block tab, not the toolbar, and only appears when the block is selected in a specific way.
The onboarding Welcome Guide is four slides of generic information that doesn't teach you anything through interaction. It tells you blocks exist. It doesn't show you how to insert one, style it, rearrange it, or publish it. There is no interactive tutorial anywhere in the editor.
Drag-and-drop reordering becomes unreliable in complex nested layouts. Moving a block many positions requires either repeatedly clicking the up/down arrows in the toolbar (slow) or using the keyboard shortcut (fast but undiscoverable). There is no "move to position" input.
Gutenberg Scorecard
Visual design & cleanliness 8/10
Discoverability of features 5/10
Beginner ease of use 5/10
Intermediate productivity 8/10
Advanced / power-user capability 7/10
Onboarding & documentation 4/10
Error handling & feedback 4/10
Keyboard & accessibility support 7/10
Responsive preview 8/10
Overall 6.5 / 10
Top 5 Things WordPress Should Fix in Gutenberg
Enable text labels by default. Turn on "Show button text labels" for new users. Let them switch to icon-only mode after they've demonstrated familiarity. This is the single highest-impact change available.
Unify block settings into one panel. Consolidate the floating toolbar, sidebar Block tab, and ⋮ context menu into a single, logically ordered right-side panel. Group settings into Layout, Typography, Colour, Spacing, and Advanced. Stop making users look in three places for related controls.
Replace the Welcome Guide with an interactive tutorial. Guide new users through inserting a heading, adding a paragraph, uploading an image, and hitting publish — inside the actual editor, with guided steps. The current four-slide welcome modal teaches nothing through experience.
Add contextual feature discovery hints. After a user manually duplicates content (delete + retype), show a subtle tip: "Did you know? Duplicate this block with ⇧⌘D." Surface hidden features at the moment they become relevant — exactly the way Figma, Notion, and Linear do it.
Improve error messages. "Updating failed. Invalid post ID" is not an error message — it's a developer log entry. Replace generic errors with plain-language explanations and actionable suggestions ("We couldn't save your changes. [Try again] [View your auto-saved version]").
THE BIGGER PICTURE: Where Is WordPress Editing Going?
Taken together, the Site Editor and Gutenberg represent something genuinely ambitious: a vertically integrated design system where the same block components used to write a blog post are also used to design the page template that surrounds it, the global styles that govern both, and the reusable patterns that bridge the two.
That's a coherent and powerful vision. When it works — when you're smoothly moving from editing a pattern in the Patterns library to inserting it into a template to previewing it at mobile width — it feels like the future of accessible web design.
The gap between that vision and the current execution is primarily a UX gap, not a capability gap. The tools are there. The discoverability, the onboarding, the contextual guidance, the error handling, and the mode transparency are not.
WordPress is competing in 2026 against tools that have spent years and significant resources on user experience: Webflow's visual canvas, Squarespace's curated templates, Notion's block system, Wix's drag-and-drop. None of them are more powerful than WordPress. But all of them feel more comprehensible on day one.
The good news is that the fixes required are not architectural. The foundations are solid. What WordPress needs is a focused investment in the layer between the technology and the user — the tooltips, the empty state messages, the onboarding flows, the mode indicators, the contextual hints. These are not hard engineering problems. They are design and communication problems, and WordPress has the community, the talent, and the user feedback to solve them.
When that investment happens, the WordPress editing experience will be genuinely world-class. Right now, it's world-class capability wearing a "some assembly required" label — and for 40% of the web, that matters a great deal.
Analysis conducted using WordPress 7.0 with the Twenty Twenty-Five theme in WordPress Playground. All Claude observations are based on direct hands-on interaction with every panel, menu, and feature described.
Leave a Reply