Anyone searching for “best WordPress theme frameworks” a decade ago ran into a different landscape than the one that exists now. Several once-popular Foundation and Bootstrap starter kits from that era have gone quiet or been archived outright, and the ecosystem has consolidated around a smaller set of actively maintained projects. That is arguably healthier for anyone choosing today, since it cuts down on the risk of building a client site on something that quietly stops receiving updates a couple of years in. It is still worth checking a project’s actual commit history before committing to it rather than trusting a five-year-old blog post’s recommendation, this one included, since the landscape keeps shifting.

A starter theme is not a theme in the way most WordPress users mean the word. It has no polished design, no demo content, no options panel promising a finished site in twenty minutes. What it offers instead is a clean scaffold: the template hierarchy wired up correctly, sane defaults for things like navigation menus and post formats, and none of the bloat that comes bundled into a commercial theme built to look good in a screenshot. For a developer building a custom site from scratch, that is exactly the point. Starting from a blank style.css file means reinventing decisions that have already been solved well; starting from a bloated multipurpose theme means stripping out far more than you keep. A good starter theme sits in the middle.

Below are the starter themes and frameworks developers actually reach for going into 2026, what each one assumes about your workflow, and one that used to be a common recommendation but is worth avoiding now.

Underscores (_s)

Underscores, usually written as _s, is Automattic’s own answer to “give me nothing extra.” It has been the reference starting point for WordPress theme development for over a decade, and it is still actively maintained on GitHub under the Automattic organization. The project describes itself plainly: a theme meant for hacking, not a theme meant for using as-is.

What you actually get is a lean set of HTML5 templates with generous inline comments explaining what each file does and why, a working mobile navigation toggle, sample layouts with and without a sidebar, and template tags that cut down on repeated code across files. There is no build process forced on you and no opinion about Sass versus plain CSS beyond what you choose to add yourself. That minimalism is the whole appeal. A developer who wants full control over their tooling, their CSS methodology, and their JavaScript bundler, without a starter theme dictating any of it, tends to land on Underscores first and often stays there. The tradeoff is that you are setting up your own build pipeline from zero, which is more setup time upfront than a framework-based starter theme requires.

Sage by Roots

Sage sits at the opposite end of the spectrum from Underscores: instead of giving you a blank canvas, it hands you an opinionated, modern development stack and expects you to work within it. The current version pairs Laravel’s Blade templating engine with Tailwind CSS and Vite for the build process, with an Acorn layer providing Laravel-style service providers and PSR-4 autoloading inside a WordPress theme. If that stack sounds familiar, it is deliberately borrowing patterns from Laravel application development and bringing them into WordPress theming.

The payoff for buying into that opinion is real: Blade’s template inheritance and component syntax is considerably cleaner than raw PHP template partials once a theme grows past a handful of templates, Tailwind’s utility classes cut down on hunting through stylesheets, and Vite’s hot module replacement makes the local development loop noticeably faster than manually refreshing a browser tab. Sage also generates theme.json automatically from its Tailwind config, which keeps the block editor’s color and typography options in sync with the front-end design system instead of maintaining two separate sources of truth. The cost is a steeper initial learning curve for a developer who has not used Blade or Tailwind before, and a genuine dependency on Composer and Node both being part of the deployment workflow, which not every hosting environment makes painless.

WP Rig

WP Rig positions itself specifically around performance and accessibility as first-class concerns rather than afterthoughts bolted on at the end of a build. It bundles a starter theme with a full build toolchain, esbuild for JavaScript and TypeScript, Lightning CSS for stylesheet processing, plus linting through PHP CodeSniffer, ESLint, and Stylelint wired in from the start so code quality checks are part of the default workflow rather than something a team has to configure themselves later.

The project is community-maintained rather than tied to a single company, and it has kept shipping releases and community events, including a scheduled appearance at WordCamp US, which is a reasonable signal that it has not gone quiet the way a lot of starter theme projects eventually do. For a developer who wants performance and accessibility baked into the tooling defaults, rather than something checked with a separate audit pass at the end, WP Rig is worth evaluating specifically for that reason. The instant refresh workflow, using either hot module replacement or BrowserSync depending on setup, also makes it one of the more pleasant starter themes to actually develop against day to day.

Understrap

