You rebuild the same hero, the same call-to-action band, the same footer nav on every project by pasting the same markup by hand. Then the client wants the button color changed and you’re hunting through 14 pages to fix it in 14 places. WordPress has no home for reusable raw HTML. Save it once as a named snippet, insert it by token anywhere a Canvas editor accepts input, and edit the master once when it needs to change.

WordPress saves revisions for posts and pages, but not for anything a Canvas site is actually built from: your global header, footer, head code, snippets, templates, sets, or injections. Canvas pages live in a single Custom HTML block, so they sit outside revision browsing too. Make one bad edit and the only fix is a full-site backup restore, which drags everything else back with it. Version history covers all of it. Every save is recorded. Compare 2 versions side by side, then restore one. Restores are non-destructive, so a restore can itself be undone.

Copy and paste your way through 20 landing pages and the layout drifts, a CTA band falls out of sync on half of them, and a small structural change turns into an afternoon of hunting down every page you made. Define a scaffold once as a template. Create a new page from it with 1 button and the page opens in the Canvas editor, pre-filled and ready to edit. Or apply it across a batch of existing pages at once.

Adding a third-party script, a pixel, a CSS override, or a seasonal banner usually means editing functions.php or header.php, where one bad bracket can take the entire site down and there’s no undo. Save named blocks of CSS, JavaScript, or HTML instead, each with its own toggle and its own load rules. Enable them everywhere, or only where a URL pattern or category matches. Schedule a start and end date so a banner turns itself off when the sale ends, no reminder required.

One landing page needs no nav at all, another needs a campaign header, a third needs a stripped-down footer without the usual links. With a single global header and footer the usual answer is a display:none rule scoped to a page ID, or a custom page template, or a premium plugin you don’t have. Create named sets instead and assign each one by page, by category, or by URL pattern. Each set can carry a schedule too, so a seasonal header takes over for a date range and steps back on its own.

Starting a new client site usually means rebuilding the same setup by hand: copy the header from somewhere, paste the footer, re-enter the snippets one by one, recreate the templates you’ve been refining for two years. WordPress won’t carry a configuration across installs. Export the whole thing as a single file and import it on the next install. Every item is a checkbox, so you pick exactly what to move and leave the rest alone. It doubles as a backup you can actually read.

You know what a product card looks like in HTML. Writing one is 15 minutes. Connecting it to WordPress as a custom post type is a different afternoon: register_post_type in functions.php, which you’re not supposed to edit, or pile on CPT UI to register it and ACF to add fields, and then discover you still need PHP or the block editor to output anything on the front end. The whole chain breaks if you switch themes, because the registration lives in your old theme’s functions file. Canvas Pro registers the type, stores its definition in options (not the theme), handles the permalink flush on save, and outputs every entry via HTML templates you write yourself with {field:key} tokens. No PHP anywhere in that chain.