Can You Build a WordPress Site With Only Core Blocks?

Yes — and further than most people think. Core blocks handle a blog or brochure site comfortably. They run out in four specific places: tables with real features. Gallery layouts, sliders, and structured data.

Here’s our credential for saying so. We sell block plugins, and our own sales pages use core blocks only. That’s policy, not accident: pages that sell things should never break. Because a plugin update did. So this isn’t a pitch that core is broken. It’s a map of where core genuinely ends. From a team that lives on both sides of the line.

What “core blocks” means

Core blocks are the ones WordPress ships with. No plugin, no theme magic — install WordPress. Open the editor (the block editor, once called Gutenberg), and they’re there. Paragraphs, headings, images, lists. Layout tools: columns, groups, cover sections, spacers. Buttons. A gallery. A table. A query loop for listing posts. Embeds for the usual outside services. And in recent versions, a Details block for simple show-hide content.

Everything below assumes current WordPress, as of August 2026. Core grows a little each release. Which is exactly why the honest question isn’t “is core good?” It’s “where does core stop?”

What core does well — a longer list than you’d guess

If your site is words, pictures and sections, core blocks are enough. Stop reading and go build.

That covers more sites than the plugin industry likes to admit. A blog, top to bottom. A small business site: hero cover, three columns of services, a contact section, buttons. Documentation. A portfolio with straightforward grids. Landing pages, honestly — ours included. The block editor’s layout tools got genuinely good over the years. Columns, groups and patterns compose into real designs without a page builder. A point we’ve argued with numbers in blocks vs page builders.

Core images even do lightboxes now — “expand on click” ships with WordPress. And because core blocks are part of WordPress itself. They cost nothing on the four surfaces that matter. No extra vendor, no extra update stream, no plugin assets. The cheapest block is the one already installed.

Patterns quietly extend this further. A pattern is a pre-arranged group of core blocks . A pricing section, a testimonial row, a hero . Shipped by your theme or copied from WordPress’s pattern directory. Patterns close the design-skill gap without adding a single plugin. If your hesitation about core is “I can’t make it look like that.” Browse patterns before you browse plugins. The look you want may already be arranged from parts you own.

The four places core runs out

1. Tables

The core Table block is a grid of text cells. That’s the whole feature list. No images or buttons inside cells. No sorting, no search, no sticky headers. No control over how columns collapse on a phone. For a simple two-column list of facts, it’s fine — we use it that way ourselves. The moment you need a pricing table, a comparison table. Or a product table, you’ve left core’s territory. The longer version is in the block-category gap audit.

2. Galleries

Core’s Gallery block arranges images in even columns, with captions and the click-to-expand lightbox. What it can’t do is layout: masonry, justified rows, mosaic tiles, carousels. Photographers and portfolio owners hit this wall first. Everyone else may never hit it.

3. Sliders

There is no core slider block. Not a limited one — none. If a design calls for a slider or carousel. Core has no answer at any quality level. (Whether the design should call for one is a fair fight. When it does, you’re installing something.)

4. Structured data

This is the invisible one, and increasingly the expensive one. Search engines and AI assistants read JSON-LD structured data . Machine-readable labels saying “this is an FAQ,” “this is a review,” “these are steps.” Core blocks emit none of it. The Details block looks like an FAQ accordion. But to a crawler it’s an unlabelled box.

Concretely: the FAQ section at the bottom of this post emits FAQPage JSON-LD. Because a block plugin renders it. Rebuilt with core Details blocks, it would look identical to you. And say nothing to a machine. If being quoted by search results and assistants matters to your site. This gap matters most of all.

The core-only workarounds, rated honestly

People don’t usually leave core the moment they hit a gap. They improvise. Some improvisations are fine indefinitely; some are debt. Here’s each gap’s workaround, rated.

Tables from columns. Three pricing “columns” built from core Columns blocks work well . That’s a pattern, not a hack, and plenty of good sites stop there. It stops working when the data does: more than a few rows. Anything needing alignment across entries, anything a phone must reflow in order. Columns reflow by column, not by row, so mobile readers get your data shuffled.

The grid gallery, accepted. The honest gallery workaround is lowering your layout ambitions, and often that’s correct. An even grid with the core lightbox serves most sites forever. Rate this one “fine” — it only fails photographers and portfolios, who know who they are.

The slider substitute. The best core workaround for a slider is deciding you didn’t need one. Stack the slides as Cover sections instead; readers scroll happily. And see everything, which sliders can’t promise. Sometimes that’s genuinely better design. When it isn’t — testimonial rotation, product showcases. Anything a client insists must move — core has nothing, and the workaround is the plugin.

Schema by hand. You can paste JSON-LD into a Custom HTML block, and it works. The debt: your FAQ now exists twice — once as visible text, once as markup. Edit an answer, forget the copy, and the two drift apart. That mismatch between page and schema is precisely what search engines distrust. Hand-written schema suits content that never changes; for anything alive. Blocks that generate schema from the visible content are the maintainable path.