Understrap fills a specific gap: developers who need Bootstrap’s grid system, components, and utility classes but do not want to bolt Bootstrap onto a random commercial theme by hand. It combines Underscores’ PHP and JavaScript foundation with Bootstrap’s HTML, CSS, and JavaScript, currently offering both Bootstrap 4 and 5 depending on which a project needs, along with the Sass source files so the design can be customized rather than left as stock Bootstrap styling.

This is a good fit for agency work where a client or design team already thinks in Bootstrap terms, or for developers coming from a general front-end background who are more comfortable with Bootstrap’s component patterns than with building a design system from scratch. The project has stayed active, with thousands of commits and ongoing issue and pull request activity, plus a documentation site and a paid course for teams that want structured onboarding rather than reading source code cold. The obvious tradeoff is that any site built on Understrap inherits Bootstrap’s visual fingerprint unless a developer puts real effort into overriding it, which is either a feature or a limitation depending on the project.

Timber

Timber is not a starter theme in the traditional sense; it is a library that changes how theme templates get written in the first place. Instead of mixing PHP logic directly into HTML template files, Timber lets a developer write templates in Twig, a templating language that enforces a cleaner separation between what the data layer does and what the markup looks like. As of version 2.0, Timber requires Composer for installation, having moved away from distribution as a WordPress.org plugin.

The appeal is strongest for developers who have worked with Twig or a similar templating language elsewhere, since the separation of concerns Timber enforces tends to keep template files far more readable as a project grows past a handful of pages. It pairs naturally with a starter theme rather than replacing one outright, so a common pattern is combining Timber’s templating approach with a minimal base like Underscores rather than treating Timber as a complete starting point on its own. The project remains actively maintained, now requiring PHP 8.2 or newer for its current major version, which signals ongoing investment rather than legacy maintenance mode.

Building a block theme instead of a classic PHP-template theme

Everything above assumes a classic, PHP-template-driven theme, which is still where most custom development happens, but it is worth addressing the other path directly: full site editing and block themes, where layout lives in HTML template files and theme.json rather than PHP templates. Underscores, Sage, and the rest of the classic starter theme ecosystem were not built with that model in mind, and a developer specifically targeting a block theme needs a different starting point.

The most reliable current option here is the official Create Block Theme plugin, maintained by WordPress core contributors and available directly through WordPress.org. Rather than scaffolding files on your local machine before a project starts, it works from inside the block editor itself: generate a blank theme, clone an existing one as a starting point, or export a child theme, all while managing theme.json configuration, style variations, and font assets through a UI instead of hand-writing every value. It is worth calling out because an older project in this same space, Blockbase, a parent theme built specifically for early full site editing work, was archived in 2025 and should not be treated as a current recommendation even though older tutorials still point to it. For any developer starting a block theme project, Create Block Theme is the tool actually being maintained by the team building the underlying editor, which matters more than usual in a part of WordPress that is still evolving quickly.

A quick option worth knowing about: WP-CLI scaffolding

For developers who already live in the terminal, WP-CLI ships a built-in scaffold command that generates a starter theme without needing to clone anything from GitHub first. Running wp scaffold _s themename against a local WordPress install produces an Underscores-based theme pre-configured with the site’s own name and text domain already filled in, which saves the handful of manual find-and-replace steps that setting up Underscores from its own repository normally requires. It is a small convenience, but for anyone who spins up new theme projects often, skipping that setup friction adds up over a year of projects.

One that is worth knowing to avoid

FoundationPress used to show up in nearly every list like this one, pairing Zurb’s Foundation framework with a WordPress starter theme structure. It is worth mentioning specifically because so much old advice still points developers toward it. The project’s own repository was archived in 2019 and its creator has publicly recommended against building on it further, since Zurb Foundation itself stopped active development. A developer who stumbles onto an old tutorial or forum thread recommending FoundationPress today should treat that advice as outdated and pick one of the actively maintained options above instead.

What actually matters when evaluating a starter theme

Star counts and download numbers are a weak signal on their own. A project with a huge number of stars from years ago but no commits in the last year is a worse bet than a smaller, actively maintained one, since WordPress core itself keeps shifting underneath every theme, most recently with the ongoing push toward full site editing. Checking the actual commit history and recent release dates before adopting anything is worth the two minutes it takes, and it would have saved a lot of developers from building on FoundationPress well past the point it stopped being a safe choice.

