# How to use Blueprints in WordPress Studio > [!question] Lingering Questions > - How does the Studio Blueprint JSON schema compare to WordPress Playground's own blueprint schema — same format, or a fork? > - What's the full list of supported blueprint steps (plugins, themes, WP-CLI, site settings)? > [!tip] Article Ideas > - n/a — a feature tutorial; the reusable idea (repeated setup → declarative config) is already captured as a Permanent note. > [!link] Cross Reference > - [[3. Resources/Literature Notes/How Agencies Can Streamline Client Work with WordPress Studio]] — Blueprints reappears there as the agency-scaffold-standardization feature; same mechanism, different use case. > - [[3. Resources/Literature Notes/WordPress Studio Review]] — Brian Coords credits Blueprints (inherited from WordPress Playground) as one of Studio's genuinely useful pieces. > [!quote] Vocabulary > - **Blueprint** — a JSON file describing how a WordPress Studio site is built (plugins, theme, settings), so a repeated local-site setup becomes a reusable, version-controllable config. ## Metadata - Source: [[3. Resources/Readwise/Articles/How to use Blueprints in WordPress Studio]] - Author: WordPress.com - Format: vendor feature tutorial (YouTube) - Date processed: 2026-08-16 ## Author's thesis Blueprints let a developer turn a repeated local-site setup — same plugins, same theme, same settings — into a JSON file that recreates the site on demand, instead of clicking through the same setup steps every time. It matters because it reframes local-dev configuration as portable, shareable, reviewable config rather than opaque app state trapped in one machine's Studio install. ## Key arguments (≤3) 1. Blueprints are a JSON recipe format, not proprietary app state — portable and version-controllable in principle. 2. The workflow trigger is explicit: notice repetition in your local-site setups, then encode it once as a blueprint. 3. Featured/pre-built blueprints (e.g. WooCommerce) demonstrate the format before asking users to author their own. ## Claim atoms ### Blueprints are JSON recipes that build local sites > [!quote] ID:rw_transcript > Blueprints are just a JSON file that describe how a site is built in WordPress Studio. **Context & use**: ~01:10, defining blueprints under the featured-blueprint screen. Matters because it frames blueprints as portable, version-controllable config, not opaque app state. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### Codify repeated local-site setups into a blueprint > [!quote] ID:rw_transcript > if you find yourself creating the same local sites with the same plugins, same theme, same site settings over and over again, consider turning that into a blueprint **Context & use**: ~02:20, the pitch for authoring custom blueprints. Matters because it states the core workflow trigger: detect repetition, then automate it. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - **Reproducible environments encode repeated setup as config** — supported directly by the codify-repetition atom; promoted to [[3. Resources/Permanent Notes/Reproducible Environments Encode Repeated Setup as Config]]. ## Processing checklist - [ ] Compare the Studio blueprint schema against the WordPress Playground blueprint schema for divergence - [ ] Find the official Studio blueprints docs for the full step list (beyond plugin/theme/settings) - [x] Connect into the relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — declarative, reviewable environment config is a hosting/dev-stack hygiene practice. - [[3. Resources/MOCs/DevRel MOC]] — a well-documented blueprint format is exactly the kind of reusable onboarding artifact DevRel teams want to ship for contributor/agency ramp-up.