Match your site to the answer

The question resolves differently by site type. Here’s the honest matrix — this table, incidentally, is our own Tableberg block doing its job.

Site type	Core blocks enough?	First gap you’ll hit
Blog or personal site	Yes	Possibly never
Small business brochure	Yes	FAQ schema for local search
Portfolio or photography	Mostly	Gallery layouts beyond a grid
Restaurant, menus, price lists	Mostly	Tables that hold more than text
Affiliate or review site	No	Comparison tables, review schema
Content-heavy commerce	No	Product tables, sliders

The pattern in one sentence: core blocks cover sites that present content. And run out on sites that compare, convert or showcase.

How to decide, without overbuying

Start core-only. Genuinely — build the site with what ships, and note where it pinches. Then add a block plugin when you can name the gap. Never install one “just in case.” Aspirational plugins age into the clutter we described in how many plugins is too many.

Then match the fix to the gap count:

• One gap: install one plugin for it — free version first. Our four each have one on WordPress.org, and free may be all you need.
• Two or more gaps: that’s when bundle math starts working. We showed the full arithmetic, losing rows included, in are plugin bundles worth it.
• No gaps: you’re done. Core-only is a feature, not a compromise. It’s how we build our own money pages.

And whichever way you go, performance is a choosing-well problem, not a block-plugin problem. We measured what block plugins cost a page in do block plugins slow down WordPress.

What leaving core costs — and how to keep it cheap

Leaving core isn’t free, and pretending otherwise would undercut everything above. Every block plugin you add costs on four surfaces. Assets it loads, security exposure it adds, updates it demands. And a vendor you now depend on. We wrote that accounting up fully in how many plugins is too many.

Three habits keep the bill small. Prefer blocks that render server-side and load assets only on pages that. Use them — ask the vendor, and view source to verify. Prefer free versions first; a gap that free features close was never a paid gap. And when you need blocks from several categories. Prefer one vendor over four — the update streams and support paths collapse. Even though the plugin count doesn’t.

One more honesty checkpoint: notice what this page is doing. The prose, headings, lists and layout you’re reading are core blocks. The decision matrix above and the FAQ below are our plugin blocks. Used exactly where core runs out. That’s the division of labour we’re recommending, practised on ourselves.

Core block questions, answered

Run a core-only acceptance test

Build the hardest ordinary page using core first. Include real content, media, and responsive constraints.

1. Define the page outcome.
2. List mandatory content types.
3. Select a suitable theme.
4. Configure global styles.
5. Create required templates.
6. Build recurring patterns.
7. Add representative content.
8. Test intended editor roles.
9. Test responsive layouts.
10. Test keyboard completion.
11. Check headings and landmarks.
12. Measure page performance.
13. Test search and navigation.
14. Document unmet requirements.
15. Add specialists only for proven gaps.

Core can cover structure, media, layout, navigation, templates, patterns, and ordinary editorial content.

Complex data, specialist interaction, or governed structured data may need another tool.

Keep the core site maintainable

• Version theme and WordPress changes.
• Preserve template ownership.
• Name and document patterns.
• Restrict unsuitable design controls.
• Train editors on approved workflows.
• Maintain suitable backups.
• Test major platform updates.
• Monitor accessibility regressions.
• Monitor performance budgets.
• Review custom CSS.
• Remove obsolete patterns.
• Record intentional exceptions.

Core-only does not mean maintenance-free. WordPress, themes, hosting, content, and integrations still change.

Know when to add one plugin

Add a plugin when a material requirement remains unmet. Choose the smallest supportable specialist.

• Confirm the missing outcome.
• Test WordPress core alternatives.
• Evaluate current plugin maintenance.
• Test representative workflows.
• Inspect stored content.
• Check deactivation effects.
• Measure added assets.
• Assign update ownership.
• Document replacement options.

A focused addition does not invalidate the core-first architecture. It closes one evidenced gap.

Record the core boundary

• Core blocks used.
• Theme capabilities used.
• Templates and template parts.
• Global style decisions.
• Patterns and owners.
• Custom CSS and purpose.
• External services.
• Known accessibility exceptions.
• Known performance exceptions.
• Unmet specialist requirements.
• Approved plugins.
• Next platform review.

This record keeps “core-only” precise. It prevents hidden custom systems from escaping maintenance.

Review the final core build

• Every template has a named owner and accepted purpose.
• Every pattern uses approved blocks and current design tokens.
• Editors can finish normal tasks without unsafe workarounds.
• Important content remains accessible across expected devices.
• Performance remains inside the site’s approved operating budget.
• Backups and recovery cover templates, content, and configuration.

The verdict

When you do hit the gaps. The four plugins in WP Block Suite exist precisely for them. Tables, galleries, sliders and schema-emitting content blocks. $299 once. Unlimited sites, 30-day money-back guarantee — and free versions to prove the gap. Is real before you spend anything.