Documentation quality matters more than it gets credit for. A starter theme with thin or outdated documentation costs real time later, when a developer six months into a project needs to remember a decision a starter theme’s file structure made for them and there is nothing written down explaining why. Underscores and Sage both do this well, in different ways: Underscores through generous inline comments in the code itself, Sage through a maintained documentation site kept current with each major version.

It is also worth checking how a starter theme handles updates to its own dependencies. A theme like Sage that depends on Composer packages and npm modules needs a plan for keeping those dependencies patched over a project’s lifetime, which is a different maintenance burden than Underscores, where there is effectively nothing external to update once the theme is generated. Neither approach is wrong, but picking one without accounting for that tradeoff means discovering it the hard way during a security audit a year or two into a client’s site being live.

Mistakes worth avoiding once you have picked one

The most common mistake is treating a starter theme as a finished product and shipping it with minimal customization, which produces sites that all look faintly the same because they never diverged far from the starter’s default markup and spacing. A starter theme is a foundation specifically because it is meant to be built on top of extensively, not a shortcut to skip design work entirely.

The second common mistake is picking a framework-heavy option like Sage or Understrap for a genuinely simple project that never needed the extra tooling in the first place. Setting up Composer, Node, a build pipeline, and a templating engine for a five-page brochure site adds real overhead that a plain Underscores-based build would have avoided entirely. Matching the starter theme’s complexity to the project’s actual complexity, rather than defaulting to whichever tool is currently trendy, saves real time across a portfolio of client work.

A third mistake shows up later in a project’s life: forgetting that a starter theme’s generated code is a starting point, not a dependency to keep tracking upstream. Once Underscores or Sage has scaffolded a theme, that code belongs to the project from that point forward; there is no ongoing “update the starter theme” step the way there is with a typical plugin. Some teams mistakenly try to keep pulling changes from the original starter theme repository into an already-customized project, which usually creates merge conflicts with no real benefit, since the whole point of a starter theme is that you already took what you needed and diverged from there.

Picking between them

The right starting point depends less on which project has the most GitHub stars and more on how a developer actually wants to work. Someone who wants zero opinions imposed on their build tooling, CSS methodology, or JavaScript setup should start with Underscores and build everything else themselves. Someone who wants a modern, batteries-included stack with Blade, Tailwind, and Vite already wired together, and who does not mind Composer and Node both being part of the deployment pipeline, fits well with Sage. A developer prioritizing performance and accessibility tooling from the first commit should look at WP Rig. Bootstrap-based agency work points toward Understrap, and anyone who wants Twig’s cleaner template syntax layered on top of whatever base theme they choose should bring in Timber rather than expecting a single package to cover everything.

None of these choices are permanent either. A theme built on Underscores today can migrate template logic to Timber later without starting over, and a team that outgrows Bootstrap’s visual conventions in Understrap can gradually replace the framework’s CSS while keeping the underlying PHP structure intact. Starting with any actively maintained option beats over-planning the perfect starter theme choice before writing a single template file.

Team size and skill mix also deserve real weight in this decision, more than most comparisons give them credit for. A solo developer or a two-person agency team can absorb Sage’s Composer and Node dependency chain without much friction, since one or two people can keep that tooling current without a formal process. A larger team, or one with contractors rotating in and out of projects, often does better with something closer to Underscores, where the barrier to a new contributor opening a file and understanding what is happening is lower, precisely because there is less abstraction standing between the markup and the PHP generating it.

Long-term maintenance plans matter just as much as the initial build. A theme handed off to an in-house marketing team after launch, one without dedicated developer support going forward, is generally better served by the simpler end of this list, since every layer of build tooling is one more thing that can silently break when nobody is watching for it. A theme that will stay under active developer ownership for years can absorb the more opinionated, tooling-heavy options without that same risk, and often benefits from the productivity gains those tools provide once the team is past the initial learning curve.

None of this needs to be decided in isolation from the rest of a project’s stack either. A team already running Laravel elsewhere in its work naturally gets more value out of Sage’s shared conventions than a team with no prior Laravel exposure would. A team already comfortable maintaining Composer dependencies for other projects will find that part of Sage or Timber’s setup far less daunting than a developer encountering Composer for the first time on a WordPress project specifically. Weighing a starter theme against the tools already in a team’s regular rotation, rather than evaluating it purely on its own merits, tends to produce a better long-term fit than picking whichever option ranks highest on a comparison list.